Remediation is an operating model, not a scanner output

A CISO showed us a deck last quarter with a critical count of three hundred forty two and a subheading that read "down 18% quarter over quarter." Two floors below the boardroom, an infrastructure lead was staring at a spreadsheet of the same rows, sorted by severity and titled "backlog." The scanner and the dashboard had done their jobs; the space between the two teams was where the work went to age, and nobody in the room had drawn a picture of that space.

That picture is the operating model, the artifact every high-functioning program eventually writes down. What has been missing is a single vendor-neutral spec for the contract between security and the teams that actually change production.

Prior art the model already stands on

Jonathan Risto and Zach Hazar published the SANS Vulnerability Management Maturity Model, five maturity levels across the PIACT domains of Prepare, Identify, Analyze, Communicate, and Treat, later carried into MGT516 and refreshed as VMMM v2 earlier this year. Its Communicate domain is where operating-model gaps tend to surface first.

NIST SP 800-40 Revision 4 reframed patching as a seven-step preventive-maintenance cycle rather than an incident response, and its move away from an exceptions register toward maintenance groups keyed to how software actually gets updated is the paper's most durable idea.

On the federal side, BOD 22-01 ran for four and a half years on flat deadlines keyed to KEV membership and CVE age, then was revoked on June 10, 2026 alongside BOD 19-02. BOD 26-04 replaced them with a four-variable risk model built on public exposure, KEV membership, exploit automatability, and technical impact, plus graduated deadlines of three, fourteen, or sixty days with mandatory forensic triage on the top tier. Frame the shift honestly: BOD 22-01 was exploitation-evidence-driven, BOD 26-04 is the federal government catching up to the exposure-based operating model the private sector has been running for years.

Vendor tools encode pieces of it as well. Rapid7 InsightVM Remediation Projects group findings by solution and push tickets into Jira or ServiceNow, Qualys VMDR does the same via group-by-solution, and Nucleus Security threads finding lifecycle across those queues. What none of them has published, because it is not their layer to write, is the contract that governs the ticket after it leaves the security tool.

Four owners, or the ticket does not move

Four roles get filled on every remediation ticket before real work happens on it:

Security owner establishes that the risk is real, sizes it in local context, and holds the priority.
Technical owner applies the fix, the mitigation, or the compensating control on the production surface.
Business owner accepts operational impact and any residual risk, and signs the exception when one is written.
Evidence owner proves the change happened, ties the proof to the risk, and files it where auditors and future incident responders will find it.

One person can hold two or three of these roles on a given ticket; what breaks the model is a role that is unassigned. A finding with no technical owner is not ready for a ticket, and a high-risk exception with no business owner is not risk acceptance, it is drift.

Queues by action, not by severity

Severity is a property of the CVE while action is a property of the finding, and severity-only queues invite the argument the model was supposed to resolve. Splitting the queue by action gives the team a shape it can work:

Emergency containment. The clock is measured in hours and nothing else on the queue matters until the top item is closed.
Planned remediation. The change is agreed, the maintenance window is scheduled, the owner is executing.
Owner discovery. The finding is real, no owner has been identified, and routing is the queue's problem.
Exception review. A written exception is due for renewal or has expired and needs a decision.
Validation failed. A previous close was rolled back by the next scan and the ticket returns with the failure attached.
Awaiting patch. The vendor has not shipped, the compensating control is in place, and the queue owns the vendor follow-up.
Accepted with compensating control. The residual is documented, the control is monitored, the review date is on the calendar.

The ticket contract

A remediation ticket is a contract between the security function and the team that owns the production surface, and one that omits any of the fields below is asking the receiving team to do security's analysis for them.

Affected asset. A durable identifier from the identity graph, not a scanner-local host name.
Business service. What the asset participates in, so the receiving team knows why the ticket exists.
Owners. The four roles, resolved to named people, with backups.
Vulnerability or exposure. The finding, with a link to the source of record.
Why it matters here. The local context that turned a generic CVE into a specific risk on this asset.
Priority band and reason. The band (ACT, ATTEND, TRACK, or MONITOR) and the sentence that placed it there, so the priority is defensible without a follow-up meeting.
Exploitation signal. KEV membership, EPSS bucket, in-the-wild sightings, or the honest absence of any of those, with the source cited.
Reachability. Whether the finding is reachable from an untrusted network, from a compromised adjacent asset, or only via code paths that never run.
Remediation options. The upgrade, the config change, the compensating control, ordered by preference.
Validation requirement. How closure will be proved, chosen at ticket-open time and not at ticket-close time.
SLA. The date on the calendar, tied to the priority band.
Exception path. What the ticket becomes if the fix cannot land in time.

Every field maps to an action the receiving team would otherwise invent for itself. Leave "why it matters here" blank and infra pushes back at every review; drop "reachability" and every 9.8 becomes an emergency; skip "validation requirement" and closure decays into a paste operation. Vendors carry tickets well; the contract has to live inside the program.

SLAs are a property of the exposure, not the CVE

Severity is an input to the SLA, not the policy itself. The operating model treats SLA as a property of the finding in local context and not of the CVE record in the abstract, which is the same move BOD 26-04 formalized for federal agencies in June; the deeper argument for the four-band shape (ACT for confirmed exploitation on a reachable path, ATTEND for high exposure with a strong signal, TRACK for meaningful non-emergency risk, MONITOR for low exposure with validated controls) belongs in our ACT/ATTEND/TRACK/MONITOR piece.

Exceptions that do not lie about expiring

Some systems cannot be patched on security's clock: a clinical workstation, an OT controller, a vendor appliance that lags its own advisory by a quarter. What breaks the operating model is the exception that never expires. NIST SP 800-40r4 is explicit that deferred patches need a governed exception workflow with periodic review, and we would go one step further and say no expiration means no exception. Every exception on the register carries an owner, a reason, a scope, a compensating control, a validation record for that control, an expiration date, and a re-review trigger; when the date passes, the exception either renews with fresh evidence or the ticket reopens on the queue that started it.

Closure is proof, not paste

Ticket closure is the act of proving the risk is gone, and the proof has to match the risk. A hygiene finding closes on a clean rescan. Internet-facing exploited CVEs need a validated attack-path failure, a rotated credential set, and a rescan on top of that. Configuration changes close on the config state, not on the change-request status. Write the validation method into the ticket at open time so the receiving team knows the bar before they touch the change, and so security cannot move the goalposts at close time.

Report outcomes, not activity

Total finding counts drop out of the deck. What replaces them: age distribution inside the emergency-containment queue, ACT band opens and closes over the quarter, exceptions expiring inside the next thirty days, the ownerless-finding rate, mean time from detection to owner assignment, and validation failure rate. A backlog trending down while none of those trend in the right direction is not a program metric.

The short version

Design the model on one page: four owners with backups, seven action queues, the twelve-field ticket contract, an exception path with expirations, evidence-based closure, and an executive report keyed to outcomes. Vendors deliver pieces; the operating model is the program's own artifact.

CVEasy AI runs this operating model on a local-first Continuous Threat Exposure Management platform, with TRIS holding the priority-band decision and every ticket carrying its own evidence trail.