# SOC 2 to ISO 27001 Control Mapping: What Transfers

Source: https://truvocyber.com/blog/iso-27001-soc-2-control-mapping
Published: 2026-05-12
Topic cluster: ISO 27001

> SOC 2 to ISO 27001 control mapping: every Trust Services Criterion mapped to Annex A, which SOC 2 evidence carries over, and what is new work for ISO 27001.

In our experience, a SOC 2 program covers roughly 70 percent of the work for ISO 27001 certification. The policies carry over, and most controls need only small adjustments. By direct mapping, the SOC 2 Security criteria (CC1 to CC9) cover 40 of the 93 Annex A controls in our mapping spreadsheet, 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.

Most of the net-new work 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.

ISO 27001 vs ISO 27002: What the difference means for this post

**ISO 27001** is the ISMS standard. It defines what your management system must do and what controls must be addressed. This is what organizations certify against. You cannot certify to ISO 27002.

**ISO 27002** is the implementation guide. It provides detailed guidance on how to implement each of the same 93 controls, using identical numbering (5.x, 6.x, 7.x, 8.x). When searches combine *ISO 27002 controls* with *SOC 2 mapping*, they mean the same Annex A control set. The controls are identical; 27002 explains them in greater depth.

All mapping tables in this post use the ISO 27001:2022 Annex A control numbers, which are the same in both documents.

Not sure where your ISO 27001 gaps are?

Answer 20 questions and get a personalized readiness score based on your existing security posture.
[Take the ISO 27001 Readiness Scorecard](/iso-27001-scorecard)

## 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.

Criteria ID
Criterion Name
ISO 27001:2022 Reference
Overlap Type
SOC 2 Evidence Already Reusable

[CC1.1](/blog/soc-2-cc1-1-integrity-ethical-values)
Commitment to integrity and ethical values
A 5.1, A 5.10, A 6.2
Partial
Code of Conduct, Acceptable Use Policy, policy acknowledgement records

[CC1.2](/blog/soc-2-cc1-2-board-oversight)
Board oversight of internal control
A 5.1, A 5.4
Partial
Board meeting minutes, IST charter, quarterly security team meeting records

[CC1.3](/blog/soc-2-cc1-3-structures-reporting-lines)
Management establishes structure and authority
A 5.2, A 5.4
Partial
Organizational chart, job descriptions with security responsibilities, ISM role documentation

[CC1.4](/blog/soc-2-cc1-4-commitment-to-competence)
Commitment to competence
A 6.1, A 6.2, A 6.3, A 6.6
Full
Background check records, security awareness training completion, confidentiality agreements, performance reviews

[CC1.5](/blog/soc-2-cc1-5-accountability)
Enforcement of accountability
A 5.4, A 6.4
Full
Disciplinary process documentation, performance review policy, security team meeting records

[CC2.1](/blog/soc-2-cc2-1-information-quality)
Information quality
A 5.37
Partial
Risk assessment records, vulnerability scan reports, internal control monitoring evidence

[CC2.2](/blog/soc-2-cc2-2-internal-communication)
Internal communication of responsibilities
A 5.37, A 5.4
Partial
Incident Response Plan, IR notification records, organizational chart, security meeting minutes

[CC2.3](/blog/soc-2-cc2-3-external-communication)
External communication
A 5.14, A 5.6
Partial
Terms of Service, Privacy Policy, security commitments page, system description

[CC3.1](/blog/soc-2-cc3-1-objectives)
Specifying objectives
ISO 27001 Clause 6.1.2, A 5.7
Full
Risk Assessment Policy, risk assessment report, risk register

[CC3.2](/blog/soc-2-cc3-2-risk-identification)
Identifying and analyzing risks
ISO 27001 Clause 6.1.2, Clause 6.1.3
Full
Risk register with likelihood/impact ratings, risk treatment plan

[CC3.3](/blog/soc-2-cc3-3-fraud-risk)
Fraud risk assessment
ISO 27001 Clause 6.1.2
Partial
Risk assessment (if fraud is listed as a threat category), Code of Conduct

[CC3.4](/blog/soc-2-cc3-4-change-assessment)
Identifying and assessing significant changes
ISO 27001 Clause 6.1.2, Clause 6.1.3, A 5.8
Full
Vendor risk assessment process, change-triggered risk reviews, risk register update cadence

