A sales prospect asks whether you have ISO 27001. A different one asks for your SOC 2. Procurement wants to know if one substitutes for the other. Underneath the acronyms sit two genuinely different things — built by different bodies, proving different claims, valid in different ways. Choose well and you satisfy your market with one program; choose by reflex and you can spend a year earning the wrong document.
This is a decision guide, not a sales brochure for either framework. We'll separate what each one is, walk the 2022 control set that trips people up, put them side by side, and lay out when one is enough and when running both is the right call.
- ISO 27001 is a certification against an international standard; SOC 2 is an attestation by a CPA firm against criteria you map to your own controls. That's the root of every other difference.
- ISO 27001's heart is the ISMS — a management system for security risk. The controls (Annex A) serve the system; the system is the thing being certified.
- The 2022 revision restructured Annex A into 93 controls across four themes, including 11 new controls covering threat intelligence, cloud, data leakage, secure coding, and more.
- For many regulated mid-market firms the honest answer is both — and a shared control set lets you earn them off one body of evidence.
01 / The core splitCertification versus attestation
Start here, because almost every practical difference flows from it. ISO/IEC 27001 is an international standard you get certified against: an accredited certification body audits you and, if you conform, issues a certificate. SOC 2 is an attestation: a licensed CPA firm examines your controls and issues a report containing an opinion. There is no SOC 2 certificate, and there is no ISO 27001 "report" in the SOC 2 sense.
The two also differ in what they prescribe. ISO 27001 defines a required management system plus a reference set of controls you select from. SOC 2 prescribes broad criteria and lets you define whatever controls meet them. So ISO leans toward a common bar that certified organizations share; SOC 2 leans toward a tailored description that you must actually read to understand. Neither is "stricter" in the abstract — they prove different things.
02 / The ISMSWhat ISO 27001 actually requires
The most common misread of ISO 27001 is that it's a list of security controls. The controls are real, but they're Annex A — an annex. The body of the standard is a set of management-system requirements: the ISMS, or Information Security Management System.
The ISMS is specified in clauses 4 through 10, and conformance to these clauses is mandatory — they are the part you're truly certified against:
- Clause 4 — Context. Understand the organization, its interested parties, and the ISMS scope.
- Clause 5 — Leadership. Top-management commitment, an information security policy, and assigned responsibilities.
- Clause 6 — Planning. Risk assessment and risk treatment, security objectives, and the Statement of Applicability.
- Clause 7 — Support. Resources, competence, awareness, and documented information.
- Clause 8 — Operation. Running the risk assessment and treatment in practice.
- Clause 9 — Performance evaluation. Monitoring, internal audit, and management review.
- Clause 10 — Improvement. Nonconformity, corrective action, and continual improvement.
Two artifacts from Clause 6 do a lot of work. The risk treatment plan shows how you decided which risks to address and how. The Statement of Applicability (SoA) lists which Annex A controls apply to you, which you've excluded, and why — it's the document that connects your risk decisions to the control set. An auditor reads the SoA to see whether your controls follow from your risks, rather than from a copy-paste.
ISO 27001 certifies a management system, not a checklist. The controls exist to treat risks the system identified — which is why two certified firms can run different controls and both conform.
03 / The 2022 revision93 controls, four themes, 11 new
The current revision reorganized Annex A substantially, and it's the detail that most often confuses people working from older material. The previous version listed 114 controls across 14 domains; the 2022 revision consolidated these into 93 controls across four themes.
| Annex A theme | Controls | What it covers |
|---|---|---|
| A.5 — Organizational | 37 | Policies, roles, supplier and cloud relationships, incident management, continuity |
| A.6 — People | 8 | Screening, terms of employment, awareness, disciplinary process, remote working |
| A.7 — Physical | 14 | Secure areas, equipment, physical monitoring, clear desk and screen |
| A.8 — Technological | 34 | Access control, cryptography, logging and monitoring, secure development, configuration |
The revision also introduced 11 new controls that reflect how security has actually changed — cloud, continuous monitoring, and software supply chain. They're worth knowing by name, because they're frequently the gaps a 2022-aligned audit surfaces first:
- 5.7 Threat intelligence
- 5.23 Information security for use of cloud services
- 5.30 ICT readiness for business continuity
- 7.4 Physical security monitoring
- 8.9 Configuration management
- 8.10 Information deletion
- 8.11 Data masking
- 8.12 Data leakage prevention
- 8.16 Monitoring activities
- 8.23 Web filtering
- 8.28 Secure coding
Threat intelligence (5.7), cloud services (5.23), data leakage prevention (8.12), and secure coding (8.28) formalize practices that map directly onto modern and AI-adjacent risk. If you're aligning a program now, build to the 2022 set — anything still organized around the old 14 domains is working from a superseded structure.
04 / The audit cycleHow ISO 27001 certification works
Certification is a defined, repeating process — not a one-time event. An accredited certification body conducts the audit in two stages:
- Stage 1 — a documentation and readiness review. The auditor checks that the ISMS exists on paper: scope, policies, risk assessment, SoA, and the required records.
- Stage 2 — the implementation audit. The auditor tests whether the ISMS is actually operating and effective, gathering evidence across the organization.
Clear Stage 2 and you're issued a certificate that is valid for three years. That validity isn't passive: the body conducts annual surveillance audits to confirm the ISMS is still operating, and a full recertification audit happens at the three-year mark to renew. The model rewards a living management system, not a one-time push — which is the whole point of certifying a system rather than a snapshot.
05 / Side by sideThe comparison that settles most questions
With the mechanics established, the contrast becomes practical:
| ISO/IEC 27001 | SOC 2 | |
|---|---|---|
| Nature | Certification against a standard | Attestation report with an auditor's opinion |
| Issued by | Accredited certification body | Licensed CPA firm |
| Origin | ISO / IEC (international) | AICPA (United States) |
| Core of it | An ISMS (clauses 4–10) plus Annex A controls | Controls mapped to the Trust Services Criteria |
| Control approach | Reference control set, selected via risk and an SoA | Organization defines its own controls to meet criteria |
| Deliverable you can share | A certificate (plus SoA) | A detailed report (often under NDA) |
| Validity | 3 years, with annual surveillance audits | Type 2 covers a period (typically 3–12 months); buyers expect refresh |
| Market pull | Strong internationally (EU, UK, APAC) | Strong in North American B2B / SaaS |
| Best when | You need a globally recognized mark and a durable management system | Buyers want evidence of operating controls, fast, in a US-centric market |
06 / ChoosingWhen one is enough — and which one
For most organizations the deciding factor isn't the framework's merits; it's who's asking and where they are. A few clear signals:
- Lead with SOC 2 if your buyers are predominantly North American SaaS and enterprise procurement teams. It's the document they request by name, and a Type 2 maps cleanly onto a US sales cycle.
- Lead with ISO 27001 if you sell into Europe, the UK, or APAC, or into sectors and tenders where the certificate is an expected mark of maturity. International buyers recognize it instantly; a SOC 2 report can read as unfamiliar.
- Let your risk register break the tie when the market signal is mixed. If you want an internal operating system for security that outlives any single audit, ISO 27001's ISMS gives you that backbone. If you need fast, evidence-based answers for deals, SOC 2 delivers sooner.
The wrong move is choosing by prestige or by whichever name you heard first. Earning the framework your market doesn't ask for is an expensive way to learn the difference.
07 / Running bothTwo frameworks, one body of evidence
Plenty of regulated mid-market firms end up needing both — a US enterprise wants the SOC 2, an overseas client wants the certificate. The good news is that the two overlap heavily at the control level, so the second one should never cost what the first did. The leverage comes from refusing to run them as separate projects.
- Build one control set. Map your controls once to both the Trust Services Criteria and Annex A. The large majority satisfy both frameworks simultaneously.
- Keep a single evidence repository. The same access reviews, logs, and policies feed both the CPA's testing and the certification body's audit. Collect once, present twice.
- Run a crosswalk. A control-to-framework mapping shows exactly where the two diverge, so you add only the delta — the ISMS clauses and SoA for ISO, the report's system description for SOC 2 — rather than rebuilding.
Sequencing usually follows the market: earn the one your nearest deals require first, then extend the same evidence base to the second. Treated this way, the second framework is an extension of the first, not a repeat of it.
08 / Where AI fitsExtending the system to model risk
Neither ISO 27001 nor SOC 2 was written for AI, and neither covers model-specific risk on its own. The encouraging part is that the management-system pattern extends cleanly to it. ISO/IEC 42001 is the AI management system standard — it applies the same certify-the-system logic to the governance of AI, and it's designed to sit alongside an existing ISMS rather than replace it. On the US side, the NIST AI RMF provides a voluntary risk framework that complements either compliance track.
If you already run an ISMS, you have the scaffolding to govern AI without starting over: extend the risk assessment to model risks, add AI-specific controls, and align to 42001 or the NIST AI RMF. And when you're evaluating a vendor's AI rather than governing your own, remember that their SOC 2 or ISO certificate almost certainly doesn't reach the model — which is its own diligence exercise, covered in Your Vendor Has a SOC 2 — But Is Their AI Covered?
09 / Bottom lineDifferent proofs for different audiences
ISO 27001 and SOC 2 aren't competitors and aren't substitutes — they're different instruments aimed at different audiences. ISO 27001 certifies a living management system against an international standard; SOC 2 attests to the controls you've defined and run. Pick the one your market actually asks for, build to the current control sets, and if you need both, earn them off a single body of evidence rather than two parallel programs. Then extend the same discipline to AI through ISO 42001 or the NIST AI RMF — because the frameworks that prove your security today weren't built for the models you're deploying tomorrow.