SOC 2 to ISO 27001 Mapping: The Full Control Crosswalk Guide

You've got SOC 2 done, and now ISO 27001 is on the roadmap. Before anyone starts building anything new, the first real question is: how much of what you already have actually counts?

A SOC 2 to ISO 27001 mapping answers that directly. It's a control-by-control comparison showing which SOC 2 Trust Services Criteria controls already satisfy which ISO 27001:2022 Annex A controls, and which ones don't. Most of SOC 2's access control, change management, and incident response evidence carries over in some form. ISO 27001's management-system clauses, internal audits, management review, the Statement of Applicability, have no SOC 2 equivalent at all.

By the end of this, you'll have the full CC1-CC9 mapping down to the sub-criteria level, an honest answer on how much overlap is real (competitors don't agree, and there's a reason why), and the specific Annex A controls with no SOC 2 counterpart.

This isn't a business-case pitch for why dual compliance is a good idea, and it isn't another explainer on what each framework is. It assumes you've already decided and just need the actual control-by-control work, turned into a gap analysis you can hand to whoever's building the timeline.

Here's what's ahead:

• What a SOC 2 to ISO 27001 mapping is, and what it isn't
• Why ISO 27001's 2022 Annex A restructure matters before you map anything
• The full sub-criteria-level control mapping, section by section
• Where the two frameworks genuinely diverge
• How much overlap is actually real, and why every source states a different number
• How to turn this mapping into a real gap analysis
• Common mistakes teams make doing this work

What This SOC 2 to ISO 27001 Mapping Actually Covers

A SOC 2 to ISO 27001 mapping is a control-by-control comparison that shows which SOC 2 Trust Services Criteria controls already satisfy which ISO 27001 Annex A controls, so a company adding the second framework isn't rebuilding evidence it already has.

This is an execution-stage document. It assumes SOC 2 is already done, or close to it, and ISO 27001 is the confirmed next step, not a maybe.

This SOC 2 ISO 27001 Crosswalk Isn't the "Which One" Question

If you're still deciding whether to pursue SOC 2, ISO 27001, or both from scratch, that's an earlier and different decision than the one this article covers. ComplyJet's SOC 2 vs. ISO 27001 guide walks through picking one, both, or a phased-vs-parallel strategy. Everything below assumes that decision is already made and SOC 2 is in hand.

ISO 27001 is also one path among several. What to Do After SOC 2 covers the full post-SOC-2 roadmap by buyer type, healthcare, enterprise, government, if ISO 27001 isn't the only framework on your list.

This work usually falls to whoever already owns SOC 2, a security lead, a compliance manager, sometimes an engineering lead wearing both hats at a smaller company. The timing that matters most: start the mapping as soon as ISO 27001 is confirmed as the next framework, not once the audit is already scheduled. A gap analysis done early changes what gets built and in what order. Done late, it just tells you what you should have started months ago.

Why This SOC 2 to ISO 27001 Mapping Saves Real Audit Work

Without a mapping, teams do one of two things, and both cost real time. Some rebuild evidence from scratch for ISO 27001, duplicating work they already did for SOC 2. Others assume more reuse exists than actually does, and get surprised by gaps late in the ISO 27001 audit cycle, when there's no time left to fix them cleanly.

An ISO 27001 auditor doesn't accept "we already have SOC 2" as evidence. Each Annex A control still needs its own evidence trail. But that evidence can often be the same underlying artifact, an access review log, an incident response runbook, re-presented against the specific ISO clause it maps to instead of built new.

Picture the two failure modes side by side. A team that assumes nothing transfers spends six months rebuilding an access review process that already exists, just because nobody checked whether the SOC 2 version could be adapted.

A team that assumes everything transfers walks into a pre-assessment three weeks before the ISO 27001 audit and discovers the Statement of Applicability was never started, because "we're basically done, we have SOC 2" was never actually verified against the real Annex A list. Both mistakes trace back to the same root cause: nobody did the mapping first, on paper, before committing to a timeline.

Trust Services Criteria ISO 27001 Mapping: The Real Reason to Do This Work

The practical payoff isn't a nice-to-know percentage. It's sequencing. Knowing exactly which controls reuse tells you what to start building now, the genuinely new ISMS documentation, and what to defer, since it's already covered by evidence you maintain for SOC 2.

The ISO 27001 Annex A SOC 2 Mapping Depends on Using Current 2022 Numbering

