What Is Control Mapping?

Control mapping is the practice of documenting how one internal control relates to the requirements of one or more external frameworks. You implement a control once — multi-factor authentication on administrative accounts, say — then record that the same control satisfies a SOC 2 criterion, an ISO 27001 Annex A control, a NIST CSF 2.0 Subcategory, and a HIPAA implementation specification.

The output is usually called a common control set, a common controls framework, or a unified control framework. The mechanics are the same in each case: a many-to-many relationship between your controls and everyone else’s requirements, with a documented rationale for every link.

Mapping is a relationship, not a lookup

The most common failure in control mapping is treating it as a synonym exercise. NIST’s National Online Informative References (OLIR) Program exists precisely to stop that. OLIR is a NIST effort that lets subject matter experts publish standardized, machine-readable mappings between their documents and NIST publications such as the Cybersecurity Framework and SP 800-53.

Under NIST IR 8278A Rev. 1 (February 2024), every mapped pair gets one of five set-theory relationship types: subset of, intersects with, equal, superset of, or not related to. Each assertion also carries a rationale — syntactic (word-for-word, strictest), semantic (interpretation of language), or functional (outcome-based, least strict) — and a strength of relationship from 0 to 10, where 10 is reserved for genuine equality.

That vocabulary matters because most real mappings are “intersects with,” not “equal.” A SOC 2 criterion and an ISO Annex A control can share 60% of their meaning and still diverge on scope, on who is in scope, and on what an assessor will accept as proof. If your mapping table has only two states — mapped and not mapped — you have already lost the information that determines whether evidence transfers. Most organizations discover this the hard way, when their policies and controls turn out to be less aligned than they assumed.

NIST formalized the underlying method in NIST IR 8477, Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines (February 2024), which is now the reference practice for crosswalk development across the industry.

How Much Do SOC 2, ISO 27001, NIST CSF and HIPAA Actually Overlap?

There is no single credible number for “SOC 2 and ISO 27001 overlap by X percent.” Vendors quote figures between 50% and 90%, and none of them survive contact with a primary source, because the answer depends entirely on which direction you measure and at what level of granularity.

What you can measure is published mapping data. The CIS Controls Navigator publishes CIS’s own mappings from CIS Critical Security Controls v8.1 — 18 Controls and 153 Safeguards — to 30 other frameworks. Counting those mappings as published in August 2026 gives a concrete picture of overlap breadth.

Read those numbers carefully. The low HIPAA and CSF 2.0 figures do not mean those frameworks demand less. They mean HIPAA and CSF 2.0 are written as outcomes and standards, while CIS is written as configurations — so a single HIPAA implementation specification absorbs many Safeguards at once. Granularity, not rigor, drives the ratio.

The reuse case is clearer when you invert the question and count obligations per control. In CIS’s published mappings, Safeguard 6.4 (Require MFA for Remote Network Access) maps to 48 distinct requirements across 24 frameworks. Safeguard 6.5 (Require MFA for Administrative Access) maps to 34 requirements across 23 frameworks, including SOC 2 CC6.1, ISO/IEC 27001:2022 Annex A 8.2, PCI DSS v4.0 8.4.1, NIST SP 800-53 IA-2(1), CMMC IA.L2-3.5.3, and NYDFS 23 NYCRR 500.12(a). That is the argument for mapping in one sentence: implement once, attest many times.

The counterweight is just as important. NIST’s own published crosswalk of SP 800-53 Rev. 5 to ISO/IEC 27001:2022 contains 1,189 distinct controls and control enhancements, and only 220 of them — 18.5% — have any ISO counterpart at all. NIST labels that OLIR as not comprehensive. Even authoritative crosswalks leave most of the work to you. For a plain-language walk through where the frameworks genuinely converge, see our SOC 2, ISO 27001, HIPAA and PCI DSS comparison and our breakdown of ISO 27001 vs. SOC 2.

Which Control Mapping Frameworks Should You Build On?

You do not need to invent mappings from scratch. Four sources cover most of what a security program needs, and three of them are free.

NIST OLIR and the Cybersecurity and Privacy Reference Tool

The OLIR Informative Reference Catalog held 101 published mappings as of 11 August 2026, of which 24 use NIST CSF 2.0 as the focal document. Contributors include the Center for Internet Security, the Cloud Security Alliance, the Cyber Risk Institute, the SCF Council, the UK Department for Science, Innovation and Technology, and NIST itself. Deliberately, NIST CSF 2.0 (26 February 2024) ships no informative references inside the publication — its 6 Functions, 22 Categories and 106 Subcategories are mapped online instead, so references can be updated without reissuing the framework.

The Secure Controls Framework

