A model claiming to cover everything is not credible. This page names the exclusions, and it is intended to be read before the model rather than after it.
Out of scope
Physical and environmental security. IO can measure Physical Security domain performance where attributable evidence is available. This does not, by itself, establish a Physical Security maturity finding. The current IO Maturity Model requires defined material practices, attributable execution lineage, representative evidence coverage, a completed assessment window and calibrated maturity gates. Until those requirements are satisfied for the Physical Security practice set, IO reports domain performance, evidence coverage and verification outcomes without presenting them as maturity.
Business continuity and disaster recovery planning. IO holds evidence about incident response, timelines, containment, recovery durations from real incidents and exercises. It holds nothing about the adequacy of a continuity plan, which is a document review exercise.
This boundary does not remove Resiliency from IO. Exercise occurrence, recovery time, repeat findings and whether a tested path held are execution evidence and remain in scope. The design quality and completeness of the underlying plan do not.
Personnel security and vetting. Background screening, clearance status, right-to-work. Largely held in HR systems under access restrictions that make ingestion inappropriate even where it is technically possible.
Cybersecurity architecture adequacy. Architecture reviews, exceptions and change decisions can leave execution records, and IO may measure whether those processes operate. Those records do not establish that the architecture itself is sound; that requires expert design assessment.
Any practice producing no execution record. This is the general form of the rule. If a practice leaves no trace of who did what, when, under which rule, with what outcome, then IO has nothing to measure and will say so rather than inferring.
The general rule, stated once
IO measures practices that leave execution records. Everything above fails that test in one way or another.
This is a narrower claim than most maturity models make, and narrowing it is what makes the covered practices believable. A model that scores physical security from a questionnaire, architecture from an interview, and access review from execution data is presenting three very different kinds of evidence as one number.
Seven terms are kept apart throughout: domain performance is a weighted measured result; post-intervention verification is a remeasurement outcome; maturity is a practice-based, all-or-nothing gate result; evidence confidence describes how much a value can be relied on; evidence coverage describes how much of the population was observed; assurance is an independent opinion; and compliance is a determination made by an assessor or regulator. A domain performance score is not a maturity result, maturity levels are never produced by weighting or averaging domain scores, and no verification outcome proves causation, compliance or complete control effectiveness.
What this means for a full assessment
If you need a complete security programme assessment, IO is one input and not the whole. It will give you a rigorous, evidence-based position on the practices it covers, and a clearly marked absence everywhere else.
The absence is the useful part. An assessment that reports Physical Security as domain performance with named evidence coverage, and declines to convert it into a maturity level, is more trustworthy than one that returns a confident 3 out of 5 derived from asking someone.
Where the boundary is likely to move
Physical Security is the boundary most likely to move next, and it will move on model readiness, defined practices, execution lineage, coverage and calibrated gates, not on source availability, which now exists. Continuity planning could come into scope if exercise records became rich enough to evidence plan adequacy rather than just exercise occurrence. Architecture adequacy almost certainly will not, there is no execution record that proves design quality. Architecture-governance execution may move into scope without claiming to score the design itself.
Any change to this boundary is a version increment on the model, not a quiet expansion.
Relationship to broader assessments
C2M2, NIST CSF and ISO/IEC 27001 span areas beyond IO's current evidence model. A crosswalk must therefore show covered, partially evidenced, not evidenced and out of product scope rather than forcing every framework outcome into an IO score. “Not covered” is a product boundary, not a statement that the practice is unimportant.