Question 1

What is open finding state staleness economics?

Accepted Answer

Open finding state staleness economics is the analytical frame that prices the carrying cost of an open vulnerability finding against the state the finding is currently in, instead of pricing all open findings on the same per-day line. Open findings traverse a lifecycle of named states (open and untriaged, triaged but unowned, owned but unstarted, in progress, awaiting verification, awaiting administrative closure), and each state has its own per-day cost signature, its own staleness signature, and its own intervention path. Staleness is not the same as age. A 90-day finding sitting in awaiting-verification with a deployed fix carries a different cost shape than a 90-day finding sitting in triaged-but-unowned with no engineer assigned. The frame surfaces where the carrying cost is concentrated in the state distribution so the programme can fund the intervention that lowers the cost rather than treating staleness as undifferentiated backlog.

Question 2

How is state staleness different from finding age?

Accepted Answer

Finding age is the elapsed wall-clock time since the finding was opened. Staleness is the elapsed time the finding has spent in its current state without progress. A finding can be old but not stale (a confirmed exception sitting in renewal cadence) and a finding can be young but stale (a 7-day finding that has been in awaiting-verification for 6 days because the retest queue is blocked). Programmes that report only finding age collapse these two distinct signals into one number. Programmes that report state-resident time alongside age catch both the chronic-backlog problem (high age across all states) and the per-state bottleneck problem (high state-resident time concentrated in one or two states) before they accumulate into management-letter findings at audit time.

Question 3

What are the six common open finding states?

Accepted Answer

Six states cover the bulk of the open finding lifecycle in enterprise programmes. Open and untriaged is the intake state where the finding has been captured but not yet validated for severity, scope, or duplicate status. Triaged but unowned is the post-validation state where the finding has been confirmed but no engineer or team has been assigned. Owned but unstarted is the assignment state where ownership has landed but remediation work has not begun. In progress is the active engineering state where the fix is being designed, implemented, and tested. Awaiting verification is the post-deployment state where the fix has shipped but retest has not confirmed closure. Awaiting administrative closure is the post-verification state where the retest has passed but the closure record has not been signed off. Each state has different actors, different unblockers, and different per-day costs. Programmes that report only open versus closed lose the state distribution that drives most of the carrying-cost variance.

Question 4

Why does carrying cost vary by state?

Accepted Answer

Carrying cost varies by state because the cost components that compound per day are different in each state. Open and untriaged findings carry context-loss cost (the original scanner output or pentest narrative degrades in clarity over time), false-positive risk cost (an unvalidated finding may be incorrectly aging in the queue), and audit-defensibility cost (untriaged findings show up at audit as evidence of intake hygiene gaps). Triaged but unowned findings carry routing-failure cost (the finding has been validated but ownership has not been resolved, which is a workflow-design problem) and exposure-window cost (the underlying risk persists while ownership is debated). Owned but unstarted findings carry scheduling-conflict cost (the engineer or team has the work but cannot start it due to competing commitments). In-progress findings carry inventory cost in the engineering sense (work-in-progress that ties up engineer capacity until it ships). Awaiting-verification findings carry retest-queue cost (the deployed fix is unverified, so the closure cannot be signed off). Awaiting-closure findings carry administrative-tail cost (the finding is technically remediated but the record is not closed, which inflates open counts and skews leadership reporting). The six states produce six different cost shapes.

Question 5

What does the cost stack look like for open and untriaged findings?

Accepted Answer

Open and untriaged findings carry a carrying-cost stack dominated by context-loss cost and false-positive risk cost. Context-loss cost compounds because the scanner output (which scanner version produced it, which authentication context, which target version) and the pentest narrative (which test plan, which scope, which severity rationale) become harder to read accurately as time passes; reproduction and severity confirmation later cost more than they would have at intake. False-positive risk cost compounds because an unvalidated finding consumes triage capacity each time it surfaces on a dashboard or report without resolution. Audit-defensibility cost compounds because untriaged findings older than the programme-defined triage window show up at audit as direct evidence that intake hygiene is not enforced. The dominant intervention is to fund triage capacity that matches inflow rather than treating triage as overhead. Programmes that under-fund triage absorb the cost as accumulating untriaged backlog that compounds over time, and then pay it back at audit fieldwork.

Question 6

What does the cost stack look like for triaged but unowned findings?

Accepted Answer

