
Most ISO 27001 Annex A controls have a SOC 2 counterpart, and most SOC 2 criteria land on an Annex A control. The overlap is largest in access control, logging, change management, vendor oversight and incident response. The two do not map one to one, though. ISO 27001 adds a management system (Clauses 4 to 10) that SOC 2 has no direct equivalent for. SOC 2 adds system-specific criteria and a CPA’s opinion that ISO certification cannot replace.
This guide shows where the controls line up, how to build a mapping matrix, which evidence you can reuse and how to size the work that remains. It is written for compliance officers, IT managers and security leads at U.S. companies that already hold one framework and need the other.
TL;DR
- Access control, logging and monitoring, change management, vendor management and incident response map most cleanly between Annex A and the SOC 2 Common Criteria.
- The main gap for a team with a SOC 2 report is the ISMS itself: Clauses 4 to 10, the risk treatment process and the Statement of Applicability.
- Technical evidence such as logs, configurations and scan reports is often reusable. Governance records such as management reviews and the SoA are assessed separately.
- ISO 27001 certification does not replace a SOC 2 examination, and a SOC 2 report does not give you ISO certification.
- Build one control inventory, map it to both frameworks, then size only the gaps.
Table of Contents
- What you are actually mapping
- Where the controls line up
- What does not map
- How to build the mapping matrix
- Evidence you can reuse, and evidence you cannot
- Does ISO 27001 replace SOC 2, or the reverse?
- Sizing the work to close the gaps
- Estimate the effort before you commit
- Our perspective
- FAQ
- Sources
What you are actually mapping
The two frameworks are built differently, and that shapes every mapping decision.
ISO 27001 certifies an Information Security Management System. It requires compliance with Clauses 4 to 10, including internal audits and management review. Annex A works as a reference set of controls: ISO 27001:2022 contains 93 Annex A control recommendations, and you decide which apply through risk treatment. The result is a certificate that runs for three years, with surveillance audits in between.
SOC 2 is an AICPA attestation. A CPA firm evaluates a defined system against the Trust Services Criteria. AICPA describes the criteria as outcome-based: they test whether a system and its controls give reasonable assurance of meeting management’s objectives. Security (the Common Criteria) is mandatory. Availability, Processing Integrity, Confidentiality and Privacy are optional categories you add based on what customers expect. Type 1 tests design on a single date. Type 2 tests operating effectiveness, generally across a three-to-12-month period. The output is a report, not a certificate.
In short, ISO asks whether you run security as a managed, risk-driven system. SOC 2 asks whether a specific service has controls that worked. Because the question differs, the same control can satisfy both while the paperwork around it does not.

