The Multi-Framework Problem
Organisations in regulated and critical sectors rarely face a single compliance obligation. A UK energy company may need to demonstrate compliance with ISO 27001, the NCSC Cyber Assessment Framework, the NIS Regulations, IEC 62443 for its operational technology, Ofgem expectations, and — in the near term — the requirements of the UK Cyber Security and Resilience Bill. A financial services firm may face DORA alongside ISO 27001, PCI DSS, and sector-specific FCA guidance.
Each framework has its own control structure, its own terminology, its own evidence expectations, and its own assessment cycle. The natural organisational response is to manage each framework as a separate compliance programme: separate control sets, separate evidence repositories, separate assessments, separate reports. This is understandable. It is also structurally inefficient and, over time, counterproductive.
The Structural Cost of Duplication
The problem with parallel compliance programmes is not simply that they cost more. It is that they create structural weaknesses in the very governance they are intended to strengthen.
The first weakness is evidence fragmentation. When the same firewall configuration is referenced in four different compliance programmes, each with its own naming convention, review cycle, and responsible owner, there is no single authoritative record of whether that evidence is current. When it is refreshed in one programme but not another, the inconsistency is invisible until an audit exposes it.
The second weakness is assessment divergence. A control that is assessed as "effective" under one framework methodology may be assessed as "partially implemented" under another — not because the control has changed, but because the assessment criteria, maturity model, or evidence threshold differ. The organisation now has two conflicting assessments of the same control, with no mechanism to reconcile them.
The third weakness is reporting incoherence. When boards receive separate compliance reports from separate programmes, they see framework-specific compliance status rather than the organisation's actual security posture. The aggregate view — how well-governed is this organisation, across all its obligations — is left for executives to synthesise informally, if it is synthesised at all.
Why Mapping Spreadsheets Do Not Solve It
The most common response to multi-framework complexity is a mapping spreadsheet: a cross-reference table that shows which controls in Framework A correspond to requirements in Framework B, C, and D. This is useful reference material, but it does not resolve the structural problem.
A mapping spreadsheet is a static artefact. It shows relationships between frameworks at a point in time, but it does not manage evidence, track assessment status, enforce review cycles, or produce compliance reporting. The controls in the spreadsheet still need to be assessed separately for each framework. The evidence still needs to be collected and maintained separately. The reporting still needs to be produced separately.
In practice, a mapping spreadsheet identifies the duplication without eliminating it. The organisation knows that ISO 27001 Annex A.8.1 and NCSC CAF B4.a address related concerns, but it still manages them as separate compliance items with separate evidence and separate assessment activity. The mapping documents the problem rather than solving it.
The Canonical Principle
A canonical control model takes a fundamentally different approach. Rather than starting with multiple frameworks and mapping between them, it starts with a single, framework-independent control taxonomy. Each control is defined once, in terms that are operationally meaningful regardless of which regulatory lens is applied. The framework requirements are then mapped to this canonical baseline — not to each other.
The consequence is structural: when an organisation assesses a canonical control, the result is automatically reflected across every mapped framework. When evidence is linked to a control, it becomes available through every compliance view. When a control's maturity changes, the change propagates consistently. There is one control reality, with multiple framework perspectives on it.
This is not a theoretical distinction. It changes the operational model for compliance. Instead of assessing the same underlying capability multiple times through different framework lenses, the organisation assesses it once through the canonical model and derives framework-specific compliance status from the result. Instead of maintaining separate evidence for each framework, the organisation maintains one evidence set and maps it to the controls it supports. Instead of producing separate compliance reports, the organisation generates framework-specific views from a single data source.
What a Canonical Model Requires
Building a credible canonical model is not a trivial exercise. It requires several structural properties that distinguish it from a simple consolidated control list.
First, comprehensive domain coverage. The model must span the full breadth of security governance — from leadership and risk management through to technical controls, operational processes, and compliance assurance — so that no framework requirement falls outside its scope. A model that covers information security but not operational technology, or that covers technical controls but not governance, will leave gaps that force organisations back into framework-specific programmes for the uncovered areas.
Second, layered complexity. Not all controls apply equally to all organisations. A canonical model must distinguish between foundational controls that form a universal baseline and complex controls that address specific contexts: safety-critical systems, advanced persistent threats, heightened regulatory obligations, or sector-specific requirements. Without this layering, the model either imposes disproportionate requirements on simpler environments or fails to capture the depth required by complex ones.
Third, extensibility through overlays. A canonical model cannot anticipate every sector-specific or context-specific requirement in its core structure. It must support overlay domains — dedicated extensions that add controls for specific operational contexts without duplicating or modifying the mandatory baseline. This allows the model to serve an IT-only environment, an OT-heavy industrial operation, and a converged IT/OT critical infrastructure operator from the same foundational structure.
Fourth, traceable mapping. Every relationship between a canonical control and a framework requirement must be explicit, auditable, and documented. When an auditor asks how the organisation satisfies a specific clause of ISO 27001 or a specific indicator of the NCSC CAF, the answer must be traceable from the framework requirement through the canonical control to the evidence that supports it. Without this traceability, the canonical model is an abstraction rather than an assurance instrument.
The Evidence Dividend
Perhaps the most immediate practical benefit of a canonical approach is the elimination of evidence duplication. In a traditional multi-framework programme, the same evidence artefact — a network diagram, a risk assessment, an access control policy — may be collected, stored, reviewed, and maintained separately for each framework it supports. Multiply this across dozens of controls and several frameworks, and the evidence management burden becomes a significant proportion of the total compliance effort.
In a canonical model, evidence is linked to controls, not to frameworks. A network diagram that supports a canonical network security control simultaneously satisfies the corresponding requirements in ISO 27001, the NCSC CAF, IEC 62443, and any other mapped framework. It is stored once, reviewed once, and refreshed once. When it expires, the impact is visible across all frameworks simultaneously, not discovered piecemeal during separate audits.
This is not merely an efficiency gain. It is an assurance improvement. Evidence that is managed once is more likely to be current than evidence that must be maintained in parallel across multiple repositories. The canonical model makes evidence currency a standing governance obligation rather than an audit preparation exercise.
The Reporting Transformation
A canonical model also transforms compliance reporting. Rather than producing separate reports for each framework — each with its own methodology, its own scoring, and its own recommendations — the organisation produces a single assurance view that can be filtered by framework, by domain, by sector, or by stakeholder audience.
For boards, this means a composite assurance position that reflects the organisation's genuine security posture rather than a collection of framework-specific compliance statuses. For auditors, it means traceable evidence chains from framework requirements through canonical controls to supporting evidence. For operational teams, it means a single governance model to manage, rather than parallel programmes competing for the same resources.
The shift is from compliance as a reporting exercise to assurance as a governance function. The canonical model does not just make compliance cheaper — it makes assurance more credible, because the underlying data is consistent, current, and traceable.
The Bottom Line
Multi-framework compliance duplication is not a process problem to be managed — it is a structural problem to be resolved. Mapping spreadsheets document the duplication. Process improvements mitigate it. A canonical control model eliminates it by design.
The case for a canonical approach is straightforward: assess once, evidence once, report once — comply across all applicable frameworks from a single source of truth. The alternative is to continue investing in parallel programmes that are individually compliant but collectively incoherent, progressively more expensive, and structurally incapable of delivering the unified assurance confidence that boards and regulators increasingly require.