The Secure Controls Framework (SCF) is the most complete free metaframework available: 1,500+ controls across 34 domains, mapped to 200+ laws, regulations and frameworks, released under Creative Commons and updated quarterly. SCF publishes every crosswalk using Set Theory Relationship Mapping, its implementation of NIST IR 8477, so each mapping shows the relationship type and strength rather than a bare checkmark. SCF has also submitted its CSF 2.0 crosswalk to the NIST OLIR catalog.

CIS Controls mappings

CIS Controls v8.1 is the pragmatic starting point for technical controls. It realigned its security function mappings to NIST CSF 2.0 and publishes crosswalks to SOC 2, ISO/IEC 27001:2022, HIPAA, PCI DSS v4.0, NIST SP 800-171 Rev. 2 and Rev. 3, CMMC v2.0, NIS2, DORA, NYDFS Part 500 and more — all exportable from the Navigator.

Certifiable metaframeworks

Where a customer wants assurance rather than a spreadsheet, HITRUST offers a control library that harmonizes 60+ frameworks and standards and comes with e1, i1 and r2 assessment tiers. That is a different product from a mapping: you are buying a certifiable common control set. Our guide to HITRUST-to-SOC 2 mapping covers where the two overlap and where HITRUST goes further.

For healthcare specifically, NIST SP 800-66 Rev. 2 (14 February 2024) points to the Cybersecurity and Privacy Reference Tool, where the HIPAA Security Rule’s standards and implementation specifications are mapped to CSF Subcategories and SP 800-53 Rev. 5 controls.

What Does One Control Mapped Across Four Frameworks Look Like?

Abstract mapping advice is easy to nod along to and hard to apply. Here is a single, real control — multi-factor authentication on administrative accounts — carried across four frameworks with the actual identifiers an auditor will reference.

Three things are worth noticing. First, the identifiers are not parallel: SOC 2 gives you a broad criterion, ISO gives you two narrower Annex A controls, CSF 2.0 gives you an outcome, and HIPAA gives you a regulatory standard that never says “MFA.”

Second, the HIPAA row is the weakest link, and honest mapping says so. The current text at 45 CFR 164.312 requires authentication procedures but leaves the method to your risk analysis. HHS’s 6 January 2025 proposed rule would change that, adding an express MFA standard at 164.312(f)(1); the comment period closed on 7 March 2025 after 4,747 comments, and as of August 2026 the rule has not been finalized, so the 2013 text still governs.

Third, CIS’s own published mapping for Safeguard 6.5 includes SOC 2 and ISO 27001:2022 but returns no HIPAA and no CSF 2.0 match at all. The mapping in the table above is defensible, and a well-known crosswalk still does not contain it. No single published mapping is complete.

How Do You Build a Common Control Set, Step by Step?

A common control set is an internal artifact. You own the control IDs, the wording, and the mappings; the frameworks are consumers of it, not authors of it. Build it in this order.

1. Fix your framework scope first. List every framework, regulation and contract you must satisfy in the next 24 months, including customer security addenda. Mapping to frameworks you will never be assessed against is the most common source of wasted effort.
2. Pick an anchor framework. Choose the most granular, best-mapped catalog you must comply with and make it the spine. NIST SP 800-53 Rev. 5, the SCF, or CIS Controls v8.1 all work. Do not anchor on an outcome framework like CSF 2.0 — it is too coarse to hang evidence from.
3. Write controls in your own operational language. A good control names the system, the enforcement mechanism, the population and the frequency. “MFA is enforced through Okta for all accounts in the Administrators group across production AWS, GitHub and Snowflake” is a control. “Access is appropriately restricted” is not.
4. Map with relationship types, not checkmarks. Record subset / intersects / equal / superset per NIST IR 8278A Rev. 1, plus the rationale and strength. When a requirement only intersects your control, the residue is a gap, and you need a second control to close it.
5. Map controls to evidence objects. Define the artifact once — “Okta admin group MFA policy export, monthly” — and attach it to the control, not to a framework. Evidence-to-control is the relationship that produces reuse.
6. Assign one accountable owner per control. Not per framework. If three owners maintain three near-identical access control statements for SOC 2, ISO and HITRUST, you have three controls that will drift apart within a year.
7. Resolve the residue explicitly. Any framework requirement with no full mapping gets a decision: new control, control amendment, compensating control, or documented risk acceptance. Blank cells are how audits fail.
8. Version and re-baseline on a schedule. Record the framework version behind every mapping. PCI DSS v4.0 to v4.0.1, NIST SP 800-171 Rev. 2 to Rev. 3, and ISO 27001:2013 to 2022 all invalidated large blocks of existing mappings. Re-validate at least annually and on every framework release.

Expect the first pass to take four to eight weeks for a mid-sized program, and expect roughly a fifth of your existing controls to be duplicates written by different teams for different audits.

What Are the Most Common Control Mapping Mistakes?

