AWS Security Audit Checklist: What Auditors Check and How to Prepare

Most AWS audit failures are predictable: public data exposure, weak identity boundaries, missing logging, and untracked infrastructure drift. This checklist is for CTOs and platform leads who need to prepare for an external AWS security audit or SOC 2 without turning engineering into a compliance bottleneck.

---

What an AWS security audit usually covers

An effective audit aligns with a known framework (e.g. CIS AWS Foundations Benchmark) and focuses on identity, data, network, and evidence. The sections below map to what auditors typically check and what you can fix in advance.

---

1. IAM and identity

1.1 Root and MFA

• Root account has MFA and is not used for day-to-day operations.
• No long-lived access keys for human users; use SSO or IAM Identity Center with short-lived credentials.
• Privileged roles (admin, power user) require MFA.

1.2 Least privilege and escalation paths

• No wildcard (*) permissions except where strictly required and documented.
• Roles are scoped to environment (dev/stage/prod) and purpose.
• There are no privilege-escalation paths (e.g. a role that can attach a new policy granting itself admin).
• Unused users, roles, and access keys are removed or disabled.

1.3 Cross-account and assume-role

• Cross-account access is documented and uses least-privilege role assumption.
• No hardcoded long-lived keys for cross-account access where assume-role is possible.

Internal link: For a structured AWS Security Audit (CIS-aligned review of IAM, S3, network, and logging), see the service page.

---

2. S3 and storage

2.1 Public access

• Block Public Access is enabled at account and bucket level.
• No bucket policies or ACLs grant public read/write/list unless there is a justified, documented exception.

2.2 Encryption and transport

• Default encryption is enabled (SSE-S3 or SSE-KMS).
• Bucket policies deny non-TLS requests where applicable.
• Sensitive data is not stored in buckets that allow public or overly broad access.

2.3 Lifecycle and classification

• Retention and lifecycle rules exist where required for compliance.
• There is a simple data classification approach so teams know what can live in which buckets.

---

3. Network and security groups

3.1 Inbound exposure

• No security groups allow 0.0.0.0/0 on SSH (22) or RDP (3389); use SSM Session Manager, bastions, or VPN with strict access.
• Production databases and internal APIs are not open to the internet.
• Any rule allowing 0.0.0.0/0 is documented and reviewed.

3.2 Segmentation and flow logs

• VPC and subnet design support segmentation (e.g. web / app / data tiers).
• Flow logs are enabled for critical VPCs or subnets.
• Network ACLs are used where they add defence-in-depth.

---

4. Logging and monitoring

4.1 CloudTrail

• CloudTrail is enabled in all regions you use (or organisation-wide).
• Logs are centralised in a dedicated account or bucket with restricted access.
• Log integrity (e.g. log file validation) is enabled.
• Retention meets compliance requirements.

4.2 Config and GuardDuty

• AWS Config is enabled where required for compliance and drift detection.
• GuardDuty (or equivalent) is enabled and findings are reviewed.
• There is a process to respond to critical findings.

4.3 Alerting

• Alerts exist for sensitive actions: IAM policy changes, new access keys, disabling of logging, public S3 policy changes, and similar.
• Ownership and response procedures for alerts are defined.

---

5. Secrets and configuration

• No long-lived secrets in plaintext in user data, environment variables, or public parameter stores.
• Secrets are stored in Secrets Manager or Parameter Store (encrypted) and access is restricted by IAM.
• CI/CD and automation do not log secrets; secret scanning is in place and blocks merges when leaks are found.

---

6. Infrastructure as code and drift

• Critical resources are managed as code (e.g. Terraform, CloudFormation).
• There is a security or policy check in the pipeline (e.g. policy-as-code, IaC scanning).
• Drift between code and live resources is detected and reviewed (e.g. weekly).

---

A practical 2-week audit readiness plan

Phase	Focus	Actions
Days 1–2	Identity + logging	MFA everywhere; remove unused IAM; enable CloudTrail in all regions; centralise logs and set retention.
Days 3–5	Data + network	Block public S3; default encryption; tighten security groups; remove 0.0.0.0/0 on SSH/RDP.
Week 2	Guardrails	IaC security checks in CI; drift detection; define vulnerability/patch SLA and tracking.

This gets most teams from “audit panic” to a defensible baseline without heavy process.

---

What you should get from an AWS audit

A useful engagement should deliver:

• A prioritised list of findings with risk ratings and affected resources.
• Clear, implementable fixes that engineers can execute.
• Recommendations for guardrails so the same issues do not reappear.
• Reporting suitable for leadership and auditors.

For a structured AWS Security Audit aligned with CIS and best practices, see the service page.