Here's a real gap worth checking for: at least one competitor guide on this exact topic still cites 2013-era Annex A numbering (A.9.1, A.17, A.18), the old structure with 114 controls across 14 categories. That structure was replaced in the 2022 revision. Any mapping built against it is already wrong.

This article uses ISO/IEC 27001:2022's current Annex A, 93 controls across 4 categories, not 14. If you're cross-checking against another source and the numbers don't match this one, check which edition it's using before assuming this mapping is off.

The Four Annex A Categories at a Glance

93 controls total, down from 114 in the 2013 edition. The 2022 revision consolidated overlapping controls and added 11 new ones, including threat intelligence (A.5.7) and cloud services security (A.5.23), both of which show up in the mapping below.

The consolidation is why an old 2013-numbered source can't just be re-labeled with new numbers, it genuinely restructured the standard. Several 2013 controls that used to sit in their own dedicated clauses got folded into broader 2022 controls: old A.9's access-control family became the current A.5.15 through A.5.18 plus A.8.2 through A.8.5, spread across two different Annex A categories instead of one.

A mapping built against the old structure isn't just using outdated labels. The underlying groupings themselves have changed, which is exactly why dsalta.com's guide, still citing A.9.1 and A.17, ends up pointing at controls that no longer exist in that specific form.

The four-category structure also changes how the mapping below should be read. Organizational (A.5) and People (A.6) controls skew toward policy and process, the kind of evidence SOC 2's CC1 and CC2 already produce.

Physical (A.7) and Technological (A.8) controls skew toward implementation-specific evidence instead: configurations, logs, access lists, which is where SOC 2's CC6 and CC7 do most of the work. Keeping that four-way split in mind while reading the sub-criteria table below makes it easier to predict, before checking a specific row, roughly how much reuse to expect from it.

The Full SOC 2 to ISO 27001 Mapping, Control by Control

This mapping goes one level deeper than any competitor guide available on this topic. The deepest third-party crosswalk available maps at the CC-category level only, CC6 as a block, for example. This is real SOC 2 ISO 27001 control mapping, not the category-level summary every competitor treats as the finish line: sub-criteria by sub-criteria, the level a real gap analysis actually needs.

Treat "maps to" below as "the same underlying evidence typically supports both," not "identical requirements." Each Annex A control still has its own specific language an ISO 27001 auditor will check against.

CC1-CC2: Control Environment and Communication

This is the strongest overlap category in the whole mapping, and the least discussed. Competitor pieces skip straight to CC6 because access control is the obvious headline, but CC1 and CC2 are "tone at the top" controls. ISO 27001's leadership clause (Clause 5.1) demands almost exactly the same thing SOC 2's CC1 auditors already check: documented commitment from management, clear roles, and a real accountability structure, not just a policy PDF nobody reads.

If your SOC 2 auditor has already tested this, most of the underlying evidence, org charts, role definitions, training records, transfers with light re-formatting rather than a full rebuild.

CC3: Risk Assessment

Worth flagging directly: CC3 is the first place a SOC 2 control maps to an ISO 27001 management-system clause rather than an Annex A control. If your gap analysis only checks against Annex A, you'll miss this entirely, and it's a required part of the ISMS.

CC4-CC5: Monitoring and Control Activities

CC4 is where the ISMS starts asking for more than SOC 2 ever did. SOC 2's CC4.1 wants ongoing monitoring of controls, which most companies already do through their compliance platform's continuous checks. ISO 27001's Clause 9.2, internal audit, wants something structurally different: a scheduled, independent review of the ISMS itself, with its own findings and remediation trail, separate from day-to-day control monitoring. Don't assume your existing CC4 evidence covers this. It's adjacent, not equivalent.

CC6: The Access Control Core of the SOC 2 to ISO 27001 Mapping

This is the densest, most-cited mapping area, and the one every competitor reviewed treats as the headline example. Here it is at the sub-criteria level instead of one broad "CC6 maps to access control" statement.

Companies that already have the review but never wrote down the policy behind it are "partial reuse," not "full reuse," on this control specifically.

It's a real gap, just a small one, and the mapping table above is what surfaces it before an auditor does, not three weeks into an ISO 27001 pre-assessment when there's less room to fix it cleanly.

