AWS Security Audit Checklist (CIS-Aligned)

A practical AWS security audit checklist aligned with the CIS AWS Foundations Benchmark: what to check in IAM, logging, storage, networking and governance, and how to rank what you find.

This AWS security audit checklist follows the structure of the CIS AWS Foundations Benchmark and AWS’s own security guidance. Use it to review your accounts yourself, or to know what a professional audit should cover before you buy one.

What is an AWS security audit checklist?

An AWS security audit checklist is a list of configuration checks across identity, logging, storage, networking and governance that together describe a secure baseline for an AWS account. Working through it shows you which misconfigurations exist and which to fix first.

The checks below are aligned with the CIS AWS Foundations Benchmark, which is published by the Center for Internet Security and available from cisecurity.org. Benchmark numbering changes between versions, so check the current version for exact control IDs. We describe each check in plain language instead.

How do you run an AWS security audit?

Start with read-only access, review identity first, then logging, storage, networking and governance, and rank what you find by how easily it can be exploited. Use scanners such as the open-source Prowler for coverage, and review the results by hand.

Give yourself read-only access with the AWS managed SecurityAudit and ViewOnlyAccess policies so the review cannot change anything. Then work through each section below.

1. Identity and access (IAM)

Every AWS security audit checklist should start with identity, because it is where most AWS compromises start, so review it first.

• Root account has MFA and no access keys. The root user can do anything and cannot be restricted by IAM policies. Protect it with MFA, delete any root access keys and use it only for the few tasks that require it.
• Every human user signs in with MFA. Enforce MFA for console users, ideally through IAM Identity Center with your identity provider, rather than creating individual IAM users.
• No wildcard administrator policies on everyday roles. Search for policies that allow Action: "*" on Resource: "*" and replace them with scoped permissions. IAM Access Analyzer can generate a least-privilege policy from real CloudTrail activity.
• Access keys are rare, short-lived and rotated. Prefer roles and temporary credentials. Where keys exist, remove any unused for 90 days and rotate the rest. The IAM credential report lists every key and its last use.
• Password policy meets your standard. If any IAM users sign in with passwords, require a sensible minimum length and prevent reuse.
• IAM Access Analyzer is on in every region in use. It flags roles, buckets and keys shared outside your account or organisation.
• Role trust policies are reviewed. Look for roles that any principal in another account can assume, and confirm every external account listed is one you know.

2. Logging and detection

You cannot investigate what you did not record.

• CloudTrail is enabled in all regions. Use a multi-region trail that records management events, with log file validation turned on so tampering can be detected.
• The CloudTrail bucket is private, encrypted and access-logged. It holds your audit trail. Block public access, encrypt with KMS and limit who can delete objects.
• AWS Config is recording in every region you use. Config gives you configuration history and lets you evaluate rules continuously.
• GuardDuty is enabled and someone reads the findings. Switching it on is not enough. Route findings to a channel a human watches.
• AWS Security Hub is enabled with a relevant standard. Security Hub aggregates findings and runs automated checks against standards such as the CIS AWS Foundations Benchmark.
• VPC flow logs exist for production networks. They record accepted and rejected traffic and are essential during an incident.
• Alarms exist for the high-signal events. The CIS benchmark lists the key ones: root account use, console sign-in without MFA, unauthorised API calls, IAM policy changes, CloudTrail configuration changes, security group and network ACL changes.

3. Storage and data protection

Public or unencrypted data is the most visible failure.

• S3 Block Public Access is on at account level. Turn on all four settings for the account, then create explicit exceptions for the rare bucket that must be public, such as a static website.
• Bucket policies deny non-TLS requests. Add a condition that denies requests where aws:SecureTransport is false.
• Default encryption is enabled on S3, EBS and RDS. Use KMS keys you control for sensitive data, and enable automatic key rotation.
• RDS and other databases are not publicly accessible. Databases belong in private subnets, reached through an application tier or a bastion alternative such as Session Manager.
• Backups exist, are encrypted and restores have been tested. A backup you have never restored is a hope, not a control.

4. Networking and compute

Reduce what is reachable from the internet.

• No security group allows 0.0.0.0/0 to SSH or RDP. Use AWS Systems Manager Session Manager or a VPN instead of exposing ports 22 and 3389.
• The default security group in every VPC allows no traffic. Resources should use purpose-built groups, not the default one.
• EC2 instances require IMDSv2. Version 2 of the instance metadata service defends against a common credential-theft technique through server-side request forgery.
• Public IP addresses are intentional. List every internet-facing load balancer, instance and endpoint and confirm each one needs to be there.
• Container and serverless roles are least-privilege. Check ECS task roles, EKS service accounts and Lambda execution roles for broad permissions and hard-coded secrets.

5. Governance across accounts

The structure around your accounts matters as much as any single setting.

• Workloads are separated across accounts. Production, staging and development should not share an account.
• AWS Organizations service control policies set guard rails. Use them to prevent disabling CloudTrail, leaving the organisation or using unapproved regions.
• Centralised logging goes to a separate account. A log archive account that workload administrators cannot modify protects your evidence.
• Billing and security contacts are current. AWS sends security notifications to these addresses, so they must reach a person.

How do you prioritise AWS security audit checklist findings?

Once the AWS security audit checklist is complete, fix anything that gives an outsider access first, then anything that lets an insider escalate, then gaps in logging. Rank by exploitability and exposure, not by the number of items. A public bucket holding customer data outranks fifty missing tags.

1. Public exposure: open storage, databases and administrative ports.
2. Identity: missing MFA, wildcard admin policies and stale access keys.
3. Detection: missing CloudTrail, GuardDuty or alarms.
4. Encryption and backups.
5. Governance and hygiene.

What mistakes make a self-run AWS security audit checklist miss things?

The most common mistakes are auditing only the main region, skipping accounts nobody remembers, trusting a scanner score without reading the findings, and fixing items in the order they appear instead of the order of risk. Each leaves real exposure behind a reassuring report.

• Looking at one region. Attackers like unused regions because nobody watches them. Check every region, or block the ones you do not use with a service control policy.
• Forgetting old accounts. Sandbox and acquisition accounts often have the weakest controls. List every account in your organisation before you start.
• Treating a score as the result. A scanner can report hundreds of findings. Only a human can say which ones are reachable in your environment.
• Never re-checking. Environments drift. Put the high-signal checks into AWS Config rules or Security Hub so they run continuously.

Should you do this yourself or hire an auditor?

Do the first pass yourself if you have an engineer with the time, and bring in an auditor when you need independent evidence, a faster result or a second pair of eyes. Self-review tends to miss what you are used to seeing, which is why customers and auditors prefer independent reports.

If you want the independent version, our AWS security audit covers every area above and delivers a severity-ranked report with exact fixes, quoted at a fixed price after a free call. See how we price, or read what an AWS security audit costs in 2026. For the Azure equivalent, see our Azure security assessment checklist.

The bottom line

Use this AWS security audit checklist as a repeatable routine, not a one-off. Most AWS security problems are ordinary: an unprotected root user, a wildcard policy, a public bucket, a missing alarm. A disciplined pass through identity, logging, storage, networking and governance finds nearly all of them. Book a free 20-minute assessment if you would like us to run it for you.

Last updated: 11 October 2026 · Written by AegisElligent.