Mapping Vendor Controls Across SOC 2, ISO 27001, and NIST

The Mapping Problem

Vendor risk practitioners live inside a framework mismatch. Your organization may have standardized on NIST CSF or built its risk register around NIST SP 800-53 control families. Your vendors, especially those serving enterprise customers across industries, overwhelmingly produce SOC 2 Type II reports. A smaller set holds ISO 27001 certificates. Almost none produces evidence perfectly aligned to what your questionnaire asks for.

The result is a translation tax paid on every vendor review. An analyst receives a SOC 2 report, needs to satisfy a NIST-aligned questionnaire, and has to manually bridge the gap — often re-interviewing the vendor, requesting supplemental documentation, or making judgment calls that create inconsistency across the portfolio. The same problem runs in reverse: a vendor holding an ISO 27001 certificate may struggle to answer a SOC 2-oriented questionnaire because the evidence they have is organized around Annex A domains, not Trust Services Criteria.

Control framework mapping is the discipline of finding which controls in one framework correspond to which controls in another. Done well, it lets you extract maximum signal from the evidence a vendor already has rather than asking them to produce something new. Done poorly, it creates false assurance — assuming that because two frameworks both address access control, a finding in one fully satisfies the other.

The Common Spine

Despite meaningful structural differences, SOC 2, ISO 27001, and NIST share a control spine that covers the vast majority of enterprise security risk. Five domains appear across all three frameworks in substantively equivalent form, even if the naming, granularity, and evidence expectations differ.

Understanding this common spine is the foundation of any cross-framework vendor review. When a vendor has strong evidence in one framework, your first move is to identify where that evidence lands on the spine before deciding what gaps remain.

• Access control and identity management — who can access what, how access is provisioned, and how that access is reviewed.
• Cryptography and data protection — encryption in transit and at rest, key management, and certificate governance.
• Incident response — detection, evaluation, response, notification, and post-incident review processes.
• Change management — how changes to systems and software are authorized, tested, and deployed.
• Business continuity and disaster recovery — documented continuity plans, recovery time objectives, and tested restoration procedures.

How to Run a Cross-Framework Vendor Review in Practice

A practical cross-framework review starts by identifying what evidence the vendor has, then mapping that evidence to the control families your program cares about, and finally identifying residual gaps that require supplemental assessment.

Begin by cataloging the vendor's available evidence: SOC 2 report (Type I or II, scope, period, TSCs included), ISO 27001 certificate (scope, issue date, certification body), any additional attestations such as PCI DSS, FedRAMP, or HIPAA BAA. Note the recency of each artifact — a SOC 2 report older than twelve months and an ISO certificate in its third surveillance year both carry degraded assurance.

Next, map the vendor's evidence against the control families your questionnaire or risk register requires. Use the common spine as your starting point: for each of the five spine domains, note which artifacts provide coverage and at what assurance level. The compact reference below maps the spine domains to their framework anchors and can serve as a reusable starting template for any cross-framework review.

For residual gaps, determine whether to issue targeted questionnaire items, request supplemental documentation, or accept compensating controls with documented rationale. The goal is not to achieve perfect framework equivalence but to obtain sufficient evidence that a reasonable judgment about vendor risk is defensible.

• Step 1: Catalog all available vendor evidence with artifact type, scope, and recency.
• Step 2: Map evidence against the five common spine domains using the reference below and note coverage level for each.
• Step 3: Identify structural gaps — areas where the vendor's framework type cannot address your program's requirements.
• Step 4: Issue targeted supplemental questions only for genuine gaps, not for controls already evidenced.
• Step 5: Document mapping decisions and residual risk acceptance rationale for audit trail.
• Spine reference — Access control: SOC 2 CC6 | ISO 27001 Annex A 8.2, 8.3, 8.5 | NIST 800-53 AC and IA.
• Spine reference — Cryptography: SOC 2 CC6.7 | ISO 27001 Annex A 8.24 | NIST 800-53 SC.
• Spine reference — Incident response: SOC 2 CC7.2–CC7.5 | ISO 27001 Annex A 5.24–5.28 | NIST 800-53 IR.
• Spine reference — Change management: SOC 2 CC8 | ISO 27001 Annex A 8.32 | NIST 800-53 CM.
• Spine reference — Continuity and recovery: SOC 2 A1 | ISO 27001 Annex A 5.29–5.30 | NIST 800-53 CP.

