Control Mapping Guide: One Control Set Across ISO 27001, SOC 2 and NIST

Most organisations that answer to more than one framework end up running the same security control several times, once per audit, with different owners, different evidence and different results. Control mapping fixes that by defining one set of controls, recording precisely how each one relates to the requirements of ISO/IEC 27001, SOC 2, NIST and the regulations you are subject to, and collecting evidence once. This guide covers the method rather than the tooling: how mapping relationships are expressed (including the NIST OLIR set theory and supportive styles), how to choose an anchor framework, how to build and test a common control set, where evidence reuse breaks, and how to keep mappings current as frameworks change. It is written for GRC leads, security architects and internal auditors who own a multi-framework programme.

Key takeaways

• A mapping is a claim, not a fact. Every link between two requirements should state its relationship type (subset, intersects, equal, superset, supports) and a rationale, or auditors will reject it and engineers will misread it.
• Pick one anchor and map everything to it. Mapping every framework to every other framework grows quadratically; mapping each to one control set grows linearly.
• Use published mappings as a starting point. NIST hosts CSF 2.0 informative references for SP 800-53, ISO/IEC 27001:2022, CIS Controls v8.1 and PCI DSS 4.0.1, but NIST does not verify the correctness of mappings it did not write.
• "Test once, comply many" only works when parameters match. The control may be shared, but frequencies, periods, populations and thresholds often differ, so record framework deltas explicitly.
• Mappings decay. CSF 2.0, SP 800-53 Release 5.2.0, CIS Controls v8.1, PCI DSS 4.0.1 and the NIS2 implementing rules all changed in the last few years, so version and review your mappings like code.

What control mapping is, and what it is not

Control mapping is the analytical work of relating the elements of one document (a standard, regulation or internal policy) to the elements of another. Its output is a crosswalk or a common control framework (CCF): a single control catalogue where each control lists the external requirements it helps satisfy. Compliance automation platforms consume these mappings to route evidence, but they do not remove the need for someone to decide, and defend, what each link means.

• Focal document: the document everything is mapped to. In NIST's OLIR programme and its Cybersecurity and Privacy Reference Tool (CPRT), the focal document is the NIST publication, such as CSF 2.0 or SP 800-53 Rev. 5.
• Reference document: the other document in the pair, for example ISO/IEC 27001:2022 Annex A.
• Common control framework: your own catalogue of controls, written in your language, that acts as the focal document for your organisation. Public options such as the Secure Controls Framework (SCF) exist; NIST lists an SCF to CSF 2.0 informative reference.
• Control rationalisation: merging duplicate controls that arrived from different frameworks into one control with one owner.
• Not the same as: a gap assessment or compliance automation. Mapping is the layer that lets one assessment and one evidence stream serve many frameworks.

Relationship types: how to say what a mapping means

NIST IR 8477, Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines (February 2024), defines the vocabulary NIST accepts for OLIR submissions. It is the best public vocabulary for defensible mappings, even if you never submit one.

• Prefer semantic or functional rationale: two requirements can share wording and differ in effect. Recording a functional rationale ("executing our control produces the outcome the requirement asks for") forces the mapper to think about results, which is what an auditor tests.
• Treat "intersects with" as a warning: it means each side contains something the other lacks. For every intersect, write down the missing part on your side and either add it to the control or record the gap.
• Converting styles: NIST IR 8477 notes that set theory subset of, equal and superset of convert to supportive "supports (integral to)", "equivalent" and "is supported by (integral to)", but "intersects with" cannot be converted automatically.
• Direction matters: "our control is a superset of PCI DSS Requirement 8.4" is useful; "PCI DSS 8.4 maps to our MFA control" says nothing about coverage. Always write the relationship from the reference requirement to your control so coverage can be read off directly.

Choosing the anchor framework

The anchor is the catalogue your CCF is built on. It should be granular enough to test, stable across revisions and familiar to your auditors.

• Small organisations (one or two frameworks): anchor on CIS Controls v8.1 IG1 or IG2, map up to SOC 2 or ISO 27001, and skip a bespoke CCF until a third framework arrives.
• Mid-sized (two to four frameworks): anchor on ISO/IEC 27001 Annex A or SP 800-53 moderate controls, report through CSF 2.0 Organizational Profiles (current and target).
• Large or heavily regulated: build an own CCF with stable internal IDs, use SP 800-53 as the granular reference, and maintain mappings as data (OSCAL or CPRT JSON exports) rather than spreadsheets.

Framework structures you are mapping between

