By Steffan Norberhuis | 22 Jun 2026
ISO 27001 is daunting. It demands a professional organization around information security risk, changes to how you ship software, and making sure your AWS infrastructure is configured correctly.
The moment you pass the audit, though, ISO 27001 certification turns into a serious business accelerator. You can sell into regulated industries that were previously closed. Instead of answering a security questionnaire, you point at your ISO 27001 certificate.
The hard part is that the standard never tells you what to do in AWS. It lists requirements in plain organizational language, and leaves you to translate each one into concrete configurations: which AWS service, which setting, what evidence to collect. That translation step is where most teams lose months.
This blog shows the nine pillars that cover most of the AWS side of ISO 27001:2022. It is drawn from years of building production AWS infrastructure for companies operating under ISO 27001 in heavily regulated industries. The full Annex A-to-AWS mapping for every one of the 93 controls is in the free cheat sheet at the end.
How the standard is structured
ISO 27001:2022 organizes its controls into four families:
- Organizational controls: governance, identity, classification, incident response, continuity. The largest family and the one with the most AWS work.
- People controls: HR, training, off-boarding. Mostly outside AWS.
- Physical and environmental controls: perimeter, facilities, environmental threats. Almost entirely inherited from AWS.
- Technological controls: access management, network, logging, cryptography, change control, development lifecycle. The second largest family, and the most technical.
Most of the AWS work concentrates in the organizational and technological families. The rest of this blog covers the nine pillars that handle them.
The shared responsibility model is your friend
Before going into the families, remember that AWS already does a lot of the work. AWS itself handles the physical perimeter, the fault tolerance, and the hard-drive disposal. You inherit those controls through the shared responsibility model, and most auditors accept AWS SOC 2 and ISO 27001 attestations as evidence.
This is the largest single shortcut in the whole standard. Roughly a third of the requirements turn into “inherited from AWS” or “use multi-AZ” the moment you build on AWS. What is left is the part you actually own: identity, classification, network, logging, change management, and incident response.
Nine pillars cover most of Annex A
Read the four families end to end and the same handful of pillars keeps appearing. Build these nine once and you have covered most of the AWS side of the standard.
1. One account per environment, one VPC per environment
ISO 27001 requires you to isolate data appropriately. Commonly, you do this between different workloads, environments, and data sovereignty regions.
The standard does not say how, but AWS has a clear answer: one account per workload per environment and one VPC per environment. Account boundaries are the strongest isolation primitive AWS offers. Each workload-environment combination gets its own AWS account. That gives you separation for identity, encryption, and billing, making it easy to build and have a trust boundary. You can create a single VPC per environment and share your VPC. This reduces the number of VPCs you have to manage and networking costs, and it is a common pattern for multi-account AWS setups.
This is the number one recommendation because it is the hardest to fix later. You will have to migrate workloads if you get it wrong, and that is a lot of zero-value work.
2. AWS Identity Center with single sign-on and role-based access
ISO 27001 requires you to control access to information and systems. It prescribes doing this at the authentication and authorization layer. You should not have any permanent credentials that can be stolen or access that is not necessary.
No IAM users with long-lived access keys, no shared credentials. Every developer authenticates through Identity Center. Access is granted through roles that map to job functions. A common trap is to use the AWS permissions model directly to grant access to resources. This is a mistake because it can unexpectedly give you too broad access. Instead, use six access levels per role: read-data, write-data, delete-data, use-resource, administer-resource, read-config.
The SSO login with role model is the single highest-impact security control for an ISO 27001 audit on AWS. Auditors open Identity Center first, and what they want to see is consistency: every developer starts from the same role, elevated access is time-boxed and reviewed, and off-boarding kills all sessions immediately.
3. KMS keys classified per confidentiality, integrity, and availability
ISO 27001 requires you to classify data and protect it appropriately. The easiest way to do this in AWS is to use KMS keys per classification. You can classify data by confidentiality, integrity, and availability, and then encrypt it with a KMS key that matches the classification.
Provision KMS keys per classification per account. The KMS key policy enforces access control at the cryptographic layer, not in application code.
This sounds heavyweight but it pays off twice. You get data classification and encryption at rest following the same approach.
4. AWS Config for continuous compliance evidence
ISO 27001 audits are all about showing if you follow your own processes. If you have a process that automatically reports on your control then it is easy to show you follow your processes.
AWS Config records the configuration of every resource in every account, evaluates it against rules in real time, and produces evidence the auditor can pull on demand. Enable it org-wide, apply the conformance pack that matches your regime (CIS, NIST, ISO 27001), and route non-compliance events to your security team.
It puts your compliance team in full control during an audit without having to chase developers for screenshots that show EBS volumes are properly encrypted.
5. GuardDuty, Detective, Inspector, and Macie for detection
ISO 27001 requires you to detect and respond to security incidents. You need to have a current threat-intelligence feed, and you need to be able to investigate incidents when they happen.
AWS provides several security tools that you need to use to get full coverage. AWS GuardDuty for threat detection, AWS Detective for investigation, AWS Inspector for vulnerability scanning, and AWS Macie for personal-data discovery. These four managed services collectively cover most of the detection and monitoring controls. Enable all four org-wide and route findings to your security team’s on-call.
These tools give you a current threat-intelligence feed AWS updates that continuously monitors your accounts for threats. When an incident happens, you can investigate it with Detective.
6. Organization-wide CloudTrail with an immutable log-archive account
ISO 27001 isn’t only about preventing security incidents from happening, but also making sure that you can detect and respond to them. You need to have forensic evidence of what happened, and that evidence must be immutable.
CloudTrail can record everything that happens in your AWS accounts. You can create one organization trail capturing every API call across every account, written to an S3 bucket in a separate log-archive account that hackers cannot reach. Add S3 object lock for write-once-read-many semantics so the logs are immutable.
The point is not “we have logs” but “we have logs that an attacker who compromised production cannot delete.” The log-archive account should be locked down so that the logs cannot be changed.
7. AWS Backup with 3-2-1-1 retention and immutability
ISO 27001 requires you to have a backup and restore strategy. For critical data, you should not rely on a single copy but you need to have several. The 3-2-1-1 means three copies of the data, on two different media, with one offsite copy and one immutable copy. The immutable copy is the ransomware-resistant one.
You implement 3-2-1-1 by using the resource-specific backup and adding another copy in AWS Backup that is copied cross-region and is made immutable.
AWS Backup also makes it easy to implement a validation using AWS Lambda so you can also show that you have tested the restore process.
8. Infrastructure as Code with GitOps for every change
ISO 27001 requires you to control changes to your software change process but also your infrastructure change. You need to have a process that ensures that every change is reviewed and approved before it is applied.
Infrastructure as Code is the default standard for this. Every change to AWS goes through a pull request: the Infrastructure as Code tool of your choice (CDK, Terraform, CloudFormation), a CI pipeline that verifies its quality, and an automated deploy when the PR is merged.
IaC with GitOps gives you a full audit trail of every change, and it is the only way to ensure that your infrastructure is always in a known state. It also makes it easy to roll back changes if something goes wrong. You can add Drift Detection on top so that you can show that your infrastructure is always in the state you expect, matching your git repository.
9. Service Control Policies for guardrails and data sovereignty
ISO 27001 requires you to make sure your data does not end up in the wrong places. You need to have guardrails that prevent developers from making mistakes that could compromise your data.
Service Control Policies sit at the AWS Organization level and apply to every account beneath them. They prevent dangerous actions structurally instead of relying on every role being configured correctly. Common SCPs: block use of the root user, block IAM user creation, restrict regions to a data-sovereignty allowlist, prevent disabling CloudTrail or GuardDuty.
The audit becomes a matter of pointing the auditor at the SCPs and showing that some actions can never happen because they are blocked at the organization level.
Want the one-page version?
Get the ISO 27001 on AWS cheat sheet. Every control with the AWS action behind it, in a single PDF.