What is the difference between scanner finding age and scanner finding staleness?

Age is a cumulative count from first detection. A finding first opened on day one and still open on day three hundred has an age of three hundred days. Staleness is a freshness signal: how long ago the workspace last had evidence that the finding was still present. A finding first opened three hundred days ago but last confirmed by an authenticated scan yesterday has high age and low staleness. A finding first opened twenty days ago but last seen in any scan output ninety days ago has low age and high staleness. The two signals answer different questions and need separate fields on the record. Age drives SLA, escalation, and aged-debt reporting; staleness drives the question of whether the finding still represents real exposure or whether the underlying asset, scope, or scan path has changed and the finding has quietly fallen out of view. Programmes that collapse both into one updated-at column lose the ability to distinguish a backlog that is being worked from a backlog that is being ignored.

Why do scanner findings go stale and what are the most common causes?

Findings go stale for six structural reasons that have nothing to do with remediation work. Scope changed: the asset that produced the finding fell out of the scan target list, was decommissioned, or moved to a different scanner. Authentication failed: subsequent authenticated scans dropped to unauthenticated and the depth-dependent finding stopped recurring without any fix being applied. Coverage shifted: the scanner module that produced the finding was disabled, the rule pack was updated, or the credential class changed and the detection no longer fires. Rate limiting truncated output: the scan completed but the finding was past the response budget on subsequent cycles. The asset moved: an IP changed, a hostname rotated, a container image was rebuilt, or a repository was renamed and the finding identifier no longer resolves. Scheduled scans never ran: a credential expired or a worker drifted off schedule and the finding has not been re-evaluated against live infrastructure for weeks or months. Treating any of these patterns as a remediation event silently closes findings that still represent real exposure.

What does a defensible scanner finding age record look like?

A defensible record carries six durable fields against every finding. First_seen captures the timestamp the finding first entered the workspace as an open scanner detection. Last_seen captures the most recent scan cycle that confirmed the finding was still present in the scanner output. Detection_count captures how many scan cycles have observed the finding since first_seen. Last_evaluated_against_target captures the last scan that ran against the bound asset, regardless of whether the finding appeared or not (this is the staleness anchor; a finding absent because the scan ran is materially different from a finding absent because the scan never ran). Open_duration_days captures the cumulative age. Source_class captures which scanner produced the latest evidence (external scan, authenticated scan, code scan, third-party import, manual pentest writeup). With these six fields the workspace can answer four operational questions auditors and security leaders ask: when did this exposure first land on the record, when did the workspace last see evidence it still applies, how long has this exposure been carrying, and which scan source last touched the underlying asset.

Why does silently closing a stale finding break the audit chain?

Silent close is the failure mode where the workspace removes a finding from the open queue because the scanner stopped reporting it, without any verification evidence that a fix was applied. To the auditor reading PCI DSS 6.3.1, ISO 27001 Annex A 8.8, SOC 2 CC4.1, or NIST 800-53 RA-5 and SI-2, a missing finding looks identical whether it was remediated, quietly suppressed, or dropped because the scan path changed. The audit conversation that follows is whether the team operates a controlled remediation programme or whether closure happens by absence. The cleanest pattern is treating disappearance from scanner output as a transition into a staleness state that requires explicit triage rather than as a closure event. The finding stays open with an updated last_seen timestamp; the staleness queue surfaces it for a named triager who decides whether the disappearance maps to a verified fix, a scope change, an authentication drift, or a coverage drop. The activity log records the decision and the rationale. Only after the explicit triage does the finding move into a closed or retired state.

How should an aged-finding queue be structured so it surfaces real risk rather than noise?

A useful aged-finding queue separates four bands and treats each as a different operational signal. Band one is current age inside SLA: findings whose age has not yet crossed the SLA cutoff for their severity band. Band two is past SLA but recent last_seen: findings carried past the SLA window but confirmed present in the most recent scan cycle (the active aged backlog that needs remediation attention). Band three is past SLA with high staleness: findings carried past the SLA window where the last_seen timestamp predates the latest scan against the bound asset (the stale aged backlog that needs staleness triage before remediation work). Band four is retired with verification: findings that have been moved into a retired or closed state with explicit retirement evidence on the activity log. The queue reads the four bands as separate workstreams. Programmes that surface all aged findings as one undifferentiated list ask remediation owners to triage the staleness question and the fix question at the same time, which slows both.

