Why You Need a Checklist

In cloud security, creativity is a liability. While threat actors continuously invent novel ways to breach environments, defending those environments relies on the rigorous, unglamorous, and consistent application of established controls. You do not get hacked because you lacked an esoteric, military-grade AI defense mechanism. You get hacked because an engineer temporarily disabled Multi-Factor Authentication (MFA) on a root account and forgot to turn it back on.

Complex systems fail in predictable ways. In aviation, checklists prevent experienced pilots from making fatal routine errors. In cloud architecture, a comprehensive cloud security framework translated into a tactical checklist prevents systemic breaches.

This checklist details the 50 mandatory controls required to secure modern AWS, Azure, and GCP environments in 2026. Treat this not as a suggestion, but as a pass/fail audit for your infrastructure.

Identity and Access Management (IAM)

Identity is the new perimeter. If an attacker compromises valid credentials, traditional network defenses are irrelevant.

• [ ] 1. MFA Enforced Everywhere: Multi-Factor Authentication is strictly enforced for all human users, specifically prioritizing hardware tokens (FIDO2) for privileged access.

• [ ] 2. Root Accounts Secured: Cloud provider root accounts (AWS Root, Azure Global Admin) are protected by hardware MFA, use complex passwords, and are never used for daily operational tasks. Usage triggers immediate critical alerts.

• [ ] 3. No Long-Lived Access Keys: Static IAM access keys (e.g., AWS AKIA...) are disabled for human users. Access is granted via federated SSO (Okta, Entra ID) using short-lived STS tokens.

• [ ] 4. Least Privilege Principle: IAM policies are strictly scoped. No user or service role possesses *.* (administrative) permissions unless explicitly justified and time-bound.

• [ ] 5. IAM Access Analyzer: Automated tools continuously scan IAM policies to identify roles with overly permissive access or excessive cross-account access.

• [ ] 6. Service Account Segregation: Every microservice or application runs under its own unique, dedicated service role. Services do not share roles.

• [ ] 7. Just-In-Time (JIT) Access: Administrative access to production environments is granted dynamically upon approval, restricted to a specific time window, and automatically revoked.

• [ ] 8. Regular Access Reviews: Automated workflows force managers to recertify user permissions every 90 days. Dormant accounts are automatically disabled after 30 days.

Data Protection and Encryption

Assume the network will be breached. Data must be protected at rest and in transit.

• [ ] 9. Default Encryption at Rest: EBS volumes, S3 buckets, Azure Blobs, and databases are configured to encrypt data at rest by default using provider-managed keys (KMS) or Customer Managed Keys (CMK).

• [ ] 10. No Public Storage: Account-level "Block Public Access" is enabled for S3 and Azure Storage. Public buckets require explicit, multi-level approval.

• [ ] 11. Secrets Management: Hardcoded credentials in source code are banned. All secrets (API keys, DB passwords) are stored in dedicated vaults (AWS Secrets Manager, HashiCorp Vault) and accessed dynamically.

• [ ] 12. Pre-Commit Secret Scanning: Developers cannot push code containing secrets. Pre-commit hooks and CI/CD pipeline scanners (e.g., git-secrets) block commits containing sensitive strings.

• [ ] 13. TLS 1.2+ Enforced: All in-transit data, including internal service-to-service communication, is encrypted using TLS 1.2 or higher. Insecure protocols (HTTP, Telnet, FTP) are blocked at the network level.

• [ ] 14. Data Classification Tags: Storage resources are tagged with data classification levels (e.g., Confidential, Public, PII) to drive automated DLP policies.

• [ ] 15. Automated Backups: Mission-critical databases and file systems have automated, immutable backups tested quarterly for restoration integrity. See the Cloud Disaster Recovery Guide.

Network and Perimeter Security

While the perimeter has dissolved, network segmentation limits the blast radius of a compromised service.

• [ ] 16. Strict VPC Segmentation: Production, staging, and development environments reside in completely isolated VPCs/VNets, or distinct cloud accounts, with no default routing between them.

• [ ] 17. No Direct Internet Access for Databases: Databases and backend application servers reside in private subnets without public IP addresses.