Triaged but unowned findings carry a carrying-cost stack dominated by routing-failure cost and exposure-window cost. Routing-failure cost is the cost of the workflow-design gap that leaves a validated finding without a named owner; the cost shows up as unassigned-queue length, as repeated triage meetings that re-debate the same finding, and as the cost of escalation to security leadership to break the routing tie. Exposure-window cost is the cost of the underlying technical exposure persisting while ownership is debated; this is highest on critical and high-severity findings where the per-day cost of an unmitigated exposure is real. The dominant intervention is to define routing rules that produce a named owner at triage time rather than after triage, and to surface the unowned queue as a separate operational metric rather than burying it in the open backlog. Programmes that surface unowned-queue length as a board-level metric tend to drive it toward zero quickly because the metric exposes the workflow-design gap rather than the underlying remediation gap.

Question 7

What does the cost stack look like for owned but unstarted findings?

Accepted Answer

Owned but unstarted findings carry a carrying-cost stack dominated by scheduling-conflict cost and dependency-blocker cost. Scheduling-conflict cost is the cost of the named owner having the finding on the backlog but unable to start because of competing engineering commitments; this is a capacity-planning question more than a workflow question. Dependency-blocker cost is the cost of waiting for an upstream dependency (a change window, a vendor patch, a coordinated release, an architectural decision) that has to land before remediation can begin. The dominant intervention is to surface the unstarted queue with the named blocker (capacity, dependency, change window) attached, so the programme can read whether the bottleneck is engineering capacity or external coordination. Programmes that report unstarted-queue length without the named blocker conflate two distinct problems and apply uniform interventions that do not lower the right cost.

Question 8

What does the cost stack look like for in-progress findings?

Accepted Answer

In-progress findings carry a carrying-cost stack dominated by work-in-progress cost and stage-cycle-time cost. Work-in-progress cost is the cost of engineering capacity tied up on an unshipped fix; this is the inventory analogue from manufacturing where work-in-progress represents capital tied up until the work ships. Stage-cycle-time cost is the per-day cost of the fix sitting in the engineering pipeline (design, code review, testing, staging, production deployment) without crossing the finish line. The dominant intervention is to surface stage-cycle-time per finding rather than reporting only in-progress count, so the programme can read whether the bottleneck is design time, review time, test time, or deployment time. Programmes that adopt stage-cycle-time reporting tend to catch lock-step bottlenecks (a single reviewer becoming the system bottleneck, a flaky test suite becoming a deployment gate) before they accumulate into pipeline-wide cycle-time inflation.

Question 9

What does the cost stack look like for awaiting-verification findings?

Accepted Answer

Awaiting-verification findings carry a carrying-cost stack dominated by retest-queue cost and unverified-closure cost. Retest-queue cost is the cost of the deployed fix sitting in the verification queue without being confirmed closed; this is often a hidden bottleneck because the engineering team has moved on to other work and the verification queue is owned by a separate function. Unverified-closure cost is the audit-defensibility cost of carrying a finding as administratively closed (or partially closed) without retest evidence; some frameworks read this as a failed closure. The dominant intervention is to surface awaiting-verification queue length as a separate operational metric and to pair verification capacity with remediation capacity so the verification queue does not become a hidden bottleneck. Programmes that under-fund verification absorb the cost as inflated awaiting-verification queue length that hides the underlying engineering velocity behind a closure-confirmation gap.

Question 10

What does the cost stack look like for awaiting-closure findings?

Accepted Answer

Awaiting-closure findings carry a carrying-cost stack dominated by administrative-tail cost and reporting-distortion cost. Administrative-tail cost is the cost of the finding being technically remediated and technically verified but not signed off as closed; this consumes administrative capacity each reporting cycle. Reporting-distortion cost is the cost of carrying findings as open that are functionally closed; this inflates the open count, drags the median age of the open queue, and produces leadership dashboards that report a worse remediation picture than the underlying technical state warrants. The dominant intervention is to surface awaiting-closure queue length as a separate metric and to define administrative-closure SLA that pulls these findings off the open queue once retest passes. Programmes that batch administrative closure into quarterly clean-ups under-report remediation throughput in the intervening period.

Question 11

How do per-state SLA windows differ from end-to-end SLA windows?

Accepted Answer

