ISO/IEC 27001:2022 to SOC 2 (2017 Trust Services Criteria): how they map
The short version: an ISO/IEC 27001:2022 ISMS covers most of the SOC 2 common criteria, and your policies, risk assessment and controls carry over. The gaps are predictable: ethics and board oversight (CC1), fraud risk (CC3.3), processing integrity, and privacy. The bigger change is structural. A SOC 2 is a CPA firm’s attestation report, not a certificate, and a Type 2 tests that controls operated throughout a period.
The table maps the 2017 Trust Services Criteria (with the 2022 revised points of focus) to ISO/IEC 27001:2022 clauses and Annex A controls. The common criteria CC1 to CC9 are shown first, then the four optional categories. It’s our own crosswalk, not an official ISO or AICPA mapping.
- Broad means ISO controls cover the same ground. You still need evidence in the form a SOC 2 auditor tests.
- Partial means at least one criterion in the group has no clear ISO counterpart.
| SOC 2 (2017 TSC) | ISO/IEC 27001:2022 | Coverage | Notes |
|---|---|---|---|
| CC1 Control environment (CC1.1–CC1.5) | Clauses 5.1, 5.3 and 7.2 (leadership, roles, competence) A.5.2 Information security roles and responsibilities A.5.4 Management responsibilities A.6.1 Screening; A.6.2 Terms and conditions of employment A.6.3 Information security awareness, education and training A.6.4 Disciplinary process | Partial | Roles, competence, screening, training and accountability (CC1.3–CC1.5) map well. Integrity and ethical values (CC1.1) has no Annex A control; a code of conduct is the usual evidence. Board oversight independent of management (CC1.2) goes further than ISO, which asks for top management commitment (5.1) and management review (9.3) but no independent board. |
| CC2 Communication and information (CC2.1–CC2.3) | Clauses 7.3, 7.4 and 7.5 (awareness, communication, documented information) A.5.1 Policies for information security A.5.5 Contact with authorities (CC2.3) | Broad | ISO covers internal and external communication and controlled documentation. SOC 2 looks harder at what you tell customers, regulators and vendors, including about your commitments and security incidents (CC2.3). |
| CC3 Risk assessment (CC3.1–CC3.4) | Clauses 4.1, 6.1.2 and 8.2 (context, risk assessment) Clauses 6.3 and 8.2 for changes (CC3.4) A.5.7 Threat intelligence | Partial | ISO's risk assessment process meets CC3.1 and CC3.2 well. ISO has no requirement to assess fraud risk as such (A.5.3 segregation of duties is one fraud control), so CC3.3 usually needs its own assessment. CC3.4, assessing changes that could affect internal control, aligns with planning of changes (6.3) and carrying out risk assessments under 8.2. |
| CC4 Monitoring (CC4.1–CC4.2) | Clauses 9.1, 9.2 and 9.3 (monitoring, internal audit, management review) Clause 10.2 Nonconformity and corrective action A.5.35 Independent review of information security A.5.36 Compliance with policies, rules and standards | Broad | A close fit. Internal audit and independent review are ongoing and separate evaluations (CC4.1). Its points of focus give pen testing, internal audit and third-party assessments as examples. ISO's corrective-action process covers evaluating and communicating deficiencies (CC4.2). |
| CC5 Control activities (CC5.1–CC5.3) | Clause 6.1.3 Risk treatment and the SoA Annex A theme 8, technological controls (CC5.2) Clause 5.2 and A.5.1 Policies; A.5.37 Documented operating procedures | Broad | Selecting controls to bring risk to an acceptable level (CC5.1) is what ISO's risk treatment does, with the SoA as the record. Policies and procedures (CC5.3) map directly. |
| CC6 Logical and physical access (CC6.1–CC6.8) | CC6.1: A.5.15, A.8.2, A.8.3, A.8.5 CC6.2–CC6.3: A.5.16, A.5.18, A.5.3 CC6.4: A.7.1, A.7.2, A.7.3 CC6.5: A.7.10, A.7.14, A.8.10 CC6.6: A.8.20, A.8.21, A.8.22, A.6.7 CC6.7: A.5.14, A.8.24, A.8.12 CC6.8: A.8.7, A.8.19 | Broad | The most heavily tested area in a SOC 2, and the best-covered by Annex A. In a Type 2, expect the auditor to sample joiners, leavers and access reviews from across the period. Leavers' access not removed on time (CC6.2) is a frequent gap. |
| CC7 System operations (CC7.1–CC7.5) | CC7.1: A.8.8, A.8.9 CC7.2: A.8.15, A.8.16 CC7.3: A.5.25 CC7.4: A.5.24, A.5.26, A.5.28 CC7.5: A.5.26, A.5.27, A.8.13 | Broad | Vulnerability and configuration management, logging, monitoring and incident management map closely. In a Type 2, expect to show the process operated during the period, for example incident records and log reviews, not just a written procedure. |
| CC8 Change management (CC8.1) | A.8.32 Change management A.8.25 Secure development life cycle A.8.29 Security testing in development and acceptance A.8.31 Separation of development, test and production environments A.8.8 Management of technical vulnerabilities (patches) | Broad | A close fit. CC8.1's points of focus include patch changes, so patching evidence counts here as well as under CC7.1. Clause 6.3 is about changes to the ISMS itself, not to systems. |
| CC9 Risk mitigation (CC9.1–CC9.2) | CC9.1: A.5.29 Information security during disruption; A.5.30 ICT readiness for business continuity CC9.2: A.5.19 to A.5.22 supplier controls; A.5.23 Information security for use of cloud services | Broad | Business disruption (CC9.1) and vendor risk (CC9.2) both map. SOC 2 adds its own terms for vendors whose controls your service depends on: subservice organizations, presented carve-out or inclusive, and the controls you assume they run (CSOCs). Monitoring them, for example by reviewing their SOC 2 reports, is your control under CC9.2. |
| A1 Availability (A1.1–A1.3) | A1.1: A.8.6 Capacity management A1.2: A.7.5, A.7.11, A.8.13, A.8.14 A1.3: A.5.30 ICT readiness for business continuity | Broad | Capacity, environmental protection, backup and redundancy map directly. No Annex A title names recovery-plan testing, which A1.3 tests directly. Make sure your A.5.30 and backup evidence includes the tests and their results. |
| C1 Confidentiality (C1.1–C1.2) | C1.1: A.5.9, A.5.12, A.5.13 C1.2: A.8.10 Information deletion; A.7.14 Secure disposal or re-use of equipment | Broad | Inventory, classification, labeling and deletion map directly. SOC 2 tests them against the confidentiality commitments you make to customers. |
| PI1 Processing integrity (PI1.1–PI1.5) | Clause 6.1.2 (integrity risks, in part) A.8.26 Application security requirements (in part) | Partial | Weak overlap. ISO's risk assessment covers integrity of information, but Annex A has no controls for complete, accurate and timely processing to specification: input checks, processing error handling, output reconciliation. Expect to design most PI1 controls from scratch. |
| P Privacy (P1.1–P8.1, 18 criteria) | A.5.34 Privacy and protection of PII A.5.31 Legal, statutory, regulatory and contractual requirements | Partial | One Annex A control against 18 criteria: notice, choice and consent, collection, use, retention and disposal, access and correction, disclosure, data quality, and complaints. ISO/IEC 27701:2025, now a standalone privacy management standard, is the closer ISO match. |
Annex A numbers are shown without titles where a cell lists several. A.5 controls are organizational, A.6 people, A.7 physical and A.8 technological. Check each against your SoA.
The structural differences
The control overlap is the easy part. The two schemes produce different things, for different readers, on different timelines.
| Topic | ISO/IEC 27001:2022 | SOC 2 |
|---|---|---|
| What you get | A certificate, after a certification audit of your ISMS. | An attestation report with a practitioner's opinion. There is no certificate, and nothing is “SOC 2 certified”. |
| Who does it | A certification body. Accredited bodies work under ISO/IEC 17021-1 and ISO/IEC 27006-1. | An independent CPA firm, under the AICPA attestation standards (AT-C 105 and 205). Readiness work needs no CPA firm. |
| Period | No reporting period. Stage 2 evaluates implementation and effectiveness; surveillance audits follow at least once a calendar year. | Type 1: design of controls as of a date. Type 2: design plus operating effectiveness throughout a stated period. No minimum length is set; 3 to 12 months is market practice. |
| Lifespan | A three-year cycle: surveillance audits in years one and two, recertification before expiry. | No expiry. How old a report a customer accepts is the customer's own policy. |
| Core document | The Statement of Applicability: necessary controls, why they're included, whether each is implemented, and why any Annex A control is excluded. | The system description (DC1–DC9): services, commitments, system components and boundaries, incidents, controls, CUECs, subservice organizations, criteria not relevant, and significant changes (Type 2). |
| What's fixed | Clauses 4 to 10 can't be excluded. Annex A controls are selected through the SoA. | The common criteria always apply. You choose which other categories to add. A criterion that isn't relevant is disclosed with reasons (DC8). |
| What the reader sees | The certificate and its scope statement, plus the SoA if you share it. | The description and the opinion. A Type 2 in practice also sets out the tests of controls and their results, including deviations. |
Two consequences people miss. First, an ISO surveillance audit can’t produce a SOC 2 report: you need a separate CPA engagement, even if your certification body has an affiliated CPA firm. Second, a Type 2 covers the whole stated period: if a process changes halfway through, both the old and the new process are in scope, and the change may need disclosing (DC9).
What you can reuse
- Risk assessment. Your 6.1.2 process and register support CC3.1 and CC3.2. Add fraud risk for CC3.3.
- Your SoA control set. It’s a strong starting list for the controls in your system description (DC5). Map each control to the criterion that actually covers it.
- Policies and procedures. They map to CC5.3 and most of CC6 to CC8. Every figure in them, such as a deprovisioning window or patch deadline, becomes what the auditor tests.
- Internal audit and management review. Evidence from 9.2 and 9.3 supports CC4.
- Supplier and incident management. A.5.19 to A.5.23 support CC9.2; A.5.24 to A.5.28 support CC7.3 to CC7.5.
How to use this
- Decide scope first. Choose the categories, the system boundary and how each key vendor is presented (carve-out or inclusive). Your ISMS scope (4.3) is a guide, not the answer.
- Run a gap check on the “Partial” rows and any category you add beyond Security.
- Start collecting evidence before the Type 2 period opens. A Type 2 needs evidence that each control operated throughout the period, not only at audit time.
If you also handle card data, see how PCI DSS maps to ISO 27001: neither an ISO certificate nor a SOC 2 report is PCI DSS evidence. For how ISO 27001’s clauses, Annex A and SoA fit together, see how many requirements are in ISO 27001.
Compliance Colleague answers questions like “Which SOC 2 criteria does our ISO 27001 SoA leave uncovered, and what evidence would a Type 2 need?” with the clause, control or criterion cited. Try it free, no card required →
ISO/IEC 27001 is copyrighted by ISO and IEC, and the Trust Services Criteria by the AICPA. This guide cites numbers and short titles only and paraphrases everything else. The mapping is our own research aid, not an official crosswalk. Confirm against the official texts and with your auditor before relying on it. Not legal or audit advice.