[CC4.1](/blog/soc-2-cc4-1-monitoring-evaluations)
Selecting and developing monitoring activities
A 5.35
Partial
Vulnerability scanning cadence, penetration test results, internal control monitoring reports

[CC4.2](/blog/soc-2-cc4-2-deficiency-communication)
Evaluating deficiencies
A 5.35, A 5.36
Partial
Vulnerability tracking records, security team meeting minutes with action items, post-incident reviews

[CC5.1](/blog/soc-2-cc5-1-control-selection)
Selecting control activities to mitigate risk
ISO 27001 Clause 6.1.3
Partial
Risk register with treatment decisions. Note: Statement of Applicability is ISO-specific and net-new.

[CC5.2](/blog/soc-2-cc5-2-technology-general-controls)
Technology general controls
A 5.3, A 8.x broadly
Full
Baseline configuration records, SAST/DAST/SCA scan results, access control configurations, role separation evidence

[CC5.3](/blog/soc-2-cc5-3-policies-procedures)
Policies and procedures deployed
A 5.1, A 5.10, A 5.37
Full
Full policy library, annual acknowledgement records, policy review evidence

CC6.1
Restricts logical and physical access
A 5.15, A 5.16, A 5.17, A 5.18, A 8.3, A 8.5
Full
RBAC matrix, MFA configuration screenshots, asset inventory with owners, unique user ID records

CC6.2
Manages new access and provisioning
A 5.18, A 6.5
Full
Provisioning workflow records, user access review reports, access change approvals

CC6.3
Removes access
A 5.15, A 5.18, A 8.2
Full
Offboarding checklists, access removal confirmations, SSH key revocation records

CC6.4
Restricts physical access
A 7.1, A 7.2, A 7.3, A 7.4
Full
Physical access logs, visitor sign-in records, physical access review records. For SaaS orgs, cloud provider SOC 2 reports.

[CC6.5](/blog/soc-2-cc6-5-asset-disposal)
Logical access security measures (data protection)
A 8.10, A 7.14
Full
Data Retention and Disposal Policy, customer data deletion records, storage media disposal procedures

[CC6.6](/blog/soc-2-cc6-6-boundary-protection)
Restricts external access and transmission
A 8.20, A 8.21, A 8.22, A 5.14
Full
Network security group configurations, firewall rules, VPN configurations, MFA for remote access records

[CC6.7](/blog/soc-2-cc6-7-data-transmission)
Manages security for transmitted and stored data
A 8.24, A 8.1
Full
Encryption at rest/in transit configurations, key management records, disk encryption evidence, Encryption Policy

[CC6.8](/blog/soc-2-cc6-8-malware-prevention)
Controls detect threats from malicious software
A 8.7, A 8.8, A 8.25, A 8.26-8.29
Full
SAST/DAST/SCA/container scanning results in CI/CD, code change approvals, antivirus configurations, baseline configuration records

CC7.1
Detects and monitors security vulnerabilities
A 8.8, A 5.7
Full
Internal/external vulnerability scan reports, pen test results, vulnerability tracking records, threat detection alerts

CC7.2
Monitors system components for anomalies
A 8.15, A 8.16, A 8.17
Full
SIEM alert evidence, infrastructure monitoring dashboards, log retention records, alerting configuration

CC7.3
Evaluates security events
A 5.24, A 5.25
Full
Incident Response Plan, incident tracking log, escalation procedures

CC7.4
Responds to security incidents
A 5.26, A 5.28
Full
Incident tracking and resolution records, post-incident reviews (lessons learned), IR tabletop exercises

CC7.5
Recovery activities
A 5.27, A 8.13, A 8.14
Full
BCDR Plan, backup restoration tests, BCDR tabletop records, high availability configuration

CC8.1
Change management
A 8.32, A 8.31, A 8.33
Full
Change approval records, PR templates with required reviews, test environment segregation, change management policy

CC9.1
Risk mitigation (business disruption)
A 5.29, A 8.14
Partial
BCDR Policy, cybersecurity insurance documentation, high availability configuration. Note: A 5.29 requires documented business continuity plans; extend, don't replace.

CC9.2
Vendor and business partner risk
A 5.19, A 5.20, A 5.21, A 5.22
Full
Vendor Risk Management Policy, vendor security assessments, vendor SOC 2 review records, vendor confidentiality agreements

**Notable gap in CC3 and CC5:** The Statement of Applicability (SoA) is an ISO 27001 artifact required by Clause 6.1.3 with no SOC 2 equivalent. It lists all necessary controls, the justification for including each, whether each is implemented, and the justification for excluding any Annex A controls. Even if all your controls are fully implemented, building the SoA for the first time is net-new work.