What review cadence works for the aged-finding queue?

A defensible cadence depends on the severity band and asset class. For critical and high-severity findings on tier-zero and tier-one assets, review weekly: the band-two queue (active aged) goes to the remediation owner for status; the band-three queue (stale aged) goes to the scanner operator or AppSec triager for a staleness decision. For medium-severity findings, review biweekly to monthly: the same queue split applies but the cadence reflects the lower exposure. For low-severity findings, review monthly to quarterly: at this cadence the staleness signal often dominates the SLA signal because the underlying conditions change faster than the remediation window. The cadence is itself audit evidence. A workspace that can show the weekly aged-queue review with named attendees, decisions made, and findings retired or extended reads as a controlled programme. A workspace with an aged queue that has not been reviewed in two quarters reads as a queue that has been left behind.

How does scanner finding aging interact with vulnerability remediation SLAs?

SLA assignment uses the open_duration_days field as the age anchor and the workspace severity as the policy anchor. A critical finding with a fourteen-day SLA breaches at day fifteen of open_duration_days, regardless of whether the finding was last seen yesterday or two months ago. The staleness signal is additive: a breached SLA on a stale finding raises a separate question about whether the breach represents real exposure or a measurement artefact, and the staleness triage runs in parallel with the SLA escalation. The cleanest workflow runs aging against SLA on every open finding, surfaces both the SLA breach and the staleness state on the same row of the aged-finding queue, and lets the remediation owner read the two signals as one operational view. Programmes that suspend SLA accrual when a finding goes stale lose the discipline of treating exposure as exposure until it is verified gone; programmes that ignore staleness when reading SLA breach reports overcount the aged backlog. Both signals matter and both have to be visible.

How does SecPortal handle scanner finding aging and staleness?

SecPortal records every finding in a dedicated findings table keyed by workspace and engagement with timestamps captured at creation and on every status change. The findings table carries created_at as the durable first-seen anchor for the lifecycle, updated_at as the most recent record-level change anchor, and a structured status enumeration covering open, in_progress, resolved, verified, reopened, and the compliance-control finding states. The activity log captures every state transition with the acting user, the timestamp, and the rationale, with CSV export for audit evidence preparation. Recurring scanner detections key against the workspace plus finding plus target tuple, so the same scanner condition appearing on the same target across scan cycles matches the existing record rather than creating duplicates. The bulk import workflow that lands Nessus, Burp Suite, and CSV exports against the engagement record uses the same record-level matching so re-importing a later scan cycle updates the existing finding rather than creating a fresh one. Honest framing: SecPortal does not ship an automated staleness-triage engine that decides whether a disappeared finding maps to a fix, a scope change, or an authentication drift. Staleness triage is operator discipline against the activity log and the bound scan target rather than bespoke workflow automation. The recurring-detection match, the workspace-level audit trail, and the structured finding state machine give the workspace the anchors that an aged-finding policy needs to be defensible.

How do compliance frameworks read scanner finding aging evidence?

Auditors read aging evidence through three artefacts. The aging policy (the SLA bands per severity, the staleness threshold per source class, the retirement criteria, the review cadence) is the policy evidence; it is reviewed at audit kickoff and read as the operating discipline that bounds finding lifecycle behaviour. The finding-level aging history (the first_seen, last_seen, open_duration_days, source_class, and the activity log of state transitions) is the operating evidence; it is sampled at audit fieldwork and read as proof the policy was applied consistently. The aged-queue review record (which aged findings were reviewed in each cycle, which were retired with verification, which were extended, which were converted to risk acceptances) is the programme evidence; it is read as proof the team operates aging as a controlled activity rather than as a passive accumulation. ISO 27001 Annex A 8.8 reads aging through technical vulnerability management; SOC 2 CC4.1 and CC7.1 read it through monitoring controls and risk treatment; PCI DSS 6.3.1 and 11.3 read it through ranking, remediation, and the recurring scan record; NIST 800-53 RA-5 and SI-2 read it through vulnerability monitoring and flaw remediation cadence; CIS Controls v8.1 control 7 reads it through continuous vulnerability management. An aging history that cannot answer when the finding first landed, when it was last seen, and what decisions changed its state fails every one of these readings.