• [ ] 18. Default Deny Security Groups: Security Groups (firewalls) follow a default-deny approach. SSH (22) and RDP (3389) are never open to 0.0.0.0/0.

• [ ] 19. WAF Deployment: A Web Application Firewall (WAF) fronts all internet-facing APIs and web applications to block SQLi, XSS, and common botnet attacks.

• [ ] 20. DDoS Protection: Provider-native DDoS protection (e.g., AWS Shield Standard/Advanced, Cloudflare) is active on critical endpoints.

• [ ] 21. VPC Flow Logs Enabled: Network traffic logs are enabled and forwarded to a centralized SIEM for behavioral analysis and incident response.

• [ ] 22. Bastion Hosts / Session Manager: Direct SSH access to servers is prohibited. Access is routed through audited Bastion hosts or securely via AWS Systems Manager Session Manager (SSM) without requiring open inbound ports.

Workload and Application Security

Securing the underlying infrastructure is insufficient if the application code or containers are vulnerable.

• [ ] 23. Automated Vulnerability Scanning: Container images (Docker/OCI) and AMI templates are automatically scanned for CVEs during the CI/CD pipeline. Vulnerable images fail the build.

• [ ] 24. Immutable Infrastructure: Servers and containers are never patched in place via SSH. Updates are applied by deploying a new, patched image and destroying the old one.

• [ ] 25. Runtime Container Protection: Kubernetes clusters utilize runtime protection (e.g., Falco) to detect anomalous container behavior, such as a web server spawning a bash shell.

• [ ] 26. Cloud Patch Management: A formalized cloud patch management process ensures critical OS and library vulnerabilities are patched across the fleet within SLA timeframes.

• [ ] 27. IaC Security Scanning: Terraform and CloudFormation templates are scanned using tools like Checkov or OPA to catch misconfigurations before infrastructure is provisioned.

• [ ] 28. Software Composition Analysis (SCA): Third-party libraries and open-source dependencies are continuously monitored for vulnerabilities (e.g., log4j).

Logging, Monitoring, and Response

You cannot defend against what you cannot see. Robust logging accelerates incident response from days to minutes.

• [ ] 29. Centralized Immutable Logging: CloudTrail, VPC Flow Logs, and application logs are aggregated into a centralized, locked-down S3 bucket or SIEM. These logs cannot be deleted or modified, even by administrators.

• [ ] 30. GuardDuty / Threat Detection: Provider-native threat detection (e.g., AWS GuardDuty, Azure Defender) is enabled across all accounts to detect anomalous API activity and compromised instances.

• [ ] 31. Automated Incident Response: High-confidence alerts (e.g., "S3 bucket made public") trigger automated Lambda functions to revert the change immediately, rather than waiting for human intervention.

• [ ] 32. Documented IR Playbooks: The security team maintains tested incident response playbooks for common scenarios (compromised credential, ransomware, data exfiltration).

• [ ] 33. Game Days / Tabletop Exercises: The organization conducts bi-annual simulated breach exercises to test the effectiveness of alerting and the response capabilities of the engineering teams.

Governance and Continuous Compliance

Security is not a point-in-time achievement; it must be continuously enforced.

• [ ] 34. CSPM Deployment: A Cloud Security Posture Management (CSPM) platform is deployed to continuously evaluate the cloud environment against benchmarks like CIS Foundations.

• [ ] 35. Policy-as-Code Guardrails: AWS Service Control Policies (SCPs) or Azure Policy are actively used to enforce organizational boundaries (e.g., "Deny deployment in unauthorized regions," "Deny disabling of CloudTrail").

• [ ] 36. Regular Penetration Testing: Independent, third-party penetration tests are conducted annually on critical infrastructure and applications.

Key Takeaway

This checklist represents the baseline for operating securely in the cloud. Missing even one control—like failing to enforce MFA or leaving an S3 bucket public—can invalidate the rest. To achieve 100% compliance across thousands of resources, manual checks must be replaced by continuous automated scanning and policy-as-code enforcement via dedicated security platforms.