Physical access (CC6.4) is worth a separate note for remote-first companies. If your team doesn't operate a physical office, this control still applies, just scoped to wherever information assets actually live: a co-working space, a data center, someone's home office if company hardware goes home with them.

SOC 2 auditors increasingly accept a narrower physical-access scope for remote-first companies, and ISO 27001's A.7.1 through A.7.3 will generally follow the same logic, but only if that scoping decision is written down somewhere an auditor can actually check, not just assumed and left unstated.

CC7: System Operations, Logging, and Incident Response

The mechanics reuse well here. The format doesn't always. SOC 2 incident response evidence is usually written for an auditor sampling a handful of events over the report period. ISO 27001's A.5.24 through A.5.27 expects a documented incident management process, planning and preparation, assessment criteria, response steps, and a formal learning-from-incidents loop back into the ISMS. The individual incident records often transfer fine. The overarching process documentation connecting them usually needs to be written for the first time.

CC8-CC9: Change Management and Vendor Risk

Vendor risk is a genuine bright spot. If CC9.2 evidence already covers vendor risk assessments, security questionnaires, and subprocessor tracking, most of that reuses directly, since ISO 27001's supplier controls (A.5.19 through A.5.23) ask for the same underlying due diligence. The gap is usually narrower than expected: formal supplier agreement language that explicitly references information security obligations, which a lot of SOC 2 vendor management programs handle informally rather than in the contract itself.

Additional Criteria in the SOC 2 to ISO 27001 Mapping: Availability, Confidentiality, and Privacy

That last row is worth sitting with. SOC 2's Privacy category runs P1 through P8, covering notice, choice, collection, use, retention, access, disclosure, and quality. ISO 27001 gives it exactly one Annex A control. If privacy is a real driver for your ISO 27001 work, ISO 27701 (ISO 27001's dedicated privacy extension) is the more direct fit, not a substitute for this mapping.

SOC 2 to ISO 27001 Mapping: Where the Two Frameworks Diverge

The table above shows real, substantive overlap. It also isn't the whole picture. Some of ISO 27001's real work has no SOC 2 starting point at all, and pretending otherwise is how gap analyses turn out to be wrong.

The ISMS Clauses SOC 2 Doesn't Touch

These aren't harder than the Annex A controls above. They're a different kind of work: a documented, auditable management system, not a technical control with a matching piece of evidence. Budget for this as its own workstream, not a byproduct of mapping the technical controls.

Take the Statement of Applicability specifically, since it's the one most teams underestimate. It isn't a checklist. It's a documented justification for every single Annex A control, all 93 of them, stating whether it's included in scope and why, or excluded and why that's defensible.

SOC 2 has nothing resembling this. SOC 2 scoping happens once, informally, at the start of the engagement, and isn't revisited control by control in a standalone document an auditor reviews independently. Writing a real Statement of Applicability, one that would survive a certification body's scrutiny, is its own multi-week project even for a team with strong existing controls and a genuinely mature SOC 2 program already in place.

Internal audit and management review follow the same pattern. SOC 2's continuous monitoring tells you controls are working day to day. ISO 27001 additionally wants a formal, periodic step back: an internal audit function testing the ISMS itself against the standard, and a documented management review where leadership actually looks at audit findings, risk assessment results, and objectives, then records decisions. Neither is exotic. Both are new paperwork disciplines layered on top of whatever monitoring already exists.

Clause 4 and Clause 6.2 are smaller but easy to miss entirely. Clause 4 asks for a documented picture of the organization's context, the internal and external issues, and the interested parties, regulators, customers, partners, that actually shape what the ISMS needs to cover. Clause 6.2 asks for specific, measurable security objectives tied to a plan for achieving them, not a general statement of intent.

Neither maps to a SOC 2 control, because SOC 2 never asks a company to justify its own scope in writing this explicitly. Both are usually short documents once someone actually sits down to write them, but they're easy to leave off a gap-analysis list built purely from the Annex A table above, since neither clause lives there at all.

How Much of the SOC 2 to ISO 27001 Mapping Is Real Overlap?

Every source that publishes a number publishes a different one, and none of them show their work. That's worth addressing directly instead of just picking one to repeat.

The SOC 2 ISO 27001 Overlap Percentage No One Agrees On

A 30-point spread on the same claimed source isn't a rounding error. It means "overlap" depends entirely on what you're counting, which Annex A categories, at what level of granularity, and no one citing a single number is telling you which scope they used. -- Upendra Varma, CTO at ComplyJet