How SOC 2 TSCs Map to ISO 27001 and NIST

If you hold a SOC 2 report and need to satisfy an ISO 27001 or NIST-aligned questionnaire, start here.

SOC 2 is organized around Trust Services Criteria. The Security TSC (CC series) is required for every SOC 2 engagement; the remaining four — Availability (A), Confidentiality (C), Processing Integrity (PI), and Privacy (P) — are optional and included only when the service organization and its auditor determine they are relevant to the engagement scope.

The CC series maps most directly to the Technological and Organizational themes of ISO 27001 Annex A and to the AC, AU, CA, CM, IA, and IR families of NIST 800-53. CC6 (logical and physical access) corresponds closely to ISO Annex A 8.2 (privileged access rights), 8.3 (information access restriction), and 8.5 (secure authentication), and to NIST AC and IA. Note that Annex A 8.4 covers access to source code specifically and is narrower than general access control. CC7.2 (anomaly and security event detection) through CC7.5 (incident recovery) maps to ISO Annex A 8.15–8.16 (logging and monitoring) and to NIST AU and IR. CC8 (change management) aligns to ISO Annex A 8.32 and NIST CM.

The optional TSCs are harder to map. The Privacy TSC has partial overlap with ISO 27701, a privacy information management standard that complements ISO 27001 but is now certified independently rather than as an extension of it. Processing Integrity has limited equivalents in either ISO or NIST because it addresses the accuracy and completeness of a service's output — a concern more specific to service organizations than to internal control frameworks. When a vendor's SOC 2 includes optional TSCs relevant to your use case, note which ones are in scope and map them separately from the CC series.

How ISO 27001 Annex A Maps to SOC 2 and NIST

If a vendor holds an ISO 27001 certificate and you need to satisfy a SOC 2 or NIST-aligned questionnaire, start here.

The 2022 revision of ISO 27001 restructured Annex A to 93 controls organized across four themes: Organizational (37 controls), People (8 controls), Physical (14 controls), and Technological (34 controls). This restructuring from the 114-control, 14-domain layout of the 2013 version introduced several consolidated and new controls, including those explicitly addressing threat intelligence, information security for cloud services, and data masking.

Mapping ISO 27001 to SOC 2 works reasonably well for the Technological theme, which covers much of the same ground as the CC series. ISO Annex A 8.2 (privileged access rights), 8.3 (information access restriction), and 8.5 (secure authentication) map to SOC 2 CC6; note that 8.4 covers access to source code specifically and is narrower than general access control. ISO Annex A 8.15–8.16 (logging, monitoring) maps to CC7. The Organizational theme's incident response controls (5.24–5.28) map to CC7.3–CC7.5.

Mapping ISO 27001 to NIST 800-53 is more systematic because both frameworks are designed as internal control catalogs rather than audit frameworks. NIST's informative references in the CSF cite ISO 27001 frequently. The Physical theme (Annex A 7.1–7.14) maps cleanly to NIST PE (Physical and Environmental Protection). The People theme (Annex A 6.1–6.8) maps to NIST AT (Awareness and Training) and PS (Personnel Security).

One structural difference matters for evidence review: ISO 27001 certification attests that a management system exists and operates, validated through audit cycles and surveillance audits. It does not attest to the operating effectiveness of every individual control the way a SOC 2 Type II does. When a vendor offers an ISO 27001 certificate in lieu of a SOC 2, you are getting management system assurance, not control-by-control effectiveness testing over a defined period.

How NIST CSF and SP 800-53 Map to the Others

If your program is NIST CSF or SP 800-53 aligned and you need to evaluate vendor evidence in SOC 2 or ISO 27001 format, start here.

NIST CSF 2.0 introduced a sixth Function — Govern — bringing the framework to six Functions: Govern, Identify, Protect, Detect, Respond, and Recover. The Govern Function includes the GV.SC category, which addresses supply chain risk management explicitly. This is a direct acknowledgment that third-party risk is a first-class concern within the CSF, not an afterthought.

GV.SC maps partially to SOC 2 in that vendor SOC 2 reports are a common form of supply chain assurance evidence, but SOC 2 has no equivalent to the buyer-side governance requirements in GV.SC. GV.SC maps more directly to NIST SP 800-161, the Cybersecurity Supply Chain Risk Management (C-SCRM) guidance, which is a detailed companion framework with no true SOC 2 or ISO 27001 equivalent.

