Catalog Updates & Deprecated Controls

The Secure Controls Framework publishes new catalog versions (for example SCF 2026.2). When the platform adopts a new version, each organisation is brought up to date through a per-organisation reconciliation — always previewed first, always reversible, and never deleting any of your data.

This guide explains what reconciliation means for your organisation: the banner you’ll see, the preview, the choices for deprecated controls, the Catalog Changelog page, and rollback. The platform-side upgrade that precedes reconciliation is an administrator task — see the Platform Catalog Upgrade runbook.

The banner in Org Settings

When the platform catalog moves to a newer version than the one your organisation was last reconciled to, Org Settings shows:

Catalog new version available — your organisation is reconciled to your version.

This is informational. Nothing about your data has changed. Your control library, scoping, assessments, and evidence keep behaving exactly as before until a platform administrator reconciles your organisation.

What the reconciliation preview shows

Reconciliation is run per organisation by a platform administrator, always from a preview. The preview has five sections:

1. New controls in your scope — controls added by the new catalog version that intersect your active framework selections. These will be added to your scope on apply. Additions outside your selected frameworks are shown as a count only.
2. Deprecated controls you have data on — for each retired control where your organisation has scoping decisions, assessments, or evidence: what data is at stake, the successor control (if the catalog names one), and an action decision (see below).
3. Changed controls in your scope — informational list of catalog text changes to controls you have selected, flagged “re-assessment recommended” where you already have assessment results.
4. Orphan report — pre-existing references to identifiers that are not in the catalog. Report-only; never blocks anything.
5. Framework confirmation (first reconciliation only) — the framework selections inferred from your historical scoping, to be confirmed before the first apply.

The three actions for a deprecated control

For every deprecated control your organisation has data on, one action is recorded before apply:

Action	What it does	When to choose it
Migrate	Creates a scoped entry for the successor control and takes the retired control out of scope with a justification. Historical data is kept.	Default when a successor exists
Retain	Keeps the retired control exactly as it is, still in scope, rendered with a deprecated badge.	Mid-engagement, or when you need continuity for an audit
Retire only	Takes the retired control out of scope with a justification, without creating a successor entry.	The control no longer applies and has no successor you want

Nothing is ever deleted

All three actions preserve your existing rows — they only change scope selection and add successors. Scoping decisions, assessments, and evidence on retired controls remain visible everywhere they were before.

What the deprecated badge means

Anywhere the app renders a control that has been retired from the catalog — control library, control detail, scoping, engagements, analytics drill-downs — it carries a Deprecated badge. Hovering shows the catalog version it was retired in and its successor control, when one exists.

Existing data keeps rendering forever; only new scoping of a retired control is refused (the error names the successor to use instead).

Audit engagements are frozen: an engagement keeps rendering the control set it was created with, stamped with the engagement’s own catalog version, regardless of later reconciliations.

The Catalog Changelog page

The Catalog Changelog page (Admin section of the sidebar) is a read-only log of every change already applied to your organisation, version by version: controls, domains, evidence, assessment objectives, capability themes, and framework mappings, each classed as Added, Changed, Deprecated, Reactivated, or Unchanged.

Use it to answer “what did the last catalog update actually change for us?” without digging through the control library.

What happens on apply

• Your scope is re-materialised from your active framework selections against the new catalog (new controls come into scope).
• Deprecated controls are handled per the recorded actions.
• Engagements are untouched.
• Organisation admins receive a notification (the bell menu links to the Catalog Changelog).
• Every row the run touches is snapshotted first — this is what makes rollback exact.

Rollback semantics

The latest applied reconciliation run can be rolled back by a platform administrator:

• Snapshotted rows are restored verbatim to their pre-reconciliation state.
• Rows the run created are deleted only if nothing references them (for example an engagement scope); otherwise they are kept but taken out of scope.
• Your organisation’s recorded catalog version returns to the previous one, and the banner reappears.
• A notification is sent when the rollback completes.

Rollback is per-organisation and does not affect the platform catalog or any other organisation.

---

Related Guides

• Platform Catalog Upgrade — the administrator runbook for the platform-side upgrade
• Control Management — scoping and implementation tracking
• Audit Engagements — why engagements are frozen at their own catalog version