The honest answer: overlap is genuinely high in some categories and genuinely thin in others. Organizational and People controls (A.5, A.6) overlap heavily with SOC 2's CC1, CC2, and CC6. Physical controls (A.7) overlap moderately, mostly through CC6.4. Some Technological controls (A.8) overlap strongly (access control, logging, change management); others, secure coding practices, cryptography implementation details, have thinner SOC 2 equivalents. A single blended percentage flattens that real variation.

That's also why this article doesn't lead with its own single number. A blended percentage is only useful once you already know which categories it's weighting, and none of the sources above say which ones they counted.

The category-by-category table above is the more honest version of the same answer: high confidence where SOC 2 controls map one-to-one against Annex A, lower confidence where the relationship is partial, and an explicit "no equivalent" where it's genuinely absent, rather than folding all three into one reassuring-sounding figure that hides which parts of the work are actually done.

What About the AICPA SOC 2 ISO 27001 Mapping Spreadsheet?

The AICPA does publish an official resource, "Mapping: 2017 Trust Services Criteria to ISO 27001." It's member-gated, though: an AICPA or CIMA login is required, and it isn't a public download.

That's very likely why neither Vanta's nor Drata's dedicated mapping articles show a single specific control-ID pair. Both name the AICPA resource as their authority and stop there. Worth saying plainly instead of silently working around it: the canonical source for this exact topic isn't public, which is exactly why an independently reasoned, sub-criteria-level mapping like the one above has real value.

How to Map SOC 2 Controls to ISO 27001 for a Real Gap Analysis

The table above is the reference. This is how to turn it into a document someone can actually plan against, rather than a resource you read once and set aside.

1. Pull your current SOC 2 control matrix and evidence list. You need the actual artifacts, not just the control descriptions, to know what genuinely transfers. A control description can look identical across two frameworks while the underlying evidence is formatted in a way that doesn't hold up under a different auditor's expectations.
2. Walk each SOC 2 sub-criterion against its mapped Annex A control(s) from the table above. Mark each as full reuse, partial reuse, or no reuse. Do this at the sub-criteria level, not the CC-category level, since that's exactly where the category-level summaries every competitor stops at lose the detail that actually matters.
3. For every partial or no-reuse control, scope the real net-new work. A new policy, a new evidence artifact, a new recurring process, not just "needs work." Vague gap notes turn into vague timelines.
4. Scope the ISMS clauses as their own separate workstream. They don't map to any SOC 2 control at all, so they don't belong mixed into the technical-control gap list, where they'll get treated as smaller items than they actually are.
5. Sequence net-new Annex A controls and ISMS documentation first. They have no existing SOC 2 head start, so they're the actual critical path to your ISO 27001 timeline, not the controls that already mostly exist. Everything with strong SOC 2 reuse can wait until the genuinely new work is underway.

Common SOC 2 to ISO 27001 Mapping Mistakes

Most of these come from treating the mapping as a formality instead of the actual planning document it should be. Each one shows up repeatedly across teams that have done this work before, and each one is avoidable with the table and the gap-analysis steps above.

• Assuming "high overlap" means minimal new work. The ISMS clauses alone, the Statement of Applicability, internal audits, management review, are a real project regardless of how much the technical controls overlap. A high percentage on the technical side says nothing about the management-system side.
• Treating the mapping as one-directional. ISO 27001 also requires ongoing internal audits and management reviews SOC 2 never asked for. This isn't just "add a few controls" to an existing program, it's a genuinely new operating rhythm layered on top.
• Using a mapping built against 2013 Annex A numbering. If a source cites A.9.1, A.17, or A.18, it's using the old structure. Cross-check the edition before trusting any specific control pair, since the 2022 revision renumbered and consolidated most of them.
• Skipping the Statement of Applicability because SOC 2 never required documenting scope this way. It's a required ISO 27001 deliverable with no SOC 2 equivalent, not optional paperwork, and auditors check it against the actual Annex A list line by line.
• Assuming an auditor accepts SOC 2 evidence as-is. The underlying artifact might be reusable, but it still needs to be re-presented against the specific Annex A control language the certification body is testing against.
• Not scoping the ISMS as its own workstream. Folding management-system work into the technical-control gap list understates the real timeline and usually means it gets deprioritized until it's the thing blocking certification.
• Starting the mapping too late in the process. Doing this exercise after the ISO 27001 audit is already scheduled leaves no room to actually close the gaps it surfaces.

