A control crosswalk maps the requirements of different frameworks onto a single set of controls you actually operate. It exists because frameworks overlap enormously - they all want access control, encryption, logging, incident response, supplier oversight and awareness training. Only the wording and the numbering differ.
The problem it solves
Without a crosswalk, each new framework is treated as a fresh project: a new spreadsheet, a new evidence request to the same engineers, a new set of answers to questions they already answered. Teams end up collecting the same access review three times because three auditors asked for it under three different control identifiers.
With a crosswalk, adding a framework is largely a mapping exercise, not a security programme. The marginal cost of the second, third and fourth framework collapses.
How much actually overlaps
The same underlying activity appears in nearly every framework:
- Access control and MFA - ISO 27001, SOC 2, NCA ECC, SAMA CSF, PCI DSS, NIST.
- Encryption in transit and at rest - all of the above.
- Logging and monitoring - all of the above.
- Vulnerability management - all of the above.
- Incident response - all of the above, plus the GDPR and PDPL for personal data.
- Supplier and cloud risk - a dedicated domain in the NCA ECC and SAMA CSF.
- Awareness training - all of the above.
What differs is depth, evidence expectations and scoring - for example, SAMA CSF grades maturity from 0 to 5 rather than pass or fail.
Map once, report everywhere
GRC Copilot builds the crosswalk for you - mapping your controls and evidence across every framework you report against, and showing projected coverage before you start the next one.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
Building a crosswalk that works
- Choose an anchor framework. Usually the most comprehensive one you already run - ISO 27001 for most organisations, or the NCA ECC in Saudi Arabia.
- Define your control library. These are the controls you operate, described once in your own language.
- Map requirements to controls, not framework to framework. Framework-to-framework mappings break as soon as one is revised; a control library survives.
- Record mapping strength - full, partial or related. Partial mappings are where audit surprises come from, so mark them honestly.
- Attach evidence to the control, never to the framework requirement. One artefact then flows to every mapped requirement automatically.
- Track the residue - the requirements no existing control satisfies. That short list is your real gap.
The trap: assuming a mapping is a pass
A mapped control is not automatically a satisfied control. Frameworks differ in the depth of evidence they demand for the same topic. Access review is a good example: ISO 27001 wants periodic review; PCI DSS wants specific frequencies and scope; SAMA CSF wants measurable, reported effectiveness to reach maturity level 4.
Map for efficiency, then verify each mapping against the stricter framework's evidence bar. Mapping saves you the work of discovering the requirement - it does not save you the work of meeting it.
What good looks like
- One control library, owned and versioned.
- Every framework requirement mapped to a control, with strength recorded.
- Every piece of evidence attached to a control, dated and owned.
- Coverage reporting per framework, driven by the same underlying data.
- A visible list of unmapped requirements - your genuine backlog.
Frequently asked questions
How much overlap is there between ISO 27001 and SOC 2?
Substantial - the majority of SOC 2 common criteria have a close ISO 27001 counterpart. The difference is in form: ISO certifies a management system, SOC 2 tests control operation over a period.
Should we map framework to framework or to our own controls?
To your own controls. Direct framework-to-framework mappings become stale with every revision and hide what you actually do.
Can AI do the mapping?
Yes - semantic comparison of control text is a task language models handle well, and it turns a multi-week exercise into a reviewable draft. A human should confirm the mappings, particularly the partial ones.
Does mapping reduce audit effort?
It reduces evidence collection effort substantially, because one artefact serves many requirements. The audit itself still tests each framework on its own terms.
Key takeaways
- Frameworks overlap heavily; the wording and numbering differ more than the substance.
- Map requirements to your own control library, not framework to framework.
- Attach evidence to controls so one artefact serves many requirements.
- Record mapping strength - partial mappings are where audits go wrong.