End-to-end SLA windows measure elapsed time from finding open to finding closed against a severity-band target; the SLA reads as one number per finding. Per-state SLA windows measure elapsed time inside each state against state-specific targets; the SLA reads as a stack of per-state numbers per finding. Per-state SLA windows surface the diagnostic shape that end-to-end SLA windows hide. Two findings with identical end-to-end cycle time can have radically different per-state profiles: one that moves quickly through triage but stalls in verification, and one that stalls in triage but moves quickly through engineering. Per-state SLA windows let the programme define triage-to-ownership SLA, ownership-to-start SLA, in-progress SLA, awaiting-verification SLA, and awaiting-closure SLA separately, with intervention paths tied to the state that is breaching rather than to the end-to-end window. The defensible reporting discipline pairs per-state SLA with end-to-end SLA so audit committees can read both the operational shape and the cumulative outcome.

Question 12

How does state distribution change over the lifetime of a programme?

Accepted Answer

State distribution shifts predictably as remediation programmes mature. Early-stage programmes tend to concentrate findings in open-and-untriaged because triage capacity has not been built. Mid-stage programmes shift the concentration toward triaged-but-unowned as triage capacity grows but routing rules and ownership models lag behind. Programmes that build routing maturity next see the concentration shift to owned-but-unstarted as capacity planning becomes the binding constraint. Programmes that solve capacity planning see the concentration shift to in-progress, then to awaiting-verification, then to awaiting-closure as each downstream function becomes the bottleneck in turn. Reading the state distribution alongside the programme maturity stage produces a more accurate read of where to invest than reading open-count alone. The mature programme is not the one with zero open findings; it is the one whose state distribution moves predictably from intake through closure without bunching in any single state.

Question 13

What metrics survive audit scrutiny for state staleness?

Accepted Answer

Six paired metrics outperform open-count-only reporting and survive audit scrutiny. Per-state median resident time names how long findings sit in each state. Per-state P90 resident time names the tail; outliers concentrated in one state expose the binding bottleneck. Per-state inflow versus outflow rate reads whether the state is converging or diverging. Per-state SLA breach rate reads whether the per-state cadence the programme committed to is being met. Per-state exception rate reads where risk acceptance is absorbing the variance state by state. Per-state reopen rate (findings that close and then re-open) reads whether closures from each state are durable. Programmes that adopt the six paired metrics replace the single open-count debate with a state-aware operational picture. The defensible programme reports the six metrics per state per severity band, paired against the framework citations the audit chain reads against.

Question 14

What framework citations expect state-aware vulnerability reporting?

Accepted Answer

Several enterprise frameworks expect documented progress through state-specific stages of vulnerability handling. PCI DSS v4.0 Requirement 6.3.3 expects timely remediation with documented progression; Requirement 11.3 expects retest evidence of resolved high-risk vulnerabilities. ISO 27001:2022 Annex A 8.8 expects management of technical vulnerabilities including identification, evaluation, remediation, and verification; the implicit expectation is that each phase is documented. SOC 2 Trust Services Criteria CC7.1 reads identification and remediation of security events with documented evidence; CC7.4 reads incident response and recovery procedures. NIST SP 800-53 Revision 5 RA-5 reads vulnerability monitoring and scanning with documented remediation; SI-2 reads flaw remediation with documented status. NIST CSF 2.0 ID.RA, PR.PS, and RS.MI read risk assessment, platform security, and incident mitigation across the lifecycle. CIS Controls v8.1 Safeguard 7.7 reads remediation of detected vulnerabilities with documented closure. The pattern is consistent: each framework expects state-level documentation rather than only open-versus-closed status. Per-state staleness reporting surfaces the documentation discipline the framework citations expect; reporting only open-versus-closed produces an audit gap that fieldwork has to reconstruct from the live record.

Question 15

How does SecPortal support per-state staleness reporting?

Accepted Answer

SecPortal pairs every finding to a versioned engagement record where the finding state, the actor, the timestamp, and the supporting evidence sit together. Findings management captures the state field alongside CVSS 3.1 vector, severity band, owner, evidence, and remediation status; the activity log captures the timestamped chain of state changes by user so per-state resident time is reproducible from the record rather than reconstructed from spreadsheets. Bulk finding import (Nessus, Burp Suite, CSV) carries the state field through ingest so imported findings join the same lifecycle the workspace-native findings traverse. Authenticated scanning, external scanning, and code scanning produce findings that enter the same state machine and traverse it the same way as manually added findings. Retesting workflows hold the awaiting-verification state as a first-class state and carry the closure evidence through to administrative-closure rather than collapsing verification into the closure decision. Compliance tracking maps state transitions to framework controls so audit fieldwork reads against the live state history rather than against a reconstructed timeline. Finding overrides (false positive, accepted risk, severity adjustment, category revision) sit as captured decisions on the finding so the staleness picture reads against the actual operating record. The platform does not pick the per-state SLA targets for the programme. It does keep the per-state resident time, the per-state transitions, the actor, the timestamp, and the framework mapping on one live engagement record so per-state staleness reporting is reproducible at any moment between reporting cycles rather than only at audit week.