When should a stale finding be retired versus reopened versus converted to a risk acceptance?

The decision depends on the triage outcome, not on the age alone. Retire the finding when the staleness triage produces explicit evidence the underlying condition is gone: the asset was decommissioned and the decommissioning evidence sits on the record, the affected code path was removed and a code review confirms the removal, the configuration was changed and a focused authenticated scan confirms the change. Reopen the finding into the active backlog when the staleness triage confirms the disappearance is a measurement artefact: an authentication drift dropped the scan to unauthenticated, a credential expired, the scanner module was disabled, the scope shifted, or the rate budget truncated the output. Convert the finding to a risk acceptance only when the staleness triage confirms the underlying condition still exists and the named accountable owner has decided not to remediate, with the explicit rationale, the review cadence, and the expiry condition recorded on the acceptance. Programmes that retire findings without triaging the disappearance lose the audit defence that closure represents fix evidence; programmes that hold every stale finding open indefinitely accumulate a backlog of measurement noise that masks real exposure.

← Back to Scanner Information

Scanner guide15 min read

Scanner Finding Aging and Staleness

Most vulnerability programmes track age and ignore staleness. Both signals matter, and the difference between them decides whether closure represents a verified fix or a measurement artefact that quietly disappeared. Findings carried past SLA, findings that vanish from scanner output without a fix on the record, and findings that have not been seen in months despite the asset still running all surface in the same backlog. Each one carries a different operational decision and a different audit weight.

This guide covers how to model finding age as a structured record rather than as an implicit timestamp, how to capture staleness as a separate signal that distinguishes a recent scan from a scan that never ran, how to band the aged-finding queue so SLA and staleness triage stay distinct, how to retire stale findings with explicit verification evidence rather than by silent close, and how internal vulnerability management teams, AppSec engineers, and security operations leaders read the aged-finding history as control evidence for ISO 27001 Annex A 8.8, SOC 2 CC4.1 and CC7.1, PCI DSS 6.3.1 and 11.3, NIST 800-53 RA-5 and SI-2, and CIS Controls v8.1 control 7.

Age and staleness are two different signals

The most common modelling mistake is treating finding lifecycle as one timestamp. updated_at moves whenever any field changes; created_at sits frozen at first detection. Neither field tells the workspace whether the underlying condition was last verified by a scan yesterday or by a scan that ran ninety days ago. Both signals have to live as separate fields on the record, and both have to be readable on the aged-finding queue at the same time.

Age: cumulative count from first detection

Age answers when the exposure first landed on the record. It is a function of first_seen and the current time. Age drives SLA calculation, escalation ladders, aged-debt reporting, and leadership dashboards. A finding with an age of three hundred days is a finding that has been carrying for three hundred days, regardless of how many scan cycles have observed it.

Staleness: time since the workspace last had evidence

Staleness answers when the workspace last had scan evidence the finding still applies. It is a function of last_seen and the current time. Staleness drives the triage decision when a scan stops reporting a finding: is the disappearance a fix, a scope change, an authentication drift, or a coverage drop. A finding with an age of three hundred days and a last_seen of yesterday represents a long-running exposure that is still present; a finding with an age of three hundred days and a last_seen of ninety days ago represents an unresolved measurement question.

Last evaluated against target: the staleness anchor

A finding can be absent from the latest scan output for two reasons that look the same on the record: the scan ran and the condition no longer fired, or the scan never ran at all against the bound asset. The two cases differ in evidence weight. Tracking the last scan against the bound asset, separately from last_seen on the finding, gives the workspace the signal it needs to distinguish a finding that disappeared because the scan ran from a finding that disappeared because no scan ran. The aged-finding queue reads both.

Detection count: how many cycles have observed the finding

Detection count is the cumulative number of scan cycles since first_seen that have reported the finding. A finding with a high detection count is a high-confidence long-running exposure; a finding with a low detection count and high age is a signal worth examining for measurement artefacts. The two signals together let the workspace read whether a long-running finding is being consistently observed or whether the observation record is sparse.