Mapping errors are quiet. They do not surface when you build the matrix; they surface when an assessor asks for evidence and the control you pointed at does not produce it.

Semantic drift

Two requirements use the same word and mean different things. “Access review” in SOC 2 CC6.3 covers logical access to protected information assets; “access review” under HIPAA 164.308(a)(4) is about authorizing access to ePHI consistent with the minimum necessary standard. Mapping them as equal produces a review that satisfies neither scope fully.

Treating “intersects with” as “equal”

This is the single most expensive mistake, because it silently deletes a gap. ISO/IEC 27001:2022 A.8.5 and PCI DSS 8.4.1 both concern strong authentication, but PCI names the cardholder data environment, names non-console administrative access, and prescribes the factor types. A control built to the ISO wording will fail the PCI test.

Ignoring direction

Mappings are directional. NIST’s OLIR structure separates the Focal Document from the Reference Document for exactly this reason. “Every ISO Annex A control is covered by my control set” and “my control set is fully covered by ISO Annex A” are different claims, and only the first one is an assurance statement.

Assuming evidence transfers automatically

Two frameworks can require the same control and still not accept the same proof. SOC 2 Type 2 tests operating effectiveness across a defined review period and an auditor selects samples from that period. An ISO 27001 surveillance audit examines the ISMS at a point in time against your Statement of Applicability. A screenshot dated the week of the ISO audit does not satisfy a twelve-month SOC 2 period.

Version drift and unmapped residue

Framework versions move faster than control libraries. So does your estate: a mapping written when MFA covered three SaaS applications quietly becomes wrong when a fourth is onboarded outside the identity provider. Mapping is a maintained asset, not a project deliverable.

How Do You Reuse Audit Evidence Across Frameworks?

Control mapping saves time only if it changes what your team does during audit season. The mechanism is evidence reuse, and it depends on a three-layer model rather than a two-layer one.

Most control matrices link controls directly to framework requirements. That is layer one and layer three. The layer that actually produces savings sits between them: an evidence object with its own identity, owner, source system, collection frequency and retention period. One control can require several evidence objects, and one evidence object can serve many controls across many frameworks.

Once evidence is a first-class object, three practical rules apply.

• Collect on the strictest cadence any framework requires, not the average. If SOC 2 needs continuous coverage across a 12-month period and ISO needs a point-in-time sample, collect continuously. The strict artifact satisfies the loose requirement; the reverse never works.
• Keep the raw artifact and its provenance. An exported CSV with a system-generated timestamp, the query that produced it, and the account that ran it will survive an auditor’s scrutiny. A pasted screenshot usually will not, and it definitely will not survive a second auditor reusing it.
• Do not assume auditor reciprocity. A CPA firm issuing a SOC 2 report and a certification body issuing an ISO 27001 certificate work under different standards and different independence rules. Evidence can be reused; opinions cannot. Plan for two tests of the same control, drawn from one evidence pipeline.

Teams that get this right stop rebuilding evidence packages for each audit and start maintaining one continuously refreshed set. That shift — from periodic collection to continuous controls monitoring — is where the mapping investment finally pays back.

Where Do GRC Platforms and Automation Fit In?

Control mapping is a data management problem wearing a compliance costume. Once you have several hundred controls, several thousand mappings, and framework versions changing every year, spreadsheets stop being a viable system of record.

Three capabilities separate a working platform from a static matrix.

Machine-readable mappings. The SCF publishes in NIST OSCAL, the Open Security Controls Assessment Language, alongside Excel. NIST distributes CSF 2.0 and its informative references through the Cybersecurity and Privacy Reference Tool in structured form. If your platform ingests OSCAL and OLIR data, framework updates become imports instead of projects.

Evidence automation tied to controls. Mapping without automated collection just moves the manual work upstream. The value appears when a control’s evidence is pulled from the source system on a schedule and automatically satisfies every requirement mapped to that control.

Change governance over the mappings themselves. Mappings need version history, review dates and named approvers, exactly like policies. When an auditor asks why CC6.1 points at your control AC-07, someone has to answer with a rationale and a date.

A word on AI. Large language models are genuinely good at proposing candidate mappings and terrible at being trusted with the final call — the failure mode is confident semantic equivalence between requirements that merely intersect. The SCF Council makes an additional argument for human review: it uses expert-derived content rather than natural language processing partly because AI-generated mappings raise unresolved intellectual property questions. Use AI to draft and to detect drift; keep a named human accountable for every asserted relationship. Compyl’s framework library takes the same position: automate the collection and the comparison, and keep judgment where it belongs.

Frequently asked questions

About this guide. By Compyl Research. Last updated August 11, 2026. This is general information, not legal advice — consult counsel for your specific obligations. Compyl is an AI-powered, agentic GRC platform built by CISOs.