---
title: ISO 27001 Certification on AWS: ISMS Implementation Guide for 2026
description: SOC 2 closes North American deals. ISO 27001:2022 closes the European and Japanese ones. Building an ISMS that survives Stage 1 and Stage 2 audits, mapping the 93 Annex A controls to AWS services, and producing the evidence packages assessors actually request.
url: https://www.factualminds.com/blog/iso-27001-certification-aws-isms-implementation/
datePublished: 2026-04-27T00:00:00.000Z
dateModified: 2026-04-29T00:00:00.000Z
author: Palaniappan P
category: Security & Compliance
tags: iso-27001, compliance, frameworks, governance, security, aws
---

# ISO 27001 Certification on AWS: ISMS Implementation Guide for 2026

> SOC 2 closes North American deals. ISO 27001:2022 closes the European and Japanese ones. Building an ISMS that survives Stage 1 and Stage 2 audits, mapping the 93 Annex A controls to AWS services, and producing the evidence packages assessors actually request.

ISO 27001:2022 certification is increasingly the deal-blocker for international enterprise sales. SOC 2 may close the North American deal, but a European procurement team will ask for ISO 27001. A Japanese banking customer will require it. A multinational health system will request both. Unlike SOC 2 — which describes your controls — ISO 27001 certifies that you operate an Information Security Management System (ISMS) that is scoped, documented, risk-assessed, audited, and continuously improved.

This guide walks through what ISO 27001:2022 actually requires on AWS, how to map the 93 Annex A controls to AWS services, and how to build evidence packages that pass Stage 2 audits the first time.

> **Need help with ISO 27001?** FactualMinds runs ISO 27001 readiness engagements alongside SOC 2, HIPAA, and PCI DSS — sharing evidence across audits to compress timelines. [See our compliance services](/services/cloud-compliance-services/) or [talk to our team](/contact-us/).

## Step 1: Define Your ISMS Scope

ISO 27001 audits an Information Security Management System — not your entire company, and not your entire AWS environment. Scope is the single most consequential decision you will make.

**A well-scoped ISMS covers:**

- The product or service that processes customer data (e.g., "the X SaaS platform")
- The AWS accounts that host that product (production + supporting accounts like log archive, security tooling, shared services)
- The corporate IT infrastructure that supports the product team (laptops, identity provider, code repositories, CI/CD)
- The people, processes, and physical locations involved

**A poorly scoped ISMS** tries to cover the whole company including HR, finance, sales — auditing all of it is expensive, slow, and unnecessary unless your customers demand it. Most B2B SaaS companies scope to "the production platform plus engineering operations." That is enough to satisfy enterprise procurement.

**Scope artifacts you need:**