Where the controls line up
The table below shows typical alignments between the SOC 2 Common Criteria and ISO 27001:2022. It is an orientation aid built from how the two structures are usually read side by side, not an official crosswalk. Your own mapping depends on your scope, your risk assessment and the controls you actually run.
| SOC 2 area | Typical ISO 27001:2022 counterpart | Overlap |
|---|---|---|
| CC1 Control environment | Clause 5 leadership, roles (5.2, 5.3), HR security (6.1 to 6.8), awareness training (6.3) | Strong, but ISO asks for more documented leadership commitment |
| CC2 Communication and information | Clause 7.4 communication, policies (5.1), incident reporting (6.8) | Strong |
| CC3 Risk assessment | Clauses 6.1.2 and 6.1.3, 8.2, 8.3 | Partial: ISO prescribes a defined risk method and treatment plan |
| CC4 Monitoring activities | Clause 9.1 monitoring, 9.2 internal audit, 9.3 management review | Partial: ISO demands formal internal audit and management review |
| CC5 Control activities | Policies (5.1), operational planning (Clause 8) | Strong |
| CC6 Logical and physical access | 5.15 to 5.18 access, 8.2 to 8.5 privileged and secure authentication, 8.24 cryptography, 7.1 to 7.4 physical | Very strong |
| CC7 System operations | 8.15 logging, 8.16 monitoring, 8.8 vulnerabilities, 5.24 to 5.28 incident management | Very strong |
| CC8 Change management | 8.32 change management, 8.25 to 8.31 secure development | Strong |
| CC9 Risk mitigation | 5.19 to 5.22 supplier relationships, 5.29 and 5.30 continuity | Strong |
| A1 Availability | 8.13 backup, 8.14 redundancy, 5.30 ICT readiness | Strong |
| C1 Confidentiality | 5.12 and 5.13 classification and labeling, 8.10 deletion, 8.24 cryptography | Strong |
| PI1 Processing integrity | 8.26 application security, 8.28 secure coding, 8.29 testing | Weak to partial |
| P Privacy | 5.34 privacy and PII protection, 5.31 legal requirements | Partial: ISO 27701 goes further |
For the authoritative cell-by-cell version, use the AICPA’s published mapping of the 2017 Trust Services Criteria to ISO 27001. It is a spreadsheet, so you can filter it against your own inventory. Note that it was built against the earlier ISO 27001 control numbering, so you will need to translate references to the 2022 Annex A layout. Our Annex A controls explained guide covers how the 2022 controls are grouped.
Why “80% overlap” claims need care
You will see figures like 80% or even 100% of SOC 2 controls mapping to Annex A. Treat them as directional. Overlap depends on three things:
- Which SOC 2 categories are in scope. A Security-only report overlaps differently than one that adds Privacy and Processing Integrity.
- Your Statement of Applicability. Annex A is a support tool, not a mandatory list. Which controls you must implement comes out of your own risk assessment, so two companies can have different overlap with the same SOC 2 report.
- System scope versus organizational scope. SOC 2 covers a defined system. ISO certifies the scope you declare for the ISMS. Controls can be tested once for both only when the scopes overlap.
A control that maps on paper still has to operate across the whole ISO scope. If your SOC 2 covers one production platform and your ISMS scope covers the whole company, the SOC 2 evidence covers only part of what an ISO auditor will sample.
What does not map
The unmapped items are where the effort lives, so find them early.
On the ISO side, with no direct SOC 2 equivalent
- Clauses 4 to 10. Context of the organization, interested parties, ISMS scope, policy, objectives, competence, documented information, internal audit, management review and continual improvement. This is the primary gap for a SOC 2 organization pursuing ISO 27001.
- The Statement of Applicability. ISO requires you to document necessary controls, justify them and justify any Annex A exclusions. See our Statement of Applicability guide for how to write one an auditor will accept.
- A formal risk treatment plan with risk owners approving residual risk.
- Management review minutes under Clause 9.3, and a documented internal audit program.
On the SOC 2 side, with no direct ISO equivalent
- System description and service commitments. SOC 2 wants a narrative of the system, its boundaries and the commitments made to customers.
- Complementary user entity controls and subservice organization carve-outs. These describe what your customers and vendors must do for your controls to work.
- Operating effectiveness over a period. A Type 2 report samples evidence across months. ISO’s surveillance audits sample too, but on a different cadence.
- The CPA opinion itself. SOC 2 results in an attestation report from a CPA firm, not a certificate.
How to build the mapping matrix
A matrix that stays useful is simple. Here is the sequence that works.
- Build one control inventory. List every control you actually operate: MFA enforcement, quarterly access reviews, backup restores, vendor reviews, and so on. Name an owner for each.
- Map each control to both frameworks. Use the AICPA workbook as your starting point, as the GRACE crosswalk approach does. Add columns for the Annex A reference and the SOC 2 criterion.
- Add the evidence source. Name the system the proof comes from: the identity provider export, the ticketing system, the cloud configuration scan.
- Flag the gaps. Mark every ISO requirement with no SOC 2 counterpart, and every Annex A control in your SoA that nothing in your inventory covers.
- Record status. Use simple states: operating, designed but not evidenced, missing.
- Run a targeted gap analysis on the gaps only. Our ISO 27001 gap analysis guide walks through the method.
Keep the matrix as a living file. It should change when your scope, tooling or SoA does.
A short worked example
Take access reviews. You run a quarterly review of production access in your identity provider and a reviewer signs off in a ticket.
- SOC 2: supports CC6.1 to CC6.3 (provisioning, modification and removal of access).
- ISO 27001:2022: supports 5.18 (access rights) and 5.15 (access control).
- Evidence: the quarterly export and the signed ticket serve both auditors.
- Extra for ISO: the review must trace to a risk in your register and a line in your SoA.
One control, one body of evidence, two sets of references. Repeat that for every row and you have the matrix.
Evidence you can reuse, and evidence you cannot
Technical evidence travels well. Logs, configuration baselines, vulnerability scan reports, backup test results, access review exports and change tickets can usually serve both audits. This is the idea behind the “test once, comply with many” model: shared controls can be audited for both engagements, provided you plan the two together.
Governance evidence does not travel. The SoA, ISMS scope statement, risk treatment plan, Clause 9.3 management review and internal audit reports are specific to ISO 27001 and are assessed separately. Likewise, the SOC 2 system description and management assertion belong to the SOC 2 engagement.
Two practical warnings:
- Dates and periods differ. A Type 2 window might end in June, while your ISO surveillance audit falls in November. Evidence has to be current for each audit’s own period.
- Sampling differs. Auditors from each regime choose their own samples. Consolidated evidence collection helps, but audit cadences and report structures stay distinct.
Does ISO 27001 replace SOC 2, or the reverse?
No, in both directions. ISO 27001 certification does not automatically satisfy SOC 2 because the audit objectives and criteria differ, and SOC 2 requires an examination by a CPA firm. In the other direction, a SOC 2 report does not certify your ISMS.
Practitioners generally describe the two as complementary rather than interchangeable: SOC 2 gives detailed, customer-oriented assurance about a service system, while ISO 27001 shows broader risk management and management-system capability.
The practical question is what your buyers ask for. U.S. enterprise customers tend to request SOC 2. International and regulated buyers often ask for ISO 27001. Startups selling to North American buyers may start with SOC 2, while international or regulated financial-services businesses may favor ISO 27001 or both. For a fuller decision framework, read ISO 27001 vs SOC 2: which do you need.

