Mapping SOC 2 Criteria to ISO 27001 Annex A Controls

There's a version of this project that sounds straightforward: you already have a SOC 2 report, you want ISO 27001 certification, so you build a crosswalk spreadsheet and call it controlled overlap. I have watched smart, experienced teams attempt exactly that. The audits that followed were not disasters, but they were not clean either, and the cleanup work cost more time than building the right structure from the start would have.

What I want to do here is walk through what these two frameworks are actually doing, where the control overlap is genuine, where it is illusory, and what a shared control matrix realistically needs to contain. This is less a how-to and more a way of thinking through the problem before you commit to an approach.

What These Two Frameworks Are Actually Doing

Before you can map anything, you have to understand what each framework is actually attesting, because they are not doing the same job. Conflating them is the source of almost every painful surprise that surfaces during a dual audit.

SOC 2 is an attestation. A licensed CPA firm examines your controls and issues an opinion on whether those controls meet the AICPA's Trust Services Criteria, organized around five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most organizations pursue Security alone. The criteria are stated at a fairly high level of abstraction, something like "the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events." The specific controls you implement to satisfy that criterion are, within reason, yours to define. The auditor tests whether what you said you do is actually what you do, and whether what you do satisfies the criterion.

ISO 27001 is a certification. An accredited third-party certification body audits your Information Security Management System against the requirements in the main body of the standard, clauses 4 through 10. Annex A is a reference set of controls, 93 of them in the 2022 version, organized into four themes: Organizational, People, Physical, and Technological. Here is the part people miss: Annex A is not the standard. You certify against the ISMS requirements. Annex A tells you which controls to consider implementing, and your Statement of Applicability documents which ones you have implemented and why you excluded any others.

The structural asymmetry driving almost every mapping problem comes down to this: SOC 2 asks whether your controls satisfy defined criteria. ISO 27001 asks whether you have a functioning management system with a risk treatment process, and whether that process leads you to the right controls. One is criteria-based. The other is risk-based. That distinction has concrete consequences for how you build evidence, how you scope exclusions, and where gaps actually live.

The Risk-Based Versus Criteria-Based Distinction in Practice

In a SOC 2 audit, the auditor maps your described controls to the relevant criteria and tests whether those controls are operating effectively. If CC6.1 requires logical access controls and you have MFA on your production environment, the auditor tests MFA. If MFA is configured and enforced, the criterion is addressed. Nobody is asking you to prove you identified MFA as the right control through a formal risk assessment.

ISO 27001 requires something structurally prior to the controls themselves. Clause 6.1.2 requires a formal information security risk assessment process. Clause 6.1.3 requires a risk treatment plan. The controls in Annex A, including A.8.5 on secure authentication, exist because your risk treatment process should have led you there. An ISO auditor can and will ask to see the risk register entry connecting a given threat to the control you implemented. If you cannot trace the lineage from risk identification through risk treatment to implemented control, you have a nonconformity, even if the control itself is technically sound.

This trips up a lot of teams moving from SOC 2 to ISO 27001. They have strong controls, documented policies, working evidence. They assume they are 80 percent of the way there. On the controls side, they often are. But if they have not built a credible risk assessment methodology, maintained a risk register with consistent scoring, and created a formal Statement of Applicability with justified exclusions, they will fail their ISO audit on the management system clauses regardless of how good their technical controls are.

I have seen this go the other direction too. A company with years of ISO certification, a mature ISMS, excellent risk documentation, still struggling to produce 12 months of access review records with timestamps for a SOC 2 audit. Their surveillance audits had focused on whether the management system was functioning. SOC 2 wanted sampled, dated evidence of control operation across the full audit period. These are genuinely different evidentiary demands, and you cannot satisfy one by producing artifacts designed for the other.

Where a Single Control Satisfies Both

Real overlap exists. Plenty of controls, when properly implemented and evidenced, satisfy requirements on both sides simultaneously.

Access control is the clearest example. SOC 2 Common Criteria CC6.2 and CC6.3 address provisioning and de-provisioning of access. ISO Annex A covers the same territory across A.5.18, A.8.2, and A.8.3. A documented access provisioning workflow, joiner-mover-leaver procedures tied to HR events, and periodic access reviews with documented completion: that body of evidence speaks to both frameworks. The same onboarding ticket, the same access review export, the same de-provisioning log.