What a structured aging record carries

A defensible aging record is a structured set of durable fields on the finding rather than an inferred reading of one timestamp. The components below have to survive scan cycles and audit reconstruction without interview-driven archaeology.

Field	What it captures	Why audit reads it
First seen	Timestamp of the scanner detection that first opened the finding on the workspace record.	Anchors the SLA clock and the cumulative exposure window the auditor reads for ranking and remediation evidence.
Last seen	Timestamp of the most recent scan cycle that confirmed the finding was still present in scanner output.	Separates an actively reproducing finding from a finding whose evidence has gone quiet.
Detection count	Number of scan cycles since first_seen that have reported the finding.	Surfaces high-confidence long-running exposures versus sparse observation records that warrant a measurement review.
Last evaluated against target	Timestamp of the most recent scan that ran against the bound asset, regardless of whether the finding fired.	Distinguishes a finding absent because the scan ran from a finding absent because no scan ran. The staleness anchor.
Open duration	Cumulative open age in days. Derived from first_seen and the current state.	Drives the SLA band, the escalation ladder, and the aged-debt portfolio reporting at leadership view.
Source class	The scan source that produced the latest evidence (external scan, authenticated scan, code scan, third-party import, manual writeup).	Lets the aging policy apply a different staleness threshold per source so authenticated drift does not get read as remediation.

A workspace that stores these fields against each finding survives ISO 27001 Annex A 8.8 fieldwork, SOC 2 CC4.1 monitoring sampling, PCI DSS 6.3.1 ranking and 11.3 recurring scan evidence requests, and NIST 800-53 RA-5 monitoring cadence reviews without aged-backlog archaeology.

Six structural causes of finding staleness

Findings go stale for reasons that have nothing to do with remediation work. Reading staleness as a remediation event silently closes findings that still represent real exposure. The six causes below cover most production cases. The triage decision for each cause is different.

Scope changed

The bound asset fell out of the scan target list, was decommissioned, or migrated to a different scanner. The triage decision is whether to retire the finding with decommissioning evidence on the record (the scope change reflects a real change in the deployed estate) or to reopen against the new scan target (the asset still runs, the scope record is the artefact that needs fixing).

Authentication drift

The depth-dependent finding stopped recurring because subsequent authenticated scans silently dropped to unauthenticated. The condition still exists; the scanner stopped reaching it. The triage decision is to keep the finding open, escalate the authenticated scan failure, and treat the disappearance as a coverage artefact rather than as remediation evidence.

Coverage shift

The scanner module that produced the finding was disabled, the rule pack was updated, or the credential class changed so the detection no longer fires. The condition may still exist; the workspace is no longer looking for it. The triage decision is whether to restore coverage or accept the coverage decision as programme policy, with the rationale on the record either way.

Rate-limited truncation

The scan completed but the finding was past the response budget on subsequent cycles. The output truncation looks identical to remediation on the finding record if rate-limit telemetry is not captured. The triage decision is to read the scan-coverage record alongside the finding state and reopen against a retry with expanded budget where the bound target was truncated.

Asset reference moved

An IP changed, a hostname rotated, a container image was rebuilt, or a repository was renamed and the finding identifier no longer resolves to the same canonical key. The condition is identical; the binding broke. The triage decision is to rebind the finding to the new canonical reference and keep the open record rather than letting it close as orphaned.

Scheduled scans never ran

A credential expired, a worker drifted off schedule, or the maintenance window never returned. The finding has not been re-evaluated against live infrastructure for weeks or months. The disappearance is not evidence of a fix; it is evidence the scan path is broken. The triage decision is to fix the scan schedule and reopen evaluation rather than reading the silence as resolution.

Banding the aged-finding queue

A useful aged-finding queue separates four bands and treats each as a different operational signal. The mistake is surfacing every aged finding as one undifferentiated list and asking remediation owners to triage the staleness question and the fix question at the same time.