NIST SP 800-53 Rev 5 includes a Supply Chain Risk Management family (SR) that addresses provenance, supplier assessments, acquisition strategies, and component integrity. The SR family has no direct SOC 2 counterpart — SOC 2 is a report about a specific service organization's controls, not a framework for how a buyer should manage its supply chain. When your program is 800-53 aligned, the SR family requirements will produce questionnaire items that vendors cannot answer with their SOC 2 or ISO 27001 artifacts alone and will require supplemental vendor responses.

What Doesn't Map Cleanly

Not all control framework mapping resolves to a clean lookup. The gaps fall into two categories: attestation-scope gaps, where a framework covers a domain but its evidence format cannot substitute for another's, and structural-absence gaps, where a concept in one framework has no parallel in another. Recognizing which type of gap you are facing determines whether supplemental questions or documentation requests are the right response.

• CUECs have no ISO or NIST equivalent. Complementary User Entity Controls are the controls that a SOC 2 report assumes the customer is implementing. They appear in their own section of the report, typically within or immediately following the system description. ISO 27001 and NIST have no parallel concept — there is no mechanism in those frameworks for a vendor to specify what the buyer must do for the vendor's controls to be effective. Reviewers must extract CUECs from every SOC 2 report and validate that your organization actually implements them.
• ISO 27001 surveillance cycles differ from SOC 2 periods of time. A SOC 2 Type II report covers a defined examination period, typically six or twelve months, and the auditor tests that controls operated effectively throughout that period. An ISO 27001 certificate is valid for three years with annual surveillance audits, but those audits sample rather than test all controls. A certificate dated within three years is not equivalent evidence to a SOC 2 Type II covering the past twelve months.
• NIST SP 800-161 C-SCRM has no SOC 2 or ISO 27001 twin. The C-SCRM framework addresses hardware and software supply chain integrity, provenance verification, and multi-tier supplier risk — concerns that neither SOC 2 nor ISO 27001 covers in depth. If your program has 800-161 requirements for high-risk vendors, you will need custom questionnaire items and cannot rely on existing certifications to satisfy them.
• There is no single authoritative crosswalk, and mapping documents are not equivalence tables. The AICPA has published mapping documents between SOC 2 and other frameworks, and NIST includes informative references in the CSF that cite ISO standards, but these are guidance documents. Any mapping introduces interpretation; that interpretation should be documented and consistently applied across your vendor portfolio.

Common Mistakes

Several recurring errors undermine cross-framework vendor reviews even when practitioners understand the frameworks involved. Most fall into two patterns: conflating design adequacy with operating effectiveness, and conflating certification scope with the specific product or service your organization relies on.

• Treating a SOC 2 Type I as equivalent to a Type II. A Type I report attests that controls are suitably designed at a point in time. A Type II attests that they operated effectively over a period. For ongoing vendor risk assessments, a Type I provides significantly less assurance.
• Ignoring TSC scope. A SOC 2 report scoped only to the Security TSC says nothing about availability, confidentiality, or processing integrity. If your vendor provides a critical availability-dependent service, the absence of the Availability TSC is a gap, not a minor footnote.
• Assuming ISO certification scope covers the product you use. ISO 27001 certificates specify a scope statement. A vendor may hold a certificate scoped to their corporate headquarters or a specific product line that does not include the service you are purchasing.
• Using a crosswalk table as an equivalence table. Mapping documents show correspondence, not equivalence. CC6 and ISO Annex A 8.2, 8.3, and 8.5 address the same domain but test evidence differently. A clean mapping does not mean one artifact satisfies the other without review.
• Not reading the CUECs. Complementary User Entity Controls are your organization's obligations for the vendor's controls to function as described. Missing them creates real security gaps that a SOC 2 review would technically pass.

Where Cross-Framework Mapping Fits in Your Program

Control framework mapping is most effective when it is a repeatable, documented process built into your vendor review workflow rather than an ad hoc translation exercise performed differently by each analyst. Establishing a standard mapping reference for your program — which TSCs correspond to which Annex A controls and which 800-53 families — reduces inconsistency, shortens review time, and makes your rationale auditable. v3ndor's interface lets you record vendor evidence artifacts, surface control coverage by domain, and document residual gap decisions alongside the mapping rationale, so the translation work done for one review becomes the foundation for the next. If you are building or maturing a TPRM program that handles evidence across SOC 2, ISO 27001, and NIST, request access at /request-access to see how the workflow supports cross-framework assessments at scale.