ISO 27001 Certification on AWS: ISMS Implementation Guide for 2026

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 or talk to our team.

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:

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:

For a deeper dive on the threat detection side, see our guides on GuardDuty production setup, Inspector v2, and 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:

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 →