Does a crosswalk mean one framework equals another?

No. A crosswalk shows that a control helps satisfy clauses in several frameworks, but it does not make the frameworks identical. Each still has its own required evidence, scope, and, where applicable, its own audit.

How much overlap is there between frameworks?

A lot, though not evenly. In Keel's open control library, 64% of the controls that map to SOC 2 also map to ISO 27001, but those shared controls are only 38% of what ISO 27001 draws on. The research on framework overlap has the full figures.

Frameworks

What is a compliance crosswalk?

In short

A compliance crosswalk is a mapping that shows how a single control satisfies the requirements of multiple frameworks at once, so evidence collected for one framework can be reused for others instead of rebuilt from scratch.

Last updated September 17, 2026

Definition

A compliance crosswalk is a reference table that maps each security control to the specific clauses, requirements, or safeguards it satisfies across two or more compliance frameworks.

Background

Most frameworks ask for the same underlying security practices in different words: access control, encryption, logging, incident response, vendor management. A crosswalk records, for a given control such as multi-factor authentication, which clause it satisfies in each framework (for example an ISO 27001 Annex A control, a SOC 2 Trust Services Criterion, and a NIST CSF subcategory). Standards bodies and vendors publish crosswalks, and GRC platforms use them to avoid duplicate work.

Why it matters

Crosswalks are the mechanism behind "collect once, comply everywhere." One security control often satisfies clauses in several frameworks, so a second framework starts from the evidence you already hold instead of from zero. How much carries over depends on the pair. In Keel's open control library, the controls SOC 2 and ISO 27001 share are 38% of what ISO 27001 draws on, so the rest of ISO 27001 is new work. The part that does carry over is time, cost, and audit friction a small team does not spend twice.

Step by step

Start from a canonical set of controls rather than one framework's checklist.
For each control, record which clause it satisfies in every framework in scope.
Collect evidence against the control once, then attribute it to every mapped clause.
When you add a framework, map its clauses to existing controls before authoring anything new.
Keep the mapping current as frameworks release new versions.

Examples

A single "encryption in transit and at rest" control maps to an ISO 27001 Annex A control, a SOC 2 criterion, a PCI DSS requirement, and a NIST CSF subcategory at the same time.
A team with SOC 2 adds ISO 27001. In Keel's library, 64% of the controls that map to SOC 2 also map to ISO 27001, so those need mapping and evidence rather than building. They cover 38% of what ISO 27001 draws on, and the team builds the rest.

Common mistakes

Treating each framework as a separate, from-scratch project instead of mapping to shared controls.
Assuming a crosswalk means clause-for-clause equivalence; it shows control-level reuse, and each framework still has its own evidence and scoping expectations.
Letting the mapping go stale after a framework releases a new version.

FAQ

Does a crosswalk mean one framework equals another?: No. A crosswalk shows that a control helps satisfy clauses in several frameworks, but it does not make the frameworks identical. Each still has its own required evidence, scope, and, where applicable, its own audit.
How much overlap is there between frameworks?: A lot, though not evenly. In Keel's open control library, 64% of the controls that map to SOC 2 also map to ISO 27001, but those shared controls are only 38% of what ISO 27001 draws on. The research on framework overlap has the full figures.

Do this in Keel, not a spreadsheet

Keel is the AI-native GRC platform for SMBs: one control-and-evidence graph across SOC 2, ISO 27001, HIPAA, PCI DSS, NIST CSF, and more. Start free, no credit card.

Start free See pricing