ISO 27001 Checklist for AWS: What Auditors Actually Look For

Most AWS environments have the same gaps when it comes to ISO 27001. Not because the engineers don't know what they're doing — but because security controls get deprioritised when you're moving fast, and nobody has mapped the infrastructure to the standard.

Here's a practical checklist of the controls auditors focus on in AWS environments, and how to close them before they become findings.

Identity and Access Management (Annex A.9)

Access control is the first thing auditors look at and the most common source of findings.

What auditors check: - Is MFA enforced for all IAM users, especially the root account? - Are there any users with AdministratorAccess who don't need it? - Are access keys rotated regularly — or better, replaced with IAM roles? - Is there a documented process for revoking access when someone leaves? - Are access rights reviewed periodically?

How to close it: Terraform modules that enforce MFA, deny wildcard policies, and rotate credentials. An access review cadence documented in your ISMS.

Logging and Monitoring (Annex A.12)

Auditors want to see that you would know if something went wrong — and that you'd have the evidence to investigate it.

What auditors check: - Is CloudTrail enabled in all regions, including the global services region? - Are logs stored in a separate, protected S3 bucket with object lock enabled? - Is CloudWatch configured with alerts for suspicious activity — root account usage, failed logins, security group changes? - Is log retention set to at least 12 months? - Is AWS Config enabled to track configuration changes?

How to close it: A Terraform module that deploys CloudTrail, Config, and a locked log archive bucket. CloudWatch alarms for the events that matter.

Data Protection and Encryption (Annex A.10)

What auditors check: - Are S3 buckets encrypted at rest? Is public access blocked by default? - Are RDS instances encrypted? - Is data encrypted in transit — are any services accepting unencrypted connections? - Are KMS keys managed with rotation enabled? - Is there a data classification policy that maps to how data is actually stored?

How to close it: S3 bucket policies enforced via Terraform. KMS key rotation enabled. An SSL/TLS policy on all load balancers. A one-page data classification policy.

Network Security (Annex A.13)

What auditors check: - Are security groups following least-privilege — no 0.0.0.0/0 ingress on sensitive ports? - Are databases in private subnets with no direct internet access? - Is there network segmentation between production and non-production environments? - Are VPC Flow Logs enabled?

How to close it: Terraform that enforces security group rules, private subnet placement for data tiers, and VPC Flow Logs enabled by default.

Vulnerability Management (Annex A.12)

What auditors check: - Is there a documented patching policy with defined timelines for critical patches? - Is Amazon Inspector or equivalent scanning enabled? - Are findings tracked and remediated within defined SLAs? - Has a penetration test been conducted in the last 12 months?

How to close it: Enable Inspector via Terraform. Document a patching policy. Schedule an annual pen test — even a lightweight one from a qualified provider satisfies the control.

Change Management (Annex A.12 / A.14)

This is where cloud-native teams have a natural advantage — if they're using it.

What auditors check: - Are infrastructure changes reviewed and approved before deployment? - Is there an audit trail of what changed, when, and who approved it? - Are deployments automated and repeatable, or manual and undocumented?

How to close it: If you're using Terraform with pull request reviews and GitHub Actions for deployment, you already have this. The audit trail is your Git history. Document it as your change management process.

Incident Response (Annex A.16)

What auditors check: - Is there a documented incident response plan? - Are roles and responsibilities defined? - Is there a process for notifying affected parties within 72 hours (GDPR / NIS2 requirement)? - Have you tested the plan — even a tabletop exercise?

How to close it: A two-page incident response plan with named roles, escalation paths, and notification timelines. A calendar entry for an annual tabletop exercise.

The Common Thread

Every item on this list has two components: the technical control and the evidence that it's working. AWS makes the technical controls straightforward. The gap for most teams is the evidence — the documentation, the policies, the audit trail that proves the control is real and maintained.

That's what a compliance sprint delivers. The controls implemented in your infrastructure, the policies written to match, and the evidence pack ready for an auditor to review.