IO is not a replacement for a cybersecurity framework, management-system standard, risk method, control catalog or assurance engagement. It is an evidence operating layer: it connects observed conditions to accountable work, then tests whether that work was followed by measurable change.
This map states where that position follows accepted practice, where IO adds a stronger constraint, and where IO intentionally stops.
The four layers
| Layer | Representative source | Industry question | IO contribution |
|---|---|---|---|
| Outcomes | NIST CSF 2.0 | What cybersecurity outcomes should an organisation pursue? | Organises evidence and work against outcome areas without claiming satisfaction |
| Practices and maturity | C2M2 v2.1 | Are practices implemented and institutionalised? | Tests repeatability through execution records; never converts IO levels into MILs |
| Management systems | ISO/IEC 27001:2022; ISO/IEC 42001:2023 | Is a governed system established, operated, evaluated and improved? | Supplies dated evidence for selected operational, evaluation and improvement activities |
| Risk | ISO 31000; NIST SP 800-30 | How should uncertainty, consequence and treatment be evaluated? | Preserves the organisation's scale while requiring evidence before observed residual moves |
Where IO agrees
Across these sources, several principles are already normal:
- leadership retains accountability;
- risk decisions are contextual rather than universal;
- monitoring and performance evaluation must continue after implementation;
- improvement requires feedback rather than a one-time project;
- evidence quality and scope determine how much a conclusion can support; and
- tools enable governance but do not own it.
IO should say so. A distinctive method is more credible when it acknowledges the foundation it builds on.
Where IO is intentionally more opinionated
Control presence is not operating effectiveness
A policy, configured tool or completed task can establish implementation. It does not by itself establish that the intended outcome occurred. IO preserves both facts and does not let the first impersonate the second.
Residual risk does not move on implementation alone
Accepted risk methods allow expert judgement, and IO does not reject it. IO's observed residual is narrower: only an attributable verification moves it. The larger enterprise risk view can still include scenarios, threat intelligence, loss modelling and expert judgement.
Coverage precedes pass rate
An excellent result across a small measured subset may be less informative than a mixed result across broad coverage. IO always reports the denominator and the unassessable population before it reports success.
Failure is retained
An unverified or regressed intervention stays in history and affects future playbook ranking. It is evidence for adaptation, not a record to be corrected.
Where IO stops
IO does not certify ISO conformity, calculate a C2M2 MIL, conduct a NIST control assessment, establish legal compliance, prove causation, or replace professional judgement. It does not claim that its six maturity levels are required by any cited source.
Claim language
| Avoid | Use instead |
|---|---|
| “Compliant with NIST” | “Evidence mapped to selected NIST CSF 2.0 outcomes” |
| “C2M2-aligned maturity level” | “IO maturity finding, informed by C2M2 institutionalisation concepts” |
| “ISO 42001 certified by IO” | “Evidence relevant to selected ISO/IEC 42001 clause areas” |
| “The control is effective” | “The declared measure moved in the intended direction following the intervention” |
| “AI proved compliance” | “Automation collected or analysed evidence; an accountable reviewer accepted the conclusion” |
Primary references
- NIST, Cybersecurity Framework 2.0 (opens in a new tab)
- US Department of Energy, C2M2 v2.1 (opens in a new tab)
- ISO, ISO/IEC 27001:2022 (opens in a new tab)
- ISO, ISO/IEC 42001:2023 (opens in a new tab)
- ISO, ISO 31000 (opens in a new tab)
- NIST, SP 800-30 Rev. 1 (opens in a new tab)