--- key: "assurance-mapping" title: "Control mapping between frameworks: state the relationship without overstating equivalence" url: "https://softwaresecurity.com/frameworks/control-mapping-and-evidence/" api: "https://softwaresecurity.com/api/v1/articles/assurance-mapping.json" domain: "governance" topic: "Governance \u0026 frameworks" type: "Guide" identifiers: [] tags: ["Compliance and assurance evidence"] stages: ["govern"] roles: ["appsec-engineer","security-leader"] license: "CC-BY-4.0" license_url: "https://creativecommons.org/licenses/by/4.0/" code_license: "MIT" --- # Control mapping between frameworks: state the relationship without overstating equivalence Record exactly how an implementation supports a requirement, which evidence is reusable and which obligations remain unresolved. Canonical URL: https://softwaresecurity.com/frameworks/control-mapping-and-evidence/ ## In short A mapping states how one requirement relates to another; it never shows that either is implemented. Use the vocabulary of NIST IR 8477, such as “supports”, “subset of” or “intersects with”, with a rationale and a direction, and pin the exact edition of both sources. Attach evidence to each row only for the scope it actually covers and record the gaps. Review a row again whenever either source, the product or the evidence changes. - NIST IR 8477 (February 2024) defines four mapping styles: concept crosswalk, supportive relationship, set theory relationship and structural relationship. - Set theory rows say subset of, intersects with, equal, superset of or no relationship, each with a syntactic, semantic or functional rationale. - Supportive rows say supports or is supported by, optionally qualified as example of, integral to or precedes. - A narrow technical requirement can support part of a broad policy requirement; a policy alone never satisfies a narrow technical one. - Pin NIST SP 800-53 by release, such as 5.2.0 of August 2025, not just “Revision 5”. ## Verify it 1. Check that every mapping row names both sources with their exact edition or release. 2. Confirm each row uses one defined IR 8477 relationship type and states its rationale and direction. 3. For one row reported as satisfied, open the evidence and confirm it covers the full target scope. 4. Confirm rows are flagged for review when a source edition, the product or the evidence changes. ## What you will learn - Describe a relationship with NIST IR 8477 terms instead of claiming equivalence. - Reuse evidence without copying verdicts beyond its scope. - Version mapping rows and detect product or evidence drift. Audience: Compliance engineers and assessors maintaining crosswalks between frameworks Before you start: - Compare the scope, wording and evidence expectations of two requirements. Time: About 28 minutes: 5 to read and 23 for the exercise ## What does a mapping row actually claim? A mapping states a relationship between requirements or concepts. It does not prove that either requirement is implemented. Similar words can hide different scope, rigor, actor or evidence expectations, so name the relationship precisely and record the rationale. NIST IR 8477 supplies a shared vocabulary, summarized in the table, and NIST’s Online Informative References (OLIR) program publishes mappings that use it. An informative reference is not authorization to claim automatic compliance. For example, an application command-injection control supports part of a broader secure-development control, but it does not cover code review, dependency management, build protection and incident response by itself. In IR 8477 terms the narrow control supports the broad one as an example of how to achieve part of it, and in set theory terms the two intersect. Mark direction explicitly: evidence for a narrow requirement may support part of a broad one, while a general policy does not satisfy the narrow technical requirement. | IR 8477 style | Relationship types | Use it for | | --- | --- | --- | | Concept crosswalk | Related, with no further characterization | Pointing to more information; the documented use case is the only source of meaning | | Supportive relationship | Supports or is supported by (optionally example of, integral to or precedes); identical; equivalent; contrary; no relationship | Showing how one control or capability helps achieve a requirement | | Set theory relationship | Subset of, intersects with, equal, superset of, no relationship; each with a syntactic, semantic or functional rationale | Comparing similar requirements, such as two editions of one standard | | Structural relationship | Parent and child | Showing hierarchy within one source | ## Can one piece of evidence support two requirements? A design document says how a control is intended to work; an operating record shows a particular execution; an effectiveness assessment tests whether it achieves the intended result. A single source can support several requirements if the scope and observations are relevant, but each relationship needs its own argument. Reusing evidence is efficient; copying a pass verdict across rows is unsafe when the requirements ask different questions. The fictional mapping pairs ASVS v5.0.0-1.2.5 with an internal SDLC requirement, SEC-7, for reviewed handling of all untrusted inputs. Evidence E1 shows a shell-free call for one worker, E2 contains negative-test observations, and E3 is an organization policy. E1/E2 support the worker's command-injection claim. They do not establish review of every input path across the product, which SEC-7 requires. E3 supplies intent, not operating coverage. The correct matrix therefore reports a partial contribution plus an explicit gap; /frameworks/asvs-verification-evidence/ shows how to record the worker result itself. ## What should a mapping registry record? A mapping registry should contain source and target versions, exact identifiers, the IR 8477 style and relationship type, direction, rationale, scope, exclusions, evidence IDs, evidence period, owner, reviewer and next-review triggers. Changes to either framework or the product can invalidate a row. NIST SP 800-53 remains Revision 5 with separately published releases, the latest being 5.2.0 of 27 August 2025, so the revision alone does not identify the control text used. Pin the adopted release rather than quietly mixing new controls into an old assessment. An external crosswalk can seed a relationship but should not be treated as evidence that your organization operates it. Review the original requirement text and the implementation before adopting the row. Where official standards are licensed or not fully available, state the reference and interpretation limit rather than inventing normative wording. Keep mapping maintenance owned and triggered by new editions. A framework update may change only identifiers, or it may change substance; the migration needs to distinguish those outcomes. ## How do you publish mappings in a machine-readable form? OSCAL 1.2.0 (December 2025) added a control mapping model, and release 1.2.3 of 7 August 2026 is current. A mapping collection names the source and target catalogs, a provenance block with the method, the matching rationale (syntactic, semantic or functional, as in IR 8477) and the status, and one entry per relationship: `equivalent-to`, `equal-to`, `subset-of`, `superset-of`, `intersects-with` or `no-relationship`. Below, two pairs that NIST's SSDF-to-CSF informative reference relates without a type are typed and explained, against the SSDF and CSF catalogs NIST publishes in OSCAL; /frameworks/nist-csf-2-for-product-teams/ covers the CSF side. Validate the file against `oscal_mapping_schema.json` from the same OSCAL release, as /frameworks/compliance-evidence-reuse/ shows for a component definition. The schema checks structure and vocabulary; a reviewer still checks the meaning, and the remarks say why each pair intersects rather than nests. ```json { "mapping-collection": { "uuid": "1b87036f-6b8f-42ac-9024-105c0e9aa07c", "metadata": { "title": "SSDF 1.1 to CSF 2.0: secure development environments and supplier requirements", "last-modified": "2026-10-10T09:00:00Z", "version": "1.0", "oscal-version": "1.2.3" }, "provenance": { "method": "human", "matching-rationale": "semantic", "status": "draft", "mapping-description": "Two pairs that NIST's SSDF-to-CSF informative reference relates without a relationship type, typed by this team for its own crosswalk. Reviewed against the full text of both sources." }, "mappings": [ { "uuid": "7b228166-46a8-4a65-ad92-2ef57427cd81", "source-resource": { "type": "catalog", "href": "https://raw.githubusercontent.com/usnistgov/oscal-content/v1.5.0/nist.gov/SP800-218/ver1/json/NIST_SP800-218_ver1_catalog.json" }, "target-resource": { "type": "catalog", "href": "https://raw.githubusercontent.com/usnistgov/oscal-content/v1.5.0/nist.gov/CSF/v2.0/json/NIST_CSF_v2.0_catalog.json" }, "maps": [ { "uuid": "453cb3cc-4bce-484f-a57d-b3346721d354", "relationship": "intersects-with", "sources": [{"type": "control", "id-ref": "PO.5.1"}], "targets": [{"type": "control", "id-ref": "PR.IR-01"}], "remarks": "PO.5.1 requires separating development environments, which PR.IR-01 doesn't; PR.IR-01 covers all networks and environments, not only development." }, { "uuid": "6178e8b3-7ab5-49db-8d53-a7f086430b88", "relationship": "intersects-with", "sources": [{"type": "control", "id-ref": "PO.1.3"}], "targets": [{"type": "control", "id-ref": "GV.SC-05"}], "remarks": "PO.1.3 covers communicating requirements to suppliers of commercial software components; GV.SC-05 covers all suppliers and requires the requirements in contracts." } ] } ] } } ``` ## How do you test a mapping before relying on it? Test a mapping by asking what would falsify it. If a new unreviewed input path exists, would the evidence still support the target requirement? If not, it cannot justify a blanket target pass. A reviewer should inspect the smallest concrete example and record exactly what the evidence proves. This avoids building a large matrix whose cells are untestable claims. The exercise includes an unqualified equivalence, an identifier without an edition, a doubtful set-theory relation, an unpinned release and an edition migration. The right outcome preserves useful evidence reuse while refusing automatic equivalence. The tradeoff is additional reasoning per mapping, but that work reduces duplicate collection and prevents misleading assurance statements later. A reusable evidence item should retain its immutable identity and scope so a new release cannot borrow an old passing result without considering changed behavior. ## Guided practice Your GRC team wants to publish a crosswalk to auditors. Review five draft rows with the NIST IR 8477 vocabulary before anything is copied into the matrix. ### Supplied material ```text Draft crosswalk (fictional company); relationship vocabulary: NIST IR 8477 M1 PCI DSS v4.0.1 6.2.4 (common attacks in bespoke software) "equal" ASVS 5.0.0 level 1. Rationale: none. M2 ASVS V14.2.1 "equal" PCI DSS 6.3.2 (software inventory). Rationale: "both are about components". No ASVS edition stated. M3 SSDF 1.1 PO.5.1 (separate and protect each development environment) "subset of" CSF 2.0 PR.IR-01 (networks and environments protected from unauthorized logical access and usage). Rationale: semantic. M4 NIST SP 800-53 Rev. 5 SA-11 (developer testing) "supports" SOC 2 CC8.1. Release not stated. Evidence attached: SAST results for release 4.12.0, marked "SOC 2 satisfied". M5 ISO/IEC 27001:2013 A.14.2.1 (secure development policy) "equal" ISO/IEC 27001:2022 8.25 (secure development life cycle). Rationale: syntactic. ``` ### 1. Reject the unqualified equivalence Judge M1. Worked answer: Equal claims the two say the same thing, and they don't. PCI DSS 6.2.4 asks bespoke and custom software to prevent or mitigate listed attack classes, such as injection, attacks on data structures, cryptography and business logic, and expects coding standards and tests; ASVS level 1 is 70 verification requirements across 17 chapters. With a semantic rationale they intersect. A row from one ASVS requirement, such as v5.0.0-1.2.5 supports 6.2.4 (example of), is more useful. Every row needs a written rationale. ### 2. Pin the edition Judge M2. Worked answer: V14.2.1 means different things in different editions: in ASVS 4.0.3 it is keeping components up to date, in 5.0.0 it is keeping sensitive data out of URLs. Neither equals PCI DSS 6.3.2, an inventory of bespoke and custom software and its components. The closest 5.0.0 requirement is v5.0.0-15.1.2, a maintained inventory such as an SBOM (level 2): write that pair as intersects with, semantic, with the edition in the identifier. ### 3. Check the set-theory claim Judge M3. Worked answer: Subset of says everything in PO.5.1 is also in PR.IR-01. PO.5.1 asks to separate development environments as well as protect them, which PR.IR-01 doesn't say, and PR.IR-01 covers every network and environment. They intersect. NIST's own SSDF-to-CSF reference lists the pair without a relationship type, so the type is your judgment and the rationale must be written down. ### 4. Separate the relationship from the evidence Judge M4. Worked answer: Pin the release, SP 800-53 Rev. 5 release 5.2.0, so the control text is known. SA-11 supports part of CC8.1, which also covers authorizing, approving and implementing changes. One release's SAST results are evidence for that release, not proof that CC8.1 operated over a SOC 2 period: record them as partial support for the row and remove "SOC 2 satisfied". ### 5. Handle the edition migration Judge M5. Worked answer: A syntactic rationale compares wording, and the titles differ, so syntactic equal fails; intersects with is the most it supports. A semantic judgment needs the full text of both editions, which are licensed. Keep the row only to migrate old evidence: 2013 certificates ended with the transition on 31 October 2025, so new claims cite the 2022 control. Deliverable: Five corrected rows, each with an IR 8477 style, relationship type, rationale, pinned editions and the scope of any attached evidence. Scope: The crosswalk is fictional and the relationships are this site's analysis, not official mappings. PCI DSS and ISO/IEC 27001 text is paraphrased. Articles and teaching material: CC BY 4.0. Original executable code: MIT. Attribution: Software Security. ## Sources - [NIST IR 8477: Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines (February 2024)](https://csrc.nist.gov/pubs/ir/8477/final) - [NIST Online Informative References program](https://csrc.nist.gov/projects/olir) - [NIST Cybersecurity and Privacy Reference Tool (CPRT)](https://csrc.nist.gov/projects/cprt) - [OWASP ASVS 5.0.0, V1 Encoding and Sanitization (requirement 1.2.5)](https://github.com/OWASP/ASVS/blob/v5.0.0_release/5.0/en/0x10-V1-Encoding-and-Sanitization.md). Version 5.0.0. - [NIST SP 800-53 Rev. 5 and release updates](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final). Rev. 5, with the release 5.2.0 note of 27 August 2025. - [OSCAL v1.2.3 control mapping model reference](https://pages.nist.gov/OSCAL-Reference/models/v1.2.3/mapping/). v1.2.3. - [NIST OLIR: SSDF version 1.1 to Cybersecurity Framework version 2.0](https://csrc.nist.gov/projects/olir/informative-reference-catalog/details?referenceId=196). Version 1.0.0 (final).