Every growing company hits the same wall. You finish SOC 2. Sales lands a European deal that needs ISO 27001. A healthcare prospect asks about HIPAA. A federal opportunity wants NIST 800-53. Each one arrives as if it were a brand-new project (new checklist, new evidence hunt, new spreadsheet), even though the underlying work overlaps enormously.

It overlaps because the frameworks are describing the same handful of security realities in different words. "Restrict access to authorized users" shows up in SOC 2, ISO 27001, NIST CSF, and 800-53 alike. The controls you already run satisfy most of what the next framework asks for. The problem was never the work. It's that most tooling makes you redo the mapping every time.

Bolted-on mapping vs. crosswalk-native

Most GRC platforms treat cross-framework mapping as a feature: a screen where evidence gets "auto-linked" across controls, added on top of a per-framework data model. It helps, but the seams show. Each framework is still its own island; the mapping is a bridge you maintain.

Crosswalk-native means the mapping is the data model. Keel is built on one control library. A control isn't owned by a framework. It's crosswalked to the clauses it satisfies across every framework at once. Evidence attaches to the control, and readiness for every applied framework is computed from the same graph.

The practical difference:

  • Your first framework builds the control library and collects the evidence.
  • Your second framework mostly lights up controls you already have. You're not starting over. You're seeing how much of the new standard your existing program already covers, and closing the genuine gaps.

Collect once. Comply everywhere. Not as a tagline, but as the shape of the underlying data.

Why the architecture, not the feature, is the point

Anyone can claim "cross-mapping." The question is whether it's load-bearing. Three things fall out of a crosswalk-native model that a bolted-on one struggles to match:

  1. Honest readiness across frameworks. Apply a second or third framework and each one's readiness reflects the controls and evidence you already have: no duplicate data entry, no re-uploading the same screenshot four times.
  2. One place to change things. Update a control's status or evidence, and every framework that crosswalks to it updates too. There's no fan-out of copies to keep in sync.
  3. The gap is the signal. Because coverage is computed from the shared graph, what's left after you apply a framework is exactly the delta worth working, not a fresh 100-item checklist that's 70% redundant.

The honesty part

There's a temptation in this category to advertise breadth you don't have: to list forty frameworks on a page and imply deep support for all of them. We take the opposite stance: the number of controls Keel shows for a framework is the number we've actually authored and score against, enforced by a test in our codebase. If it's listed as available, the content is real. That discipline is a feature, not a footnote. Your auditor will notice the difference.

What sits on top of the graph

The crosswalk model is the foundation; the program you run on it is the product:

  • Evidence collected once and reused across every framework it satisfies.
  • A risk register where residual risk reflects the controls actually mitigating each risk.
  • Vendor and third-party risk, a people directory with access reviews, policies, a Statement of Applicability, and the ISMS registers a real audit expects.
  • ISO 9001 quality management on the same graph, for teams whose compliance isn't only security.
  • An open REST API and MCP server, so your data is yours to automate, and an open-source migration tool to bring it in from another platform in the first place.

Where to start

Pick the framework your buyers ask for first. Build the control library and collect the evidence for that one. Then, when the next requirement lands, apply it and watch how much is already done. The second framework is where crosswalk-native stops being an idea and starts saving you a quarter of work.

That's the whole thesis: compliance is mostly the same work described four ways. Build on a model that knows that, and you only do it once.

Want to see it on your own frameworks? Start free (no card) and apply a second framework to watch the overlap light up.