A deployment can introduce security risks even when the application code itself is secure.

A new cloud resource, an overly permissive IAM role, an exposed database, or a missing logging configuration can create an attack path that was not present before the deployment.

This is why a cloud security review should happen before infrastructure reaches production—not after a vulnerability is discovered.

The following 10-point checklist focuses on the areas most likely to introduce cloud security risks during deployment.

1. Review IAM Permissions

Start with the identities that the deployment will create or modify.

Check whether:

• Users have only the permissions required for their roles
• Service accounts are limited to the resources they need
• Deployment pipelines are not using excessive privileges
• New roles do not grant unnecessary administrative access
• Temporary permissions have an expiration or removal process

A common mistake is giving deployment accounts broad permissions because it makes automation easier.

The safer approach is to give the pipeline only the permissions required to deploy and manage the intended resources.

Before deployment, ask: If this identity were compromised, what could it change?

That question often reveals excessive privilege faster than simply reviewing a list of IAM roles.

2. Check for Publicly Exposed Resources

Public exposure should be intentional.

Review the deployment for resources such as:

• Databases
• Object storage
• Virtual machines
• Kubernetes services
• Management interfaces
• APIs
• Load balancers

A resource being reachable from the internet does not automatically mean it is insecure. Public-facing applications obviously need some degree of internet accessibility.

The concern is unnecessary exposure.

For example, a public web application may need internet access, while its database should generally remain behind appropriate network controls.

Before deployment, map which resources need to be public and which should remain private.

3. Validate Network Security Rules

Review firewall rules, security groups, network security groups, and equivalent controls.

Look specifically for:

• Open ports that are not required
• Broad source ranges
• Administrative ports exposed to the internet
• Unnecessary inbound rules
• Unrestricted outbound access where it creates risk
• Rules copied from development environments

Rules such as allowing administrative access from 0.0.0.0/0 deserve immediate scrutiny.

The question is not whether the connection works.

It is whether the connection is necessary and appropriately restricted.

4. Verify Encryption

Check whether sensitive information is protected both during transmission and while stored.

Review:

• Databases
• Object storage
• Block storage
• Backups
• Application traffic
• Secrets
• Data transfers

Encryption should also be considered alongside key management.

Having encryption enabled is useful, but security teams should understand:

• Which keys are being used
• Who can access them
• How keys are managed
• Whether key permissions are overly broad

Do not treat encryption as a substitute for access control.

An encrypted database can still be accessed by an identity that should never have had permission to reach it.

5. Check Secrets and Credentials

Deployment pipelines frequently introduce credentials into cloud environments.

Look for:

• API keys
• Passwords
• Access tokens
• Private keys
• Database credentials
• Service account credentials

These should not be stored directly in application code, configuration files, container images, or source repositories.

Use appropriate secrets-management capabilities provided by your cloud platform or application architecture.

Also check whether existing credentials are being rotated and whether unused credentials can be removed.

A secret that has been committed to source control should be treated as potentially compromised, even if it was later deleted.

6. Confirm Logging and Monitoring

A secure deployment should generate enough visibility to detect and investigate suspicious activity.

Before deployment, verify that relevant logging is enabled for:

• Authentication
• Administrative actions
• API activity
• Network activity where appropriate
• Configuration changes
• Access to sensitive resources

Then verify that important events actually reach the organization’s monitoring or security platform.

Simply enabling logs does not guarantee that someone will detect an attack.

Security teams should know:

What happens when a high-risk event occurs?

For example, if someone changes a storage bucket from private to public, does anyone receive an alert?

7. Review Cloud Storage Permissions

Object storage is particularly vulnerable to accidental exposure because access can often be changed through policies and permissions.

Before deployment, check:

• Public access settings
• Bucket or container policies
• Object-level permissions where applicable
• Encryption
• Data classification
• Retention requirements
• Cross-account or external access

Pay particular attention to storage used for:

• Customer information
• Backups
• Application exports
• Logs
• Internal documents
• Database dumps

A storage resource created for temporary testing can become a permanent security problem if it is not reviewed before production deployment.

8. Scan Infrastructure-as-Code

If your organization uses Terraform, CloudFormation, ARM/Bicep, or another Infrastructure-as-Code approach, security checks should happen before the infrastructure is deployed.

Review the code for:

• Public resources
• Overly permissive IAM
• Open firewall rules
• Hardcoded secrets
• Missing encryption
• Insecure defaults
• Unrestricted network access

Infrastructure-as-Code provides an important advantage: security issues can be identified before the configuration reaches the cloud environment.

Automated scanning can make this process part of the deployment pipeline rather than relying entirely on manual reviews.

9. Check Vulnerabilities and Patch Status

Infrastructure security is not only about configuration.

Review the software running on the resources being deployed.

