Cloud Security Checklist 2026: 8 Domains, 80+ Controls

Cloud Security Checklist 2026: 8 Domains, 80+ Controls

A cloud security checklist is the foundation of any mature cloud security program. Without a structured checklist, teams inevitably miss critical controls — not because they are careless, but because cloud environments are complex and the attack surface spans dozens of services, configuration options, and integration points.

This checklist covers 8 security domains with specific, actionable controls for AWS, Google Cloud Platform (GCP), and Microsoft Azure. Each item is binary — either done or not done — which makes it suitable for use as an audit framework, an onboarding checklist, or a regular review cadence.

After completing the infrastructure-level controls, run a ZeriFlow scan on your public endpoints to verify the application-layer security that infrastructure controls alone cannot catch.

Domain 1: Identity and Access Management (IAM)

IAM is the most critical security domain in cloud environments. Compromised credentials are the leading initial access vector in cloud security incidents.

Universal controls (all cloud providers): - [ ] Root/owner account secured with hardware MFA - [ ] Root/owner credentials never used for daily operations - [ ] All human users require MFA - [ ] Service accounts use short-lived credentials (no permanent API keys) - [ ] Permissions follow least privilege — no * actions on * resources - [ ] Regular access reviews conducted (at minimum quarterly) - [ ] Orphaned accounts (departed employees, decommissioned services) removed - [ ] Privileged access requires approval workflow (break-glass procedure documented)

AWS-specific: - [ ] IAM Access Analyzer enabled in all regions - [ ] AWS Organizations SCPs restrict dangerous actions (disable region services, prevent disabling CloudTrail) - [ ] AWS SSO (IAM Identity Center) used instead of individual IAM users - [ ] IAM roles used for EC2, Lambda, and ECS — no access keys on instances - [ ] AWS Credential Report reviewed monthly

GCP-specific: - [ ] Workload Identity used for GKE workloads - [ ] No service account keys downloaded (use impersonation instead) - [ ] VPC Service Controls configured for sensitive projects - [ ] Organization Policy constraints applied (e.g., iam.disableServiceAccountKeyCreation)

Azure-specific: - [ ] Azure AD Conditional Access policies enforce MFA - [ ] Privileged Identity Management (PIM) used for privileged roles - [ ] Azure AD Password Protection enabled - [ ] Managed Identities used for Azure services (not service principals with client secrets)

Domain 2: Network Security

Network controls limit the blast radius of compromised resources and prevent lateral movement.

• [ ] Default VPC/network not used for production workloads
• [ ] Separate VPCs/networks for production, staging, and development
• [ ] No resources with public IPs that do not require them
• [ ] Database servers in private subnets, accessible only from application tier
• [ ] Inbound port 22 (SSH) and 3389 (RDP) not open to 0.0.0.0/0
• [ ] Load balancers and WAF in front of application servers
• [ ] VPC Flow Logs (or equivalent) enabled in all regions
• [ ] Network segmentation enforced between microservices
• [ ] Egress filtering on sensitive workloads (databases, payment services)

AWS-specific: - [ ] Security Groups use specific IP ranges, not 0.0.0.0/0, for admin access - [ ] AWS Network Firewall or third-party NGFW for perimeter protection - [ ] VPC Endpoints used for S3, DynamoDB, and other AWS services (avoids public internet) - [ ] AWS PrivateLink for inter-service communication

GCP-specific: - [ ] Firewall rules scoped to specific tags/service accounts, not 0.0.0.0/0 - [ ] Private Google Access enabled for subnets - [ ] Cloud Armor WAF configured for internet-facing load balancers

Azure-specific: - [ ] Network Security Groups with deny-all default on subnet level - [ ] Azure Firewall or NSG flow logs enabled - [ ] Private Endpoints for PaaS services (Storage, SQL, Key Vault)

Domain 3: Data Security and Encryption

Data security controls protect sensitive information at rest and in transit.