## 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](https://truvocyber.com/blog/soc-2-scoping) 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.

Criteria ID
Criterion Name
ISO 27001:2022 Reference
Overlap Type
SOC 2 Evidence Already Reusable

A1.1
Manages processing capacity and system components to meet objectives
A 8.6
Full
Uptime monitoring records, high availability configuration, capacity planning documentation

A1.2
Maintains environmental protections, backup processes, and recovery infrastructure
A 7.5, A 7.11, A 8.14
Partial
High availability configuration evidence. For SaaS orgs, cloud provider SOC 2 reports cover most of A 7.5 and A 7.11; the ISO 27001 ISMS must explicitly document this reliance in the SoA.

A1.3
Tests recovery plan procedures supporting system recovery
A 8.13, A 5.29, A 5.30
Full
BCDR Plan, backup configurations, backup restoration test records, BCDR tabletop exercises

## 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.

Criteria ID
Criterion Name
ISO 27001:2022 Reference
Overlap Type
SOC 2 Evidence Already Reusable

C1.1
Identifies and maintains confidential information to meet confidentiality objectives
A 5.12, A 5.13, A 8.11, A 8.12
Partial
Data Classification Policy, data access restriction records. Extend with documented labelling procedures and explicit data masking controls for non-production environments.

C1.2
Disposes of confidential information to meet confidentiality objectives
A 8.10, A 7.14
Full
Data Retention and Disposal Policy, customer data deletion records, end-user data deletion records, storage media disposal procedures

## 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.

