The most popular advice about SOC 2 to ISO 27001 mapping is to find the overlap, reuse your evidence, and concentrate on the gaps. That advice skips the decision that matters most: whether a particular record proves the same objective, for the same assets, under both frameworks.
For a penetration-testing provider or audit firm, the deliverable should be a defensible crosswalk row, not an overlap percentage. Each row needs a SOC 2 criterion, an ISO reference, an alignment level, and an evidence-reuse decision. Only then can a compliance team identify the net-new work without overstating what a penetration test proves.
Table of Contents
- What a SOC 2 to ISO 27001 Mapping Proves and Which ISO Edition to Use
- Governance and Risk Criteria Crosswalk
- Access Control and Infrastructure Crosswalk
- Operations, Change and Vendor Controls Crosswalk
- Where a Penetration Test Fits in the Mapping
- ISO Clauses SOC 2 Cannot Give You
- Audit References Every Mapping Row Should Cite
- Build Your Mapping Workbook Before the Audit Window
What a SOC 2 to ISO 27001 Mapping Proves and Which ISO Edition to Use
A mapping isn't a one-to-one conversion. The authoritative starting point is the AICPA's official framework crosswalk, which compares the 2017 Trust Services Criteria with ISO 27001 and incorporates the March 2020 TSC updates.
The frameworks ask different questions. SOC 2 evaluates controls supporting service commitments for a defined system, with operating-effectiveness testing over the examination period for a Type 2 engagement. ISO 27001 evaluates an information security management system, including its requirements and the controls selected through risk treatment.
A pentest report can contribute evidence to both. It can't establish either form of assurance by itself.
Choose the edition before mapping controls
Use ISO/IEC 27001:2022 as the default workbook edition. The ANSI National Accreditation Board comparison identifies 93 Annex A controls in four themes, compared with 114 controls in 14 categories in the 2013 edition; it also describes 56 legacy controls merged into 24 and 11 new controls.
Those changes aren't merely renumbering. Additions such as Annex A 5.7, Threat intelligence, and Annex A 8.28, Secure coding, need explicit consideration when assessing web, network, and cloud testing evidence. Keep legacy references only where a customer's documentation still uses the earlier edition, and label them clearly.
For control interpretation, use the ISO 27001:2022 resource guide alongside the organization's controlled copy of the standard. For environments with visitor networks, the guest Wi-Fi compliance guidance from Splash Access provides a useful implementation context for discussing guest access and network separation. Neither resource replaces the organization's applicability decision.
Define alignment before claiming coverage
The AICPA Trust Services Criteria document provides the criteria against which service-organization controls are evaluated. A practical crosswalk connects each criterion to an ISO clause or Annex A reference, a shared control objective, and evidence with an effectiveness test.
Alignment levels used in a SOC 2 to ISO 27001 crosswalk
| Alignment level | What it means | Example | Required follow-up |
|---|---|---|---|
| Direct | Same control objective and same evidence satisfy both frameworks | Quarterly user access review | Reuse the review record and cite both references |
| Partial | Shared objective, but ISO requires more than SOC 2 tests | Vulnerability management | Add a risk treatment decision and a named owner |
| Related | Topics overlap, but no shared test or evidence exists | Security policy wording | Align wording and create an ISO-specific document |
| Not covered | Requirement has no SOC 2 counterpart | ISMS scope and management review | Build as a net-new process with its own records |
Direct is a row-level conclusion, not automatic approval of the entire referenced ISO control. The reviewer must still confirm population, scope, test design, and evidence completeness.
Overlap percentages demonstrate why definitions matter. A 2024 framework-mapping analysis published by Top Floor Security reported shared NIST SP 800-53 mappings representing 83% of ISO-mapped controls but 15% of SOC 2-mapped controls. A 2024 comparison by Moore Colson estimated that more than 50%, often upwards of 70%, of ISO/IEC 27001:2022 controls map to the TSC.
Neither result is a conversion rate. An indirect mapping through another framework, a shared objective, and reusable audit evidence are different measures.
Finally, compare boundaries before accepting any row. A SOC 2 system description may cover a particular service, while the certified ISMS boundary may include additional teams, locations, or supporting processes. Evidence doesn't become portable merely because the control names resemble each other.
Governance and Risk Criteria Crosswalk
A 2024 mapping analysis from Truvo Cyber reported that 20 of ISO/IEC 27001:2022's 37 organizational controls mapped directly to SOC 2's Security criterion. That finding supports looking for governance reuse, but it doesn't establish that every governance record is audit-ready.
The following alignments are working classifications for the stated objectives. ISO references without the word “Clause” refer to Annex A.
SOC 2 governance and risk criteria mapped to ISO 27001
| SOC 2 criterion | Control objective | ISO 27001 reference | Alignment |
|---|---|---|---|
| CC1.1 Integrity and ethical values | Code of conduct is defined and enforced | Annex A 5.1 Policies for information security; 6.4 Disciplinary process | Partial |
| CC1.4 Commitment to competence | Personnel hold skills needed for security roles | Annex A 6.3 Information security awareness, education and training | Direct |
| CC2.2 Internal communication | Security responsibilities are communicated | Annex A 5.1 Policies; 5.4 Management responsibilities | Partial |
| CC3.2 Risk identification | Risks to objectives are identified and assessed | Clause 6.1.2 Information security risk assessment | Direct |
| CC3.4 Change in environment | Risk is reassessed after significant change | Clause 6.1.2 with Clause 6.1.3 Risk treatment | Partial |
| CC4.1 Ongoing and separate evaluations | Controls are evaluated, with penetration testing cited as an example | Clause 9.1 Monitoring, measurement and evaluation; Annex A 5.35 Independent review | Partial |
| CC4.2 Deficiency communication | Control gaps are reported and remediated | Clause 10.2 Nonconformity and corrective action | Direct |
| CC5.2 Technology general controls | IT controls are selected and deployed | Annex A 5.37 Documented operating procedures; 8.9 Configuration management | Partial |
| CC5.3 Policies and procedures | Policies are established and put into practice | Annex A 5.1 Policies; 5.36 Compliance with policies | Direct |
Reuse records by purpose
For CC1.1, CC2.2, and CC5.3, collect the signed policy set, approval history, distribution records, and acknowledgments. A code of conduct supports ethical expectations, but it doesn't necessarily establish the information-security policy commitments or management responsibilities needed for the ISO references.
For CC1.4, reuse training completion logs and role-specific competence evidence. A pentester's general awareness certificate doesn't demonstrate competence to conduct an authorized cloud exploitation assessment. Match the evidence to the assigned role.
For CC3.2 and CC3.4, preserve dated risk-register entries and the change that triggered reassessment. A new customer-facing API, identity-provider migration, or revised testing infrastructure should have an identifiable risk decision, not just a modified spreadsheet timestamp.
Distinguish evaluation from corrective action
The OX Security explanation of SOC 2 penetration testing notes that CC4.1 presents penetration testing as an example of ongoing or separate evaluation, not a compulsory test for every engagement. Reuse the evaluation plan, test report, management assessment, and resulting actions.
CC4.2's Direct classification applies to the deficiency-reporting objective. If the record lacks root-cause analysis or an effectiveness review, it doesn't establish the complete ISO corrective-action requirement.
Practical rule: A Partial row needs a defined addition, such as a treatment decision, accountable owner, or applicability entry. “More documentation” isn't an actionable gap.
This is a starting crosswalk, not the complete governance inventory. Add CC3.1 objectives against Clause 6.2 as Partial, plus CC2.1 information quality and CC5.1 control activities, before calling the workbook complete. Processing Integrity and Privacy belong in the mapping only when selected in the system description; the SOC 2 compliance framework guide can help teams organize that selection.
Access Control and Infrastructure Crosswalk
An access-review export can support several criteria, but only if the reviewer can distinguish the tests performed. The same file might show approved identities, timely removal, and privileged-role review. Those are separate assertions, even when the compliance team stores them together.
For penetration-testing firms, include the infrastructure used to reach customer environments. Test accounts, remote-access services, privileged orchestration identities, and customer evidence stores need explicit control ownership.
SOC 2 access and infrastructure criteria mapped to ISO 27001
| SOC 2 criterion | Control objective | ISO 27001 reference | Alignment |
|---|---|---|---|
| CC6.1 Logical access security | Access to protected assets is restricted | Annex A 5.15 Access control; 5.16 Identity management; 8.5 Secure authentication | Direct |
| CC6.2 Access provisioning and removal | Accounts are approved, changed and revoked on time | Annex A 5.18 Access rights; 6.5 Responsibilities after termination | Direct |
| CC6.3 Role-based access | Least privilege is enforced by role | Annex A 5.18 Access rights; 8.2 Privileged access rights | Direct |
| CC6.4 Physical access restriction | Facility access is limited to authorized people | Annex A 7.1 Physical security perimeters; 7.2 Physical entry | Direct |
| CC6.5 Asset disposal | Data is removed before equipment is disposed of | Annex A 7.14 Secure disposal or re-use of equipment; 8.10 Information deletion | Direct |
| CC6.6 External threat boundary | Network boundary is protected against external threats | Annex A 8.20 Networks security; 8.22 Segregation of networks | Partial |
| CC6.7 Transmission protection | Data in transit is protected | Annex A 5.14 Information transfer; 8.24 Use of cryptography | Partial |
| CC6.8 Malware prevention | Malicious code is prevented or detected | Annex A 8.7 Protection against malware | Direct |
Assemble identity and asset evidence
Start with CC6.1 through CC6.3. Reuse identity-provider exports, approval tickets, role definitions, and revocation records, then test whether the population includes service accounts and privileged identities. Annex A 5.17, Authentication information, is also relevant where the test evaluates credential allocation, handling, or protection.
An access-review export for CC6.2 should identify the account, application, reviewer, decision, and completion evidence. Don't treat an unchecked list of users as a completed review, and don't confuse the table's operational shorthand with the full wording of each TSC criterion.
For physical access, collect authorized-person lists and entry records rather than substituting an application login report. For disposal, retain the asset identifier, deletion or destruction method, authorization, and completion record. A successful penetration test won't establish either of these administrative processes.
Preserve design decisions behind technical tests
A segregated-network diagram supports Annex A 8.22 when it identifies trust boundaries, permitted paths, and the customer environments those paths protect. Pair it with firewall-rule evidence and an authorized segmentation test. A diagram alone shows intended design, while the test shows observed behavior.
For CC6.7, a TLS configuration report can support transmission-protection evidence for the tested endpoint. Add the cryptographic policy, certificate-management responsibilities, and information-transfer rules to address the broader ISO objective.
Malware evidence should connect deployed protection with operating records, such as alert handling and endpoint coverage. A screenshot showing an installed agent doesn't establish that the team responds to detections.
A successful boundary test proves something about the path tested. It doesn't prove that the organization identified every trust boundary.
Use the technological Annex A 8.x numbering consistently in the workbook. Mixing legacy identifiers into current rows makes an otherwise valid test difficult to trace.
Operations, Change and Vendor Controls Crosswalk
Vulnerability detection is where similar language can conceal different evidence requirements. A finding demonstrates an observed weakness; vulnerability management also needs exposure evaluation, assigned action, and a defensible disposition.
Monitoring, response, and change records can provide more direct reuse when the same operating process serves both assurance scopes. The analyst still needs to distinguish an event, an incident, a remediation change, and a verified recovery.
SOC 2 operations, change and vendor criteria mapped to ISO 27001
| SOC 2 criterion | Control objective | ISO 27001 reference | Alignment |
|---|---|---|---|
| CC7.1 Vulnerability detection | Vulnerabilities are identified and tracked | Annex A 8.8 Management of technical vulnerabilities | Partial |
| CC7.2 Anomaly monitoring | Events are monitored and analyzed | Annex A 8.15 Logging; 8.16 Monitoring activities | Direct |
| CC7.3 Incident evaluation | Security events are assessed and classified | Annex A 5.25 Assessment and decision on information security events | Direct |
| CC7.4 Incident response | Incidents are contained and resolved | Annex A 5.24 Incident management planning; 5.26 Response to incidents | Direct |
| CC7.5 Recovery from incidents | Recovery is completed and lessons are captured | Annex A 5.27 Learning from incidents; 5.29 Information security during disruption | Partial |
| CC8.1 Change management | Changes are authorized, tested and approved | Annex A 8.32 Change management; 8.31 Separation of environments | Direct |
| CC9.2 Vendor risk management | Vendors are assessed and monitored | Annex A 5.19 Supplier relationships; 5.22 Monitoring of supplier services | Direct |
| A1.2 Recovery infrastructure | Backups and recovery capacity are maintained | Annex A 8.13 Information backup; 5.30 ICT readiness for business continuity | Partial |
| C1.1 Confidential information | Confidential data is identified and protected | Annex A 5.12 Classification of information; 5.13 Labelling of information | Partial |
Trace the operating sequence
For CC7.2, retain the alert and the analyst's disposition, not just the logging configuration. CC7.3 needs the assessment that explains why an event became an incident or was dismissed. CC7.4 needs evidence of containment and resolution.
Recovery is Partial because restoring service and capturing lessons don't necessarily demonstrate how information security was maintained during disruption. Keep recovery actions, continuity decisions, and improvement assignments distinguishable.
Change management also intersects with Annex A 8.29 when security testing occurs before acceptance. Environment-separation evidence supports Annex A 8.31, while the approval and implementation trail supports Annex A 8.32.
Follow a finding through remediation
Say a pentest identifies a critical authorization flaw. The engineering team creates a change request citing CC8.1 and Annex A 8.32, records approval and testing, and links the deployed fix to the original finding.
The retest then supports the CC7.1 remediation record. It doesn't replace change authorization or demonstrate that unrelated vulnerabilities were addressed.
For CC9.2, remember that the penetration-testing firm is itself a supplier. Customers may need evidence of its access restrictions, subcontractor arrangements, evidence handling, and service oversight.
Availability and Confidentiality rows apply only when those categories appear in the SOC 2 system description. Add missing criteria, including CC9.1 and the remaining selected-category criteria, before treating this operational table as a complete mapping.
Where a Penetration Test Fits in the Mapping
Neither SOC 2 nor ISO 27001 establishes a universal penetration-test type or fixed testing frequency. The testing plan should follow the organization's risks, service commitments, selected controls, and changes to the environment, rather than an unsupported claim that every engagement requires an annual pentest.
The Software Secured guide to ISO 27001 penetration testing identifies Annex A 8.8, Management of technical vulnerabilities, and Annex A 8.29, Security testing in development and acceptance, as relevant testing connections without prescribing a universal pentest schedule.
Map outputs rather than report titles
A verified exploit chain can support CC7.1 and Annex A 8.8 by demonstrating exposure and the consequence of a weakness. The follow-up record must show how management treated that exposure, including remediation or an approved alternative disposition.
An authorization test that demonstrates unauthorized access can support evaluation of CC6.1 and Annex A 5.15. Record both identities, their intended privileges, the protected object, and the observed access. A label such as “broken access control” isn't enough to reconstruct the test.
A post-fix retest can support CC4.1 evaluation evidence. Its conclusion should be narrow: the tester could no longer reproduce the specified behavior under the recorded conditions.
The ISO 27001 penetration-testing guide can help teams connect these outputs to a risk-based testing process. The organization still decides which control assertion each output supports.
Separate discovery, validation, and scope
Nmap service discovery and Nuclei template results can identify promising attack surfaces or potential weaknesses. Exploit validation requires additional evidence that the reported condition is reproducible and consequential within authorized limits. A scanner run isn't equivalent to a penetration test.
Scope needs the same discipline. If a SOC 2 service depends on an API and cloud identity plane, testing only the public web interface leaves those other components untested. If the ISMS includes the testing provider's evidence-handling environment, customer-facing application results won't establish the provider's internal controls.
Before accepting a compliance-mapped report, check for:
- Named targets and boundaries: Identify applications, APIs, network segments, cloud accounts, exclusions, and authorization.
- Relevant test dates: Match testing to the applicable assessment period and explain any timing limitations.
- Validated findings: Preserve reproducible steps, affected assets, supporting evidence, and observed impact.
- Retest outcomes: Distinguish remediated, unresolved, partially remediated, and untested findings.
- Traceable references: Connect each finding to the specific objective and control reference, not a generic compliance badge.
Assurance boundary: Evidence that a control failed is useful assessment evidence. It isn't evidence that the requirement was satisfied.
ISO Clauses SOC 2 Cannot Give You
A SOC 2 report doesn't produce a Statement of Applicability. That missing artifact matters because ISO conformity depends on how the organization determines necessary controls, not merely on whether a table contains matching identifiers.
The ISO/IEC 27001:2022 standard preview establishes the risk-treatment and applicability approach: Annex A is a reference catalogue against which necessary controls are checked, not a checklist requiring indiscriminate implementation.
ISO 27001 clauses with no direct SOC 2 equivalent
| ISO 27001 clause | What it requires | Closest SOC 2 equivalent | Net-new evidence |
|---|---|---|---|
| Clause 4.3 ISMS scope | Defined boundary informed by context and interested-party requirements | Scope of the system description, not the ISMS | Written ISMS scope statement |
| Clause 5.1 Leadership and commitment | Top management demonstrates ownership of the ISMS | CC1.2 Board oversight, partially | Board minutes and sign-off demonstrating relevant leadership actions |
| Clause 6.1.3 Risk treatment and Statement of Applicability | Necessary controls and Annex A inclusions or exclusions are justified | None directly | Statement of Applicability with justifications |
| Clause 9.2 Internal audit | Audits of the ISMS at planned intervals | Partial overlap with SOC 2 testing, not an ISMS audit | Internal audit programme and reports |
| Clause 9.3 Management review | Top management reviews ISMS inputs and outputs | None directly | Dated management review minutes |
| Clause 10.2 Corrective action | Root-cause analysis and documented improvement | CC4.2, partially | Corrective-action log with root causes |
Classify the work behind each reference
The Workstreet analysis of SOC 2 and ISO 27001 mapping distinguishes a control crosswalk from an audit-readiness plan. The practical consequence is to give every mapped item a reuse classification and an implementation task where needed.
Use reusable when the existing policy, process, and operating evidence satisfy the defined objective. Use partially reusable when an identifiable addition will close the gap. Use net-new when the organization must establish an ISO-specific process or record.
For each classification, record the governing policy, operating process, evidence frequency, and accountable owner. Set frequency through the process design and risk assessment rather than assigning an arbitrary cadence to every control.
Test whether inherited records are sufficient
A SOC 2 risk register may support the ISO risk assessment if its methodology records risk criteria, identifies owners, and produces consistent assessments. Treatment options and decisions must also connect to the risk-treatment process; a list of vulnerabilities with severity labels isn't enough.
Likewise, security meeting minutes may contain useful management-review inputs without constituting a complete management review. The analyst must identify the missing decisions and outputs, not just rename the meeting.
Overlap percentages don't show this work. A Partial or Not-covered row needs an owner and a concrete evidence requirement before the audit window opens.
Audit References Every Mapping Row Should Cite
An auditor should be able to follow a row from criterion to control, from control to test, and from test to retained evidence. A hyperlink to a shared folder isn't a sufficient reference if the folder contents change without version control.
Record both assurance trails
On the SOC 2 side, preserve:
- Criterion and control: The TSC identifier, the organization's control identifier, and the report section where the control appears.
- Boundary and period: The applicable system description and examination-period dates for a Type 2 report.
- Test details: The procedure, population, sample selected, exceptions, and conclusion.
On the ISO side, retain:
- Exact reference: The clause number or Annex A identifier, including the edition.
- Applicability record: The Statement of Applicability version, approval date, and relevant entry.
- Evidence location: A stable document identifier, repository location, owner, and retained version.
A hypothetical row could read: CC6.2 | Annex A 5.18 | approved SoA revision dated before Stage 1 | access-review export covering the examination period | reviewer and conclusion recorded.
Remove ambiguous identifiers
Always distinguish Clause 5.1, Leadership and commitment, from Annex A 5.1, Policies for information security. The same numeric label refers to different requirements.
Prepare stable references before the certification body's Stage 1 documentation review. Stage 2 examines implementation, so a polished mapping without operating records won't resolve implementation gaps.
Don't assume a SOC 2 auditor requires an SoA. It belongs to the ISO assurance trail, although it can help explain shared control design.
Build Your Mapping Workbook Before the Audit Window
Start with a workbook that a control owner can maintain and an auditor can trace. Excel, a controlled evidence repository, and a ticketing system can support the process; a GRC platform can centralize the same fields without changing the analyst's responsibility for the conclusions.
ThreatExploit AI is another input for service providers: its automated penetration-testing reports include evidence-backed findings and compliance references across web, network, and cloud environments. Treat those references as proposed mappings to review, not automatic confirmation of conformity.
Build the rows and assign the work
Freeze the scope. Write down the SOC 2 system boundary and ISMS boundary. Where they differ, identify the additional assets, people, suppliers, and evidence needed rather than forcing a false match.
Set the ISO edition. Use the current edition selected for the engagement and isolate legacy references in a separate field. This prevents a reviewer from interpreting an old identifier as a current requirement.
Load criteria and references. Create a row for each SOC 2 criterion and ISO reference relationship. Expand the starting tables to include every applicable criterion, and add ISO-only rows so unmatched management-system requirements remain visible.
Assign alignment. Choose Direct, Partial, Related, or Not covered, then write a short rationale. For a Direct row, identify the shared test; for Partial, name the residual ISO obligation.
Attach evidence and decide reuse. Mark each item reusable, partially reusable, or net-new. Keep alignment separate from reuse: a sound conceptual mapping may still lack usable evidence because the record covers the wrong assets or period.
Give new work an owner and frequency. Assign a person or accountable role, a completion date, and the evidence-generation trigger. A change-triggered risk review needs a different collection mechanism from a scheduled access review.
Review conclusions before accepting reports
Run the management-system gap review. Check leadership, scope, risk treatment, internal audit, management review, and corrective action separately from technical testing. After remediation, perform the appropriate effectiveness check and retain its date and outcome.
Challenge tool-generated mappings. Before accepting a report, verify its control objective, test evidence, assessment period, system boundary, and owner. Reject a row that offers only a control identifier and a severity label.
Use Jira or an equivalent workflow to assign unresolved additions, and keep approved records in a controlled repository such as SharePoint. Preserve the evidence as assessed rather than relying on a live dashboard that may change after review.
The most useful final check is simple: can another analyst reproduce the reuse decision without asking its author? If not, the row needs a clearer objective, better evidence, or a narrower conclusion.
Complete, approve, and date the Statement of Applicability before the certification body's Stage 1 review. That action turns an inventory of possible mappings into a documented statement of the controls the ISMS needs.
ThreatExploit AI offers automated penetration testing with evidence-backed, compliance-mapped reports for security service providers. Visit ThreatExploit AI to explore how its findings and control references can feed your SOC 2 to ISO 27001 mapping workbook, with your team retaining responsibility for scope, applicability, and assurance conclusions.