Skip to content
Cloudreason

ISO 27001 on AWS: mapping the controls to your estate

AWS is ISO 27001 certified. That does not make you ISO 27001 certified.

ISO 27001 · AWS

Published

ISO 27001 certification runs on a three-year cycle with a surveillance audit every year. Whichever point of that cycle you are at, there is a date ahead of you, and an AWS estate that has drifted since the last visit is the most common reason the run-up to that date becomes painful.

What AWS gives you, and what it does not

AWS itself holds ISO 27001 certification for its infrastructure, and you can download its certificates from AWS Artifact to show your auditor. That matters, because it means the physical and environmental controls in Annex A, such as data centre security, power and hardware disposal, are inherited rather than implemented by you.

It settles far less than people hope. Under the shared responsibility model, AWS certifies the security of the cloud; everything you build in it is yours. Your access control, your logging, your encryption choices, your configuration, your suppliers and your operating procedures all remain squarely inside your own scope. The 2022 revision of the standard makes the point explicitly: control A.5.23, information security for use of cloud services, exists precisely because using a certified provider is not the same as using it securely.

Mapping Annex A to AWS services

ISO 27001:2022 organises Annex A into 93 controls across four themes: organisational, people, physical and technological. For a cloud estate, the technological and organisational themes carry most of the work, and most of them map naturally onto AWS services you may already be running:

  • Asset management (A.5.9, A.5.10). An inventory of information and associated assets is difficult to fake in the cloud and easy to automate. AWS Config maintains a live resource inventory; a disciplined tagging policy turns it into evidence.
  • Access control and identity (A.5.15 to A.5.18, A.8.2, A.8.5). IAM and IAM Identity Center implement least privilege, joiner-mover-leaver processes and privileged access management. Multi-factor authentication and short-lived credentials satisfy secure authentication requirements far more convincingly than a password policy document, and the same controls are audited directly in Cyber Essentials Plus.
  • Logging and monitoring (A.8.15, A.8.16). CloudTrail, CloudWatch, GuardDuty and Security Hub cover event logging, monitoring and alerting. The control is only met if someone actually reviews and acts on what they produce, which is where most estates fall down.
  • Cryptography (A.8.24). KMS and ACM give you managed key lifecycles and encryption in transit and at rest. The auditable part is the policy: what must be encrypted, with which keys, rotated when, accessible to whom.
  • Configuration and vulnerability management (A.8.8, A.8.9). AWS Config rules detect drift from your hardened baselines; Amazon Inspector and Systems Manager cover vulnerability identification and patching. Both produce timestamped evidence as a by-product.
  • Backup and continuity (A.8.13, A.5.29, A.5.30). AWS Backup centralises backup policy and reporting. Continuity controls still need testing; a backup that has never been restored is a hope, not a control.

The mapping is the easy half. The standard also demands a working information security management system around it: risk assessment, statement of applicability, management review and internal audit. No AWS service produces those.

The real problem is the gap between audits

Most ISO 27001 programmes are run annually, against an estate that changes daily. New accounts appear, permissions widen, logging gets switched off in an incident and never re-enabled. The certificate stays on the wall while the estate quietly stops resembling the one that earned it. Public sector buyers probe exactly this gap through the NCSC Cloud Security Principles, which sit alongside ISO 27001 in most procurement questionnaires.

This is the gap Cloudreason’s continuous compliance service exists to close: monitoring the estate against your control set all year, remediating findings with our own engineers rather than filing them, and collecting evidence as it is generated so the audit becomes a review of records you already hold. If you have a surveillance audit or recertification date ahead of you, talk to us well before it.

← Cloud Compliance at Cloudreason

Frequently asked questions

Does AWS's ISO 27001 certification cover my workloads?

No. AWS certifies the infrastructure it operates: data centres, hardware and the services themselves. Everything you build on it, including your access control, logging, encryption and configuration, sits inside your own certification scope under the shared responsibility model.

How many controls does ISO 27001:2022 contain?

Annex A of ISO 27001:2022 contains 93 controls organised into four themes: organisational, people, physical and technological. For a cloud estate, the technological and organisational themes carry most of the implementation work.

How often is ISO 27001 audited?

Certification runs on a three-year cycle with a surveillance audit each year in between. An estate reviewed only ahead of those visits typically drifts out of shape between them, which is why we monitor the control set continuously instead.

Which AWS services help evidence ISO 27001 controls?

AWS Config for inventory and configuration, IAM and IAM Identity Center for access control, CloudTrail, GuardDuty and Security Hub for logging and monitoring, KMS for cryptography, and AWS Backup for continuity. Each produces timestamped evidence as a by-product of normal operation.

Got an audit date?

Tell us the date and the framework, and we'll tell you honestly what stands between your estate and passing.