Encryption maps similarly. CC6.1 addresses protection of information at rest and in transit; ISO Annex A.8.24 covers use of cryptography. Your encryption policy, key management documentation, and evidence of TLS enforcement on external endpoints satisfy both. Incident response follows the same pattern. SOC 2 CC7.3 through CC7.5 and ISO Annex A.5.24 through A.5.28 cover the same lifecycle. A documented incident response plan, tabletop exercise records, and a log of incidents handled during the audit period with documented response actions serve both frameworks from the same artifacts.

Vendor management, physical security, business continuity, and vulnerability management all follow this pattern. The key phrase is careful evidence collection. Most of the friction in dual audits is not missing controls; it is missing evidence that was collected but never organized in a way an auditor can use.

Where Teams Wrongly Assume Equivalence

This is where practitioners get hurt, and where I want to spend some real time, because the gaps are not obvious until you are sitting across from an ISO auditor trying to explain why your SOC 2 documentation does not answer their question.

Risk Assessment

SOC 2 CC3.1 and CC3.2 address risk assessment. Many organizations point to their risk register and call it done on both sides. The problem is that register was usually never built to ISO's standard of rigor. Clause 6.1.2 requires that you define risk acceptance criteria, establish a consistent methodology producing comparable and reproducible results, and apply it to identify risks associated with the loss of confidentiality, integrity, and availability for assets in scope. SOC 2 auditors, in practice, often accept a less formally structured risk process as long as it is documented and shows some analytical rigor. ISO auditors want a methodology document, evidence of consistent scoring, and traceability from identified risks to treatment decisions. What satisfies CC3.2 will reliably fall short of Clause 6.1.2.

Supplier Relationships

SOC 2 CC9.2 addresses management of vendor and business partner risks. ISO Annex A.5.19 through A.5.22 covers information security in supplier relationships in considerably more granular terms, including requirements around agreements, supply chain security, and monitoring of supplier service delivery. A vendor inventory and a standard vendor questionnaire will often satisfy CC9.2. ISO requires documented agreements that explicitly address information security requirements, ongoing monitoring of supplier compliance, and a defined process for managing changes to supplier services. Organizations that map CC9.2 to A.5.19 and assume equivalence will find these gaps during an ISO audit.

Human Resources Security

CC1.4 in SOC 2 addresses commitment to competence and workforce practices. ISO's People theme covers related ground through A.6.1 through A.6.4: screening, terms of employment, awareness and training, and disciplinary processes. SOC 2's CC1.4 is primarily about organizational structure, competencies, and accountabilities. ISO's personnel security controls require background screening procedures, specific contractual information security obligations in employment terms, a documented awareness program with evidence of completion, and a disciplinary process for security violations. Teams that have satisfied CC1.4 through org chart documentation and role descriptions will have left most of the A.6.x requirements unaddressed. I have seen this one catch organizations that felt genuinely prepared.

Logging and Monitoring

CC7.2 in SOC 2 addresses detection of anomalies. ISO Annex A.8.15 and A.8.16 address logging and monitoring. The SOC 2 criterion focuses on detection capability. ISO requires that you have defined what events to log, that logs are protected from tampering, that you retain logs for a defined period, and that you have an active monitoring process. Organizations can have logging infrastructure that satisfies CC7.2 but lack a documented log retention policy with a defined retention period, or lack evidence that log integrity is actively protected. ISO auditors flag this specific gap repeatedly in organizations coming from a SOC 2 background, and it is one of those findings that feels embarrassing because the infrastructure is there; it just was never formally governed.

What a Shared Control Matrix Looks Like in Practice

A shared control matrix is the operational artifact that makes dual compliance manageable. The goal is not to create one massive spreadsheet listing every control from both frameworks side by side. That approach produces a document that is comprehensive and nearly useless. The goal is a structured mapping that connects your actual implemented controls to the requirements from both frameworks, so that evidence collected once can be cited for both.

The structure that works has several layers.

The first is your internal control inventory: your controls as you have defined them, not as SOC 2 or ISO defined them. Something like: "Privileged access to production infrastructure requires MFA and is reviewed quarterly by the infrastructure team lead, with access review records retained in the ticketing system." A real control with a real evidence location.