Band	Signal	Operational owner
Inside SLA	Age is under the SLA cutoff for severity band; last_seen recent.	Remediation owner under standard cadence.
Past SLA, recent last_seen	Age past SLA cutoff; finding confirmed present in the most recent scan cycle.	Remediation owner with SLA escalation; the active aged backlog.
Past SLA, stale last_seen	Age past SLA cutoff; last_seen predates the latest scan against the bound asset.	Scanner operator or AppSec triager for staleness decision before remediation work resumes.
Retired with verification	Finding moved into a closed or retired state with explicit retirement evidence on the activity log.	Audit lookback view; the historical record auditors sample for closure quality.

The four bands let two parallel queues run without colliding. Band-two findings need remediation work and SLA escalation; band-three findings need staleness triage before anyone starts on the fix. Programmes that conflate the two ask remediation owners to spend their cycles on measurement questions.

Review cadence by severity and asset class

The aged-finding queue drifts. The asset estate changes, scanner coverage shifts, authentication credentials rotate, scheduled scans miss windows. A review cadence is the discipline that detects drift before the next audit cycle does. The cadence varies by severity and asset class because the cost of carrying a stale finding varies.

Critical and high severity, tier-zero and tier-one assets: weekly review of the active aged queue (band two) with the remediation owner; weekly review of the stale aged queue (band three) with the scanner operator. The exposure cost is high enough that a week of silence is the maximum tolerable measurement gap.
Medium severity: biweekly to monthly review. The same band split applies. Staleness in this band more often reflects scope drift than authenticated coverage loss, so the triage emphasis shifts toward the asset register rather than the scanner state.
Low severity: monthly to quarterly review. At this cadence the staleness signal often dominates the SLA signal because the underlying conditions change faster than the remediation window. Bulk retirement with verification evidence is common and defensible at this band.
Retired-with-verification: reviewed once per audit cycle for closure quality. The auditor sampling test reads this band for evidence that retirement decisions were verified rather than silent.

The cadence record is itself audit evidence. A workspace that can show which aged findings were reviewed in the last cycle, which were retired with verification, which were extended into a fresh remediation window, and which were converted into explicit risk acceptances reads as a controlled programme rather than as a passive accumulation.

Five anti-patterns that break the audit chain

Each of these patterns turns scanner finding aging into an audit liability rather than a control. The shared root cause is treating disappearance from scanner output as equivalent to remediation rather than as a state transition that requires explicit triage.

Silent close on disappearance

The workspace closes findings automatically when the next scan cycle does not report them, with no triage of whether the disappearance maps to a fix, a scope change, an authentication drift, or a coverage drop. The closure history reads as remediation evidence but is actually scanner-output absence. The fix is treating disappearance as a transition into a staleness state that requires an explicit triager decision before the finding moves into closed or retired.

One timestamp does all the work

The workspace uses updated_at as both the age anchor and the staleness anchor. Any field change resets the staleness reading; aging is inferred from created_at minus any state change. The two signals collide and neither answers cleanly. The fix is durable first_seen, last_seen, last_evaluated_against_target, and detection_count fields, all populated on every scan cycle.

Aged queue is one list

Every aged finding sits on one undifferentiated list, regardless of whether the exposure is actively reproducing or has gone measurement-quiet. Remediation owners spend their cycles on staleness questions; scanner operators never see the measurement queue. The fix is banding the queue by SLA state and staleness state so the two workstreams stay separate.

No retirement evidence on closure

Findings move into closed or retired state without explicit retirement evidence on the record: no asset decommissioning artefact, no focused authenticated rescan confirming the fix, no code review confirming removal. The auditor reading the closure history cannot distinguish verified fixes from silent close. The fix is requiring an evidence reference on every retirement transition and surfacing the retirement reason in the activity log.

Staleness has no off-cycle trigger

The staleness review runs only on the scheduled cadence. An authenticated scan failure on a tier-zero asset, a credential rotation that broke the scan path, or a module disable that dropped coverage produces no off-cycle review. The fix is naming the events that trigger an off-cycle staleness review (authentication failure, credential rotation, scope change, module disable, schedule miss) on the aging policy and binding the trigger to the queue rather than to the calendar.

How compliance frameworks read aging evidence

The same aging record reads through several frameworks as different control evidence. The table below maps the most common readings auditors run during fieldwork.

