AWS holds ISO 27001 certification — does that make my workloads certified?

No. AWS holds an ISO/IEC 27001 certificate for its own infrastructure, and under the shared-responsibility model you inherit the controls AWS operates (physical security, hypervisor isolation, data-centre operations). Everything you configure on top — IAM, encryption settings, network exposure, logging — is your responsibility and is assessed separately. Your certificate covers your ISMS and your AWS configuration, not Amazon’s.

How is ISO 27001 different from SOC 2 for an AWS-hosted product?

SOC 2 is an AICPA attestation: a CPA firm reports on whether your controls operate against the Trust Services Criteria. ISO 27001 is a certifiable management-system standard: an accredited body audits your Information Security Management System (ISMS) and, if it passes, issues a certificate valid for three years with annual surveillance. The technical AWS controls overlap heavily — encryption, access control, logging — which is why the same CloudArq checks evidence both. If you already have SOC 2, most of the Annex A technical evidence is reusable.

Which Annex A controls actually apply to a cloud-only AWS environment?

ISO/IEC 27001:2022 Annex A has 93 controls across four themes (Organizational, People, Physical, Technological). Many are policy and people controls; a subset are technical and directly observable in an AWS account — access control (A.5.15), cloud-service security (A.5.23), cryptography (A.8.24), logging (A.8.15), configuration management (A.8.9), network security (A.8.20) and more. CloudArq maps its checks to that technical subset. The physical and organisational controls are evidenced by your policies and processes, not by a scanner.

Can CloudArq get us ISO 27001 certification?

No — and no tool can. Only an accredited certification body can issue an ISO 27001 certificate, after a Stage 1 (documentation) and Stage 2 (implementation) audit of your ISMS. CloudArq is a read-only posture scanner: it shows where your live AWS configuration meets or misses Annex A technical controls and gives the exact remediation step for each gap, so your Stage 2 audit has fewer findings. It does not certify you, and CloudArq the business holds no certification of its own.

What are the most common Annex A gaps auditors find on AWS?

CloudTrail disabled in a region (A.8.15), public S3 buckets or OpenSearch domains (A.5.23), security groups allowing 0.0.0.0/0 on SSH (A.8.20), unencrypted EBS/RDS with no key rotation (A.8.24), and AWS Config not recording (A.8.9). These are the first things an assessor looks for and each is a single misconfiguration CloudArq flags with a copy-paste fix.

What changed in ISO 27001:2022 that matters for cloud?

The 2022 revision restructured Annex A from 114 controls into 93 and added new ones that map cleanly to cloud practice — including A.5.23 (security for the use of cloud services), A.8.9 (configuration management), A.8.12 (data-leakage prevention) and A.8.16 (monitoring activities). If your ISMS was built against the 2013 Annex A, these newer controls are exactly where an AWS environment needs fresh technical evidence, and they are the controls CloudArq maps most of its cloud checks to.

frameworkiso 27001

scopeaws

annexa

compliance guide · aws · iso 27001:2022

ISO 27001 on AWS: Annex A controls, mapped to real checks

A control-by-control map from ISO/IEC 27001:2022 Annex A to the AWS configuration facts an assessor actually inspects. Every row names the technical control and the read-only CloudArq check that evidences it — so your Stage 2 audit starts with fewer surprises. This page shows posture; it does not certify you.

Updated 2026-07-20 · ~11 minute read

checks mapped to Annex A

Annex A controls below

control groups below

agents installed

See CloudArq map these View pricing

audience

Who this is for

Teams running on AWS that are scoping, preparing for, or maintaining an ISO/IEC 27001:2022 certification — whether it's your first Stage 1/2 audit or an annual surveillance visit. If you own the ISMS, use the control groups below to see exactly which Annex A technical controls your AWS account can already evidence and where the gaps are. If you're an engineer handed a list of Annex A references, read it as a translation layer: each control ID maps to a concrete AWS setting you can check today.

definition

What ISO 27001:2022 actually is (one paragraph)

ISO/IEC 27001 is the international standard for an Information Security Management System (ISMS). The certifiable requirements live in clauses 4–10 (context, leadership, planning, support, operation, performance evaluation, improvement); Annex A is the reference set of controls you select from based on your risk assessment and record in a Statement of Applicability. The 2022 revision reorganised Annex A into 93 controls across four themes — Organizational, People, Physical and Technological. An accredited certification body runs a Stage 1 (documentation) and Stage 2 (implementation) audit; a pass yields a certificate valid for three years with annual surveillance audits. CloudArq addresses the technological Annex A controls that are observable in your AWS configuration — not the ISMS clauses, and not the people or physical controls.