For compute and AI infrastructure providers, the guide to [SOC 2 Processing Integrity for compute providers](https://truvocyber.com/blog/soc-2-processing-integrity-compute-providers) covers what PI1.1 to PI1.5 ask and the evidence for each.

Criteria ID
Criterion Name
ISO 27001:2022 Reference
Overlap Type
SOC 2 Evidence Already Reusable

PI1.1
Communicates relevant, quality information about processing objectives and specifications
A 8.26, A 8.28
Partial
Input validation configurations, data input monitoring controls. ISO 27001 focuses on security of these mechanisms, not processing accuracy.

PI1.2
Controls system inputs for completeness and accuracy
A 8.26, A 8.27
Partial
System processing documentation, architecture records. ISO 27001 auditors look at security of system design, not functional correctness.

PI1.3
Controls system processing to produce products, services, and reporting that meet objectives
A 8.26, A 8.16
Partial
Automated monitoring alerts, error resolution records, SLA tracking. ISO 27001 monitoring (A 8.16) covers security events, not processing errors specifically.

PI1.4
Delivers output completely, accurately, and timely per specifications
A 8.26
Partial
Output integrity testing records, report completeness tests. Very limited ISO 27001 equivalent.

PI1.5
Stores inputs, items in processing, and outputs completely, accurately, and timely per system specifications
A 8.26, A 8.9
Partial
Encrypted output configurations, access controls on report extraction. A 8.9 covers configuration management of systems producing outputs.

## Privacy TSC: P1.0 Through P8.0

The Privacy TSC has the weakest ISO 27001 mapping, and it goes 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.

Criteria ID
Criterion Name
ISO 27001:2022 Reference
Overlap Type
SOC 2 Evidence Already Reusable

P1.1
Provides notice to data subjects about privacy practices
A 5.34
Partial
Privacy Policy, cookie notices, privacy notice at collection. A 5.34 requires awareness of applicable regulations but does not mandate specific notice mechanisms or formats.

P2.1
Communicates choices regarding collection, use, retention, disclosure, and disposal of personal information
No direct Annex A equivalent
Additive
Consent management records, opt-in/opt-out mechanisms, preference center configurations. ISO 27001 does not define consent mechanisms or data subject choice rights.

P3.1
Collects personal information consistent with privacy objectives
No direct Annex A equivalent
Additive
Records of processing activities, data inventory, purpose limitation documentation. ISO 27001 does not specify collection limitations or purpose specifications.

P3.2
Obtains explicit consent where required for collection
No direct Annex A equivalent
Additive
Consent forms, consent management system records, explicit consent workflow documentation. No ISO 27001 Annex A equivalent.

P4.1
Limits use of personal information to identified purposes
No direct Annex A equivalent
Additive
Data use limitation policy, access controls on internal use of PII. A 5.34 acknowledges applicable privacy requirements but does not define use limitation.

P4.2
Retains personal information consistent with privacy objectives
A 5.34, A 8.10
Partial
Data Retention Policy, retention schedules per data category. A 8.10 addresses deletion but not purpose-based retention rules.

P4.3
Securely disposes of personal information
A 8.10, A 7.14
Full
Data deletion records, customer data deletion workflows, storage media disposal procedures

P5.1
Grants data subjects ability to access their stored personal information
No direct Annex A equivalent
Additive
DSAR handling procedures and response records. ISO 27001 does not define data subject access rights.

P5.2
Corrects, amends, or appends personal information based on data subject requests
No direct Annex A equivalent
Additive
DSAR correction records, amendment request workflows. No ISO 27001 Annex A equivalent.

P6.1
Discloses personal information to third parties only with explicit consent or lawful basis
A 5.19, A 5.20, A 5.14
Partial
Vendor Risk Management Policy, DPAs, information transfer agreements. ISO 27001 covers third-party security requirements, not the consent or lawful basis dimension of disclosure.

P6.2
Creates and retains records of authorized disclosures
A 5.19, A 5.20
Partial
Vendor access logs, disclosure tracking records. ISO 27001 supplier controls address contractual requirements but not disclosure audit trails specifically.

P6.3
Creates and retains records of detected or reported unauthorized disclosures
A 5.24, A 5.25, A 5.26
Partial
Incident tracking log, breach records. ISO 27001 incident response covers detection and recording but scope is security events broadly, not privacy breaches specifically.

P6.4
Obtains privacy commitments from vendors with access to personal information
A 5.19, A 5.20, A 5.22
Full
Vendor DPAs, privacy addenda in vendor contracts, vendor security assessment records

P6.5
Obtains vendor commitments to notify of unauthorized disclosures
A 5.19, A 5.22
Partial
Vendor contract notification clauses, vendor review records. A 5.22 covers ongoing oversight but not the specific notification commitment requirement.

P6.6
Provides breach and incident notifications to data subjects, regulators, and others
A 5.26, A 5.28
Partial
Breach notification procedures, notification templates. ISO 27001 covers incident response but does not specify notification to data subjects or regulators.

P6.7
Provides data subjects with an accounting of personal information held, upon request
No direct Annex A equivalent
Additive
DSAR accounting records, data portability exports. No ISO 27001 Annex A equivalent.

P7.1
Collects and maintains accurate, up-to-date, complete, and relevant personal information
No direct Annex A equivalent
Additive
Data quality processes, accuracy validation procedures. ISO 27001 has no control addressing personal information accuracy or correction rights.

P8.1
Implements a process for receiving, addressing, and resolving privacy inquiries, complaints, and disputes
A 5.34, A 5.36
Partial
Privacy policy review records, complaint handling procedures, privacy council meeting records. A 5.36 covers compliance monitoring broadly but not privacy-specific complaint resolution.

**ISO 27001 alone does not close the Privacy gap.**

For 9 of the 18 Privacy sub-criteria (P2.1, P3.1, P3.2, P4.1, P5.1, P5.2, P6.7, P7.1, and parts of P8.1), ISO 27001 Annex A has no equivalent control. The ISO framework that maps directly to these criteria is ISO 27701, which extends the ISMS with a Privacy Information Management System (PIMS): consent, data subject rights, purpose limitation, privacy by design, and cross-border PII transfer controls. Organizations pursuing both SOC 2 Privacy scope and ISO privacy certification need ISO 27701 alongside ISO 27001. The dedicated ISO 27701 post covers the full Privacy TSC to ISO 27701 control mapping.

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

In our mapping spreadsheet, the SOC 2 Security criteria (CC1 to CC9) map directly to 40 of the 93 Annex A controls, about 43 percent. The other 53 have no direct Security criterion and count as new work for a SOC 2 holder, alongside the ISMS clauses covered in the next section.

Annex A themeControlsCovered directly by SOC 2 Security criteriaNo direct SOC 2 criterion
Organizational (A.5)3720 (54%)17
People (A.6)84 (50%)4
Physical (A.7)144 (29%)10
Technological (A.8)3412 (35%)22
**Total****93****40 (43%)****53**

**Organizational (A.5):** the 17 without a direct criterion are A.5.4, A.5.5, A.5.7, A.5.9, A.5.10, A.5.12, A.5.13, A.5.14, A.5.17, A.5.21, A.5.23, A.5.24, A.5.28, A.5.32, A.5.33, A.5.34 and A.5.36.

**People (A.6):** A.6.5 (responsibilities after termination), A.6.6 (confidentiality agreements), A.6.7 (remote working) and A.6.8 (event reporting).

**Physical (A.7):** A.7.3 to A.7.9 and A.7.11 to A.7.13. Perimeter, entry, storage media and secure disposal (A.7.1, A.7.2, A.7.10, A.7.14) map to CC6.4 and CC6.5.

**Technological (A.8):** A.8.1, A.8.3 to A.8.6, A.8.10, A.8.11, A.8.13, A.8.14, A.8.17, A.8.18, A.8.21, A.8.22, A.8.25 to A.8.31, A.8.33 and A.8.34.

Free · Google Sheet

ISO 27001 vs SOC 2 Control Mapping Spreadsheet

Every SOC 2 Common Criterion mapped to ISO 27001:2022 Annex A, all 93 Annex A controls mapped back to SOC 2 with what a SOC 2 holder still has to build, and two sample control sets, kept current in a shared Google Sheet. Enter your email to open it.

(function initLmMapping(){ if (window.hbspt && window.hbspt.forms) { window.hbspt.forms.create({ region: "na3", portalId: "341945322", formId: "760ef504-5a85-46c1-b4c3-5c526bd65f3b", target: "#lm-soc2-iso-mapping-form", css: "" }); } else { setTimeout(initLmMapping, 200); } })();

**What "covered" means here**

The spreadsheet counts a control as covered only when a SOC 2 Security criterion maps to it directly. Many of the other 53 still benefit from SOC 2 work: Availability criteria produce evidence for capacity, backup and redundancy (A.8.6, A.8.13, A.8.14), Confidentiality criteria for classification and labelling (A.5.12, A.5.13), and existing authentication and secure development controls often go a long way toward A.8.5 and A.8.25. Treat that as partial reuse, and confirm every control in the Statement of Applicability with your certification body.

## What's Net-New in ISO 27001 for a SOC 2 Holder

### 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 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 separate 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

Ten physical controls have no direct SOC 2 Security criterion in our mapping. Six of them need the most attention in a SaaS program, and they split into two 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 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.

Companies still building their first SOC 2 program can plan for ISO 27001 from the start through [SOC 2 compliance consulting](https://truvocyber.com/services/soc-2-compliance).

For SOC 2 holders budgeting that remaining work, the [ISO 27001 cost breakdown](https://truvocyber.com/blog/iso-27001-cost) lists 2026 prices for the internal audit and the certification body.

For a more detailed look at how the two frameworks relate, including the differences in audit mechanics and certification timelines, see our post on [SOC 2 vs ISO 27001: What Carries Over and How to Do Both](/blog/soc-2-vs.iso-27001-key-differences-shared-efficiencies).

Teams that need the certificate on a deadline can run the ISMS build through the [ISO 27001 Accelerator](https://truvocyber.com/iso-27001-accelerator), a fixed-price, done-with-you program with one dedicated consultant.

### Adding ISO 27001 to your SOC 2 program?

We assess your posture, map what transfers, and build only the net-new work toward an effective security program.

[Book Your Strategy Call](/contact-us)

## 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) Annex A controls without a direct SOC 2 Security criterion, 53 of 93 in our mapping spreadsheet, such as threat intelligence (A 5.7), classification and labelling (A 5.12, A 5.13), contact with authorities (A 5.5) and intellectual property (A 5.32); (3) physical controls for SaaS organizations, handled by documenting your cloud provider's certification as the evidence; 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. In our mapping spreadsheet, the Security criteria alone map directly to 40 of 93 Annex A controls. Availability criteria add evidence for capacity, backup and redundancy (A 8.6, A 8.13, A 8.14), and Confidentiality criteria add evidence for classification and labelling (A 5.12, A 5.13) and partial coverage of data masking (A 8.11). Processing Integrity adds partial coverage of A 8.26 to A 8.29, and Privacy adds evidence for A 5.34. Confirm each control in the Statement of Applicability.

#### Which ISO 27001 controls have no SOC 2 equivalent?

In our mapping spreadsheet, 53 of the 93 Annex A controls have no direct SOC 2 Security criterion: 17 organizational, 4 people, 10 physical and 22 technological. The downloadable sheet lists each one with what a SOC 2 holder still has to build. For SaaS organizations, the data center controls (A 7.5, A 7.11, A 7.12, A 7.13) are typically addressed by referencing the cloud provider's SOC 2 or ISO 27001 certification in the Statement of Applicability, while A 7.7 and A 7.8 cover the organization's own office and devices and need lightweight procedures.

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

For organizations with a mature [SOC 2 Type 2](https://truvocyber.com/blog/what-is-a-soc-2-type-2-report-and-why-is-it-important) 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 to SOC 2 Control Mapping: All 93 Annex A Controls](/blog/iso-27001-to-soc-2-mapping) - the same mapping starting from each Annex A control, rated Full, Partial, or Not covered

- [SOC 2 vs ISO 27001: What Carries Over and How to Do Both](/blog/soc-2-vs.iso-27001-key-differences-shared-efficiencies) - scope differences, certification mechanics, and sequencing decisions

- [Does my company need SOC 2 or ISO 27001?](/blog/iso-27001-vs-soc2-which-first) - how customer geography and the sales pipeline decide which framework comes first

- [SOC 2 Trust Services Criteria: A Practitioner's Guide](/blog/soc-2-trust-services-criteria-guide) - what each Trust Services Criterion requires

- [Building SOC 2 Evidence Architecture](/blog/soc2-security-documentation) - how to design evidence collection so the same records serve multiple frameworks

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Can I use my SOC 2 evidence for the ISO 27001 certification audit?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes, for controls with Full overlap - access provisioning records, incident response evidence, change management approvals, encryption configurations, and vendor review records, among others. Where the mapping is Full, the same log or record goes into both audit packages. Where it is Partial, existing evidence is a starting point that needs supplementing. The artifacts with no reuse value are ISO-specific ISMS documents: the Statement of Applicability, internal audit reports, and management review records."
      }
    },
    {
      "@type": "Question",
      "name": "What is the difference between ISO 27001 and ISO 27002?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "ISO 27001 defines the requirements for an information security management system and is what organizations certify against. ISO 27002 is the companion implementation guide with the same 93 controls and the same numbering. You cannot certify to ISO 27002. When someone searches for ISO 27002 controls mapped to SOC 2, they mean the same Annex A control set."
      }
    },
    {
      "@type": "Question",
      "name": "What is net-new in ISO 27001 if I already have SOC 2 Security TSC?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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) Annex A controls without a direct SOC 2 Security criterion, 53 of 93 in our mapping spreadsheet, such as threat intelligence (A 5.7), classification and labelling (A 5.12, A 5.13), contact with authorities (A 5.5) and intellectual property (A 5.32); (3) physical controls for SaaS organizations, handled by documenting your cloud provider's certification as the evidence; and (4) the ICT supply chain specifics of A 5.21, which go beyond typical SOC 2 vendor management."
      }
    },
    {
      "@type": "Question",
      "name": "Does adding Availability or Confidentiality TSC to SOC 2 increase ISO 27001 overlap?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. In our mapping spreadsheet, the Security criteria alone map directly to 40 of 93 Annex A controls. Availability criteria add evidence for capacity, backup and redundancy (A 8.6, A 8.13, A 8.14), and Confidentiality criteria add evidence for classification and labelling (A 5.12, A 5.13) and partial coverage of data masking (A 8.11). Processing Integrity adds partial coverage of A 8.26 to A 8.29, and Privacy adds evidence for A 5.34. Confirm each control in the Statement of Applicability."
      }
    },
    {
      "@type": "Question",
      "name": "Which ISO 27001 controls have no SOC 2 equivalent?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "In our mapping spreadsheet, 53 of the 93 Annex A controls have no direct SOC 2 Security criterion: 17 organizational, 4 people, 10 physical and 22 technological. The downloadable sheet lists each one with what a SOC 2 holder still has to build. For SaaS organizations, the data center controls (A 7.5, A 7.11, A 7.12, A 7.13) are typically addressed by referencing the cloud provider's SOC 2 or ISO 27001 certification in the Statement of Applicability, while A 7.7 and A 7.8 cover the organization's own office and devices and need lightweight procedures."
      }
    },
    {
      "@type": "Question",
      "name": "How long does adding ISO 27001 take if I already have SOC 2?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "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 Stage 1 and Stage 2 external audits. Compare this to 9-12 months for organizations without existing security controls. The SOC 2 program compresses the timeline by eliminating the implementation phase, not the audit and documentation phases."
      }
    }
  ]
}