The Vulnerability Management Programme Schematic

A companion reference for the CAXA Technologies Security Operations Series: Vulnerability Management

There is a specific problem that comes after reading about a framework: you have the intellectual structure but not the document that makes it operational. The ownership conversation has happened, or is about to. The maturity baseline has been assessed. The SLA structure needs to be agreed and recorded in a form engineering leadership can commit to, security can report against, and a QSA or regulator can review.

That is what the Programme Schematic is. Not a checklist. Not an assessment tool. A programme design document you complete for your own environment, covering the decisions the series has been building toward.

What the Schematic contains

Seven sections. Each has completable fields and inline instructions.

Section 0: Programme identity. Owner, version, review cadence, and a checklist of applicable regulatory obligations. Version control matters: the Schematic changes when engineering leadership agreements change, when a new asset class comes into scope, or when regulatory obligations shift. The owner field identifies who calls the review.

Section 1: Programme scope. Which asset classes are in scope, which scanner or discovery mechanism covers them, and where the known gaps are. An accurate scope declaration with documented gaps is more useful than an over-claimed scope with no evidence of coverage. Gaps belong here; they become a tracked commitment rather than a hidden liability.

Section 2: Per-Pillar maturity baseline. A self-assessment using the observable behaviours from Episode 11's maturity model, applied per-Pillar. The observable behaviours and per-Pillar level descriptions are in Episode 11 of the CAXA Technologies Security Operations Series, available on the CAXA blog at [link]. Complete this before the ownership and SLA sections; it establishes where the programme is before you document where it is going. The weakest Pillar sets effective programme maturity; the per-Pillar view identifies the constraint.

Section 3: Asset tier classification. The tier schema that feeds the SLA structure. Without tier classification maintained consistently, SLA enforcement is not tractable at volume. The required classification criteria, asset examples by tier, and the fields that must appear in the CMDB are all here.

Section 4: SLA structure. The schema, not the values. Your regulatory obligations, risk appetite, and operational capacity determine the values; the Schematic provides the structure. The one non-negotiable: any finding in the CISA KEV catalogue triggers the top SLA regardless of CVSS base score. This is a programme-level commitment, not a per-finding decision, and it is not subject to exception. The KEV threshold is not a regulatory mandate: it is an operational commitment grounded in the fact that exploitation of these specific vulnerabilities is already occurring at scale. The risk calculus for a KEV item cannot be resolved by CVSS score because the theoretical exploitability question has already been answered in the wild. Where the fix requires a vendor patch that is not yet available, the SLA commitment is met through compensating controls (engineering owns both the control and the deployment when the patch ships), but the SLA itself does not move. EPSS score is captured per finding and informs remediation ordering within a tier: findings in the same tier with higher EPSS values are addressed first. This is consistent with the prioritisation model in Episode 6 and explains why EPSS also appears as a required field in the Section 6 exception records.

Section 5: Ownership RACI. The load-bearing rows from "The Conversation That Kills Programmes": SLA for closure sits with engineering; exception approval sits with engineering leadership, with security defining the criteria and maximum permitted lifetime; SLA breach escalation sits with engineering; validation sits with security. The RACI also covers asset discovery, scan scheduling, finding publication, vendor-dependent CVE handling, metrics reporting, and programme governance. Completable role names and notes fields throughout.

Section 6: Exception framework. A per-record schema for every exception: finding reference, asset tier, severity, CVSS and EPSS scores at the time of acceptance, risk acceptance rationale, compensating controls with named owner and review date, approval chain, and a hard expiry. An exception process with no expiry date is a deferral mechanism. The fields here enforce the lifecycle.

Section 7: Escalation paths. Three named scenarios: SLA breach in progress, exception approval dispute, and expired exception not renewed. Each has a completable trigger condition, recipient, evidence requirement, and expected response timeframe.

How to complete it

The sections follow a recommended order, but not all of them can be completed in isolation.

The programme owner can complete Sections 0 and 1 independently. Section 2's maturity baseline is largely a solo exercise, though worth calibrating with security leadership before treating it as definitive.

Section 3 requires security and IT or platform engineering to define jointly. The tier definitions feed directly into Section 4, so complete 3 before 4.

Section 4's SLA values cannot be finalised without engineering leadership: these are the values engineering commits to meeting. Security proposes; engineering leadership agrees; regulatory obligations shape the floor.

Section 5 is the most demanding section structurally because it is not a documentation exercise. The RACI records the outcome of the ownership conversation described in "The Conversation That Kills Programmes." It does not substitute for that conversation. At a UK challenger bank, the breakthrough moment in building a VM programme was not a tooling deployment. It was an engineering leadership meeting where the RACI rows were read out and each VP confirmed they accepted the accountability assignment. Until that conversation happened, the document was aspirational. After it happened, it was operational. Where that conversation does not produce commitment, the Schematic does not resolve it. An incomplete RACI is diagnostic: the programme lacks the leadership agreement it needs, and the path forward runs to the CISO before the document is treated as settled.

Sections 6 and 7 follow from Section 5: the exception criteria security defines in the exception framework and the escalation paths named in Section 7 depend on the approval chain established in the RACI.

The practical order: Sections 0, 1, 2, 3, 4; then the ownership conversation; then Sections 5, 6, 7.

From framework to delivery

The series now constitutes a complete framework for programme design and governance. An organisation with no incumbent VM capability can read the episodes, use the companion resources, and build a credible, audit-defensible programme.

The example Technical Blueprint companion covers what to deploy at each maturity level. This Schematic covers what to decide and document. They are complementary: one answers the tooling question, the other answers the governance question.

The Supply Chain and AI Security series follow from here. The supply chain thread was seeded in Episode 9; both series treat TVM as a foundation rather than a problem to solve again.

Purchase the VM Programme Schematic (£150 + VAT): here