Framework clause	What auditors read for
ISO 27001 Annex A 8.8	Technical vulnerability management. Auditors read aging as evidence the programme tracks finding lifecycle from detection through closure rather than treating disappearance as resolution.
SOC 2 CC4.1, CC7.1	Monitoring controls and risk treatment. The aged-queue review record is sampled across the observation period for evidence the team operates against the aging policy consistently.
PCI DSS 6.3.1, 11.3	Vulnerability ranking and recurring scan evidence. Auditors read first_seen and last_seen alongside the scan record to confirm scheduled scans actually executed against in-scope systems and that ranking applied through the SLA window.
NIST 800-53 RA-5, SI-2	Vulnerability monitoring and flaw remediation. The aging record is read as evidence of monitoring cadence and remediation cycle adherence; silent close without retirement evidence fails the reading.
CIS Controls v8.1 7	Continuous vulnerability management. The aging cadence and the retirement-with-verification record are read as evidence of the ongoing management discipline rather than ad hoc cleanup.
NIST CSF 2.0 ID.RA, DE.CM	Risk assessment and continuous monitoring. The first_seen to last_seen window reads as evidence the programme identifies and tracks exposures across the monitoring period.

The pattern across frameworks is consistent. An aging history that captures first detection, last evidence, observation cadence, and retirement rationale reads as control evidence. An aging history reduced to one timestamp and a status flag reads as missing data.

How SecPortal handles scanner finding aging

SecPortal records every finding in a dedicated findings table keyed by workspace and engagement. Each finding carries created_at as the durable first-seen anchor for the lifecycle and updated_at as the most recent record-level change anchor. The finding status enumeration covers open, in_progress, resolved, verified, and reopened states for vulnerability findings, plus the compliance-control states (compliant, non_compliant, not_applicable, not_assessed, implemented, partially_implemented, not_implemented, effective, ineffective, not_tested) used for control assessments. The findings management feature surfaces every open and recently changed finding so age and recent activity are readable on the same view.

The activity log captures every state transition with the acting user, the timestamp, and the rationale, with CSV export for audit evidence preparation. Recurring scanner detections key against the workspace plus finding plus target tuple, so the same scanner condition appearing on the same target across scan cycles matches the existing record and updates the last-touch timestamps rather than creating a fresh finding. The bulk import workflow that lands Nessus, Burp Suite, and CSV exports onto the engagement record uses the same record-level matching so re-importing a later scan cycle updates the existing finding rather than creating duplicates.

The continuous monitoring schedules (daily, weekly, biweekly, monthly) produce the cadence record that aging policy reads against; a scheduled scan that runs against the bound asset is the anchor for last_evaluated_against_target even when the finding does not appear in that cycle. Retesting workflows handle the verification-of-fix path that turns a disappeared finding into a verified closure rather than a silent retirement.

Honest framing: SecPortal does not ship an automated staleness-triage engine that decides whether a disappeared finding maps to a verified fix, a scope change, an authentication drift, or a coverage drop. Staleness triage is operator discipline against the activity log, the bound scan target, and the published aging policy rather than bespoke workflow automation. The recurring-detection match, the workspace-level activity log with CSV export, the structured finding state machine, and the published continuous monitoring schedule give the workspace the anchors that an aging policy needs to be defensible; the policy itself lives in workspace documents and is operated by named owners under team management role-based access control.

Where aging fits alongside related disciplines

Aging is one decision inside a wider vulnerability management programme. The pages below cover the disciplines that aging interacts with and the workflows that aging is not a substitute for.