shared responsibility

AWS's certificate is not your certificate

Amazon holds an ISO/IEC 27001 certificate for the AWS platform, which lets you inherit its physical, environmental and hypervisor-isolation controls as evidence — you cite AWS's certificate for “security of the cloud.” Everything you configure — IAM policies, encryption settings, public exposure, logging, key rotation — is “security in the cloud,” and it is what your auditor examines for the technological Annex A controls. That boundary is exactly where CloudArq operates: it reads your account's configuration metadata (never your data) and tells you which of those in-cloud controls currently hold.

annex a · technical controls

Annex A controls, mapped to AWS checks

Each row below is one real Annex A:2022 control and the CloudArq check IDs that evidence it. In total, 62 distinct checks map to Annex A technical controls; the 11 highlighted here are the ones most teams are asked about first.

Access control & identity (A.5.15, A.8.10)

Who can reach what — and cleaning up the identities that no longer should.

2 controls

A.5.15Least-privilege access is enforced. CloudArq checks for wildcard IAM policies (`iam_policy_wildcard`) and privileged runtime execution roles (`runtime_privileged_role`) that grant far more than a workload needs.
A.8.10Information and identities no longer required are removed. Checks for unused secrets (`secrets_unused`) and dormant IAM users (`iam_unused_users`) that widen your attack surface without earning their keep.

Cloud services & network security (A.5.23, A.8.20)

What of yours is reachable from the public internet.

2 controls

A.5.23Security for the use of cloud services. Checks for public S3 buckets (`public_s3`), publicly reachable OpenSearch domains (`opensearch_public`), and runtimes exposed on public networks (`runtime_public_network`).
A.8.20Networks are secured against unauthorised access. Checks for SSH open to `0.0.0.0/0` (`open_ssh`) and self-hosted inference endpoints exposed to the internet (`exposed_self_hosted_inference_endpoint`).

Use of cryptography (A.8.24)

Data protected at rest with keys you control and rotate.

1 controls

A.8.24A defined rule set for cryptography is applied. Checks for unencrypted EBS volumes (`unencrypted_ebs`), customer-managed keys without rotation enabled (`kms_key_rotation_disabled`), and agent token vaults not backed by a CMK (`token_vault_no_cmk`).

Logging, configuration & change management (A.8.15, A.8.9, A.8.32)

A record of what happened, and control over how the estate changes.

3 controls

A.8.15Activity is logged and retained. Checks for CloudTrail disabled in a region (`no_cloudtrail`) and VPC flow logs turned off (`vpc_flow_logs_disabled`).
A.8.9Configurations are managed and enforced. Checks that AWS Config is recording (`config_not_enabled`) and that deployed stacks have not drifted from their template (`cloudformation_drift`).
A.8.32Changes are controlled and traceable. The same audit-trail (`no_cloudtrail`) and configuration-baseline (`config_not_enabled`) evidence supports demonstrating that changes are logged and reviewable.

Endpoints & secure development (A.8.1, A.8.25)

Hardened instances and a build pipeline that catches known flaws.

2 controls

A.8.1User endpoint devices are protected. Checks for the legacy instance-metadata service (`ec2_imdsv1`, an SSRF credential-theft vector) and unpatched instances behind SSM (`ssm_unpatched`).
A.8.25Security is built into the development life cycle. Checks for deprecated Lambda runtimes (`lambda_deprecated_runtime`) and container repositories without scan-on-push (`ecr_no_scan_on_push`).

Data-leakage prevention (A.8.12)

Closing the paths that let sensitive data escape a workload.

1 controls

A.8.12Data-leakage prevention measures are applied. Checks for exposed Bedrock knowledge-base sources (`bedrock_kb_source_exposure`) and SageMaker data-capture sinks that could collect PII (`sagemaker_data_capture_pii_sink`).

scope · what this does & doesn't do

What CloudArq does

Maps 62 read-only checks to Annex A:2022 technological controls.
Shows, per control, which live AWS settings currently pass or fail.
Ships an exact remediation step (CLI / IaC) and an evidence pointer for each gap.
Runs from a read-only IAM role with an ExternalId — never stores your credentials, app data, database contents, or S3 objects.

What it does not do

