SOC 2 to ISO 27001 Control Mapping: What Transfers and What's Net-New

The question arrives once a company closes its first European contract or a board-level prospect asks for ISO 27001 alongside the SOC 2 report: We already have SOC 2. How much of this is actually new work?

The short answer: your Security TSC work covers roughly 74 percent of ISO 27001:2022's 93 Annex A controls, with the strongest overlap in access control, system operations, and change management. Availability and Confidentiality TSC add moderate additional coverage. Processing Integrity has limited but real overlap. Privacy has the weakest mapping, because ISO 27001 covers PII through a single control (A 5.34) while the AICPA defines eight Privacy criteria.

What is genuinely net-new is not more controls. It is the management system wrapper: a Statement of Applicability documenting every control's inclusion justification and implementation status, a formal internal audit programme, a structured management review with required inputs and documented decisions, and a nonconformity tracking process. These have no SOC 2 equivalent and represent new work regardless of how mature your existing program is.

The mapping tables below cover every criterion across all five Trust Services Criteria. Each row identifies the relevant ISO 27001:2022 Annex A controls, the overlap type, and what SOC 2 evidence already in your possession is reusable for the ISO 27001 certification audit.

How to Read These Tables

Each row maps one SOC 2 criterion to its ISO 27001:2022 Annex A equivalents. The Overlap Type column uses three values:

• Full: The evidence you produce for SOC 2 satisfies the ISO 27001 requirement without adaptation. The same log, policy, or record goes into both audit packages.
• Partial: Existing evidence covers the intent but needs supplementing or reframing. Typically this means adding documented scope, extending a policy, or adding a step to an existing process.
• Additive: ISO 27001 requires something that SOC 2 does not address. These are net-new artifacts regardless of TSC scope.

Annex A control references use the format A 5.x (organizational), A 6.x (people), A 7.x (physical), A 8.x (technological). These are the same numbers in ISO 27001 and ISO 27002.

Security TSC: CC1 Through CC9

The Security TSC has the deepest ISO 27001 overlap. Every one of the 33 criteria in CC1 through CC9 maps to at least one Annex A control. The strongest alignment is in CC6 (Logical and Physical Access Controls), CC7 (System Operations), and CC8 (Change Management), where ISO 27001's technological controls (A 8.x) are direct counterparts. CC1 through CC5 map to organizational and people controls with somewhat less precision, since SOC 2's COSO-based framing and ISO 27001's management system framing approach governance from different angles.

Availability TSC: A1.1 to A1.3

The Availability TSC maps directly to ISO 27001's availability-related controls: capacity management (A 8.6), redundancy (A 8.14), backup (A 8.13), and the business continuity controls (A 5.29, A 5.30). If your SOC 2 scope includes Availability, the BCDR evidence is largely reusable for ISO 27001. The main gap is that A 5.30 (ICT readiness for business continuity) requires a more structured ICT continuity plan than BCDR tabletops alone typically demonstrate.

Confidentiality TSC: C1.1 and C1.2

The Confidentiality TSC maps to ISO 27001's information classification and deletion controls. C1.2 is a strong Full overlap: both frameworks require documented processes for disposing of confidential information when retention periods expire or on customer request. C1.1 is Partial because ISO 27001 adds two controls SOC 2 doesn't address at the same granularity: A 5.13 (labelling of information) requires that classification markings be physically or logically applied to information assets, and A 8.11 (data masking) requires explicit procedures for masking sensitive data in non-production environments.

Processing Integrity TSC: PI1.1 to PI1.5

Processing Integrity is where ISO 27001 coverage weakens. The AICPA's PI criteria address the accuracy, completeness, authorization, and timeliness of system processing. ISO 27001's application security controls (A 8.26 through A 8.29) address security of processing but are not designed to verify processing accuracy or completeness in the same way.

All five PI criteria map to Partial overlap: ISO 27001 touches the security dimensions of application processing but your SOC 2 PI evidence will demonstrate substantially more than ISO requires. The mapping is worth noting, but the unique value of PI TSC work lies in the AICPA attestation, not ISO 27001 certification.

