AWS Security Audit: The 47-Point Checklist (2026)

An AWS security audit is not a check of whether MFA is enabled on the root user. That is the first of roughly 47 things that matter and the easiest to fix. The gap between “we checked the CIS Benchmark boxes” and “our AWS environment would survive a motivated attacker” is substantial, and it lives in the items that do not appear in the default posture scanners. This is the 47-point AWS security audit checklist we use for Indian SaaS and mid-market engagements in 2026, organized by blast-radius category.

Category 1 — Root account and organization-level controls (5 items)

1. Root account MFA enabled with a hardware MFA device (not a virtual MFA on the same phone the root email runs on). Root credentials never used for operational work — only for account-level operations AWS requires root.
2. Root account access keys deleted. The root user should have no programmatic credentials ever.
3. Billing alarms configured; CloudWatch alarms on unusual spend velocity that could indicate credential abuse or cryptomining.
4. AWS Organizations in use for multi-account setup; Service Control Policies (SCPs) enforcing account-level guardrails (no opt-out from CloudTrail, no disabling of security services, required tags for cost allocation).
5. IAM Identity Center (SSO) for human access; no direct IAM users for humans in any account beyond initial bootstrap.

Category 2 — IAM (9 items)

6. No IAM users with attached access keys older than 90 days. Automated rotation or alternative (OIDC federation, IAM Roles Anywhere) in use.
7. MFA enforced on every IAM user with console access — enforced via IAM policy that denies most actions unless MFA is present.
8. No policies with "Action": "*" and "Resource": "*" attached to any principal except break-glass roles with strong access controls.
9. IAM Access Analyzer enabled in every account and every region; findings reviewed and resolved.
10. Cross-account trust relationships audited; external-ID requirements enforced on any role assumable by a third party.
11. Password policy meets minimum: 14+ character length, no reuse of previous 24, max age 90 days (though federated auth is preferred over password-based).
12. Service-linked roles used where available; no custom IAM roles for services that AWS has blessed roles for.
13. IAM roles follow least-privilege principle; permissions boundary policies in use for developer-created roles.
14. Quarterly review of all IAM users, roles, and policies for continued necessity; automated report produced and reviewed by a named owner.

Category 3 — Network (8 items)

15. No security group with ingress from 0.0.0.0/0 on administrative ports (22, 3389, 3306, 5432, 27017, 6379, 9200, 5601). Any exceptions documented with justification.
16. No RDS, ElastiCache, OpenSearch, or other managed data service with public accessibility unless a specific business requirement is documented.
17. VPC endpoints used for service-to-service communication (S3, DynamoDB, Systems Manager) to keep traffic on the AWS backbone.
18. VPC Flow Logs enabled on all VPCs, stored to a centralized logging account, retained 12 months minimum.
19. Network Access Control Lists (NACLs) configured as second-layer defense (allow lists where feasible).
20. Egress filtering in place on application subnets; workloads cannot reach arbitrary internet destinations.
21. Bastion hosts replaced with SSM Session Manager; no public-IP EC2 instances used for administrative access.
22. VPC peering relationships audited; no peering to accounts outside the organization without documented business need and security review.

Category 4 — Data (7 items)

23. All S3 buckets have S3 Block Public Access enabled at account level and bucket level.
24. All S3 buckets have encryption at rest enabled, with customer-managed KMS keys for sensitive data.
25. S3 Object Lock in use for audit logs and critical backup data.
26. RDS encryption at rest enabled on all instances; customer-managed keys for sensitive databases.
27. Secrets stored in AWS Secrets Manager or Systems Manager Parameter Store, with automatic rotation enabled for supported services (RDS, Redshift).
28. EBS volume encryption enabled at account level; no unencrypted volumes can be created.
29. Backup policies defined for RDS, DynamoDB, and critical EBS; tested restore at least annually.

Category 5 — Compute (6 items)

30. EC2 instances configured with IMDSv2 required (no IMDSv1 fallback); hop limit of 1 for additional hardening.
31. Systems Manager Session Manager used for shell access; no SSH key pairs distributed to engineering teams.
32. AMI hardening baseline in use for all EC2 instances; Systems Manager Patch Manager applying security patches automatically.
33. Lambda functions have no overly permissive execution roles; each function has a dedicated role with least-privilege policy.
34. Container images built from minimal base images; scanned for vulnerabilities at build time; signed with Sigstore or equivalent for supply-chain integrity.
35. ECR repositories configured with image scanning enabled; policies denying pulls of images with critical vulnerabilities.

Category 6 — Logging and detection (7 items)

36. CloudTrail enabled in all regions, in all accounts; organization trail aggregating to a centralized logging account.
37. CloudTrail log file integrity validation enabled; S3 Object Lock on the destination bucket.
38. CloudWatch Logs used for application and infrastructure logs; log groups have defined retention (minimum 12 months for security-relevant logs).
39. GuardDuty enabled in all accounts and all regions; findings routed to a central security monitoring solution.
40. Security Hub enabled with CIS AWS Foundations and AWS Foundational Security Best Practices standards; findings triaged and resolved on defined SLAs.
41. Config enabled recording all supported resources; conformance packs for relevant compliance frameworks.
42. Custom CloudWatch alarms on high-signal events: IAM policy changes, root user activity, security group changes, disabling of logging.

Category 7 — Compliance and governance (5 items)

43. Tagging strategy enforced via SCPs and tag policies; every resource carries owner, cost-center, environment, data-classification tags.
44. Resource inventory complete; no “mystery resources” with unclear ownership.
45. Cross-account IAM roles for audit/assessment purposes use external-ID and are limited to read-only SecurityAudit or ViewOnlyAccess policies.
46. Incident response plan documented, tested, and accessible to the team during incidents (not in a Confluence page that requires the compromised SSO to access).
47. Annual security review conducted against this checklist or equivalent; results reported to leadership with remediation plan.

How to use this checklist

Score yourself: each item is Done, Partial, or Not Started. If more than 8 items are Not Started, your environment is in urgent-action territory. If more than 15 are Not Started, an engagement with an external security partner is the right path — the gap is too large to close from the inside without dedicated effort.

This checklist is directional, not exhaustive. A full audit also covers workload-specific hardening, compliance-specific controls (PCI DSS, HIPAA, SOC 2 controls beyond CIS), and developer workflow security (CI/CD pipeline, IaC review). Those are scoped in depth during our engagements.

Related reading

• Cloud Security for Indian Businesses: The Complete Guide
• S3 Bucket Misconfigurations That Still Cause Breaches
• AWS IAM Best Practices for Indian SaaS
• SOC 2 Readiness Assessment for Indian Cloud Startups

For an AWS security audit against this checklist, book a scoping call. Typical engagement: 1-week configuration audit per account, prioritized findings, IaC remediation patches for common issues.