How ComplyJet Supports Your SOC 2 to ISO 27001 Mapping

ComplyJet supports both SOC 2 and ISO 27001 directly, on the same flat per-company pricing, using one shared control environment instead of two separate compliance programs.

That's the same thesis this article is built on: build the evidence once, tag it to both frameworks, and know precisely what's still net-new instead of guessing. ComplyJet maps your existing SOC 2 evidence against the ISO 27001 Annex A controls above automatically, and flags the ISMS documentation work separately so it doesn't get lost in the technical-control list.

Practically, that means the two failure modes described earlier in this article, rebuilding evidence that already exists, or discovering a gap three weeks before the audit, both get addressed by the same underlying system instead of two separate compliance programs run in parallel.

A change to an access control policy updates evidence for both frameworks at once. A new hire's background check satisfies both CC1.4 and A.6.1 without separate tracking. The mapping work this article walks through by hand is the same work ComplyJet's platform does continuously, kept current as both frameworks' requirements evolve, not reasoned out once and left to quietly go stale as either standard is revised again.

FAQs

Is There an Official SOC 2 to ISO 27001 Mapping?

The AICPA publishes one, "Mapping: 2017 Trust Services Criteria to ISO 27001," but it's member-gated behind an AICPA or CIMA login, not a public document. The mapping in this article is independently reasoned at the sub-criteria level and cross-referenced against multiple public sources, since the canonical version isn't publicly accessible. Treat any specific control pair, from this article or anyone else's, as a strong starting point to verify with your own auditor rather than a substitute for their sign-off.

Can I Use My SOC 2 Report for ISO 27001 Certification?

Not directly. A SOC 2 report isn't accepted as ISO 27001 evidence on its own. But the underlying evidence behind many SOC 2 controls, access reviews, incident response records, change logs, can often be re-presented against the matching Annex A control instead of rebuilt from scratch. The report itself is a SOC 2-specific deliverable; it's the evidence trail behind it that has reuse value.

Which ISO 27001 Controls Are Not Covered by SOC 2?

The ISMS management-system clauses have no SOC 2 counterpart at all: the Statement of Applicability, Clause 4 (context of the organization), Clause 9.2 (internal audit program), Clause 9.3 (management review), and Clause 10 (continual improvement). A few Annex A controls, like ISO 27701-adjacent privacy work, are also far thinner in SOC 2 than in ISO 27001, since SOC 2's Privacy category maps to essentially one Annex A control.

Is There a SOC 2 to ISO 27001 Mapping Spreadsheet I Can Download?

The AICPA's official spreadsheet exists but requires AICPA or CIMA membership to access. This article's table above covers the same ground at the sub-criteria level and is publicly available without a login, though it's presented as a reference table rather than a downloadable file.

How Do I Map SOC 2 Controls to ISO 27001 Annex A?

Start with the sub-criteria-level table in this article, mark each SOC 2 control as full, partial, or no reuse against its mapped Annex A control, then scope the actual net-new work for anything short of full reuse. The step-by-step section above walks through this in order, including where to sequence the ISMS-specific work that doesn't map to SOC 2 at all.

Does SOC 2 Satisfy ISO 27001 Requirements?

Partially. SOC 2's technical and operational controls, especially around access control, change management, and incident response, substantially overlap with ISO 27001 Annex A. SOC 2 does nothing to satisfy ISO 27001's ISMS management-system requirements, which are a separate, required body of work regardless of how strong the technical overlap is.

What SOC 2 Evidence Can I Reuse for ISO 27001?

Access control and provisioning records, change management logs, incident response documentation, and vendor risk assessments are the strongest candidates, based on the CC6, CC7, CC8, and CC9 mappings above. Documentation tied to SOC 2's specific reporting format, like the report itself, doesn't transfer directly, and the ISMS documentation covered earlier has no SOC 2 starting point to reuse from at all.

Related Reading

• SOC 2 vs. ISO 27001: Picking One, Both, or a Dual Strategy, for readers still deciding between SOC 2 and ISO 27001, or choosing a phased-vs-parallel strategy, rather than mapping controls between the two
• What to Do After SOC 2, the broader post-SOC-2 framework roadmap this article's ISO 27001 path extends
• ISO 27001 Certification Process, the full certification process once this mapping has scoped the real gap