Asset decommissioning and finding retirement
dispose deliberately, not by silent erasure

An AWS account, Azure subscription, GCP project, or SaaS tenant is wound down because the workload moved, the team disbanded, or the entity was divested. Domains under the account, instances inside it, code hosted from it, and findings discovered against it all need a deliberate retirement decision rather than ageing in the queue forever.

A monolith moves to containers, a VM-based service moves to Kubernetes, or an on-premise system moves to a managed cloud equivalent. The old asset still has open findings, but the workload is no longer there. Without a retirement event, the dead host keeps inflating critical and high counts on the dashboard for years after the migration shipped.

A code repository is archived, renamed, replaced by a rewrite, or marked end-of-life. SAST and SCA findings against the retired repository do not need to be closed by code changes; they need to be retired with the asset so the queue reflects the actual scope of work the team owes.

A subdomain is removed from DNS, a marketing property is wound down, an acquired company domain is consolidated, or a brand is retired. External scanner findings on the retired domain belong to a host that no longer answers, and the queue needs an explicit retirement decision rather than a silent skip on the next scan.

A merger consolidates two security backlogs into one, an acquisition adds an inherited backlog the new programme has to triage, or a divestiture splits assets across two organisations. Inherited findings on assets that no longer fall under the new programme scope need a retirement decision tied to the consolidation event so the audit trail explains the disposition.

A network appliance, a database server, an integration endpoint, or an internal microservice is decommissioned because the function moved, the dependency was removed, or the asset reached end-of-life. Findings on the decommissioned asset need to retire with it; without the retirement event, the dashboard shows persistent critical and high counts that nobody can act on.

Without a retirement workflow, dead hosts, archived repositories, and parked domains continue to own findings on the dashboard. Headline severity counts include critical and high entries the team cannot remediate because the asset no longer exists, and the leadership read of programme health is permanently distorted by the long tail of dead-asset findings.

Some teams allow the scanner to drop findings on assets that stop responding by ageing them out automatically. The closure has no evidence, no rationale, no approver, and no link back to the decommissioning event. ISO 27001, SOC 2, and PCI DSS audits read this as missing closure trail rather than legitimate retirement.

The infrastructure team decommissions a host. The security team finds out months later when a stakeholder asks why a critical is still open. Pairing the asset retirement to the finding retirement at the same moment, with the same approver, on the same engagement record, prevents the gap that lets dead-asset findings age forever.

Findings closed without a documented retirement rationale (the asset was decommissioned, migrated, replaced, sold, or archived) read in the audit as undocumented closures. The same finding closed with a retirement event captured (cause, target asset state, approver, evidence link) is defensible. The data model carries the rationale or it does not exist for the audit.

An acquired company arrives with an open vulnerability backlog the parent programme inherits. Without a consolidation owner, an explicit scope decision per asset (in scope, retire, accept under exception), and a documented event linking each retired finding to the consolidation, the inherited backlog quietly mixes into the parent queue and audits cannot distinguish prior debt from current programme posture.

Sometimes a retired asset is brought back: a parked domain is reactivated, an archived repository is unarchived because a downstream consumer surfaced, or a decommissioned service is restored after a roll-back. Without an audit trail of the retire-and-reinstate sequence, the previously retired findings reappear without context. The activity log has to record the retire event, the reinstate event, and the rationale for both.

The fixed list of acceptable retirement causes recorded on the engagement: cloud account closure, workload migration, repository archive, domain expiry, M&A consolidation, hardware decommissioning, or service end-of-life. A free-text reason without a taxonomy makes audit aggregation impossible; a taxonomy without enforcement lets retirement become a synonym for hidden closure.

The role that has to approve a retirement under each cause. Cloud account closure typically needs the cloud platform owner plus the security lead. Repository archive needs the engineering owner plus AppSec. Domain expiry needs the marketing or product owner plus the external scanning lead. The approver is recorded on the finding so the audit reads the named decision-maker rather than a generic team.

The proof that the asset is actually retired: the cloud account closure confirmation, the repository archive timestamp, the DNS removal record, the workload-migration cutover note, or the hardware decommissioning ticket. Findings retire with evidence that the underlying asset is gone, not on the assertion that it should be.

When the workload migrated rather than disappeared, the retirement record points to the successor asset (the new repository, the new cloud account, the new service) so any open findings that should follow the migration are paired to the new owner rather than retired by accident. Migration without a successor reference is the most common path to silent backlog erasure.

Retired findings do not get deleted; they get marked retired with evidence and stay searchable for the audit retention period (commonly seven years for ISO 27001 and PCI DSS environments). The retention window is on the engagement so the activity log export covers the period the assessor expects.

The condition that forces a retired record to be reviewed: the asset is brought back online, a successor scan re-discovers the same finding, or a downstream consumer reports the resource. The trigger is documented so the retire-and-reinstate sequence is auditable rather than discovered in retrospect.

A close event records that the underlying vulnerability was remediated on a still-live asset: a patch was applied, a configuration was changed, a code fix shipped, a compensating control was put in place. A retire event records that the asset itself no longer exists, so the finding has nothing to remediate. Mixing the two corrupts both the closure rate (artificially inflated by retirements) and the retirement posture (hidden inside closures).

An exception event records that the team has decided to accept residual risk on a live asset for a documented reason and a finite expiry. A retire event records that the asset is gone, so there is no residual risk to accept. Mixing the two pushes findings on dead assets into the exception register where they sit forever, and it pushes findings on live assets into retirement where the audit cannot find them.

A deferral event records that the team has decided to push remediation to a later cycle on a still-live asset. A retire event records that the asset is gone. Deferral keeps the SLA clock running and the finding visible in the queue. Retirement removes the finding from the live queue with evidence that the underlying asset is gone. Treating one as the other breaks both signals.

Asset retirement is not a default state findings drift into. It is a deliberate decommissioning event with a cause, an approver, asset state evidence, and (where applicable) a successor reference. The retire event lands at the same moment as the decommissioning event, with the same approver, on the same engagement record. Anything else is silent erasure dressed as cleanup.

Retirement runs alongside vulnerability backlog management (which excludes retired findings from the live queue), vulnerability SLA management (which excludes retired findings from breach scoring), vulnerability acceptance and exception management (which handles the live-asset deferred-risk track), and patch management coordination (where the retire decision is one of four routes alongside apply, defer, and mitigate).

Retirement evidence rolls up into the broader security testing programme and feeds the security leadership reporting workflow where retirement-by-cause, migration-with-successor share, and reinstate-rate become indicators on the quarterly leadership cadence. The remediation tracking workflow keeps closure on live assets distinct from disposition on retired assets. M&A consolidation events that drive bulk retirement upstream are produced by the M&A security due diligence workflow, so divested-asset retirement carries the deal-side context rather than a free-text consolidation note.

The live backlog reflects work the team can actually do. Findings on assets that no longer exist are retired with cause, approver, and evidence rather than ageing forever on the dashboard. Critical and high counts on the leadership view are not distorted by dead-asset entries.

Findings retire when the underlying asset retires, with the same approver, on the same engagement record. Silent closure on the next scan does not happen. The retire event carries a cause from the taxonomy, asset state evidence, and where applicable a successor reference.

Migrated workloads carry their findings to the successor asset rather than retiring them by accident. Disposed workloads retire cleanly with documented cause. The split between migration and disposition is observable on the dashboard and in the AI report.

Retirement-by-cause, retired-with-successor share, reinstate rate, and the activity log export all derive from the live findings record. Nobody assembles the retirement evidence the week before the audit; the activity log is the trail, and the AI report is the narrative.