- A written scope statement (1–2 paragraphs)
- An asset inventory inside scope (AWS accounts, repos, identity provider, employee laptops with access)
- An exclusion register (what's out of scope and why)

## Step 2: Run a Risk Assessment

ISO 27001 requires a documented risk assessment that is **methodology-driven, repeatable, and reviewed at least annually**. This is what trips up first-time certifiers — auditors expect to see the methodology, not just the output.

### Risk Methodology

Document the methodology before running the assessment:

- **Risk identification:** how you discover risks (asset-based, threat-based, scenario-based, or hybrid)
- **Risk analysis:** likelihood scale (e.g., 1–5: rare → almost certain) × impact scale (e.g., 1–5: insignificant → catastrophic)
- **Risk evaluation:** thresholds for treat / tolerate / transfer / terminate decisions
- **Risk owners:** who owns each identified risk

### Risk Register

Once the methodology is set, populate the risk register. For an AWS SaaS, expect 30–80 risks across categories:

- Identity and access (privileged access compromise, session hijacking)
- Data protection (data exfiltration, snapshot exposure, accidental deletion)
- Availability (region outage, DDoS, dependency failure)
- Application security (OWASP Top 10, supply chain attacks)
- Personnel (insider threat, departing employee credentials)
- Third party (vendor breach, sub-processor exposure)

Each risk has: description, asset, threat, vulnerability, likelihood, impact, inherent risk score, treatment plan, residual risk score, and owner.

### Risk Treatment Plan

For each risk above your threshold, document the treatment: which controls (Annex A or custom) reduce the risk, who owns implementation, target completion date, and the evidence that demonstrates the control is operational.

This is where the **Statement of Applicability** is born — every applicable Annex A control gets traced from a risk back through the treatment plan.

## Step 3: The 93 Annex A Controls — AWS Mapping

ISO/IEC 27001:2022 reorganized Annex A from 114 controls (2013 edition) into 93 controls across 4 themes. Most overlap with SOC 2 Trust Service Criteria, but the structure differs.

### Theme A.5: Organizational Controls (37 controls)

Policies, supplier management, incident response, threat intelligence, business continuity. These are largely **not technical** — they are written documents, processes, and management activities. Examples:

| Control                                       | What it requires                       | AWS evidence                                                |
| --------------------------------------------- | -------------------------------------- | ----------------------------------------------------------- |
| A.5.7 Threat intelligence                     | Documented threat intelligence process | GuardDuty findings reports, Security Hub trends             |
| A.5.23 Cloud services security                | Cloud-specific security policy         | AWS responsibility matrix, BAA, AWS Artifact reports        |
| A.5.30 ICT readiness for business continuity  | DR plan tested annually                | Backup & DR runbooks, restore test logs                     |
| A.5.36 Compliance with policies and standards | Continuous compliance monitoring       | AWS Config conformance pack reports, Security Hub standards |

### Theme A.6: People Controls (8 controls)

Background checks, awareness training, disciplinary process, remote work, and confidentiality. These are HR-driven. Evidence is largely from your HR system — but A.6.7 (remote working) needs an AWS-touching policy covering VPN/Verified Access, MFA enforcement, and approved devices.

### Theme A.7: Physical Controls (14 controls)

Most AWS-only organizations exclude or inherit these from AWS. The SoA documents this: "A.7.1–A.7.13 are inherited from AWS data center controls per AWS Artifact (ISO 27001 certificate, SOC 2 report)." Your office controls (A.7.5, A.7.10) still apply.

### Theme A.8: Technological Controls (34 controls) — The AWS Heavy Lifting

This is where AWS services deliver most of your evidence:

| Control                              | AWS service & evidence                                                            |
| ------------------------------------ | --------------------------------------------------------------------------------- |
| A.8.2 Privileged access rights       | IAM Identity Center, IAM Access Analyzer, permission boundaries, session policies |
| A.8.3 Information access restriction | IAM policies, RBAC, Verified Permissions for fine-grained authorization           |
| A.8.5 Secure authentication          | MFA enforced, SSO via IAM Identity Center, password policy                        |
| A.8.7 Protection against malware     | Inspector v2 for EC2/ECR/Lambda, GuardDuty Malware Protection                     |
| A.8.9 Configuration management       | AWS Config, CloudFormation drift detection, infrastructure-as-code repos          |
| A.8.10 Information deletion          | S3 lifecycle, secure data destruction procedures, BYOK key deletion via KMS       |
| A.8.11 Data masking                  | Macie discovery, application-level tokenization, KMS envelope encryption          |
| A.8.12 Data leakage prevention       | Macie, S3 Block Public Access, GuardDuty S3 Protection, VPC endpoints             |
| A.8.13 Information backup            | AWS Backup with cross-region copies, immutable vaults, scheduled restore tests    |
| A.8.15 Logging                       | CloudTrail (Org trail), CloudWatch Logs, VPC Flow Logs, S3 access logs            |
| A.8.16 Monitoring activities         | GuardDuty, Security Hub, CloudWatch alarms, EventBridge alerts                    |
| A.8.21 Network security              | VPC, Security Groups, NACLs, AWS Network Firewall, AWS Shield                     |
| A.8.23 Web filtering                 | Network Firewall, Route 53 Resolver DNS Firewall                                  |
| A.8.24 Use of cryptography           | KMS, ACM, S3 encryption, EBS encryption, Secrets Manager rotation                 |
| A.8.28 Secure coding                 | CodeGuru, dependency scanning, IaC scanning in CI/CD                              |

For a deeper dive on the threat detection side, see our guides on [GuardDuty production setup](/blog/aws-guardduty-threat-detection-production-guide/), [Inspector v2](/blog/amazon-inspector-v2-container-lambda/), and [Security Hub compliance monitoring](/blog/how-to-set-up-aws-security-hub-compliance-monitoring/).

## Step 4: Build the Statement of Applicability

The Statement of Applicability is a single document (often a spreadsheet exported to PDF) listing all 93 Annex A controls with:

- Control number and title
- Applicability: Yes / No / Inherited
- Implementation status: Implemented / In progress / Not started
- Rationale for inclusion or exclusion
- Owner and evidence reference

For an AWS-native SaaS, expect roughly:

- ~85 controls applicable
- ~5 controls inherited from AWS (most physical controls)
- ~3 controls not applicable (e.g., A.7.4 Physical security monitoring if you have no on-prem datacenter)

The SoA is the **first thing the auditor reads**. A well-crafted SoA with clear rationale dramatically reduces audit friction.

## Step 5: Implement the Mandatory ISMS Documentation

ISO 27001 has a small but non-negotiable set of mandatory documents:

1. **ISMS Scope** — what's in, what's out, why
2. **Information Security Policy** — top-level statement signed by leadership
3. **Risk Assessment Methodology** — how you assess risk
4. **Risk Assessment Report** — the output
5. **Risk Treatment Plan** — how you treat each risk
6. **Statement of Applicability** — the 93-control table
7. **Information Security Objectives** — measurable goals (e.g., "100% of admin actions logged within 60 seconds")
8. **Records of Training** — who attended what, when
9. **Internal Audit Program & Reports** — how often, who audits, findings
10. **Management Review Records** — quarterly or biannual leadership review of ISMS performance
11. **Corrective Actions Log** — nonconformities found and how they were resolved

These exist independently of your technical AWS controls. Without them, you fail Stage 1 (documentation review) before Stage 2 even begins.

## Step 6: Run an Internal Audit

ISO 27001 mandates an internal audit before the certification body audit. This catches gaps while you can still fix them.

The internal audit can be:

- Performed by an internal team member who is not the ISMS owner (segregation of duties)
- Performed by a consultancy doing a "mock audit" prior to the real thing
- Performed by a different business unit's audit function

The output is a documented audit report listing nonconformities, observations, and improvement opportunities. Each nonconformity must have a corrective action with an owner and target date — and the corrective action must be evidenced as closed before Stage 2.

## Step 7: Pass the Stage 1 and Stage 2 Audits

The certification audit happens in two stages.

### Stage 1 — Documentation Review (1–2 weeks)

The auditor reviews:

- ISMS scope statement
- Mandatory documents (above)
- SoA
- Internal audit reports
- Management review records

Stage 1 outcomes: ready for Stage 2, or remediation required (with a defined timeline before Stage 2). About 30% of first-time certifications fail Stage 1 — usually because the SoA is incomplete or the risk assessment lacks methodology.

### Stage 2 — Operational Effectiveness (1–2 weeks)

The auditor evaluates whether the ISMS operates as documented:

- Sample interviews (engineers, security team, leadership)
- Evidence sampling (CloudTrail logs, IAM policies, backup test results, training records)
- Control walk-throughs ("show me how a privileged access request gets approved")
- Site visits (physical office controls if in scope)

Stage 2 outcomes: certification recommended, minor nonconformities (must be resolved within ~90 days), or major nonconformities (re-audit required). Most well-prepared organizations exit Stage 2 with 0–3 minor nonconformities.

## Step 8: Maintain the Certification

ISO 27001 certification is valid for 3 years, with mandatory annual surveillance audits.

- **Year 1:** Initial certification (Stage 1 + Stage 2)
- **Year 2:** Surveillance audit (smaller scope, ~3–5 days)
- **Year 3:** Surveillance audit
- **Year 4:** Recertification (full Stage 1 + Stage 2 again)

Surveillance audits sample roughly 30% of controls each cycle, so over 3 years all controls get re-audited. Your ISMS must remain operational continuously — there is no "dormancy" period between audits.

**Annual maintenance activities:**

- Update risk assessment (annually or after significant change)
- Run internal audit (annually, before surveillance)
- Hold management review (typically quarterly)
- Run information security awareness training (annually)
- Test the incident response plan (at least annually)
- Test the disaster recovery / business continuity plan (annually)

## Cost and Timeline Summary

For a B2B SaaS company already running on AWS with reasonable security hygiene:

| Phase                           | Duration        | Cost (consulting + audit) |
| ------------------------------- | --------------- | ------------------------- |
| Gap analysis                    | 2–3 weeks       | $8,000–$15,000            |
| ISMS implementation             | 8–16 weeks      | $25,000–$60,000           |
| Internal audit                  | 2–4 weeks       | $5,000–$10,000            |
| Stage 1 + Stage 2 audit         | 4–6 weeks       | $15,000–$30,000           |
| **Total Year 1**                | **6–12 months** | **$50,000–$110,000**      |
| Annual surveillance (Years 2–3) | 1 week          | $5,000–$12,000 each       |

Companies with a mature SOC 2 Type II program save roughly 30–40% of effort because most controls overlap.

## ISO 27001 + SOC 2 Together

If you're pursuing both, plan them in this order:

1. **Months 1–3:** Build SOC 2 controls (most overlap with ISO 27001 technical controls)
2. **Month 3:** Hire SOC 2 auditor — observation period begins
3. **Months 3–6:** Build ISO 27001 ISMS documentation in parallel
4. **Month 6:** Internal audit (covers both)
5. **Months 6–9:** SOC 2 audit observation continues; ISO 27001 Stage 1 + Stage 2
6. **Month 9–10:** SOC 2 Type II report issued; ISO 27001 certification issued

This sequencing produces both deliverables in the same fiscal year and shares audit prep effort.

## Get Started

If your sales team is fielding "Are you ISO 27001 certified?" requests from international enterprise buyers, the answer is no longer optional. We help organizations build ISMS programs that pass audits the first time and survive surveillance audits without crisis.

[Book a Free Compliance Gap Assessment →](/contact-us/)

## FAQ

### What is ISO 27001 and why does it matter for AWS workloads?
ISO 27001:2022 is the international standard for an Information Security Management System (ISMS). Unlike SOC 2 (which is US-focused and customer-driven), ISO 27001 is a globally recognized certification — increasingly required by enterprise customers in Europe, Asia-Pacific, and any business pursuing international deals. It evaluates not just controls but the management system around them: risk assessment, treatment, internal audits, management review, and continuous improvement. For AWS workloads, ISO 27001 means demonstrating that your organization runs a documented, repeatable security program — not that AWS itself is secure (AWS is already ISO 27001 certified at the platform level).

### How long does ISO 27001 certification take?
A realistic ISO 27001:2022 certification timeline is 6–12 months for a first-time certification. Phase breakdown: Gap Analysis (2–3 weeks), ISMS design and risk assessment (8–12 weeks), control implementation (6–12 weeks, often parallel to risk work), internal audit (2–3 weeks), Stage 1 audit (documentation review, 1–2 weeks), Stage 2 audit (operational effectiveness, 1–2 weeks), and certification issuance (2–4 weeks). Annual surveillance audits are required for years 2 and 3, with full recertification in year 4. Companies with a mature SOC 2 program often cut this in half because most controls overlap.

### How does ISO 27001 differ from SOC 2 on AWS?
Both standards address access control, encryption, logging, incident response, and risk management — and the technical AWS controls map to both. The key differences: (1) Audience — SOC 2 is US-focused; ISO 27001 is international. (2) Audit format — SOC 2 produces an attestation report describing your controls; ISO 27001 produces a certification (a pass/fail badge). (3) Scope — ISO 27001 evaluates the management system (your ISMS), not just the controls; SOC 2 evaluates control effectiveness against Trust Service Criteria. (4) Cadence — SOC 2 is annual; ISO 27001 has annual surveillance audits and a 3-year recertification cycle. Most B2B SaaS companies pursuing both share evidence between audits, which can save 30–40% of audit prep effort.

### What is the Statement of Applicability (SoA)?
The Statement of Applicability (SoA) is the central ISO 27001 artifact. It lists all 93 Annex A controls (in the 2022 revision), states whether each applies to your organization, and documents the implementation status and rationale for inclusion or exclusion. Auditors read the SoA before anything else — it tells them what to expect during the audit. Excluding a control requires justification (e.g., "A.7.4 Physical security monitoring — not applicable; we operate exclusively on AWS managed infrastructure"). The SoA is a living document; it must be updated whenever you change scope, add cloud services, or modify controls.

### Which AWS services satisfy the most ISO 27001 Annex A controls?
Five AWS services do most of the heavy lifting: (1) AWS IAM + IAM Identity Center for A.5.15-A.5.18 (access control), A.8.2 (privileged access), and A.8.3 (information access). (2) AWS KMS for A.8.24 (cryptography). (3) AWS CloudTrail + CloudWatch Logs for A.8.15 (logging) and A.8.16 (monitoring activities). (4) AWS Config + Security Hub for A.5.36 (compliance with policies and standards) and A.8.9 (configuration management). (5) AWS Backup + cross-region replication for A.8.13 (information backup) and A.8.14 (redundancy). Around 60% of the technical Annex A controls map cleanly to these five services. The remaining controls are organizational: policies, training, supplier management, incident response procedures.

### Can my AWS architecture inherit AWS's ISO 27001 certification?
Partially. AWS holds ISO 27001:2022 certification for the AWS infrastructure layer — physical security, hypervisor security, environmental controls, and the managed service implementations. You inherit those certifications for the controls AWS manages, and AWS Artifact provides the certification documents your auditor will need. But you must independently certify your ISMS — the policies, procedures, configurations, access controls, monitoring, and incident response that you operate. Inheritance reduces evidence collection (no need to audit AWS data centers) but does not reduce the scope of your ISMS audit.

---

*Source: https://www.factualminds.com/blog/iso-27001-certification-aws-isms-implementation/*