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, the certification turns into a serious business accelerator. Buyers that require ISO 27001 can finally talk to you. You can sell into regulated industries that were previously closed. Instead of answering a 200-row 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, which evidence in CloudTrail. That translation step is where most teams lose months.
This blog walks through the four control families in ISO 27001:2022 and shows how each one translates into concrete AWS work. It is drawn from years of building production AWS infrastructure for companies operating under ISO 27001 in heavily regulated industries.
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.
For each family, the tables below show every control, the AWS-side action we recommend, and which controls are process-only (flagged with an em dash so you can see the boundary between AWS work and information security management system work).
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.
Organizational controls
| Ref | Control | Rocketleap recommendation |
|---|---|---|
| A.5.1 | Policies for information security | Adopt the CIS AWS Foundations Benchmark as the AWS InfoSec policy. |
| A.5.2 | InfoSec roles and responsibilities | Create dedicated InfoSec roles with org-wide security-audit access in AWS. Create org-wide auditing tools using AWS Config. |
| A.5.3 | Segregation of duties | Define least privilege using RBAC in AWS Identity Center. |
| A.5.4 | Management responsibilities | Automatically inform management of non-compliance using AWS Config. |
| A.5.5 | Contact with authorities | — |
| A.5.6 | Contact with special interest groups | Subscribe to the AWS Security Bulletin. Subscribe to CIS Benchmark updates. |
| A.5.7 | Threat intelligence | Implement threat detection with Amazon GuardDuty. Implement threat investigation with Amazon Detective. |
| A.5.8 | InfoSec in project management | — |
| A.5.9 | Asset inventory | Assign ownership and segregate information assets using AWS accounts. Implement information classification with classification-specific KMS keys. |
| A.5.10 | Acceptable use | Implement information classification with classification-specific KMS keys. Restrict access per classification with KMS resource policies. |
| A.5.11 | Return of assets | Automatically provision access through roles with SSO and AWS Identity Center. Deny any current sessions on deactivation. |
| A.5.12 | Classification of information | Classify KMS keys on confidentiality, integrity, and availability. |
| A.5.13 | Labelling of information | Label information through classification-specific KMS keys. |
| A.5.14 | Information transfer | Enforce information transfer policy through classification-specific KMS keys. |
| A.5.15 | Access control | Provision access through roles with SSO and AWS Identity Center. Assign least-privilege access per role using six access levels: read-data, write-data, delete-data, use-resource, administer-resource, read-config. |
| A.5.16 | Identity management | Provision access through roles with SSO and AWS Identity Center. Split access to root-user MFA and password across two distinct groups. |
| A.5.17 | Authentication information | — |
| A.5.18 | Access rights | Provision access through roles with SSO and AWS Identity Center. Enforce change through Infrastructure as Code and GitOps. |
| A.5.19 | Supplier relationships | — |
| A.5.20 | InfoSec in supplier agreements | — |
| A.5.21 | ICT supply chain | — |
| A.5.22 | Monitoring of supplier services | — |
| A.5.23 | InfoSec for cloud services | — |
| A.5.24 | Incident management planning | Rehearse incident response regularly. |
| A.5.25 | Assessment of security events | Investigate security events using Amazon Detective. |
| A.5.26 | Response to incidents | Alert all information security events through on-call alerting. Investigate using Amazon Detective. |
| A.5.27 | Learning from incidents | Conduct a post-mortem after every information security incident and track actions to closure. |
| A.5.28 | Collection of evidence | Implement a CloudTrail organisation-wide trail. Implement forensic logging on all AWS resources. Implement a log-archive account that aggregates forensic information. |
| A.5.29 | InfoSec during disruption | — |
| A.5.30 | ICT readiness for business continuity | Define RTO and RPO. Use multi-AZ or multi-region. Implement 3-2-1-1 backup strategy with native resource backup and AWS Backup. |
| A.5.31 | Legal / regulatory | Segregate information using accounts based on data sovereignty. Enforce data sovereignty using regional SCPs. Apply necessary regulatory compliance baselines in AWS Config. |
| A.5.32 | Intellectual property rights | — |
| A.5.33 | Protection of records | Make CloudTrail logs immutable. Implement a 3-2-1-1 backup policy with native resource backup and AWS Backup. Make backups immutable with AWS Backup. |
| A.5.34 | PII protection | Implement information classification with classification-specific KMS keys. Enforce data sovereignty using region-specific SCPs. |
| A.5.35 | Independent review | — |
| A.5.36 | Compliance with policies | — |
| A.5.37 | Documented operating procedures | — |
People controls
| Ref | Control | Rocketleap recommendation |
|---|---|---|
| A.6.1 | Screening | — |
| A.6.2 | Terms and conditions of employment | — |
| A.6.3 | InfoSec awareness, education, training | — |
| A.6.4 | Disciplinary process | — |
| A.6.5 | Responsibilities after termination | — |
| A.6.6 | NDAs | — |
| A.6.7 | Remote working | Use AWS Systems Manager Session Manager or AWS Client VPN for remote working. |
| A.6.8 | Event reporting | — |
Physical and environmental controls
| Ref | Control | Rocketleap recommendation |
|---|---|---|
| A.7.1 | Perimeter controls | Outsourced to AWS following the shared responsibility model. |
| A.7.2 | Entry controls | Outsourced to AWS following the shared responsibility model. |
| A.7.3 | Office and facility security | Outsourced to AWS following the shared responsibility model. |
| A.7.4 | Physical access monitoring | Outsourced to AWS following the shared responsibility model. |
| A.7.5 | Protecting against physical and environmental threats | Use multi-AZ or multi-region. |
| A.7.6 | Working in secure areas | — |
| A.7.7 | Clear desk and clear screen | — |
| A.7.8 | Equipment siting and protection | — |
| A.7.9 | Security of assets off-premises | Outsourced to AWS following the shared responsibility model. |
| A.7.10 | Storage media | Outsourced to AWS following the shared responsibility model. |
| A.7.11 | Supporting utilities | Use multi-AZ or multi-region. |
| A.7.12 | Cabling security | Use multi-AZ or multi-region. |
| A.7.13 | Equipment upkeep | Outsourced to AWS following the shared responsibility model. |
| A.7.14 | Equipment disposal and reuse | Outsourced to AWS following the shared responsibility model. |
Technological controls
| Ref | Control | Rocketleap recommendation |
|---|---|---|
| A.8.1 | User endpoint devices | — |
| A.8.2 | Privileged access rights | Provision access through roles with SSO and AWS Identity Center. Implement Temporary Elevated Privileges. Block the root user by SCP. |
| A.8.3 | Information access restriction | Provision access through roles with SSO and AWS Identity Center. Enforce public-access prevention per resource. Restrict access per classification with KMS. |
| A.8.4 | Access to source code | — |
| A.8.5 | Secure authentication | Provision access through roles with SSO and AWS Identity Center. Use OIDC for CI/CD pipelines. |
| A.8.6 | Capacity management | Implement auto-scaling. Implement CloudWatch capacity alerts. |
| A.8.7 | Protection against malware | Implement AWS Web Application Firewall. Implement GuardDuty Malware Protection. |
| A.8.8 | Technical vulnerability management | Implement Amazon Inspector. |
| A.8.9 | Configuration management | Enforce change through Infrastructure as Code and GitOps. Run drift detection to monitor configuration and review drift. |
| A.8.10 | Information deletion | Add lifecycle policies based upon data retention policies. |
| A.8.11 | Data masking | Implement CloudWatch data masking. |
| A.8.12 | Data leakage prevention | Implement defense-in-depth network strategy. Add Resource Control Policies (RCPs) to prevent data leakage. Implement data encryption at rest for every resource. Implement data encryption in transit for every resource. |
| A.8.13 | Information backup | Implement 3-2-1-1 backup strategy with native resource backup and AWS Backup. Use AWS Backup for automatic validation of backups. |
| A.8.14 | Redundancy of processing facilities | Use multi-AZ or multi-region. |
| A.8.15 | Logging | Implement a CloudTrail organisation-wide trail. Implement forensic logging on all AWS resources. Add CloudWatch metric log filters for log-pattern alerting. Add event dead-letter queues on event-driven flows. |
| A.8.16 | Monitoring activities | Implement VPC Flow Logs. Implement threat detection with GuardDuty. |
| A.8.17 | Clock synchronization | AWS-managed NTP. |
| A.8.18 | Privileged utility programs | Block the root user by SCP. Restrict admin roles by Temporary Elevated Privileges. |
| A.8.19 | Software on operational systems | Implement immutable and reproducible pipelines for EC2, containers, and serverless. |
| A.8.20 | Networks security | Implement a tiered VPC with public / private / isolated subnets. Protect any opening in the network perimeter with AWS WAF or mTLS to trusted peers. Apply least-privilege access with security groups and NACLs. Use VPC endpoints for AWS traffic. |
| A.8.21 | Security of network services | Implement AWS Shield for DoS. Add AWS WAF for automated attacks. Add Route 53 Resolver DNS Firewall. |
| A.8.22 | Segregation of networks | Implement subnets per workload with segregation based upon NACLs. Implement one VPC per environment. |
| A.8.23 | Web filtering | — |
| A.8.24 | Use of cryptography | Implement information classification with classification-specific KMS keys at rest. Enable automatic KMS key rotation. Use ACM for TLS certificates. Enforce encryption in transit with resource policies. |
| A.8.25 | Secure development lifecycle | Enforce change through Infrastructure as Code and GitOps. Use OIDC for CI/CD pipelines. Add quality gates in the pipeline for Infrastructure as Code (cdk-nag, lint, tests, secret + dependency scans). |
| A.8.26 | Application security requirements | — |
| A.8.27 | Secure system architecture | Implement AWS Config to verify real-time. |
| A.8.28 | Secure coding | — |
| A.8.29 | Security testing in dev and acceptance | — |
| A.8.30 | Outsourced development | — |
| A.8.31 | Separation of dev, test, production | Provision per environment and per workload an AWS account. Separate VPC per environment. |
| A.8.32 | Change management | Enforce change through Infrastructure as Code and GitOps. |
| A.8.33 | Test information | Separate production environment so production information is not used for test information. |
| A.8.34 | Protection during audit testing | Implement AWS Config to verify real-time. |
The pattern behind the controls
Read the four families end to end and the same handful of building blocks keeps appearing:
- AWS Identity Center with SSO and role-based access.
- KMS keys classified per confidentiality, integrity, and availability level.
- AWS Config for continuous compliance evidence.
- Organization-wide CloudTrail with an immutable log-archive account.
- GuardDuty, Detective, Inspector, and Macie for detection.
- AWS Backup with 3-2-1-1 retention and immutability.
- Infrastructure as Code and GitOps for every change.
- One account per environment, one VPC per environment.
- Service control policies for guardrails and data sovereignty.
Build those nine building blocks once and you have covered most of the AWS side of the standard. The audit becomes a matter of pointing the auditor at the right console screen or log query, instead of a six-month evidence-gathering project.
Where teams get stuck
The pattern is simple to describe and slow to build. Three places where companies lose months:
- Account structure. Choosing the right multi-account layout — organization, organizational units, security accounts, log archive, workload accounts per environment — is hard to reverse later. Most teams pick a single-account or two-account setup early, then have to migrate workloads under audit pressure.
- Identity model. Getting from IAM users with long-lived keys to a clean SSO and Identity Center model with Temporary Elevated Privileges is a multi-month project on its own, and it touches every developer’s daily workflow.
- Evidence pipeline. AWS Config rules, CloudTrail trails, and log-archive accounts produce the right data, but auditors want it stitched together. Without an internal compliance dashboard, the platform team spends weeks per audit cycle exporting screenshots.
A checklist or a single AWS service won’t get you there. These are platform problems.
How Rocketleap fits
Rocketleap is a turn-key AWS platform built around the nine building blocks above. It implements the AWS-side controls by default, following the CIS AWS Foundations Benchmark, and gives you an evidence pipeline auditors can read directly. You focus on building your SaaS, not on getting AWS to work under ISO 27001.
ISO 27001 is easy if you’ve done it before. We have walked dozens of companies through certification on AWS, including heavily regulated industries where the auditor reads every line. If you are heading into ISO 27001 certification on AWS in the next twelve months, the cheapest move you can make today is to start from a platform that already covers the controls, instead of building them yourself while the audit deadline approaches.
Want the one-page version of this walk-through? Grab the ISO 27001 on AWS cheat sheet. Every control with the AWS action behind it, in a single PDF.
Frequently asked questions
Does AWS make ISO 27001 easier?
Yes. Roughly a third of the standard’s controls are inherited from AWS through the shared responsibility model. AWS handles the physical perimeter, building security, cabling, and hard-drive disposal, and publishes SOC 2 and ISO 27001 attestations as evidence.
What is the baseline policy for ISO 27001 on AWS?
The CIS AWS Foundations Benchmark. It is the de-facto baseline every auditor recognizes, and it covers the information security policy requirement directly.
Which AWS services carry the most weight in an ISO 27001 audit?
Nine building blocks cover most of the AWS side: AWS Identity Center with SSO, classification-specific KMS keys, AWS Config, organization-wide CloudTrail with an immutable log archive, GuardDuty plus Detective plus Inspector, AWS Backup with 3-2-1-1 retention, Infrastructure as Code with GitOps, one account per environment, and service control policies.
Where do most teams get stuck on ISO 27001 on AWS?
Account structure, identity model, and evidence pipeline. Choosing the right multi-account layout is hard to reverse later. Migrating from IAM users with long-lived keys to SSO with Temporary Elevated Privileges touches every developer’s workflow. Stitching CloudTrail, Config, and log archive into auditor-ready evidence takes weeks per audit cycle without a compliance dashboard.
Do I need a third-party compliance tool to pass ISO 27001 on AWS?
No. AWS Config, CloudTrail, GuardDuty, Detective, Inspector, and AWS Backup cover the AWS-side controls. Bring in third-party tooling later when the audit volume justifies it.