State	What it means	Responsible function
1. Open and untriaged	Finding captured but not yet validated for severity, scope, or duplicate status.	Triage analyst, AppSec engineer, or security operations.
2. Triaged but unowned	Finding validated but no engineer or team assigned for remediation.	Routing rule, team management, or escalation function.
3. Owned but unstarted	Ownership has landed but remediation work has not begun.	Named owner; capacity planning, change windows, blockers.
4. In progress	Active engineering: design, implementation, review, testing, deployment.	Engineering team and the deployment pipeline.
5. Awaiting verification	Fix has shipped; retest has not yet confirmed closure.	Verification function (security testing, scan operations, retest queue).
6. Awaiting administrative closure	Retest passed; closure record has not been signed off.	Programme owner, GRC, or compliance closure function.

Cost component	How it compounds	Intervention path
Context-loss cost	Scanner version, target version, authentication context, pentest narrative degrade in clarity over time.	Triage SLA tied to inflow rate; intake hygiene rules that capture context at the point of capture.
False-positive risk cost	Unvalidated finding consumes triage capacity each time it surfaces on a dashboard or report.	Severity calibration at intake; duplicate suppression rules; false-positive override discipline.
Audit-defensibility cost	Untriaged findings older than the programme-defined triage window show up at audit as intake hygiene gaps.	Documented triage SLA; named triage analyst role; activity log on triage decisions.

Cost component	How it compounds	Intervention path
Routing-failure cost	Validated finding without a named owner; repeated triage meetings re-debate the same finding.	Routing rules that produce a named owner at triage; unowned-queue surfaced as a separate metric.
Exposure-window cost	Underlying technical exposure persists while ownership is debated; highest on critical and high severities.	Triage-to-ownership SLA that closes the routing gap; escalation path to security leadership.
Escalation cost	Repeated routing debates consume security leadership capacity instead of remediation capacity.	Documented escalation tree; named tie-breaker; routing rules that catch ambiguous assets at intake.

Cost component	How it compounds	Intervention path
Scheduling-conflict cost	Named owner has the finding but is committed to other engineering work; the finding waits for capacity.	Capacity planning against remediation SLA; ringfenced remediation hours per team per cycle.
Dependency-blocker cost	Upstream dependency (change window, vendor patch, coordinated release) must land before work can begin.	Named blocker on the finding; dependency-tracked unblock dates; explicit hold-state distinct from unowned.
Architecture-decision cost	Remediation requires an architectural call that sits outside the named owner's authority.	Documented escalation to security architecture; decision-by date on the finding record.

Cost component	How it compounds	Intervention path
Work-in-progress cost	Engineer capacity tied up on an unshipped fix; capacity unavailable for other work until shipped.	In-progress SLA per severity band; surfaced WIP limits; engineer-level WIP visibility.
Stage-cycle-time cost	Per-day cost of the fix sitting in design, review, test, staging, or deployment without crossing the line.	Stage-level cycle-time reporting; identification of lock-step bottlenecks (single reviewer, flaky test, deployment gate).
Context-switch cost	Long in-progress periods force engineers to re-load context each time they pick the work back up.	Smaller fix scope; explicit pause-state distinct from in-progress; named hand-back rule when work pauses.

Open Finding State Staleness Economics: Pricing the Carrying Cost Per State

Why staleness is not the same as age

The six common open finding states

State 1: open and untriaged

State 2: triaged but unowned

State 3: owned but unstarted

State 4: in progress

State 5: awaiting verification

State 6: awaiting administrative closure

How state distribution shifts as programmes mature

Six paired metrics for state-aware reporting

Framework citations on state-level documentation

For vulnerability management, AppSec, internal security, and security engineering teams

For security leadership and audit committees

How SecPortal supports per-state staleness reporting

Conclusion

Frequently Asked Questions