Sizing the work to close the gaps
Most teams that already hold a SOC 2 report have built a large share of what ISO 27001 requires. The remaining work falls into predictable buckets:
| Work item | Treat as | Why |
|---|---|---|
| ISMS clauses 4 to 10 | Net-new | No SOC 2 equivalent |
| Risk method, register and treatment plan | Mostly new | SOC 2 risk assessment is lighter |
| Statement of Applicability | Net-new | Unique to ISO |
| Annex A controls outside SOC 2 scope | New or extended | Examples: physical, HR and supplier controls beyond your system |
| Technical controls already tested in SOC 2 | Reuse | Re-point evidence, extend scope if needed |
| Internal audit and management review | Net-new | Must run before the certification audit |
Budget the ISMS clauses as new work even when your technical stack is mature. An integrated gap assessment can produce a single roadmap, and a readiness check before the formal audit is worth the time.
For SaaS companies the shape is usually the same: strong technical controls, thin governance. Our ISO 27001 for SaaS and tech companies guide covers what that looks like in practice, and the implementation timeline article shows how long each phase tends to run.
Finance firms and startups
Finance firms often face customer due diligence, regulators and international counterparties at once. That favors holding both, with ISO scope drawn around the business lines that matter. See our audit prep guide for finance companies.
Startups should start with the framework the next big customer asks for, then design controls so the second framework is an extension, not a restart. Build the control inventory from day one, and the mapping matrix costs almost nothing later.
Estimate the effort before you commit
Once you know which gaps exist, the question becomes cost and time. Our ISO 27001 cost calculator gives a real-time estimate based on company size, industry and security maturity, with editable assumptions and no signup needed for the first calculation. If you want a view of where you stand first, take the free 2-minute check, or run the fuller readiness assessment, which scores maturity across the four Annex A control themes. You can save and compare estimates, for example one for ISO alone and one for a combined SOC 2 and ISO program. The methodology page shows how the figures are built.
Our perspective
We see the same mistake repeatedly: teams treat mapping as a spreadsheet exercise, then discover that the spreadsheet only covered technical controls. The mapping is the easy 20 percent of the job. The harder part is accepting that the ISMS is a management system, with owners, reviews and records, and that no crosswalk produces those for you.
Our advice is to map early, because it shrinks the scary part of the project to a defined list. Then estimate that list honestly, with assumptions you can edit and challenge. A number you cannot trace is a number you cannot defend to your CFO or your auditor. That is why we built the calculator around versioned, visible assumptions and why we suggest comparing scenarios before committing budget.
— Martin
FAQ
Can I use one control set for both ISO 27001 and SOC 2?
Yes, in most cases. Build one inventory of the controls you operate, then reference each to its Annex A control and SOC 2 criterion. You will still need separate governance records for ISO and a separate system description for SOC 2.
Is the ISO 27001 to SOC 2 mapping official?
The AICPA publishes a mapping of the 2017 Trust Services Criteria to ISO 27001 as a downloadable spreadsheet. Use it as your starting point, and adjust it to your scope and to the 2022 control numbering. Your auditors decide how much they will rely on your own mapping.
If I have a SOC 2 report, how much more work is ISO 27001?
The technical controls are largely in place, so the new work is the ISMS: Clauses 4 to 10, the Statement of Applicability, the risk treatment plan, an internal audit and a management review. Annex A controls outside your SOC 2 system scope may also need work. Size those gaps with a gap analysis before you plan a date.
Does ISO 27001 certification mean I can skip SOC 2?
No. SOC 2 is an attestation report issued by a CPA firm, and customers who ask for it will expect that report. Some buyers accept either, so check what your key customers require before you decide.
Sources
- AICPA: Mapping 2017 Trust Services Criteria to ISO 27001
- ISO/IEC JTC 1/SC 27/WG 1: Auditing practices note on the SoA
- EY: SOC and ISO integrated attestation
- BARR Advisory: ISO 27001 vs SOC 2, how to obtain both
- GRACE crosswalk report, SOC 2 to ISO 27001
- Atlant Security: ISO 27001 vs SOC 2 comparison guide
- Schellman: Your questions about ISO 27001 answered