• [ ] All data encrypted at rest (using cloud provider KMS or customer-managed keys)
• [ ] All data encrypted in transit (TLS 1.2+ enforced, TLS 1.0/1.1 disabled)
• [ ] Data classification policy defined and implemented
• [ ] PII and sensitive data identified and tagged
• [ ] Backups encrypted and stored in a separate account/project/subscription
• [ ] Backup restoration tested at least quarterly
• [ ] Data retention policies configured and automated
• [ ] Object storage (S3/GCS/Blob) has public access blocked by default
• [ ] Database snapshots not publicly accessible

AWS-specific: - [ ] S3 Block Public Access enabled at account level - [ ] S3 default encryption enabled on all buckets - [ ] RDS encryption at rest enabled (cannot be added post-creation) - [ ] AWS Macie enabled to discover and classify sensitive data in S3 - [ ] DynamoDB encryption at rest enabled

GCP-specific: - [ ] Customer-Managed Encryption Keys (CMEK) for regulated workloads - [ ] Cloud DLP used to scan and classify sensitive data - [ ] Storage bucket IAM, not legacy ACLs

Azure-specific: - [ ] Azure Storage service encryption enabled - [ ] Azure Disk Encryption enabled for VMs - [ ] Azure SQL Transparent Data Encryption enabled - [ ] Microsoft Purview for data governance and classification

Domain 4: Logging and Audit Trails

You cannot investigate what you did not log. Comprehensive logging is the foundation of incident response.

• [ ] Audit logs enabled for all cloud services (who did what, when)
• [ ] Logs centralized in a dedicated, tamper-evident logging account/project
• [ ] Log retention meets compliance requirements (minimum 90 days hot, 1 year cold)
• [ ] Alerts configured for critical events (root login, IAM policy changes, security group changes)
• [ ] DNS query logs enabled
• [ ] Load balancer/CDN access logs enabled
• [ ] Database query logging enabled for sensitive databases

AWS-specific: - [ ] CloudTrail enabled in all regions (multi-region trail) - [ ] CloudTrail log file validation enabled - [ ] CloudTrail logs delivered to S3 in a dedicated security account - [ ] CloudWatch Log Insights configured for common queries - [ ] AWS Config enabled in all regions with all resource types recorded - [ ] GuardDuty enabled in all accounts and regions

GCP-specific: - [ ] Cloud Audit Logs (Admin Activity, Data Access) enabled - [ ] Security Command Center enabled - [ ] Cloud Logging export to a dedicated project

Azure-specific: - [ ] Azure Activity Log exported to Log Analytics Workspace - [ ] Microsoft Defender for Cloud enabled - [ ] Azure Monitor diagnostic settings configured for all resources - [ ] Microsoft Sentinel configured for SIEM/SOAR

Domain 5: Encryption Key Management

Poor key management undermines the value of encryption everywhere.

• [ ] Cloud provider KMS used (not software encryption with manually managed keys)
• [ ] Key rotation enabled (automatic, annual minimum)
• [ ] Keys used only for their intended purpose (separate keys per application/environment)
• [ ] KMS key policies grant least-privilege access
• [ ] Key deletion protection enabled (deletion requires approval period)
• [ ] Hardware Security Modules (HSM-backed keys) for compliance requirements

Domain 6: Compliance and Vulnerability Management

Compliance frameworks and vulnerability scanning catch issues before attackers do.

• [ ] Cloud security posture management (CSPM) tool enabled (Security Hub, Security Command Center, Defender for Cloud)
• [ ] CIS Benchmark compliance monitoring configured
• [ ] Container image scanning in CI/CD pipeline
• [ ] Host-based vulnerability scanning for EC2/GCE/Azure VMs
• [ ] Dependency scanning for application code (SCA)
• [ ] SAST tools integrated into code review process
• [ ] Penetration testing conducted annually (or after major changes)
• [ ] Third-party dependencies reviewed for security advisories

Domain 7: Incident Response Preparedness

An untested incident response plan is effectively no plan at all.