Privacy TSC: P1.0 Through P8.0

The Privacy TSC has the weakest ISO 27001 mapping, and it runs in the less obvious direction: for several Privacy criteria, SOC 2 requires substantially more than ISO 27001. ISO 27001:2022 added one dedicated PII control in the 2022 revision (A 5.34: Privacy and protection of PII). That control acknowledges the need for privacy protections and requires an organization to identify and comply with applicable legal and regulatory requirements for PII, but it does not define notice mechanisms, consent requirements, data subject access rights, or enforcement procedures the way the AICPA's Privacy criteria do. ISO 27701 — the privacy extension to ISO 27001 — is the ISO framework that maps directly to these criteria; the dedicated ISO 27701 post covers that mapping in full.

The Privacy TSC is organized into eight topic areas (P1.0 through P8.0), each with individual sub-criteria. The table below maps each sub-criterion. The strongest overlap is in P6 (Disclosure and Notification), where ISO 27001's supplier management controls (A 5.19-5.22) and incident response controls (A 5.26) provide meaningful coverage across several sub-criteria.

What Percentage of ISO 27001:2022 Annex A Is Already Covered?

Based on the mapping tables above, here is the breakdown across all 93 Annex A controls:

Organizational controls (A 5.x, 37 controls): 32 of 37 have at least partial SOC 2 coverage. Five controls have no meaningful SOC 2 equivalent: A 5.5 (contact with authorities), A 5.6 (contact with special interest groups), A 5.11 (return of assets), A 5.31 (legal, statutory, and regulatory requirements), and A 5.32 (intellectual property rights). These are explicitly additive for any organization pursuing ISO 27001.

People controls (A 6.x, 8 controls): All 8 have at least partial SOC 2 coverage. A 6.7 (remote working) is the weakest mapping (CC6.6 covers encrypted remote access but not a documented remote working policy), but it is still Partial rather than net-new.

Physical controls (A 7.x, 14 controls): 8 of 14 typically have some SOC 2 coverage for organizations with physical or hybrid SOC 2 scope. For SaaS organizations with no on-premises infrastructure, 4 controls related to data center operations (A 7.5, A 7.11, A 7.12, A 7.13) are typically addressed by referencing the cloud provider's SOC 2 report or ISO 27001 certificate in the Statement of Applicability. The remaining 2 controls (A 7.7 clear desk/screen, A 7.8 equipment siting) apply to the organization's own office and employee devices and typically require implementing lightweight procedures rather than relying on provider documentation.

Technological controls (A 8.x, 34 controls): All 34 have at least partial SOC 2 coverage. Six are Partial rather than Full (A 8.11 data masking, A 8.12 DLP, A 8.17 clock synchronization, A 8.18 privileged utility programs, A 8.23 web filtering, A 8.34 protection during audit testing) because SOC 2 addresses the underlying control objective but less explicitly.

Summary across all 93 Annex A controls:

The 88 percent figure assumes Security TSC scope plus at least Availability and Confidentiality. For Security-only scope, coverage drops to roughly 74 percent, with the 14 percent gap coming primarily from controls addressed by Availability (A 8.6, A 8.13, A 8.14, A 5.29, A 5.30) and Confidentiality (A 5.12, A 5.13) TSCs.

What's Genuinely Net-New

ISMS Management Clauses (Clauses 4-10)

These are the most consistently underestimated part of adding ISO 27001. SOC 2 has no equivalent for any of them.

Clause 6.1: Risk assessment methodology. Both ISO 27001 and SOC 2 require documented risk assessments with likelihood and impact ratings and a treatment plan. The ISO 27001 delta is narrower than it looks: Clause 6.1.2 requires the methodology to formally define risk acceptance criteria and produce repeatable, consistent, valid, and comparable results across the full organizational scope. Your existing risk register and methodology likely satisfy most of this with minor extension. What is genuinely new is the Statement of Applicability (required by Clause 6.1.3): a document that lists all necessary controls, the justification for including each, whether each is implemented, and the justification for excluding any Annex A controls. The SoA has no SOC 2 equivalent.

