How does a control crosswalk survive a framework revision that splits or withdraws control ids?

## Why a revision is not a rename Frameworks are revised, and when they are, identifiers do not merely change spelling. Across a major revision you will see all of: - **Withdrawn** controls, sometimes because the requirement disappeared, more often because its intent was absorbed into another control. - **Merged** controls, where two clauses become one. - **Split** controls, where one clause becomes several more specific ones. - **New** controls with no predecessor at all, frequently whole new families reflecting concerns the previous revision did not have. - **Renumbered** clauses whose text is materially unchanged. Only the last of those is a find-and-replace. The rest need a human with the old and new text side by side, because the question is not "what is this control called now" but "does my check still answer it". ## The migration, step by step **1. Add, do not edit.** The existing mapping block pins the old catalog and stays exactly as it is. The new revision arrives as an additional block pinning the new catalog. This is the property that makes everything else possible. **2. Diff the identifier sets mechanically.** Resolve every clause id in the old mapping against the new catalog and bucket the results: still resolves, no longer resolves, resolves but the text changed. The machine can do this and should; it produces the worklist. **3. Re-decide by hand, edge by edge.** For each affected edge, read the new clause text and ask whether the same check still answers it, and at what strength. A split is the interesting case: one edge frequently becomes two, and your check may fully answer one and not touch the other — so a revision can turn one full edge into one full and one missing, which is a real coverage regression that has nothing to do with your infrastructure changing. **4. Run both in parallel.** Audit periods overlap. Last year's report was issued against the old revision, evidence already collected carries the old identifiers, and a certification cycle may run months past the publication of a new revision. Both mappings coexist until the old cycle closes. **5. Never rewrite history.** Retro-fitting new identifiers onto an issued report is not tidying — it makes the record disagree with the report that was signed. Old mappings are archived, not edited. ## Detecting drift instead of discovering it The crosswalk should have its own CI check, and it is a short one: for every edge, resolve the clause id against the catalog named in `source`; fail on anything unresolved. Add a check that every named rule identifier still exists in the policy repository, so a renamed or deleted rule cannot leave a heading in a report with nothing behind it. This is the difference between finding out in a pull request and finding out in a walkthrough. The second one costs a finding and an explanation about how long the mapping had been wrong — a question you usually cannot answer, which is worse than the gap itself. ## Two things people get wrong **Trusting a published mapping table verbatim.** Framework bodies and vendors publish crosswalks between frameworks, and they are useful as a starting worklist. They map *clause to clause*, in general terms, for an imagined organisation. They do not know your check, your scope or your strengths, so a published table can tell you which clauses to look at and cannot tell you whether your rule answers them. Importing one wholesale produces a large, confident, wrong crosswalk. **Budgeting it as a chore.** A major revision of a large framework is weeks of control-owner attention: reading clause text, re-deciding edges, chasing remainders that newly exist. Teams that schedule it as an afternoon of search-and-replace produce a mapping that resolves cleanly in CI and is nonetheless false — the worst of both worlds, because it now passes its own automated check.