The Video ASM maturity model
Six levels, from an unknown estate to one managed as part of enterprise cyber risk. Each level has an evidence test. A level you cannot evidence is a level you are not at.
Maturity models are usually self-assessed, and self-assessment drifts upward. This one attaches an evidence test to each level: a question with a factual answer, which someone outside the team could check. If you cannot produce the evidence, you are at the level below, regardless of how much of the work feels done.
The levels are cumulative. Level 3 assumes levels 1 and 2 still hold, and a common failure is reaching level 3 for the estate as it was two years ago.
The levels#
Unknown
No reliable inventory. The organisation cannot say how many cameras, recorders or video servers it operates, and the question routes to whoever last dealt with the installer.
Evidence test: can you produce a device count, from any source, that someone is willing to defend? At L0 the honest answer is a range, or a number that came from a purchase order rather than the network.
Inventory
A device list exists and has a named owner. It records what the devices are and roughly where they sit. It is maintained by hand, and it is already partly wrong — but it exists, and its gaps are arguable rather than unbounded.
Evidence test: produce the list, and name the person accountable for each site's devices. Then compare it against one independent source — a VMS device export, or PoE port status on the switches — and state the difference. At L1 you can produce the list; you may not yet like the comparison.
Visibility
The inventory carries manufacturer, model and firmware version, and network services are known per device. Unknown values are recorded as unknown rather than left blank or inferred. Discovery runs from more than one source, so gaps between sources are visible.
Evidence test: produce the list of devices whose firmware version you do not know, and the list of devices that appear in one discovery source but not another. Both lists should be short and both should be non-empty — an organisation claiming zero unknowns is usually not looking hard enough.
Risk management
Vulnerabilities, lifecycle status and exposure are mapped onto the inventory and ranked into a queue that someone works. Findings that cannot be fixed are recorded as accepted risks with owners and review dates, not left open indefinitely.
Evidence test: take the top item in the queue and the fortieth, and explain the ordering without appealing to a composite score. Then produce the accepted-risk register and check that every entry has an owner and a future review date.
Continuous management
Discovery, identification and vulnerability mapping run on a schedule without being convened. New devices are detected within a stated interval. New vulnerabilities affecting models already held are surfaced automatically. Remediation moves through the organisation's normal change process rather than as a project.
Evidence test: connect a camera to a network segment and time how long it takes to appear in the inventory with an owner assigned. Then take a CVE published in the last quarter affecting a model you hold and show when it reached your queue, and by what route.
Integrated
Video infrastructure is not a separate programme. It appears in the same asset inventory, the same risk register, the same detection coverage and the same reporting as everything else the security function owns. Procurement of new video equipment carries security requirements, and the contract with the integrator reflects them.
Evidence test: find video devices in the enterprise asset system without using a video-specific tool or filter, and produce a purchase or tender document from the last year containing security requirements that were actually evaluated. If video only appears when you go looking for it specifically, this is L4.
What each increment costs#
The model is more useful with an honest note on effort, because the levels are not evenly spaced. The step from L2 to L3 is the one organisations consistently underestimate.
| Step | Principal cost | Usual blocker |
|---|---|---|
| L0 → L1 | Time, and a decision about who owns it | Nobody wants the accountability |
| L1 → L2 | Integration work against several data sources | Firmware version is inconsistently exposed; some devices need credentials nobody holds |
| L2 → L3 | Analysis, and an owner for the queue | Vulnerability data for these products is sparse and inconsistently identified; prioritisation cannot be bought as a number |
| L3 → L4 | Automation and change-process integration | Remediation depends on a third party under a contract written before any of this mattered |
| L4 → L5 | Organisational, not technical | Procurement, budget lines and reporting structures do not follow the network |
Two of the five steps are contractual rather than technical. That is not incidental — it is the characteristic difficulty of this asset class, and a programme designed as a purely technical exercise will stall at L3.
Using the model#
Assess per site, not per organisation. A retail estate with four hundred branches will not have a single maturity level, and averaging produces a number that describes nowhere. The useful output is a distribution: how many sites are at each level, and which are furthest behind.
Assess against the current estate. The most common way to overstate maturity is to have done the work once. If the last full discovery was eighteen months ago, the L2 claim covers the estate as it existed then.
Do not report a level without its evidence. The model's only real function is to make the claim checkable; a level asserted without the test attached is the thing the model exists to prevent.
Status of this model#
This is version 1.0 and it has not been validated against a body of implementations. The level definitions are derived from how video estates are actually procured and operated, and the evidence tests are written to be answerable — but the model has not been trialled at scale, and we make no claim that the five steps are correctly spaced.
It is published in this state deliberately, because a framework nobody can argue with is a framework nobody has read. Disagreement, and particularly evidence that a level test is unanswerable in practice, is the most useful thing we could receive: framework@videoasm.com.