Clause 9.2: Internal audit programme. ISO 27001 requires a documented internal audit programme with defined frequency, methods, responsibilities, planning requirements, and reporting. This is distinct from the control monitoring and vulnerability tracking your SOC 2 program produces. Typical SOC 2 programs have no structured internal audit function; building one takes 4-8 weeks for a first cycle.

Clause 9.3: Management review. ISO 27001 requires documented management review meetings at planned intervals, with required inputs including: status of actions from previous reviews, changes in external and internal issues, changes in interested party requirements, feedback on information security performance (nonconformities, monitoring results, audit results, objectives fulfilment), risk assessment results, and opportunities for improvement. The required output is documented decisions on continual improvement and any needed changes to the ISMS. SOC 2 board meeting minutes and security team records partially satisfy this, but the ISO standard requires this specific agenda structure with documented decisions as retained evidence.

Clauses 10.1 and 10.2: Continual improvement and nonconformity. Clause 10.1 is a one-sentence requirement that the organization continually improve the suitability, adequacy, and effectiveness of the ISMS. Clause 10.2 is the substantive one: it requires a documented process for identifying nonconformities, determining causes, implementing corrective actions, reviewing their effectiveness, and retaining documented evidence of each nonconformity and the actions taken. Your SOC 2 post-incident review process and vulnerability remediation workflow are directionally relevant but typically don't include the nonconformity tracking format (root cause, corrective action, effectiveness review) that ISO auditors expect.

Physical Controls for SaaS Organizations

The 6 physical controls without typical SaaS SOC 2 coverage split into two different situations.

A 7.5 (protecting against physical and environmental threats), A 7.11 (supporting utilities), A 7.12 (cabling security), and A 7.13 (equipment maintenance) apply to data center infrastructure. For SaaS organizations with no on-premises servers, these are typically marked as applicable in the SoA with the cloud provider's SOC 2 report or ISO 27001 certificate as supporting evidence. That's a legitimate approach in most scenarios, but it still requires explicit documentation: a justification statement, a reference to the provider's certification, and a review of what the provider's controls actually cover.

A 7.7 (clear desk and clear screen) and A 7.8 (equipment siting and protection) are different. These apply to the organization's own office environment and employee devices, not to cloud infrastructure. A SaaS company typically still has employees with laptops and workspaces, and an ISO auditor will expect a clear desk policy and documented equipment handling procedures regardless of where the servers live. These are usually lightweight to implement but cannot be delegated to the cloud provider.

Supply Chain Specifics (A 5.21)

A 5.21 (managing information security in the ICT supply chain) goes further than SOC 2's vendor management requirements. It requires an inventory of ICT suppliers, security requirements embedded in procurement contracts, and procedures for managing supplier-induced security incidents throughout the supply chain. Most SOC 2 vendor management programs address the top-tier vendors but don't document ICT supply chain security at this depth.

Timeline Impact

The typical timeline to ISO 27001 certification is 4-6 months for organizations with a mature SOC 2 program, versus 9-12 months from scratch. The 4-6 month estimate is primarily driven by building the ISMS management artifacts, completing an internal audit cycle, and scheduling the Stage 1 and Stage 2 external audits. The control implementation work, which dominates the timeline for greenfield programs, is largely done.