Mappings often fail because the two sides are different kinds of thing: an outcome versus a control, or a criterion versus a requirement with a testing procedure.

• SOC 2 (AICPA Trust Services Criteria): five categories (security, availability, processing integrity, confidentiality, privacy). The security category is the common criteria CC1 to CC9, which follow the COSO structure: CC1 control environment through CC5 control activities, then CC6 logical and physical access, CC7 system operations, CC8 change management and CC9 risk mitigation. Criteria are not controls: the service organisation designs its own controls and the auditor tests them, over a period for a Type 2 report. Points of focus guide the design but are not individually required.
• PCI DSS v4.0.1: 12 principal requirements with numbered sub-requirements and defined testing procedures, plus a customised approach option where the entity designs its own control to meet the stated objective. Mapping to a PCI requirement must carry its frequency and scope (the cardholder data environment).
• NIS2: Article 21 sets the risk management measures. For digital infrastructure and digital provider entities, Commission Implementing Regulation (EU) 2024/2690 adds a detailed Annex in 13 sections, from 1 (policy on the security of network and information systems) to 13 (environmental and physical security). Recital 3 says the Annex is based on standards such as ISO/IEC 27001, ISO/IEC 27002 and ETSI EN 319401, which makes ISO-anchored CCFs a natural fit. ENISA's NIS2 Technical Implementation Guidance (June 2025) adds mappings and examples of evidence for each requirement.
• DORA: the ICT risk management RTS, Commission Delegated Regulation (EU) 2024/1774, is article based: Articles 4 and 5 (ICT asset management), 6 and 7 (encryption and key management), 10 (vulnerability and patch management), 12 (logging), 17 (ICT change management), 20 (identity management) and 21 (access control). Map at article and paragraph level, because each paragraph tends to carry a distinct obligation.

Worked mapping: one control set across eight frameworks

The table shows how a compact common control set aligns by topic. NIST CSF 2.0 subcategories and the NIS2 Annex section numbers were checked against the source texts; other identifiers reflect the published framework structures and should be verified against the official informative references in CPRT and the CIS Controls Navigator before you rely on them in an audit.

For DORA, the same rows align to RTS 2024/1774 Articles 4 and 5 (inventory), 20 and 21 (identity and access), 12 (logging) and 10 (vulnerability and patch). Most cells in a table like this are "intersects with", not "equal": NIS2 Annex 11.7 and PCI DSS 8.4 both require MFA, for example, but they define the population that needs it differently. Record the relationship type in your mapping data, not just the identifier.

Building the common control set, step by step

1. Scope the obligations. List every framework, regulation and contract clause in scope, with the version (CSF 2.0, SP 800-53 Release 5.2.0, ISO/IEC 27001:2022, PCI DSS v4.0.1) and the business units and systems each applies to.
2. Import published mappings as drafts. Download CSF 2.0 informative references and the SP 800-53 crosswalks from CPRT (XLSX or JSON), and the CIS v8.1 mappings. NIST says federal civilian users should prefer government-authored mappings, then other agency mappings, then third-party submissions; that order is sensible for everyone.
3. Write controls, not requirements. Each CCF control states who does what, how often, on which population, and what evidence it produces. "Access to production is reviewed quarterly by the system owner, covering human, service and workload accounts; evidence is the signed review export" is testable. "Access is appropriately controlled" is not.
4. Map with types and rationale. For each external requirement, record the relationship (set theory or supportive), the rationale and the gap text for any intersect. Have a second mapper review a sample of at least 10% of links, and every "equal" claim.
5. Record framework parameters as deltas. Where one framework demands a tighter value (period, retention, frequency, scope), put it in the control as a parameter, not a separate control.
6. Pilot on one domain. Run identity and access first: it has the most overlap and the richest evidence. Ask your external auditor or QSA to review the mapping and sample evidence before the next audit cycle, not during it.
7. Cut over by audit cycle. Switch one framework at a time to CCF evidence. Keep the previous framework-specific control set and its evidence for one full cycle as the rollback position if an auditor rejects a mapping.
8. Publish and govern. Version the mapping, assign owners per control and per framework, and set review triggers.

Evidence reuse: where "test once, comply many" holds and where it breaks

Evidence reuse works when one artefact satisfies the period, population and parameter each framework needs, and fails quietly when one differs.

For identity evidence specifically, pull from authoritative systems (the identity provider, PAM vault, cloud IAM) rather than screenshots. See the Access Reviews Guide and the Log Management and Retention Guide.

Where identity fits