Depending on the workload, this can include:

• Operating systems
• Container images
• Application dependencies
• Virtual machine packages
• Kubernetes components
• Third-party libraries

Look for known vulnerabilities that could create unnecessary risk.

Container images deserve particular attention because an outdated base image can introduce vulnerabilities before the application is even deployed.

The objective is not necessarily to eliminate every vulnerability before every release.

It is to identify significant risks, understand their impact, and ensure that exceptions are deliberate.

10. Verify Backup and Recovery Controls

A deployment can be technically secure and still create serious business risk if critical data cannot be recovered.

Before production deployment, confirm:

• Critical data is backed up
• Backup policies are appropriate
• Backups are protected from unauthorized access
• Recovery procedures exist
• Recovery has been tested
• Retention requirements are understood

A backup that exists but cannot be restored when needed does not provide meaningful resilience.

For critical workloads, test recovery rather than simply checking whether a backup job is configured.

A Simple Pre-Deployment Security Gate

The 10 checks can be converted into a simple deployment gate:

Security Check	Question to Ask
IAM	Does every identity have only the access it needs?
Public exposure	Are all internet-facing resources intentional?
Network	Are firewall and security rules appropriately restricted?
Encryption	Is sensitive data protected at rest and in transit?
Secrets	Are credentials securely stored and managed?
Monitoring	Can we detect important security events?
Storage	Are buckets and containers protected from unintended access?
IaC	Has infrastructure code been security-tested?
Vulnerabilities	Are known high-risk vulnerabilities addressed?
Recovery	Can critical data and workloads be recovered?

A deployment should not necessarily be blocked because every finding is rated as critical.

Instead, establish clear severity levels and an exception process.

For example:

Critical → Fix before deployment

High → Fix or formally approve an exception

Medium → Track remediation

Low → Accept or address through normal maintenance

This gives engineering teams a practical security process instead of turning security review into a blanket deployment blocker.

What Should Be Automated?

The more frequently your organization deploys, the less practical manual security reviews become.

Automate checks wherever possible.

Examples include:

• Infrastructure-as-Code security scanning
• IAM policy analysis
• Public resource detection
• Vulnerability scanning
• Container image scanning
• Secrets detection
• Encryption checks
• Configuration compliance
• Security alerts

Automation is particularly valuable for identifying configuration drift.

A resource may have passed the security review during deployment but become risky later because someone manually changes its configuration.

Don’t Limit the Audit to Production

Development and staging environments often receive less security attention than production.

That can create a problem.

Attackers may target development environments because they can contain:

• Production data copies
• API credentials
• Source code
• Service account credentials
• Internal network access

Security reviews should therefore cover environments that contain sensitive information or provide pathways into production.

A development environment does not need exactly the same controls as production.

But it should not become an uncontrolled security blind spot.

Who Should Own the Pre-Deployment Security Review?

Cloud security should not be treated as the responsibility of one team.

A practical model involves:

Developers → Application and dependency security

DevOps/Platform teams → Infrastructure and deployment configuration

Cloud teams → IAM, networking, storage, and cloud architecture

Security teams → Security policies, risk assessment, monitoring, and incident readiness

Business owners → Risk acceptance and business impact

This shared responsibility is particularly important in multi-cloud environments where different teams may manage AWS, Azure, and GCP resources.

Frequently Asked Questions

What should I check before deploying to the cloud?

At minimum, review IAM permissions, public exposure, network rules, encryption, secrets, logging, storage permissions, Infrastructure-as-Code, vulnerabilities, and backup/recovery controls.

Should cloud security audits happen before every deployment?

For significant production deployments, security checks should be integrated into the deployment process. Automated controls can handle routine checks, while manual review can be reserved for high-risk changes.

What is the most important cloud security check before deployment?

There is no single control that protects every environment. However, excessive IAM permissions and unintended public exposure are two high-impact areas that should receive particular attention.

Can cloud security audits be automated?

Yes. Infrastructure scanning, vulnerability scanning, IAM analysis, secrets detection, configuration monitoring, and compliance checks can all be automated to varying degrees.

What happens if a security issue cannot be fixed before deployment?

Use a formal risk-exception process. Document the issue, business justification, compensating controls, owner, and target remediation date. High-risk exceptions should require appropriate approval rather than being silently ignored.

Final Thoughts

A pre-deployment cloud security audit does not need to be complicated.

The objective is to catch the issues most likely to create unnecessary exposure before they reach production.

Start with the basics:

Who has access? What is exposed? What can communicate with what? Is sensitive data protected? Can you detect suspicious activity? Can you recover if something goes wrong?

Then automate these checks wherever possible.

The strongest cloud security process is not the one that produces the longest checklist.

It is the one that consistently catches risky changes before they become production incidents.