Cloud Security Assessment Checklist: What to Test Before Your Next Audit

Cloud environments operate under a shared responsibility model — your cloud provider secures the infrastructure, but you are responsible for everything you deploy on top of it. Identity configurations, network segmentation, data encryption, logging, and access controls are all your problem. And they are exactly the areas where misconfigurations create the breaches that make headlines.

A cloud security assessment systematically evaluates these areas before an auditor, attacker, or regulator finds the gaps first. Whether you are preparing for SOC 2, responding to a client security questionnaire, or simply trying to understand your actual exposure, this checklist provides the structure to evaluate your AWS or Azure environment methodically.

Why Cloud Environments Need Dedicated Security Assessments

Traditional network security assessments were designed for on-premise infrastructure with clear perimeters: firewalls, switches, physical segmentation. Cloud environments have none of these. Instead, security boundaries are defined by IAM policies, security groups, virtual network configurations, and service-level settings that can change with a single API call.

The speed of cloud provisioning is both its advantage and its risk. A developer can spin up a publicly accessible database, an overly permissive IAM role, or an unencrypted storage bucket in minutes — often without anyone in security knowing it happened. Cloud security assessments catch these issues by reviewing configurations against established benchmarks and testing whether controls actually work as intended.

This is not theoretical. In our architecture hardening engagements, we consistently find that organizations running production workloads in AWS or Azure have configuration drift, orphaned resources with excessive permissions, and gaps between their documented security policies and their actual cloud configurations.

The Cloud Security Assessment Checklist

This checklist is organized by security domain. Each section includes the key areas to evaluate, the specific configurations to test, and what auditors and attackers look for.

1. Identity & Access Management (IAM)

IAM is the front door to your cloud environment. If identity controls are misconfigured, nothing else matters — an attacker with the right credentials or role assumption can bypass every other control you have in place.

• Enforce MFA everywhere. Multi-factor authentication must be enabled on all human accounts, with hardware tokens or FIDO2 keys for privileged accounts. MFA on the root account is non-negotiable — a compromised root account means total environment takeover.
• Audit IAM policies for least privilege. Review every IAM policy, role, and group. Look for wildcard permissions (*:*), unused permissions, and policies that grant administrative access to non-administrative users. AWS IAM Access Analyzer and Azure AD Access Reviews are your starting tools.
• Review service accounts and machine identities. Service accounts, Lambda execution roles, and managed identities often accumulate permissions over time. Audit each one for necessity and scope. Remove unused service accounts and rotate credentials on active ones.
• Eliminate long-lived access keys. Static access keys are the cloud equivalent of passwords taped to monitors. Use IAM roles with temporary credentials via STS (AWS) or managed identities (Azure) wherever possible. If access keys are required, enforce rotation policies and monitor for usage anomalies.
• Review cross-account and federated access. Document all cross-account role assumptions and federated identity configurations. Each trust relationship is a potential lateral movement path for attackers.

2. Network Security

Cloud network security replaces physical segmentation with virtual constructs — VPCs, subnets, security groups, network ACLs, and route tables. Misconfigurations here create direct paths from the internet to your internal resources.

• Audit VPC/VNET segmentation. Production, staging, and development environments should be in separate VPCs or VNETs with controlled peering. Flat network architectures allow lateral movement from any compromised resource to every other resource.
• Review security groups and NSGs. Enumerate all security group rules. Look for rules allowing inbound traffic from 0.0.0.0/0 on management ports (SSH/22, RDP/3389), database ports (3306, 5432, 1433), or any port range broader than required. Each rule should map to a documented business justification.
• Public exposure audit. Identify all resources with public IP addresses, public-facing load balancers, and services exposed through API gateways. Compare this inventory against your intended public attack surface. Every publicly accessible endpoint should be intentional, documented, and monitored.
• DNS and domain configuration. Check for dangling DNS records pointing to decommissioned resources (subdomain takeover risk), insecure DNS zone transfer settings, and DNSSEC configuration where applicable.
• Private connectivity. Evaluate use of VPC endpoints (AWS) or Private Link (Azure) for service-to-service communication that does not need to traverse the public internet.

3. Data Protection

Data protection in the cloud spans encryption, key management, access controls on storage services, and backup security. This is the domain where a single misconfiguration can expose millions of records.

• Encryption at rest. Verify that all storage services — S3 buckets, EBS volumes, RDS instances, Azure Storage accounts, Azure SQL databases — have encryption at rest enabled. Use customer-managed keys (CMKs) rather than provider-managed keys for regulated data.
• Encryption in transit. Confirm TLS 1.2+ enforcement on all endpoints, load balancers, and API gateways. Check for internal service-to-service communication that may be unencrypted within the VPC — not all internal traffic is automatically encrypted.
• Key management. Review KMS (AWS) or Key Vault (Azure) configurations. Audit key rotation policies, access policies on key usage, and ensure separation between key administrators and key users. A compromised key management service undermines all your encryption.
• Storage access controls. Audit S3 bucket policies, Azure Blob access levels, and storage account shared access signatures. Block public access at the account level unless explicitly required. Review bucket policies for overly permissive principal specifications.
• Backup security. Verify that backups are encrypted, stored in a separate account or subscription (ransomware resilience), and that backup retention policies meet your compliance and recovery requirements.

4. Logging & Monitoring

Without comprehensive logging and monitoring, you cannot detect attacks, investigate incidents, or demonstrate compliance. This is the area most commonly underconfigured in the environments we assess through our security testing engagements.

