A crosswalk is a claim, not evidence¶
A coverage report can look finished. Every requirement across four frameworks has a control mapped to it, color-coded and exportable. Then an auditor asks the one question that decides anything: for this requirement, show me the control operated over the period, and show me the evidence. The mapping cannot answer that. It was never built to.
That gap is worth thinking about this week, because on August 25 NIST finalized SP 1347, the Cybersecurity Framework 2.0 Informative References Quick-Start Guide. It does something useful. It turns the crosswalks that say "this part of CSF 2.0 relates to that clause of ISO 27001" into structured data you can filter, export, and pull into your own tools, instead of an appendix in a PDF. Crosswalks are becoming data.
That is real progress, because the crosswalk is the spine of any program that answers to more than one framework. It is how you write a control once and account for it across ISO 27001, SOC 2, GDPR, NIST CSF 2.0 and HIPAA. But SP 1347 is careful about something a lot of GRC tooling glosses over. An informative reference is a relationship, and it is one-to-many and imperfect on purpose. It tells you two elements are related. It does not tell you a control ran, that evidence exists, or that the relationship is exact. A crosswalk is a claim about the framework. It is not evidence about your program.
Where a crosswalk stops being enough¶
An auditor does not sample against your crosswalk. They sample against a control. The request is never "show me your mapping." It is "for A.8.16, or CC7.2, or Article 32, show me this operated for the whole period, and show me the evidence."
A mapping that survives that has to carry more than a raw informative reference does. It has to say what kind of relationship it is, because "equivalent," "supports," and "is a subset of" have different consequences, and flattening them into "related" is where the clean report comes apart under questioning. It has to record who asserted it, against which versions of both frameworks, and why, because an undated mapping becomes a liability the moment ISO reissues a control or CSF versions. And it has to hold a hard line between the mapping and the coverage: a mapping says a control would satisfy a requirement, coverage says it did, with evidence, and treating the first as the second is how teams get burned. Get those right and a crosswalk is defensible. Skip them and you have a spreadsheet that looks like assurance.
The evidence a policy cannot produce¶
There is a second gap, and AI made it wider.
More of the compliance work is done by an AI now. It drafts the policy, assesses the control, proposes the mapping, assembles the evidence. That is useful, and it raises a question a crosswalk cannot answer. When the auditor asks how this control changed, which tool the AI called, what arguments it used, and who allowed it, a policy that says "the agent must not do X" is a statement of intent. It is not evidence that anything was prevented.
This is the problem a newer category of runtime governance is built for. These layers sit between an AI agent and its tools, check each call against policy before it runs, allow or deny it, and write down who called what, with which arguments, and which rule matched, on a signed, tamper-evident ledger. They move the answer from "we have a policy" to "the action was allowed or blocked, and here is verifiable evidence of the decision."
That is the right thing to build, and the parts that decide whether it holds up in an audit are the ones that get the least attention. A signed ledger proves what the enforcement point saw. It does not prove nothing went around it, so whether that point can be bypassed, and what happens when it is down, matters as much as the ledger. If it records tool arguments verbatim, the ledger can end up holding the exact personal data the policy was meant to protect, which turns your evidence store into a problem under GDPR. Logging typed or hashed arguments by default avoids that. And auditors challenge local clocks and systems that can rewrite their own history, so a trusted timestamp, and a bundle that verifies with the running system gone, are what let the evidence stand.
The two layers fit together¶
At the tool-call edge, runtime governance produces the primary evidence: signed, portable records of what an agent did and whether it was allowed. Above it sits the compliance record: the control objects, the crosswalk that places each control against the requirements it satisfies, and the human-approved, tamper-evident trail an auditor actually reads. Auditors read control assertions backed by evidence, not raw ledgers, and a signed runtime bundle is close to ideal primary evidence for the record to point at, by reference and hash, without copying the content in. A crosswalk with no evidence under it is a claim. A signed ledger with no control model above it is a log an auditor cannot connect to anything they care about. You need both.
Where Kanonik sits¶
Kanonik is the record. The customer's own AI, connected over MCP, does the compliance work. Kanonik gives it a typed model to write to, a verifier on our side that grades every proposed change before it can land, a single-use signed approval on every write, and a hash-chained log that keeps the model, the prompt version, the reasoning and the approval together. Framework packages ship for ISO 27001:2022, SOC 2, GDPR, NIST CSF 2.0 and HIPAA, and a mapping in Kanonik is a typed object that carries its own provenance and rationale, which is the direction SP 1347 is pointing. The mechanisms line up with what an auditor and a regulator ask for: non-repudiation and retention under NIST 800-53 AU-10 and AU-11, audit generation under AU-12, human oversight and record-keeping under EU AI Act Articles 14 and 12.
We built Kanonik to take signed runtime evidence as a first-class source. A control assertion in the record can point at an external, independently verifiable bundle by its hash, so the proof that something happened, from the runtime edge, and the claim about which requirement it satisfies, from the crosswalk, resolve to one record with a person on every change. That pairing is where we think defensible AI compliance is going, and we will have more to say about a specific runtime-governance collaboration before long.
What this settles, and what it doesn't¶
SP 1347 makes the crosswalk into data. It does not make the crosswalk into evidence. Runtime governance makes the evidence real and signed. It does not, on its own, connect that evidence to the requirement an auditor asks about. The record that binds a typed crosswalk to verifiable evidence, with a human accepting each change, is what turns "the AI drafted it" into something you can hand to a stranger a year later and have it hold.
Kanonik is new-gen GRC for teams that can't afford the GRC monsters and shouldn't have to. The verifier is at kanonik.ai/verify. Start a 14-day trial at kanonik.ai.