How to read a crosswalk, and when not to trust one
Crosswalks are the backbone of multi-framework compliance, and one of its most misused tools. Five questions tell you how far to trust one.
A crosswalk is a mapping between the requirements of two frameworks. It's how a gap analysis knows that ISO 27001's A.8.24 relates to PCI DSS 3.5.1, and how a GRC tool claims a control "satisfies" six frameworks at once. Used well, crosswalks save enormous effort. Used uncritically, they produce confident answers that auditors take apart. Five questions tell you how much to trust one.
1. Who made it?
Authority varies enormously. A crosswalk published by NIST, ENISA or the framework owner has usually been through public comment and is widely used. A vendor's crosswalk may be careful or may be a junior analyst's afternoon. Our own data labels every link as crosswalk (a published crosswalk supports it) or editorial (our judgement, with a reason). The split is revealing, as our post on how much mapping rests on published evidence shows.
2. Which versions?
Mappings rot. A crosswalk from CSF 1.1 points at subcategories that no longer exist (see where the withdrawn ones went); one from ISO 27001:2013 uses a control numbering that ended with the 2022 transition; one from PCI DSS v3.2.1 misses the v4.0 requirements. Check both versions before anything else.
3. What does a line mean?
NIST's guidance on crosswalks (NIST IR 8477) distinguishes relationship types: two requirements can be equal, one can be a subset or superset of the other, or they can merely intersect. Most published crosswalks don't say which, so a line between two requirements usually means "related", not "equivalent". Treat it as a pointer to read both texts, not as a conclusion.
4. Which direction?
Mappings aren't symmetric in practice. Every NIS2 point maps to something in ISO 27001, but much of ISO 27001 has nothing in NIS2's Annex: the management system has no counterpart. Always read a crosswalk in the direction of your question: "I have A, what does B add?" A gap analysis does exactly this:
| Direction | Mapped | No mapping | ||
|---|---|---|---|---|
| Have ISO 27001 → need NIS2 | 49 of 49 (100%) | 0 | 0 | report → |
| Have NIS2 → need ISO 27001 | 104 of 123 (85%) | 13 | 6 | report → |
5. At what granularity?
A crosswalk can map whole families ("AC maps to Access Control") or individual requirements. Family-level links are almost useless as evidence; they're true of everything inside. NIST's older data linked some CSF subcategories to every SP 800-53 family; we don't count those as evidence for exactly that reason.
When not to trust a crosswalk
- It has no stated source or version.
- It maps everything to everything (a sign of family-level or keyword mapping).
- It claims "full compliance" from a mapping.
- It hasn't been updated since a framework changed.
- You can't see why two specific requirements are linked.
A worked example
Take a link from NIST's published references: CSF 2.0 PR.AA-03 (users, services and hardware are authenticated) to ISO 27001 A.8.5 (secure authentication). Apply the five questions:
- Who made it? NIST, through the CSF 2.0 informative references: authoritative.
- Which versions? CSF 2.0 and ISO 27001:2022: current.
- What does the line mean? Related outcomes. A.8.5 requires secure authentication technologies and procedures; PR.AA-03 is the outcome that authentication happens. Close, but not identical.
- Which direction? Meeting A.8.5 well achieves PR.AA-03; achieving PR.AA-03 doesn't prove every aspect of A.8.5.
- What granularity? Requirement to requirement: useful as evidence.
Conclusion: a strong link, good for planning, still worth reading both texts before relying on it in an audit.
Key takeaways
- Check source, versions, meaning, direction and granularity.
- Use crosswalks to find what to check, not to decide.
Using crosswalks well
Use them to find what to check, never to decide what's done. Start from the most authoritative source available, read both requirement texts for anything that matters, and record your own conclusion. The gap analysis shows the source of every link; the methodology lists our sources and versions.
Questions
Does a crosswalk prove compliance?
No. A crosswalk shows that requirements in two frameworks address related outcomes. Whether your implementation meets both is a separate question.
Who publishes authoritative crosswalks?
Framework owners and public bodies: NIST (CSF 2.0 references, SP 800-53 to ISO 27001, SP 800-171 Appendix D), ENISA (NIS2 to ISO 27001 and CSF), CIS and PCI SSC (their frameworks to CSF 2.0).
Data as of 2026-10-27: numbers in this post are computed from the current crosswalk and update when it changes. Crosswalk a published crosswalk (NIST, ENISA, CIS, PCI SSC) makes the link · Editorial ControlMapping's judgement where no crosswalk exists; the reason is shown · only shares a CSF 2.0 outcome: worth checking, not a mapping · No mapping in our data nothing mapped in our data; often new work, but check the coverage notes. Not compliance advice.
Related posts
Analysis · 2026-10-27APRA CPS 234 and ISO 27001: what your ISMS covers and what APRA addsAn ISO 27001 ISMS covers nearly every paragraph of APRA's CPS 234, yet APRA adds Board duties, third-party assurance and strict notification deadlines.
Analysis · 2026-10-13MFA requirements compared across 11 security frameworksWhich frameworks require MFA, for whom and how strictly: PCI DSS, CMMC, NIS2, Essential Eight, ISO 27001, SOC 2 and HIPAA compared side by side.
Analysis · 2026-09-29HIPAA Security Rule through the NIST CSF 2.0 lensA NIST CSF 2.0 programme maps to almost every HIPAA Security Rule requirement. What carries over, the two that don't, and what CSF adds beyond HIPAA.