• [ ] Incident response plan documented and version-controlled
• [ ] On-call rotation defined with clear escalation paths
• [ ] Runbooks for common incident types (compromised credentials, data breach, DDoS)
• [ ] Incident response tabletop exercise conducted (at minimum annually)
• [ ] Forensics toolkit prepared (ability to snapshot and preserve evidence without disrupting production)
• [ ] Communication templates prepared (internal, customer, regulatory)
• [ ] Regulatory notification timelines understood (GDPR: 72 hours; CCPA: 45 days; etc.)
• [ ] Cloud provider abuse/security contact information documented

Domain 8: Monitoring and Alerting

Monitoring converts your logging and security controls into actionable intelligence.

• [ ] Uptime monitoring for all public endpoints
• [ ] Anomaly detection for authentication (impossible travel, unusual volume)
• [ ] Cost anomaly alerts (unusual cost spikes can indicate cryptomining or data egress)
• [ ] Certificate expiration alerts (minimum 30 days before expiry)
• [ ] Security alert fatigue reviewed — alerts tuned to reduce noise
• [ ] On-call alerts tested regularly
• [ ] Metrics for security KPIs tracked (mean time to detect, mean time to respond)

Verifying Your Public Endpoints With ZeriFlow

Cloud infrastructure security controls protect your internal resources. Your public endpoints — load balancers, CDN origins, API gateways — are what the world sees. Infrastructure controls cannot enforce application-layer security: HTTPS behavior, security headers, TLS configuration, and certificate validity are the responsibility of your application and web server configuration.

Run a ZeriFlow scan on each of your public endpoints to verify: - HTTPS enforcement and redirect behavior - TLS version and cipher strength - Security headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options) - Certificate chain validity and expiration timeline - Information disclosure (server version, powered-by headers)

ZeriFlow's 80+ automated checks give you an outside-in security score that complements your cloud security posture management tools — covering the application layer that CSPM tools miss.

FAQ

### Q: How often should I run through this checklist? A: New environments should be audited against this checklist before going live. Existing environments should be reviewed quarterly at minimum. After any significant infrastructure change (new service, new region, new team), run through the relevant domains immediately. Automate as many checks as possible using your CSPM tool's continuous compliance monitoring.

### Q: Which cloud provider has the best built-in security tooling? A: All three major providers have mature security tooling. AWS has the most extensive ecosystem (GuardDuty, Security Hub, Config, Inspector, Macie, Detective). GCP's Security Command Center is excellent and tightly integrated. Azure Defender for Cloud and Microsoft Sentinel offer strong SIEM capabilities. The best tooling is the one your team actually uses consistently.

### Q: Is the CIS Cloud Benchmark the right compliance framework? A: CIS Benchmarks are an excellent baseline — they are vendor-neutral, regularly updated, and free. For regulated industries, you may need to meet additional frameworks: SOC 2, ISO 27001, PCI DSS, HIPAA, or FedRAMP. Most CSPM tools map their findings to multiple frameworks simultaneously, so you can track compliance against CIS and your industry-specific framework in parallel.

### Q: How do I prioritize which items to fix first? A: Prioritize by risk: IAM controls first (compromised credentials are the #1 incident vector), then network exposure (public IPs and open ports), then logging (you need audit trails before an incident occurs). Data encryption and key management are high priority for regulated data. Compliance automation and monitoring can be implemented after the foundational controls are in place.

Conclusion

A cloud security checklist is not a one-time exercise — it is a living document that your team revisits regularly as your infrastructure evolves and threat landscapes change. The 8 domains in this checklist cover every layer of cloud security from identity to incident response.

No single domain is sufficient on its own. IAM without logging means you cannot investigate incidents. Encryption without key management is theater. Monitoring without alerting is data you never act on. The value of a comprehensive checklist is precisely that it forces you to address every domain, not just the ones your team finds most familiar.

Scan your public endpoints with ZeriFlow as the final step in your cloud security review. Infrastructure security and application security are two sides of the same coin — ZeriFlow covers the application-layer side that your cloud provider's security tools cannot reach.