Vulnerability State Machine Throughput Decomposition
Aggregate throughput is the wrong unit. An enterprise vulnerability programme is a finite state machine with named queues between named states, and the binding constraint at any moment sits inside one state, not across the whole pipeline. Programmes that report one closure rate against one inflow rate can hide a triage queue that is doubling, an assigned queue that has stalled on a change window, or a retest queue that is silently growing while the headline number stays green. The defensible discipline is to decompose throughput into per-state arrival and exit rates, read the per-state queue depth on the same record, and surface the binding constraint as a state name rather than as a vague capacity complaint.1,3,4,5
This research lays out how vulnerability throughput actually decomposes across the seven-state machine that enterprise programmes run. It covers the canonical state set, the transition policy that holds the record together, the per-state arrival, exit, and queue-depth measurements that make the binding constraint observable, the failure modes per state, the per-state SLA discipline, the heavy-tailed cycle-time distributions inside each state, the closed-exception and reopen interactions with the aggregate numbers, and the eight audit reads that survive scrutiny when the live record carries the decomposition.5,6,7,8,12,13,14,16
The state machine is the unit of analysis
Every enterprise vulnerability programme already runs a state machine, whether or not the operating model documents it that way. A finding does not move from open to closed in one step; it transits through triage, ownership assignment, remediation work, fix deployment, retest validation, and administrative closure, each with its own owner, its own queue, and its own dwell time. The aggregate throughput number collapses six or seven transitions into one ratio and loses the signal that says which transition is the bottleneck. The decomposition is the inverse: read the rate at which findings enter each state, the rate at which they leave, the depth of the queue inside the state, and the dwell-time distribution per state.
The state machine that matters for an enterprise programme has seven primary states. A finding appears in the new state when the scanner output, pentest report, bug bounty submission, or disclosure intake reaches the workspace. It moves to the triaged state when severity, asset binding, validity, and category are confirmed. It moves to the assigned state when a remediation owner accepts the finding. It moves to the in-remediation state when the owner picks the work up. It moves to the in-retest state when the deployed fix is queued for verification. It terminates in the closed-remediated state on a verified retest pass, or in the closed-exception state on the recorded eight-field override decision. The exact state names are negotiable; the discipline that every finding occupies exactly one state at any moment and every transition is recorded with timestamp and named user is not.
The vulnerability remediation throughput research establishes throughput as the closure half of the inflow-versus-closure ratio. The vulnerability program data model research establishes the record schema that makes per-state queues observable in the live engagement workspace rather than reconstructed from CSV exports at audit week.26,29
The seven primary states and the transitions between them
The named state set has to be small enough that every operator carries it in their head and large enough that every transition with a real dwell-time signature is its own state. Seven states sits at the equilibrium for most programmes. Some programmes add subtate granularity (in-investigation between triaged and assigned, in-change-window between in-remediation and in-retest) when the additional state produces operational signal that the simpler model collapses; others collapse intermediate states when the traffic between them is negligible.
| State | Default owner | Exit transition |
|---|---|---|
| New | Triage queue owner | Severity, asset binding, validity, category confirmed; move to triaged. |
| Triaged | Routing queue owner | Named remediation owner accepts; move to assigned. |
| Assigned | Named remediation owner | Work begins; move to in-remediation. |
| In remediation | Named remediation owner | Fix deployed and ready for verification; move to in-retest. |
| In retest | Retest queue owner | Retest passes; move to closed-remediated. Retest fails; move back to assigned with reopen reason. |
| Closed remediated | Engagement owner / GRC partner | Terminal. Reopen on rediscovery returns finding to new state with reopen reason. |
| Closed exception | Override approver / GRC partner | Terminal. Reopen on override expiry or revocation returns finding to triaged state. |
Per-state ownership is the load-bearing record. Programmes that route every state to a single team queue collapse the ownership signal and lose the diagnostic that says which queue is the binding constraint. The cross-team finding ownership transfer latency research covers the dwell time that accumulates inside the assignment transition specifically when ownership rotates between teams.30
Per-state arrival, exit, and queue-depth
The three measurements that decompose throughput per state are the arrival rate into the state (lambda), the exit rate out of the state (the transition rate to the next state for non-terminal states, or the closure rate into the audit-evidence ledger for terminal states), and the queue depth inside the state (L). The three are connected by Little's Law in steady state: L equals lambda times W, where W is the average waiting time inside the state. The implication is that the per-state queue depth at any moment is the product of the rate at which findings flow into the state and the average dwell time inside the state. A programme that wants to shrink the queue at a given state has to either slow the arrival rate (intake throttle, dedup discipline, scope narrowing), speed the exit rate (capacity expansion, automation, routing simplification), or both.13,14
Reading the three numbers together
At any reporting cadence (weekly, monthly, quarterly), the per-state pack reports lambda (arrivals over the period), the exit rate (departures over the period), the delta (lambda minus exit; a positive delta grows the queue, a negative delta shrinks it), and L (queue depth at period end), all broken by severity band against the relevant SLA target. The pack is the same per state. Programmes that pair the three numbers per state cannot hide a doubling triage queue behind a healthy aggregate closure rate, because the new-state lambda will exceed the new-state exit rate even when the overall closure number looks fine.
The same pack works across observation windows. A monthly cadence carries enough signal for tactical budget conversations; a quarterly cadence carries enough signal for audit-committee and board reads; an annual cadence carries enough signal for capacity planning. The activity-log retention horizons of 30, 90, and 365 days on the SecPortal workspace plans give the same record three different observation windows on the same primary data, which is the part that survives audit scrutiny because the source is one rather than three.
The vulnerability ingest versus remediation capacity research extends the paired-rate frame across the inflow side and the closure side simultaneously. The decomposition extends it further across every intermediate state so the capacity question becomes a per-state capacity question rather than a single capacity-versus-inflow comparison.27
The vulnerability programme staffing and throughput economics research reads the staffing curve underneath the decomposition: each per-state transition is owned by one or two named role classes, and the per-FTE throughput envelope at that role class is what determines whether the transition is bandwidth-bound at the analyst layer or coordination-bound at the team layer. Reading the transition decomposition and the staffing curve together identifies both the binding transition and the role to add capacity at.
Per-state failure modes
Seven failure modes recur across the seven-state machine. Each is named, each has a per-state signature, and each is observable in the live record once the three measurements are reported per state. Reporting the aggregate throughput number obscures every one of them.
1. New-state pileup
Scanner output enters the new-state queue faster than triage capacity reads it. The new-state lambda exceeds the new-state exit rate across multiple reporting periods, the new-state L grows linearly, and severity calibration starts to drift because triage is rushed. The signature is a growing new-state L without a corresponding growth in any downstream queue.
2. Triaged-state drift
Severity is set at triage but the ownership routing rule does not fire deterministically, so triaged findings sit unassigned. The triaged-state L grows while the new-state L is bounded. The signature is a healthy triage exit rate paired with a depressed assignment arrival rate.
3. Assignment-loop
Ownership routing rejects findings back to triage because the affected asset cannot be identified or the remediation owner does not own the asset class. The signature is per-transition rejection rate growth on the triaged-to-assigned arc, and a roughly equal arrival rate in both directions across the arc.
4. In-remediation stall
The fix is blocked on a change window, a dependency upgrade, or a compensating-control negotiation. The dwell time inside the in-remediation state exceeds the per-state SLA alone. The signature is stable assigned-state L, growing in-remediation-state L, and a depressed in-retest arrival rate.
5. In-retest bottleneck
Retest capacity sits behind unrelated engagement work, so fixes are deployed but verification is delayed. The signature is healthy in-remediation exit rate, growing in-retest L, and a depressed closed-remediated arrival rate.
6. Exception drift
Findings move into the closed-exception terminal state without the documented eight-field override decision chain. The headline closure rate is inflated by exception arrivals masquerading as remediated arrivals. The signature is rising closed-exception arrival rate relative to closed-remediated arrival rate, particularly at high and critical severity bands.
7. Reopened-loop
Closed-remediated findings reopen on retest or rediscovery so closures from prior periods reappear as arrivals into the new-state queue. The signature is a reopen rate per terminal state that drifts upward across observation cycles, indicating that closure discipline is not durable.
The vulnerability fix verification fidelity research covers the in-retest discipline that turns the reopened-loop signature from a recurring failure into a recoverable signal. The exception conversion economics research covers the closed-exception arrival pattern that the exception-drift signature exposes.31,32
Per-state SLA targets and the end-to-end window
Per-state SLA targets are tighter than per-finding SLA targets because each state owns only a slice of the end-to-end window. CISA Binding Operational Directive 22-01 sets a 14-day end-to-end window for known exploited vulnerabilities; PCI DSS Requirement 6.3.3 sets a 30-day window for high-risk vulnerabilities; ISO 27001 Annex A 8.8 expects a programme-defined cadence justified by risk. The defensible per-state allocation breaks the end-to-end window into per-state slices that sum to less than the end-to-end target.1,3,4
| State | CISA BOD 22-01 14-day envelope | PCI DSS 6.3.3 30-day envelope |
|---|---|---|
| New triaged | 2 working days | 3 working days |
| Triaged assigned | 2 working days | 3 working days |
| Assigned in-remediation | 2 working days | 4 working days |
| In-remediation in-retest | 6 working days | 15 working days |
| In-retest closed-remediated | 2 working days | 5 working days |
The slices add to less than the end-to-end window because the programme has to absorb queue-time at each transition and the change-window calendar on the platform side rarely lines up with the discovery date. The discipline is to publish per-state SLA targets at the same severity bands the end-to-end SLA is published against so the programme can read which state actually violates the end-to-end window when a finding ages out. The SLA breach aging distribution research covers the aging shape that per-state slices have to anticipate.28
Per-state cycle-time distributions are heavy-tailed
Cycle-time distributions inside states that involve human decision-making, scheduled change windows, or third-party dependencies are heavy-tailed. Reporting only the median cycle time inside a state describes the experience of the median finding; reporting p50, p90, and p99 inside the state describes the tail risk and the SLA risk simultaneously. The defensible reporting pattern names the tail because the tail drives audit findings and customer escalations more often than the median, and the tail is where exception conversion and abandonment cluster.14,15,16
Two tail patterns to watch
State-level tail growth. The p99 cycle time inside one state grows away from the p50 across observation cycles. The median experience looks unchanged but the tail experience is degrading. A handful of findings spend an unusually long time inside the state; the SLA breach rate for that state grows; the headline median MTTR for the programme is unchanged.
State-level tail mass transfer. The p99 cycle time inside one state shrinks while the p99 inside the next state grows by a comparable amount. Findings finish the earlier state faster but stall in the next. The aggregate median MTTR looks fine; the binding constraint has moved one state downstream and the budget conversation has to follow it.
Change windows distort cycle-time inside the in-remediation state and inside the in-retest state. A weekly production change window with a freeze on the rest of the week produces in-remediation cycle-time distributions clustered at one-week increments, regardless of the underlying remediation work. The defensible diagnostic is to overlay the per-state cycle-time histogram against the change-window calendar so the distortion is visible and the budget conversation about change-window relaxation has the right evidence.
Closed-exception and reopen interact with the headline number
Both terminal states (closed-remediated, closed-exception) and both reopen paths (closed-remediated to new on rediscovery, closed-exception to triaged on override expiry) interact with the headline closure number in ways the aggregate throughput report cannot disentangle. The decomposition treats them as distinct arrivals and reports them separately at every severity band.
Closed-exception arrivals are administrative closes that move a finding into the audit ledger via the eight-field override decision chain (override class, manual severity, exception rationale, approver, scope, expiry, evidence pointer, version stamp) rather than via a verified retest. Treating closed-exception arrivals as equivalent to closed-remediated arrivals inflates the closure rate by the volume of risk acceptance decisions. The audit committee read on exception arrivals is fundamentally different from the audit committee read on remediated arrivals.
Reopen arrivals are arrivals back into the new-state queue or the triaged-state queue from a terminal state. They arrive because retest discovered the fix did not close the finding, recurring detection saw the finding regenerate, the underlying asset was restored from backup, the deployed compensating control failed, or the original triage classification was overturned during post-mortem. The defensible reporting pattern treats reopen arrivals as a distinct arrival class so the new-state lambda can be decomposed into fresh detection inflow versus reopen inflow. Programmes that report reopen rate per terminal state read whether the closure discipline is durable and which terminal state has the durability problem.
The vulnerability reopen rate research covers the durability question per terminal state in more depth. The risk acceptance decay rate research covers the closed-exception path from acceptance to override expiry.
Eight audit reads that survive scrutiny
The decomposition becomes audit-defensible when the live state record carries the eight reads listed below. Each is reported at the same severity bands the SLA is written against, and each is reproducible at any moment between audits rather than only at audit week. SOC 2 CC4.1 monitoring of controls, ISO 27001 Clause 9.1 monitoring and Annex A 8.16 monitoring activities, NIST CSF 2.0 GV.OV oversight, NIS2 Article 21 cybersecurity risk management measures, and DORA Article 9 protection and prevention each expect a recurring read of the operating state rather than an at-audit-week reconstruction.
| Read | What it answers |
|---|---|
| 1. Per-state queue depth at period end versus twelve cycles earlier | Where the backlog actually lives and how it has moved across the year. |
| 2. Per-state arrival rate trend | Whether discovery, triage, assignment, remediation, and retest are growing or shrinking as load sources. |
| 3. Per-state exit rate trend | Whether the capacity at each transition is keeping up with the corresponding arrival rate. |
| 4. Per-state cycle-time distribution (p50, p90, p99) | Where the heavy tail sits and whether the tail is growing or transferring downstream. |
| 5. Per-state SLA breach count | Which state actually violates the end-to-end SLA when a finding ages out. |
| 6. Closed-exception arrival rate with exception register currency | Whether closure is happening through remediation or through risk acceptance. |
| 7. Reopen rate per terminal state | Whether closures from prior periods are durable; which terminal state has the durability problem. |
| 8. Per-transition rejection rate | How often findings bounce back from one state to a prior state; which arc has the rejection-loop signature. |
The eight reads compose into the management review pack the leadership view samples between assessments. The audit evidence half-life research covers the rate at which artefacts age out of audit defensibility; the per-state decomposition is the artefact set that has the longest half-life because it derives from the live record rather than from a cycle-end report.
Four maturity stages on the way to decomposed throughput
Programmes do not start with the eight reads. They arrive at them through a maturity progression. Naming the stage the programme is at right now is the first step toward investing in the next.
Stage 1: Aggregate throughput only
One closure number, one inflow number, one backlog number. The bottleneck is a vague conversation about capacity. Per-state queues are implicit in the operator's head, not in the record.
Stage 2: Per-state queue depth
The record names the states and the queue depth at each state is queryable. Arrival and exit rates are still aggregated. The bottleneck conversation can now name a state, but not yet describe whether the state is filling or draining.
Stage 3: Per-state arrival and exit rates
Lambda and the exit rate are reported per state per severity band. Little's Law works against the record. The bottleneck conversation names the state, the rate dynamic, and the corrective lever (slow lambda, speed exit, or both).
Stage 4: Per-state cycle-time tails and audit-defensible reporting
The eight audit reads are reproduced at any moment between assessments. The change-window calendar overlays the per-state cycle-time histogram. Closed-exception and reopen arrivals are reported separately. The leadership read and the operational read run off the same record.
For security leadership, AppSec, GRC, and audit committees
The decomposition serves different stakeholders differently. Security leadership reads the per-state queue trends to plan capacity allocation between triage, ownership routing, remediation, and retest. AppSec teams read the per-state cycle-time tails to choose between platform investment, automation, and process change as the lever for shortening the tail. GRC teams read the closed-exception arrival rate and the exception register currency to write the audit narrative. Audit committees read the per-state SLA breach count and the reopen rate per terminal state to judge whether the closure discipline is durable. Each stakeholder reads the same record at a different cut.
The shared discipline is that the operating record carries the decomposition rather than the report. The remediation tracking workflow covers the live-record discipline that holds the per-state owners, transition timestamps, and override decision chain together. The security leadership reporting workflow covers the per-cadence read the executive surface samples from that record.
How SecPortal supports state machine throughput decomposition
SecPortal pairs every finding to a versioned engagement record with a status group field (active, fixed, accepted_risk, false_positive) and a severity field (info, low, medium, high, critical), so the per-state queue depth on any reporting date is a query against the live record rather than a reconstruction from cycle-end exports. Findings management captures CVSS 3.1 vector, severity band, owner, evidence, and remediation status. The activity log captures every state change as a named-actor entry with timestamp, with retention windows of 30, 90, or 365 days set by workspace plan; the entry covers the lifecycle for finding, engagement, scan, document, comment, invoice, and team entities.
Finding overrides record the eight-field decision chain for closed-exception transitions (override class, manual severity, exception rationale, approver, scope, expiry, evidence pointer, version stamp), so the closed-exception arrival rate is queryable next to the closed-remediated arrival rate without conflation. Retesting workflows pair retest records to original findings so the in-retest queue and the reopen rate per terminal state are observable on the same record. Bulk finding import accepts .nessus, .xml, and .csv intake so third-party scanner output joins the same state machine on the same record rather than running on a parallel ledger.
Continuous monitoring schedules run daily, weekly, biweekly, and monthly cadences so the new-state arrival curve is queryable across cycles. Compliance tracking maps findings to ISO 27001, SOC 2, PCI DSS, and NIST frameworks with CSV export, so the eight audit reads carry framework citations that survive review.
Honest scope. SecPortal does not push state-change events into Jira, ServiceNow, Slack, SIEM, SOAR, or GRC platforms; the discipline runs as a query against the live engagement record rather than as an automation between separate consoles. SecPortal does not provide enterprise SSO, SCIM, or SAML, does not provide automated risk-acceptance approval routing, does not ship a CMDB or asset-inventory synchronisation, and does not assign per-state SLA targets for the programme. The platform makes the state record, the transition timestamps, the override chain, and the retest evidence queryable on one record so the decomposition is reproducible at any moment between audits.
Conclusion
Aggregate throughput is the wrong unit because it collapses six or seven transitions into one ratio and hides which transition is the binding constraint. Decomposing throughput per state turns the operational picture from a slogan into a diagnostic that names the next intervention. The seven-state machine is small enough to operate, large enough to carry the signal, and the three per-state measurements (arrival, exit, queue depth) compose into the eight audit reads that survive scrutiny when the live record holds them. The discipline is not new tooling; it is naming the states, recording the transitions on one record, and reading the three numbers per state at every reporting cadence.
The programmes that arrive at audit week with the eight reads already reproducible from the live record spend the week defending operating-state decisions instead of reconstructing them from spreadsheets. The programmes that arrive without the decomposition spend the week explaining why the headline number looked fine while the binding constraint was somewhere the headline number could not see.
FAQ
Sources
- CISA, Binding Operational Directive 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities
- CISA, Known Exploited Vulnerabilities Catalog
- PCI Security Standards Council, PCI DSS v4.0 Requirement 6.3.3
- ISO/IEC, ISO 27001:2022 Annex A 8.8 Management of Technical Vulnerabilities
- NIST, SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
- NIST, SP 800-53 Revision 5: RA-5 Vulnerability Monitoring and Scanning
- AICPA, SOC 2 Trust Services Criteria CC7.1 Detection of Vulnerabilities
- NIST, Cybersecurity Framework (CSF) 2.0
- CISA, Stakeholder-Specific Vulnerability Categorization (SSVC)
- FIRST, EPSS Exploit Prediction Scoring System Documentation
- NIST, NVD National Vulnerability Database
- NIST, SP 800-137 Information Security Continuous Monitoring (ISCM)
- Little, J.D.C., A Proof for the Queuing Formula L = λW (Operations Research, 1961)
- Kingman, J.F.C., The Single Server Queue in Heavy Traffic (Cambridge Phil. Soc., 1961)
- NCSC, Vulnerability Management Guidance
- OWASP, Vulnerability Management Guide
- NIS2 Directive Article 21 Cybersecurity Risk Management Measures
- DORA Regulation Article 9 Protection and Prevention and Article 17 ICT-Related Incident Management
- SecPortal, Findings & Vulnerability Management
- SecPortal, Activity Log & Workspace Audit Trail
- SecPortal, Finding Overrides
- SecPortal, Retesting Workflows
- SecPortal, Continuous Monitoring
- SecPortal, Compliance Tracking
- SecPortal, Bulk Finding Import
- SecPortal Research, Vulnerability Remediation Throughput
- SecPortal Research, Vulnerability Ingest vs Remediation Capacity
- SecPortal Research, SLA Breach Aging Distribution
- SecPortal Research, Vulnerability Program Data Model and Record Design
- SecPortal Research, Cross-Team Finding Ownership Transfer Latency
- SecPortal Research, Exception Conversion Economics
- SecPortal Research, Vulnerability Fix Verification Fidelity
Run the decomposition against your live record
SecPortal holds findings, status groups, severity bands, override decisions, retest records, scanner intake, and the activity log on a single workspace, so per-state arrival, exit, and queue depth are queries rather than reconstructions. Start with the free plan, import existing scanner output, and read the seven-state queues against your own data.
Get Started FreeNo credit card required. Free plan available forever.