What a new framework version changes — and what it must never touch

Versions happen

ISO/IEC 27001 moved from the 2013 to the 2022 edition and reorganised Annex A from 114 controls in 14 domains to 93 in 4 themes. DORA’s technical standards keep landing. NIS2 national transposition acts change the detail. A curated framework pack that a compliance team adopts is therefore not a document; it is a version of a document, and the interesting question is what happens to a year of applicability decisions, control mappings and evidence when the next version is published.

Two bad answers are common. The first: silently update the requirements in place, so the decisions your team made against last year’s wording now sit under this year’s — the audit trail is corrupted and nobody knows which text a decision was about. The second: start over — a new adoption, empty, and re-type everything. Both are how spreadsheets behave.

A published version is immutable, an adoption pins one, and a transfer to the next is an explicit, audited move — never a background rewrite.

The three invariants

1. A published framework version is immutable. Once published, its requirements do not change. Corrections and additions are a new version.
2. An adoption pins a version. Your applicability decisions, control mappings and evidence coverage are made against that pinned text, and stay meaningful because the text cannot move under them.
3. Publishing a new version never touches existing adoptions. The framework owner cannot reach into a tenant’s decisions by publishing; tenants move when they decide to, and the old adoption remains as frozen history.

With those, the update becomes a well-defined operation instead of a migration project.

Four buckets

When a team transfers from version N to version N+1, every requirement falls into one of four buckets, decided by comparing requirement codes and content — with editorial changes (a typo, a reworded sentence that does not change meaning) explicitly not counting as material:

• Unchanged — the requirement is the same in substance. Applicability decisions and coverage carry over automatically, re-anchored to the new version’s requirement, with provenance back to the old row.
• Changed — the requirement’s meaning changed materially. Decisions and coverage carry over flagged “needs review” — you keep the work, but the record says a human must confirm it still holds.
• Removed — the requirement no longer exists in N+1. Its decisions stay in the old, superseded adoption as audit history; nothing is deleted.
• Added — new requirements. Nothing to carry; each becomes an open work item — an undecided requirement that shows as undecided until someone decides it.

The transfer creates a new adoption on N+1 and marks the old one superseded — never mutated, never deleted. Your controls are untouched; only the edges from requirements to controls are re-anchored, each carrying a pointer to the row it came from. The whole thing is one transaction, idempotent (running a committed transfer again changes nothing), and audited with a per-bucket manifest.

Why the flag matters more than the diff

Any tool can diff two versions. The value is that the diff is projected onto your decisions: the “changed” bucket is not “these 7 requirements changed” but “these 7 of your applicability decisions were made against text that has changed materially — here they are, still standing, marked for review”. That is the difference between a release note and a work list, and it is why editorial changes must not trigger the flag: a team that has to re-confirm 90 decisions because of typo fixes stops reading the flag.

What the auditor sees

Two adoptions: the superseded one, frozen exactly as it was on the day of the transfer, and the active one on the new version with provenance on every carried decision. The question “which text was this decision made against?” has an unambiguous answer for every row in both. Posture snapshots taken before and after bracket the change. And “we moved to the 2022 edition” is a dated, audited event with a manifest, not a line in a memo.

In Secantra

Framework packs are versioned; a published version is immutable and adoption is version-pinned. Publishing a successor never mutates adoptions. Moving is an explicit transfer: a preview shows the four buckets, the commit creates the new adoption, carries unchanged and changed rows (changed with needsReview), leaves removed rows on the superseded adoption, lists added requirements as work items, and audits the whole move; superseded adoptions are read-only. Editorial changes in the curated pack are marked as such by the curator so that they do not flag your decisions. What Secantra does not do: decide for you — every “needs review” waits for a person.

Checklist

• Published versions immutable; adoptions pinned; publishing never touches adoptions
• Transfer is explicit and previewed: unchanged / changed / removed / added
• Changed decisions carried with a review flag; added requirements as undecided work
• The superseded adoption stays frozen with every original decision
• Editorial changes never trigger review; material ones always do