Sources

Run per-state staleness on the live engagement record

Cost component	How it compounds	Intervention path
Retest-queue cost	Deployed fix sits in the verification queue without being confirmed closed; verification capacity is a separate constraint.	Awaiting-verification surfaced as a separate metric; verification capacity paired to remediation capacity.
Unverified-closure cost	Audit-defensibility risk of carrying findings as administratively or partially closed without retest evidence.	No closure without retest evidence rule; retest evidence captured on the finding record; framework citation on verification.
Re-emergence risk cost	Findings closed without verification re-appear on later scans or pentests, inflating the apparent reopen rate.	Retest tied to the same engagement record; closure evidence linked to the original finding identity.

Cost component	How it compounds	Intervention path
Administrative-tail cost	Finding remediated and verified but not signed off; consumes administrative capacity each reporting cycle.	Administrative closure SLA; automated closure trigger when retest passes; closure-batch cadence aligned to reporting cycle.
Reporting-distortion cost	Functionally-closed findings carried as open inflate open count, drag median age, and produce a worse remediation picture than warranted.	Awaiting-closure surfaced as a distinct queue; leadership dashboards exclude awaiting-closure from open count.
Compliance lag cost	Frameworks expect timely closure documentation; deferred administrative closure can read as deferred remediation at audit.	Closure evidence and timestamp captured at retest pass; administrative sign-off as a documented but bounded step.

Programme stage	Dominant concentration	Binding constraint
Early stage	Open and untriaged; intake outpaces triage capacity.	Triage capacity; intake hygiene rules.
Building triage	Triaged but unowned; triage clears but routing lags.	Routing rules; ownership model; team management.
Building routing	Owned but unstarted; ownership lands but capacity is the binding constraint.	Capacity planning; ringfenced remediation hours; dependency tracking.
Building capacity	In progress; work begins promptly but pipeline cycle time is long.	Stage-level cycle-time discipline; smaller fix scope; pipeline unblockers.
Building delivery	Awaiting verification; fixes ship but verification queue is the bottleneck.	Verification capacity; retest tied to deployment; closure-evidence rule.
Building verification	Awaiting administrative closure; verification clears but closure sign-off lags.	Administrative-closure SLA; automated closure trigger; reporting-cycle alignment.
Mature	Even distribution; no single state bunches; cycle time predictable per state.	Continuous capacity-vs-inflow calibration; per-state SLA monitoring.

Metric	What it reads	Diagnostic value
Per-state median resident time	How long the typical finding sits in each state.	Surfaces the headline per-state cadence; baseline read.
Per-state P90 resident time	The tail behaviour in each state; how long the slowest 10 percent take.	Surfaces outliers concentrated in one state; exposes the binding bottleneck.
Per-state inflow versus outflow rate	How fast findings enter versus leave each state per period.	Surfaces converging or diverging states; flags growing per-state backlogs early.
Per-state SLA breach rate	Percent of findings that exceed the per-state SLA target.	Surfaces whether the per-state cadence the programme committed to is being met.
Per-state exception rate	Share of findings that exit a state via exception rather than progression.	Surfaces where risk acceptance is absorbing the variance state by state.
Per-state reopen rate	Findings closed via this state that re-open within 90 days.	Surfaces durability of closures per state; flags shallow remediation paths.

Framework	Citation	State-relevant expectation
PCI DSS v4.0	Requirement 6.3.3 and 11.3	Timely remediation with documented progression; retest evidence of resolved high-risk vulnerabilities.
ISO 27001:2022	Annex A 8.8	Management of technical vulnerabilities including identification, evaluation, remediation, and verification phases.
SOC 2	CC7.1 and CC7.4	Identification and remediation of security events with documented evidence; incident response and recovery procedures.
NIST SP 800-53 Rev 5	RA-5 and SI-2	Vulnerability monitoring with documented remediation; flaw remediation with documented status across stages.
NIST CSF 2.0	ID.RA, PR.PS, RS.MI	Risk assessment across identified vulnerabilities; platform security including patching; incident mitigation across the lifecycle.
CIS Controls v8.1	Safeguard 7.7	Remediation of detected vulnerabilities with documented closure across the remediation cycle.
DORA	Articles 5 and 28	ICT risk management with documented stages; ICT third-party risk management with documented progression.
HIPAA	164.308(a)(1)(ii)(B)	Risk management including documented verification of risk treatment across each phase.