For a more detailed look at how the two frameworks relate structurally, including the differences in audit mechanics and certification timelines, see our post on ISO 27001 and SOC 2: How They Work Together (and Where They Don't).

Frequently Asked Questions

Can I use my SOC 2 evidence for the ISO 27001 certification audit?

Yes, for the controls that have Full overlap (access provisioning records, incident response evidence, change management approvals, encryption configurations, and vendor review records, among others). ISO 27001 auditors are conducting a different type of assessment than SOC 2 auditors, but they are looking for evidence of the same underlying operational practices. Where the mapping is Full, the same log or record goes into both audit packages. Where the mapping is Partial, existing evidence is a starting point that needs supplementing, not replaced. The artifacts with no reuse value are the ISMS management documents: the Statement of Applicability, internal audit reports, and management review records. These are ISO-specific and need to be built.

What is the difference between ISO 27001 and ISO 27002?

ISO 27001 defines the requirements for an information security management system and is what organizations certify against. Annex A of ISO 27001 contains 93 controls that the ISMS must address. ISO 27002 is the companion implementation guide: it uses the same 93 controls and the same numbering (5.x through 8.x) but provides detailed guidance on how to implement each one. You cannot certify to ISO 27002. When someone says "map ISO 27002 controls to SOC 2," they mean the same Annex A structure used in this post.

What is net-new in ISO 27001 if I already have SOC 2 Security TSC?

Four categories: (1) ISMS management clauses with no SOC 2 equivalent, including the Statement of Applicability (Clause 6.1.3), internal audit programme (Clause 9.2), management review process (Clause 9.3), and nonconformity and corrective action tracking (Clause 10.2); (2) five organizational controls with no SOC 2 equivalent (A 5.5, A 5.6, A 5.11, A 5.31, A 5.32); (3) physical controls for SaaS organizations, handled through documentation referencing your cloud provider's certification rather than new control builds; and (4) the ICT supply chain specifics of A 5.21, which go beyond typical SOC 2 vendor management.

Does adding Availability or Confidentiality TSC increase ISO 27001 overlap?

Yes, meaningfully. Security-only scope covers approximately 74 percent of Annex A controls (69 of 93). Adding Availability TSC adds coverage for A 8.6, A 8.13, A 8.14, A 5.29, and A 5.30. Adding Confidentiality TSC adds A 5.12, A 5.13, and partial coverage of A 8.11. Together, Security plus Availability plus Confidentiality brings coverage to approximately 82 of 93 controls (88 percent). Processing Integrity and Privacy add some incremental coverage but the gains are modest: PI TSC adds partial coverage of A 8.26-8.29, and Privacy TSC adds evidence for A 5.34.

Which ISO 27001 controls have no SOC 2 equivalent?

Eleven controls typically have no meaningful SOC 2 coverage in a SaaS program: A 5.5 (contact with authorities), A 5.6 (contact with special interest groups), A 5.11 (return of assets), A 5.31 (legal and regulatory requirements), A 5.32 (intellectual property rights), A 7.5 (protection against physical and environmental threats), A 7.7 (clear desk and clear screen), A 7.8 (equipment siting and protection), A 7.11 (supporting utilities), A 7.12 (cabling security), and A 7.13 (equipment maintenance). For the data center physical controls (A 7.5, A 7.11, A 7.12, A 7.13), SaaS organizations typically address these by referencing the cloud provider's SOC 2 or ISO 27001 certification in the SoA. A 7.7 and A 7.8 apply to the organization's own office and employee devices and typically require implementing lightweight procedures. The organizational controls (A 5.5, A 5.6, A 5.11, A 5.31, A 5.32) require new policy or procedural artifacts.

How long does adding ISO 27001 take if I already have SOC 2?

For organizations with a mature SOC 2 Type 2 program: 4-6 months from engagement kickoff to certification. The bulk of that time is building the ISMS management artifacts (6-8 weeks), completing an internal audit cycle (4 weeks), and scheduling the Stage 1 and Stage 2 external audits (4-8 weeks lead time with most certification bodies). Control implementation, which dominates the timeline for greenfield programs, is largely done. Compare this to 9-12 months for an organization without existing security controls. The SOC 2 program compresses the timeline by eliminating the implementation phase, not the audit and documentation phases.

Further Reading

• ISO 27001 and SOC 2: How They Work Together (and Where They Don't) - the structural comparison: scope differences, certification mechanics, and sequencing decisions
• SOC 2 Trust Services Criteria: A Practitioner's Guide - what each TSC actually requires
• SOC 2 vs ISO 27001: Key Differences and Shared Efficiencies - decision framework for which to pursue first
• SOC 2 and ISO 27001 FAQ - common questions addressed
• Building SOC 2 Evidence Architecture - how to design evidence collection so the same records serve multiple frameworks