Scanner evidence chain from scan to finding: the seven-layer audit chain that aging records sit inside. The first_seen and last_seen timestamps belong on layer five of the chain (triage transitions) and layer seven (retest and closure).
Scanner finding suppression and deferral controls: the structured override register. Suppression and deferral are explicit decisions applied to aged findings rather than substitutes for staleness triage.
Scanner finding exception lifecycle and expiry: the lifecycle that operates the override after it is recorded. Aging tracks whether the underlying finding is still being detected; the lifecycle tracks whether the override on it is still being reviewed. The two disciplines read against one another so an aged finding does not silently inherit an old exception that no reviewer has re-authorised.
Scanner finding to asset binding: the canonical-key discipline that decides whether a renamed or rotated asset breaks the finding identifier. Asset-reference movement is one of the six structural causes of staleness.
Scanner authentication failure modes: the diagnostic chain for authenticated coverage drops. Authentication drift is the most common cause of stale depth-dependent findings, and the off-cycle staleness trigger fires from this guide.
Scanner coverage and limits: the upstream coverage view. A coverage drop produces a staleness signal that has to be triaged against this guide before the finding can be closed.
Scan scheduling and baseline cadence: the cadence record that aging reads against. A scheduled scan that never ran against the bound asset is the anchor for the missed-cycle staleness cause.
Vulnerability backlog management: the operating-queue workflow that aged-finding bands feed into. The band-two active aged queue lives here.
Asset decommissioning and finding retirement: the explicit retirement-with-verification path. Findings retired because the underlying asset was decommissioned move through this workflow rather than through silent close.
Vulnerability finding state lifecycle: the state-machine view of finding transitions. Aging is the temporal axis the state machine reads against.
Security debt portfolio management: the steering-cycle view. The aged-finding queue is the raw input that classifies findings into the four debt classes.

For the analytical view on how aging distributions move across programmes, the aging pentest findings research and the security finding ownership decay research cover how findings drift out of view, why ownership goes quiet over time, and what the distribution shape implies for staffing and policy. For the leadership reporting view that reads aged-debt portfolios at the steering committee level, the security leadership reporting workflow covers the upstream cadence.

An operational checklist

When a finding first lands

Capture first_seen with the scanner source class and the bound target.
Start detection_count at one; bind the finding identifier to the source-emitted finding plus target tuple.
Set last_seen equal to first_seen at intake; both update on recurring detections.
Record the SLA band based on workspace severity policy at the moment of intake.

On every scan cycle

Recurring detections match the existing finding-target tuple and update last_seen plus detection_count rather than creating duplicates.
Update last_evaluated_against_target for every finding bound to a target the scan ran against, regardless of whether the finding appeared.
Findings that do not appear in the scan output but whose target was scanned move toward the staleness threshold per source class rather than auto-closing.
Findings whose target was not scanned hold last_seen unchanged; the staleness anchor sits on last_evaluated_against_target.

On the aged-queue review

Read the queue by band: inside SLA, past SLA recent, past SLA stale, retired with verification.
Route band-two findings to the remediation owner; route band-three findings to the scanner operator for staleness triage.
For each band-three finding, identify the cause: scope, authentication, coverage, rate limiting, asset reference, missed schedule.
Record the triage outcome (retire with verification, reopen into active backlog, convert to risk acceptance, restore coverage) on the activity log with the rationale.

When closing a stale finding

Require an evidence reference on the retirement transition: decommissioning artefact, focused authenticated rescan, code review, or scope-change record.
Capture the closure rationale on the activity log alongside the actor and the timestamp.
Preserve the historical first_seen and detection_count so the closure record reads as verified rather than as silent close.
For findings closed because the asset was decommissioned, link the decommissioning record so the audit lookback resolves to the artefact.

Scope and limitations

Aging discipline only works when the underlying findings record is durable. Programmes that store findings in spreadsheets, in ticketing tools without a stable finding identifier, or in scanner UIs that reset state on every rule update cannot operate a defensible aged-queue review at all. The leverage point is consolidating findings into a workspace with a stable identifier per finding-target tuple before attempting to govern aging behaviour.

Aging is not a substitute for verification. A finding that has been retested and confirmed fixed moves to verified through the security finding fix verification workflow; a finding retired because the scanner stopped reporting it does not represent a fix unless the retirement evidence is on the record. Conflating the two in reporting produces a closure history the audit cannot defend.

For the broader vulnerability management lifecycle that aging sits inside, the vulnerability management programme guide covers identification, ranking, treatment, and reporting as one end-to-end discipline. For the governance frame that names the accountable owner for each retirement and staleness decision, the ISO 27001 framework page covers how Annex A 8.8 expects technical vulnerability management to operate as a controlled activity.

Frequently Asked Questions

Run scanner finding aging as a controlled programme

SecPortal records every finding with durable timestamps, a structured state machine, recurring-detection matching across scan cycles, and a workspace-level activity log with CSV export so the aged-finding history reads as control evidence.

Start free See the backlog management workflow