Identity and access controls are the most heavily mapped area in any CCF, and the most prone to scope errors. CSF 2.0 PR.AA-01 is explicit that "Identities and credentials for authorized users, services, and hardware are managed by the organization", and the NIS2 Annex separates privileged and system administration accounts (11.3) from general access rights (11.2). A CCF control that only covers joiner, mover and leaver for employees will map neatly on paper and still miss service accounts, API keys and AI agents. Write the population into the control ("human, service, workload and agent identities") and evidence it from inventories that include them. See the Identity Security Regulatory Map and the Service Account Security Guide.

Keeping mappings current

• Change triggers: re-review when a framework revises (CSF 2.0 replaced 1.1 with a new Govern function and renumbered subcategories; SP 800-53 moved to Release 5.2.0 in August 2025; CIS v8.1 added a Govern security function and revised asset classes), when a regulation's secondary rules land (NIS2 implementing acts, DORA RTS), and when your own control changes.
• Machine-readable mappings: store mappings as data with fields for reference ID, reference version, CCF control ID, relationship type, rationale, gap text, mapper, reviewer and review date. SP 800-53 is published in OSCAL (JSON, XML, YAML) and CPRT exports XLSX and JSON, which makes version diffs practical.
• Third-party mappings: NIST publishes non-NIST informative references after limited conformance testing against NIST IR 8278A and a 30-day public comment period, and states that listing does not imply endorsement or a check of correctness. Treat them as drafts to review.
• Governance: a mapping change that alters audit coverage needs the same approval as a control change.

Measuring whether it works

• Duplicate control ratio: number of CCF controls divided by the total number of framework requirements in scope. It should fall as rationalisation proceeds, then stabilise.
• Typed mapping coverage: percentage of links with a relationship type and rationale recorded. Target 100% for anything an auditor will rely on.
• Open intersect gaps: count of "intersects with" links with unresolved gap text, by framework.
• Evidence reuse rate: percentage of evidence artefacts accepted by two or more audits without rework.
• Mapping currency: days between a framework revision and completion of the mapping review.
• Audit findings attributable to mapping: findings where a control was mapped but did not meet the requirement. It shows whether "equal" claims are honest. See the Identity Security Metrics Guide for metric design.

Common failure patterns

• Untyped crosswalks treated as coverage: a spreadsheet that says "ISO 8.5 = PCI 8.4" without a relationship type hides that the two scope MFA differently.
• Mapping at the wrong level: linking a CSF Category to one SP 800-53 control, or a whole NIS2 Article to one ISO control, looks complete and tests as a gap.
• Human-only identity controls: the joiner-mover-leaver control maps to every framework but its population excludes keys and service accounts. The Coupang breach, where a former engineer's signing key was not revoked, shows how a leaver process that stops at the human account leaves credentials live.
• Vendor mapping accepted wholesale: a default library maps controls you do not run, leaving claims you cannot evidence.
• Stale versions: mappings still cite CSF 1.1 identifiers (PR.AC, PR.PT) or ISO/IEC 27001:2013 Annex A numbering.
• One owner for everything: GRC owns every mapping and no engineer owns the control behaviour, so drift surfaces only at fieldwork.

Practitioner checklist

• List every framework and regulation in scope with its exact version and applicability.
• Choose an anchor (CSF 2.0 for reporting plus SP 800-53, ISO 27001 Annex A, CIS v8.1 or an own CCF) and document why.
• Import NIST CPRT informative references and CIS mappings as drafts, never as final.
• Record a NIST IR 8477 relationship type and rationale for every link; write gap text for every intersect.
• Write each CCF control with owner, frequency, population (including non-human identities) and evidence.
• Capture framework-specific parameters as deltas inside the control.
• Pilot on identity and access, and have your auditor review mapping and evidence before fieldwork.
• Keep the previous control set for one audit cycle as a rollback position.
• Version mappings as data and re-review on every framework revision.
• Report typed coverage, open intersects and evidence reuse rate quarterly.

Standards and references

• NIST: IR 8477, Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines
• NIST: National Online Informative References (OLIR) Program
• NIST: CSF 2.0 Informative References
• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• CIS: CIS Controls Navigator (v8.1 mappings)
• EUR-Lex: Commission Implementing Regulation (EU) 2024/2690 (NIS2 technical and methodological requirements)
• ENISA: NIS2 Technical Implementation Guidance

Related NHI Mgmt Group resources: Identity Security Regulatory Map · Access Reviews Guide · GDPR Compliance Guide for Security Teams · AI Governance Guide. This guide summarises control mapping practice across security frameworks and regulations and is not legal advice.