It does not certify you to ISO 27001 and is not a Stage 1 or Stage 2 audit.
It does not cover the ISMS clauses 4–10 (leadership, risk treatment, internal audit, management review) or the organisational, people and physical Annex A controls.
It detects and gives you the fix — it never auto-fixes and never changes your account.
CloudArq the business holds no certification of its own; the product maps checks to controls, it does not confer compliance.

product · output

How CloudArq groups the gaps by Annex A control

compliance-gaps · framework · iso 27001:2022illustrative example

Critical2High2Medium1

A.8.20

Security group 0.0.0.0/0 on SSH

sg-0example · eu-north-1

fix →

A.5.23

Public S3 bucket (list + read)

arn:aws:s3:::example-assets

fix →

A.8.24

EBS volume unencrypted at rest

vol-0example · eu-north-1

fix →

A.8.15

CloudTrail disabled in a region

eu-west-1

fix →

A.8.9

AWS Config not recording

config · eu-north-1

fix →

Each failing control ships with a copy-paste CLI / Terraform fix and its evidence pointer for the assessor.

faq

Frequently asked

01AWS holds ISO 27001 certification — does that make my workloads certified?: No. AWS holds an ISO/IEC 27001 certificate for its own infrastructure, and under the shared-responsibility model you inherit the controls AWS operates (physical security, hypervisor isolation, data-centre operations). Everything you configure on top — IAM, encryption settings, network exposure, logging — is your responsibility and is assessed separately. Your certificate covers your ISMS and your AWS configuration, not Amazon’s.
02How is ISO 27001 different from SOC 2 for an AWS-hosted product?: SOC 2 is an AICPA attestation: a CPA firm reports on whether your controls operate against the Trust Services Criteria. ISO 27001 is a certifiable management-system standard: an accredited body audits your Information Security Management System (ISMS) and, if it passes, issues a certificate valid for three years with annual surveillance. The technical AWS controls overlap heavily — encryption, access control, logging — which is why the same CloudArq checks evidence both. If you already have SOC 2, most of the Annex A technical evidence is reusable.
03Which Annex A controls actually apply to a cloud-only AWS environment?: ISO/IEC 27001:2022 Annex A has 93 controls across four themes (Organizational, People, Physical, Technological). Many are policy and people controls; a subset are technical and directly observable in an AWS account — access control (A.5.15), cloud-service security (A.5.23), cryptography (A.8.24), logging (A.8.15), configuration management (A.8.9), network security (A.8.20) and more. CloudArq maps its checks to that technical subset. The physical and organisational controls are evidenced by your policies and processes, not by a scanner.
04Can CloudArq get us ISO 27001 certification?: No — and no tool can. Only an accredited certification body can issue an ISO 27001 certificate, after a Stage 1 (documentation) and Stage 2 (implementation) audit of your ISMS. CloudArq is a read-only posture scanner: it shows where your live AWS configuration meets or misses Annex A technical controls and gives the exact remediation step for each gap, so your Stage 2 audit has fewer findings. It does not certify you, and CloudArq the business holds no certification of its own.
05What are the most common Annex A gaps auditors find on AWS?: CloudTrail disabled in a region (A.8.15), public S3 buckets or OpenSearch domains (A.5.23), security groups allowing 0.0.0.0/0 on SSH (A.8.20), unencrypted EBS/RDS with no key rotation (A.8.24), and AWS Config not recording (A.8.9). These are the first things an assessor looks for and each is a single misconfiguration CloudArq flags with a copy-paste fix.
06What changed in ISO 27001:2022 that matters for cloud?: The 2022 revision restructured Annex A from 114 controls into 93 and added new ones that map cleanly to cloud practice — including A.5.23 (security for the use of cloud services), A.8.9 (configuration management), A.8.12 (data-leakage prevention) and A.8.16 (monitoring activities). If your ISMS was built against the 2013 Annex A, these newer controls are exactly where an AWS environment needs fresh technical evidence, and they are the controls CloudArq maps most of its cloud checks to.

Where CloudArq helps

CloudArq maps 62 read-only checks to the technological Annex A:2022 controls on this page. The compliance-gaps view groups every failing control by its Annex A reference, and each finding ships with a CLI command or Terraform block you can apply today — turning your Statement of Applicability evidence-gathering from a screenshot hunt into a diff.

Preparing for more than one framework? Most of this technical evidence is reusable. See the SOC 2 on AWS checklist and the NIST 800-53 on AWS mapping, which draw on the same underlying checks.

See the demo View pricing