The second is the mapping. That control maps to CC6.1, CC6.2, and CC6.3 on the SOC 2 side, and to A.8.2 and A.5.18 on the ISO side. Some organizations also include the relevant ISMS clause, particularly if they want the matrix to serve as a reference during internal audits.

The third is the evidence library. For each control, you maintain a pointer to the specific evidence artifacts: where the records live, who owns them, and what the cadence is. Both auditors go to the same location. This sounds obvious; it is almost never done well on the first attempt.

The fourth layer, specific to ISO and frequently omitted, is the SoA cross-reference. Your Statement of Applicability needs to document which Annex A controls are applicable, which are implemented, and the justification for any exclusions. When the matrix says a control is implemented and the SoA says it is partially implemented or excluded, you have a documentation conflict an ISO auditor will flag. I have seen this create a genuinely uncomfortable audit moment that a simple reconciliation step could have prevented.

One more thing worth addressing explicitly: scope divergence. ISO 27001 scope, defined in Clause 4.3, and SOC 2 scope, defined during engagement planning with your CPA firm, will not always align. If your ISO ISMS scope excludes a business unit that falls within your SOC 2 examination scope, the same matrix cannot serve both without annotations. This comes up frequently in organizations that scoped their initial ISO certification narrowly, around a single product or data center, and later expanded their SOC 2 scope to cover more of the business. Managing scope divergence explicitly in the matrix, rather than hoping no one notices, saves considerable time during both audits.

Where the Mapping Gets Complicated

Two areas deserve specific attention because they do not map cleanly regardless of how carefully you approach the exercise.

The first is Privacy. SOC 2's Privacy category, built on the AICPA's Privacy Trust Services Criteria and heavily influenced by GAPP, addresses notice, choice, collection, use, retention, disclosure, and access as they relate to personal information. ISO 27001 addresses privacy only obliquely; Annex A.5.34 touches on privacy and protection of personal information, but ISO 27001 is not a privacy standard. If you attempt to map the SOC 2 Privacy criteria to ISO 27001 Annex A, the mapping is thin. ISO 27701 is the extension to ISO 27001 that addresses privacy information management, and if Privacy is a meaningful part of your compliance posture, that is the more appropriate reference for ISO-side coverage. Treating A.5.34 as equivalent to the SOC 2 Privacy criteria is a common error with real consequences.

The second is the ISMS management system clauses. Clauses 4 through 10, covering context of the organization, leadership, planning, support, operation, performance evaluation, and improvement, have no direct counterpart in SOC 2. SOC 2 Common Criteria CC1 through CC3 touch some of this territory, but they do not require that you formally define internal and external issues relevant to your ISMS purpose, determine the needs and expectations of interested parties, or conduct formal management reviews of the ISMS. These are additive ISO requirements, full stop. Any organization expecting their SOC 2 program to get them halfway to ISO 27001 needs to account for the management system overhead as a separate workstream, not something you arrive at through mapping.

Reading the Map Clearly

What becomes apparent once you work through this in practice is that these frameworks are not parallel versions of the same thing. They are instruments measuring different dimensions of security maturity. SOC 2 measures whether specific controls are operating effectively at a point in time. ISO 27001 measures whether an organization has built the management infrastructure to identify, treat, and continuously improve its handling of information security risk.

The control overlap is real. A well-run SOC 2 program produces policies, evidence, and control discipline that translate directly into ISO 27001 compliance across the Annex A controls. But the risk treatment methodology, the Statement of Applicability, the ISMS management system requirements, and the scoping discipline are not covered by SOC 2 and cannot be assumed present just because a SOC 2 report exists.

The shared control matrix works, but only if you are honest about where the mapping holds, where it is approximate, and where there is simply no bridge. The teams that get through dual audits without too much damage are the ones who maintain that distinction in the matrix, in conversations with auditors, and in how they allocate remediation effort. The teams that struggle are the ones who assumed the frameworks were mostly the same, and then spent months explaining to an ISO auditor why their SOC 2 evidence does not answer the question being asked.

That explanation is a bad place to be. Building the right structure before the audit is a much better use of everyone's time.