• Enable comprehensive audit logging. AWS CloudTrail must be enabled in all regions with management and data event logging. Azure Activity Log and diagnostic settings should capture all control plane and relevant data plane operations. Logs must be stored in a centralized, tamper-resistant location.
• SIEM integration. Cloud logs should flow into your SIEM or security analytics platform with retention periods that meet both operational and compliance requirements. Typical minimums are 90 days hot storage and one year cold storage.
• Alerting on critical events. Configure real-time alerts for: root account usage, IAM policy changes, security group modifications, failed authentication attempts, console logins from unexpected geolocations, and resource creation in unused regions.
• Flow logs and network monitoring. Enable VPC Flow Logs (AWS) or NSG Flow Logs (Azure) for network traffic visibility. These logs are essential for incident investigation and detecting lateral movement, data exfiltration, and command-and-control communication.
• Log integrity. Ensure log files cannot be modified or deleted by the accounts being monitored. Use CloudTrail log file validation, S3 Object Lock, or Azure immutable blob storage to guarantee log integrity for forensic and compliance purposes.

5. Compliance Alignment

Cloud security assessments should map findings to the compliance frameworks relevant to your organization. This turns technical findings into audit-ready evidence and helps prioritize remediation based on regulatory requirements.

• SOC 2 mapping. Map your cloud security controls to SOC 2 Trust Services Criteria — particularly CC6 (Logical and Physical Access Controls), CC7 (System Operations), and CC8 (Change Management). Document control evidence directly from cloud configurations and monitoring outputs.
• CIS Benchmarks. Run your environment against the CIS Benchmark for your cloud provider (CIS AWS Foundations Benchmark, CIS Azure Foundations Benchmark). These benchmarks provide specific, testable configuration recommendations with clear pass/fail criteria. AWS Security Hub and Azure Security Center can automate portions of this evaluation.
• Regulatory requirements. If you operate in regulated industries — technology, financial services, or healthcare — map cloud controls to industry-specific requirements. HIPAA requires encryption and access logging for PHI. PCI DSS requires network segmentation and vulnerability scanning for cardholder data environments.
• Evidence collection. Document your assessment findings with screenshots, configuration exports, and test results. Auditors want evidence, not assertions. Build a library of compliance artifacts that can be refreshed with each assessment cycle.

6. Incident Response Readiness

Your cloud environment is not secure if you cannot detect, contain, and recover from incidents within it. Incident response readiness testing validates that your team and processes can handle a cloud-specific security event.

• Cloud-specific runbooks. Generic incident response plans do not address cloud-specific scenarios. Develop runbooks for: compromised IAM credentials, exposed storage buckets, cryptomining on compute resources, and lateral movement between cloud accounts. Each runbook should include specific CLI commands and console steps for containment.
• Forensic capability. Verify that you can capture and preserve forensic evidence from cloud resources — disk snapshots, memory dumps from EC2/VM instances, network flow logs, and API call history. Test this capability before you need it.
• Communication plans. Define notification procedures for cloud security incidents including internal escalation paths, customer notification timelines (if applicable), and regulatory reporting requirements. Cloud incidents can affect multiple services and customers simultaneously — your communication plan should account for this scale.
• Isolation procedures. Test that you can rapidly isolate compromised resources without disrupting production services. This means having pre-built security group rules for quarantine, IAM policies for credential revocation, and automation for common containment actions.

Common Misconfigurations We Find in Cloud Assessments

After conducting cloud security assessments across dozens of AWS and Azure environments, certain misconfigurations appear in nearly every engagement. These are the issues that create real exposure, not theoretical risks:

• S3 buckets and Azure Blob containers with public access. Despite years of awareness, publicly accessible storage remains one of the most common findings. Organizations enable public access for a specific use case and never restrict it, or legacy bucket policies override account-level public access blocks.
• Overly permissive IAM roles. Developers create IAM roles with administrative access during development and never scope them down for production. We routinely find Lambda functions, EC2 instances, and ECS tasks running with AdministratorAccess or PowerUserAccess policies attached.
• Missing MFA on root and privileged accounts. The root account in AWS and Global Administrator in Azure are the keys to the kingdom. Missing MFA on these accounts is a critical finding in every compliance framework and the first thing an attacker checks after credential compromise.
• Unencrypted databases and storage. Default configurations for some cloud database services do not enable encryption at rest. Organizations that provision databases without explicit encryption settings end up with unencrypted production data — a direct compliance violation for SOC 2, HIPAA, and PCI DSS.
• CloudTrail or Activity Log gaps. Logging is enabled in the primary region but not in all regions, or data events are not captured, leaving blind spots that attackers exploit. Without comprehensive logging, incident investigation becomes guesswork.
• Default security group rules. The default security group in AWS allows all outbound traffic and all inbound traffic from resources in the same security group. Organizations that use the default security group without modification have no network segmentation between resources.

Turning Assessment Findings Into Action

A checklist identifies gaps. What matters is closing them. Prioritize remediation based on exploitability and blast radius — a publicly exposed S3 bucket with sensitive data is a higher priority than a missing tag policy, regardless of what your compliance framework says about both.

Build a remediation roadmap with clear ownership, deadlines, and verification steps. Automate configuration enforcement using AWS Config Rules, Azure Policy, or infrastructure-as-code tools like Terraform so that fixed configurations cannot drift back to insecure states.

Schedule assessments quarterly or after significant infrastructure changes. Cloud environments evolve continuously — a point-in-time assessment provides confidence at the time of the assessment, but configurations drift as teams provision new resources, modify policies, and deploy new services.

Fortress MSSP conducts cloud security assessments that combine automated configuration scanning with manual penetration testing and architecture review. We test whether your controls actually work, not just whether they exist in a policy document. Our assessments map findings to your compliance requirements and deliver prioritized remediation guidance with specific implementation steps.

Schedule a cloud security assessment to understand your actual cloud exposure and build a remediation plan before your next audit.