How long should vulnerability scan evidence be retained?

Retention duration depends on the framework that consumes the evidence and the asset class the scan covers, not on a single number. PCI DSS v4.0 Requirement 10.5.1 sets a minimum of 12 months of audit log retention with at least the most recent three months immediately available. ISO 27001:2022 Annex A 5.33 and 8.15 expect documented retention for records and event logs justified by legal, regulatory, and contractual requirements; the retention period is defined by the organisation rather than the standard. SOC 2 Trust Services Criteria CC7.1 expects evidence that detection operated continuously across the audit observation period, which is typically 6 to 12 months. NIST SP 800-53 control AU-11 expects audit record retention defined by mission, regulatory, and operational requirements, with no fixed duration. The defensible answer is to retain summary scan evidence for at least the longest framework window that applies to each asset class, retain detailed scan output for the operational window the team needs (typically 90 days), and retain finding records for the full lifecycle of the finding plus the audit window after closure.

What is the difference between scan output retention and finding retention?

A scan execution and a finding are different artefacts with different retention requirements. The scan execution is the run-time record of a single scan: the scanner class, the target, the start and end timestamps, the modules that ran, the modules that were skipped or timed out, and the raw output produced. The finding is the lifecycle artefact derived from one or more scan executions: an identified vulnerability with a CVSS score, severity, status, owner, evidence trail, retests, and closure record. Scan executions are large, transient, and useful primarily for the diff between cycles and for reproducing a single run. Findings are the durable record auditors read for control operation. The defensible retention pattern keeps scan executions for an operational window (typically 30 to 180 days) and keeps findings for the lifecycle of the finding plus the framework retention period after closure. Programmes that conflate the two either overretain raw output or underretain finding evidence, and both fail audit reads.

What does PCI DSS Requirement 10.5.1 expect for scan evidence?

PCI DSS v4.0 Requirement 10.5.1 expects audit log history to be retained for at least 12 months, with at least the most recent three months immediately available for analysis. Vulnerability scan output is not strictly an audit log under that requirement, but the related Requirement 11.3 expects internal and external scans at least quarterly and after significant change, and the evidence package an assessor reviews has to demonstrate the scan operated as required across the audit window. PCI DSS Requirement 12.10.1 (incident response) reaches the scan record when an incident triggers retrospective analysis. The practical retention floor for PCI scan evidence is 12 months for the scan execution summaries (date, target, status, finding counts), full report retention for at least the audit window plus the period the QSA requires, and finding retention through closure plus the audit retention window.

How should retention differ for external, authenticated, and code scans?

Each scanner class produces output with different sensitivity and audit value. External scans against publicly reachable surface produce moderate-volume output that is mostly safe to retain in detail; the scan execution, the modules run, and the findings can sit in the workspace through the framework retention window. Authenticated scans produce output that includes session artefacts, request bodies, and authenticated response samples that may contain personal data, customer data, or business secrets; the defensible pattern retains the finding evidence and scrubs or summarises the raw request and response bodies after the operational window closes. Code scans produce output bound to source code state at a specific commit; the scan execution should retain the commit hash, the rule pack version, and the finding summary, while the raw code excerpts inside finding evidence can be redacted or hashed once the finding is closed and the audit window passes.

When should scan evidence be disposed?

Disposal is the deliberate end of the retention period and the deletion of records that are no longer required. Three rules govern disposal. First, disposal happens against a documented retention schedule, not by accident or storage pressure. The schedule names the artefact class (scan execution, finding, scan log, raw output), the retention period, the trigger event (creation date, finding closure, audit period close), and the disposal method. Second, disposal does not delete records under legal hold. Litigation, regulatory investigation, or active incident response can pause disposal indefinitely; the workspace tracks the legal hold and resumes disposal when the hold is released. Third, disposal is recorded as an event so the audit trail shows the disposal happened against the schedule rather than as data loss. ISO 27001 Annex A 5.33 (records protection) and 8.10 (information deletion) treat disposal as a controlled activity, not a passive byproduct of retention windows expiring.

How does a scan record support an audit observation period?

Auditors read scan evidence not as the most recent report but as the count of scan operations across the observation period and the lifecycle of the findings produced by those operations. A SOC 2 Type II audit covers a window (typically 6 to 12 months); the assessor expects evidence that scans ran inside the window at the cadence the policy named, that findings were triaged inside the policy timeline, and that closures were verified before the finding state changed. A scan record that consists of the most recent quarterly report and nothing else fails the observation read regardless of retention duration. The audit-defensible pattern retains every scan execution inside the window with summary metadata (target, scanner class, status, run timestamp, finding counts), retains the full report for any cycle the assessor samples, and retains the finding lifecycle through closure. Retention duration is the floor; cadence operation across the window is the proof.

What should a scan retention policy document?

A defensible scan retention policy names eight elements explicitly. The artefact classes covered (scan executions, scan jobs, findings, scan logs, raw module output, screenshots, request and response bodies, scan reports). The retention period per artefact class with the regulatory or business justification. The retention trigger (creation date, closure date, audit period close, project end). The storage location and access controls during retention. The disposal method (cryptographic erasure, secure deletion, sanitisation). The disposal trigger and the disposal record format. Legal hold procedures (who can place a hold, how the hold is recorded, how the hold is released). Roles and responsibilities (data owner, retention administrator, audit liaison). The policy is read by the audit conversation; an undocumented retention practice produces evidence the assessor cannot reconcile to a control operation. ISO 27001 Annex A 5.33, NIST SP 800-53 SI-12, and PCI DSS Requirement 9.4 all read retention through the policy plus the operating evidence rather than the duration alone.

How does retention interact with privacy regulations?

Scan output can include personal data when authenticated scans capture session details, when external scans pick up personal information exposed in metadata or content, or when finding evidence captures end-user data inadvertently. Privacy regulations layer retention obligations on top of security retention. GDPR Article 5(1)(e) (storage limitation) requires personal data to be retained no longer than necessary for the purpose; the scan retention period for personal data has to be justified against the security purpose and reviewed when the purpose changes. UK GDPR follows the same pattern. CCPA section 1798.100(a)(3) requires a similar retention disclosure. The defensible pattern is to minimise personal data capture in the scan configuration, redact personal data in finding evidence at the point of capture rather than at retention close, document the retention period for any artefact that may contain personal data, and process subject access and deletion requests against scan artefacts as part of the workspace privacy operating model. Retention exceeding the privacy floor is a regulatory risk regardless of the security justification.

How do you handle scan evidence after a customer or engagement ends?

When a customer relationship or an engagement ends, scan evidence enters a transitional state. The retention obligation does not end with the engagement; the scan record remains evidence of past control operation that may be required for audits inside the original retention window. Three patterns handle the transition cleanly. Hand over: the scan record, the findings, and the supporting evidence are exported to the customer or successor team in a documented format, the workspace records the handover, and disposal proceeds on the original schedule. Retain in place: the workspace retains the record under the original retention policy, with access scoped to roles that need it for audit response, and disposes on the original schedule. Selective dispose: non-audit-relevant artefacts (raw module output, screenshots beyond what the finding evidence requires) are disposed at engagement close while audit-relevant summaries are retained for the framework window. The choice depends on the contractual obligation, the regulatory requirement, and the operational need for the evidence after the engagement ends. Programmes that delete scan evidence at engagement close without documented justification create audit gaps later.

How does SecPortal handle scan evidence retention and governance?

SecPortal retains scan executions and code scan executions with a configurable retention window. The default `SCAN_RETENTION_DAYS` is 90 days, after which completed and failed scan executions, scan jobs, and code scan executions are purged on a weekly cron (Sunday 04:00 UTC) by the `purge-old-scans` job. Findings persist independently of scan execution retention; closing or archiving a scan execution does not remove the findings derived from it, which keeps the lifecycle record intact through closure and audit. Activity log retention is plan-based (30 days on Starter, 90 days on Pro, 365 days on Team) and runs through the daily `cleanup-activities` job at 03:00 UTC. The activity log records every finding, engagement, scan, document, comment, invoice, and team change with a timestamp and acting user, providing the chain-of-custody record auditors expect. Compliance tracking maps findings and controls to ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST so the retained evidence aligns to the framework view assessors read. Document upload, encrypted credential storage (AES-256-GCM), MFA enforcement, and RBAC bracket the retention model so the records are protected during the retention period and disposed cleanly at the end.

← Back to Scanner Information

Scanner guide16 min read

Scan Evidence Retention and Governance: A Production Guide

Retention is two questions, not one, and most programmes answer only the first. The first question is how long the scan output sits in storage. The second question is which artefacts inside the scan output are worth retaining at all, and which ones become regulatory liabilities after the operational window closes. Programmes that pick a single retention duration and apply it uniformly to every artefact either keep too much (privacy and storage exposure on raw scan bodies) or keep too little (audit gaps on summary records auditors actually read). The defensible policy decomposes by artefact class and operates retention against a documented schedule rather than as a storage-pressure release valve.

This guide covers how to set retention per artefact class (scan execution, finding, activity log, raw module output), how compliance frameworks read retention evidence (PCI DSS Requirement 10.5.1, ISO 27001 Annex A 5.33 and 8.10, SOC 2 CC7.1, NIST SP 800-53 AU-11 and SI-12), how privacy regulations layer on top, when to dispose and when to hold, and how internal security, AppSec, vulnerability management, and GRC teams operate retention as part of continuous monitoring rather than as a quarterly spreadsheet exercise.

Retention is per artefact class, not per scan

A single scan produces several distinct artefact classes, and they do not share a retention requirement. Scan executions are run-time records that are large, transient, and useful primarily for the diff between cycles. Findings are lifecycle artefacts that auditors read as evidence of control operation. Activity logs are timestamped chain-of-custody records that bracket every state change. Raw module output, screenshots, and request and response bodies are evidence inside finding records that may contain personal data or business secrets. A retention policy that names only a single duration either over-retains the noisy artefacts or under-retains the audit-relevant ones.

Artefact class	Typical retention	Trigger to dispose
Scan execution (run-time record)	30 to 180 days for the operational window; longer if a framework binds the cycle to evidence.	Age of execution past the operational window, with no open dispute or legal hold.
Finding (lifecycle record)	Lifecycle of the finding plus the framework retention window after closure (typically 12 to 36 months).	Closure date plus retention window, with no related open finding, audit hold, or regulatory obligation.
Activity log (chain of custody)	12 months minimum for PCI DSS Requirement 10.5.1; longer for SOC 2 Type II and ISO 27001 surveillance windows.	Plan-based or policy-based age, with audit observation periods accounted for.
Raw module output and bodies	Operational window only; redact at the point of capture for personal data.	Operational window age plus privacy review.
Scan report (final delivered artefact)	Audit window per framework, plus contractual retention if the report was delivered to a client or auditor.	End of the longest applicable retention obligation.

The shape of the policy is decomposition: short retention on the noisiest, most privacy-exposed artefacts, and longer retention on the durable lifecycle records auditors read. Programmes that set 12 months on every artefact class store noise and create privacy risk; programmes that set 30 days on every artefact class lose audit evidence. The scanner output deduplication guide covers the upstream discipline that keeps the retained record clean across cycles.

Calendar retention and trigger-based retention

Retention has to operate on two axes at once. Calendar retention answers the steady-state question: how long does each artefact class sit in storage by default. Trigger retention answers the lifecycle question: when does an event change the retention obligation for a specific artefact ahead of the calendar bound. Policies that watch only the calendar miss the trigger events that change retention; policies that watch only triggers miss the calendar floor frameworks expect.

Finding closure

A finding closure does not start retention; it starts the retention countdown for the finding record after the operational window. The finding evidence is durable from creation; closure changes the retention bound from open-ended (while the finding is active) to closure date plus the framework retention window.

Audit observation period close

A SOC 2 Type II or ISO 27001 surveillance window closes. The records inside the window have to be retained through the assessor review and any subsequent year-on comparison. The retention policy should not dispose records that span the observation window during the assessor review.

Legal hold or regulatory investigation

Litigation, regulatory inquiry, breach investigation, or active incident response pauses disposal indefinitely. The hold is recorded on the affected scope (a workspace, an engagement, a finding, a target), disposal stops for that scope, and disposal resumes on the original schedule when the hold is released.

Privacy review against personal data

A finding or scan execution is identified as containing personal data. The retention bound shifts from the security retention period to the lower of the security retention and the privacy retention justified under the regulation (GDPR Article 5(1)(e), CCPA, UK GDPR). Disposal happens at the lower bound.^9,10

Customer or engagement end

The customer relationship ends or the engagement closes. The retention obligation does not end with the engagement; the records remain audit-relevant for the framework window. The policy names whether records hand over, retain in place, or dispose selectively at engagement close.

CISA KEV-driven retrospective

A vulnerability is added to the CISA Known Exploited Vulnerabilities catalogue and the team needs to retrospectively confirm whether a past scan covered the affected service. Retention has to extend far enough back for the lookup to succeed; programmes that purge scan executions on 30-day windows often cannot answer the retrospective.¹¹

How compliance frameworks read scan retention

Auditors do not read retention as a duration claim on a policy document. They read retention as the count of records inside the audit observation period and the evidence that the records survived through the assessor review. The framework expectations below set the floor; programmes justify higher retention on a risk basis when assets warrant it.

PCI DSS v4.0 Requirement 10.5.1 expects audit log history to be retained for at least 12 months, with at least the most recent three months immediately available. Requirement 11.3 requires internal and external scans at least quarterly and after significant change; the evidence has to show the scans operated across the audit window, which depends on retention spanning the window.¹
ISO 27001:2022 Annex A 5.33 (records protection) expects records to be protected from loss, destruction, falsification, unauthorised access, and unauthorised release for the period justified by legal, regulatory, contractual, and business requirements.²
ISO 27001:2022 Annex A 8.10 (information deletion) expects information to be deleted when no longer required, in accordance with the retention policy and applicable regulations. Disposal is a controlled activity, not a passive expiration of storage.³
ISO 27001:2022 Annex A 8.15 (logging) expects event logs to be produced, stored, protected, and analysed. The standard does not name a single retention period; the period is justified against the risk assessment and the wider records policy.⁴
SOC 2 Trust Services Criteria CC7.1expects ongoing detection of new vulnerabilities. The audit observation period is typically 6 to 12 months, and retention has to span the period plus the assessor review window.⁵
NIST SP 800-53 control AU-11 (audit record retention) expects retention defined by mission, regulatory, and operational requirements. Control SI-12 (information management and retention) extends the retention discipline to organisational records more broadly.⁶
NIST SP 800-92 (computer security log management) names the operational drivers for retention: incident detection, forensic analysis, regulatory compliance, internal investigation, and trend analysis. Retention duration is the lowest common denominator across the drivers.⁷

The shared pattern across these frameworks is that retention is operational, not ceremonial. A retention policy that names a duration and produces no evidence the records persisted across the window satisfies the documentation bar and fails the operating-effectiveness bar. Programmes that retain records on the live engagement and produce evidence as a side effect of operation pass the audit read; programmes that backfill at audit week pass on date stamp and fail on retention operation.

Disposal as a controlled activity

Disposal is the deliberate end of retention and the deletion of records that are no longer required. Three rules govern disposal: it happens against a documented schedule, not by accident or storage pressure; it does not delete records under legal hold; and it is recorded as an event so the audit trail shows the disposal happened against the schedule rather than as data loss.

Documented schedule

The disposal schedule names the artefact class, the retention period, the trigger event, and the disposal method. Disposal that runs without a schedule produces evidence the assessor reads as data loss rather than as policy operation.

Disposal method

The method is named in the policy and follows the framework guidance. NIST SP 800-88 covers media sanitisation patterns (clear, purge, destroy) for storage that holds the records. For database-resident records, secure deletion through the storage layer plus cryptographic erasure of any stored secrets is the defensible pattern.¹²

Legal hold

A hold is recorded on the affected scope (workspace, engagement, finding, target). Disposal stops for that scope until the hold is released. The hold record names who placed the hold, the date, the reason class (litigation, regulatory inquiry, incident response), and the release condition.

Disposal record

Each disposal event is recorded with the artefact class, the count, the date, the schedule rule that triggered it, and the user or system actor. The record is the evidence the policy operated; absence of a disposal record is read as either non-compliance with the policy or data loss.

Retention and privacy regulations

Scan output can include personal data when authenticated scans capture session details, when external scans pick up personal information in metadata or content, or when finding evidence captures end-user data inadvertently. Privacy regulations layer retention obligations on top of security retention.

GDPR Article 5(1)(e) (storage limitation) requires personal data to be retained no longer than necessary for the purpose; the scan retention period for personal data has to be justified against the security purpose and reviewed when the purpose changes.⁹
UK GDPR storage limitation follows the same principle, with the UK Information Commissioner expecting documented justification for the retention period and a review cycle.¹⁰
Subject access and deletion requests can reach scan artefacts. The retention model has to be searchable so a deletion request can identify and dispose the relevant records inside the regulatory response window.
Sensitive data classes (health, financial, government identifiers) carry stricter retention rules under sector regulation. HIPAA, PCI DSS, and sector-specific regulators set retention windows that override the general rule for the data classes they cover.

Three operational practices keep scan retention compatible with privacy regulation. Minimise capture: configure the scanner so personal data is not collected unless the test requires it. Redact at capture: scrub personal data in finding evidence at the point of creation rather than at retention close. Document the retention period and the justification per artefact class so subject access and deletion requests can be answered against the same record the security retention operates on.

Operational checklist for a defensible scan retention policy

At policy design

The policy names artefact classes, retention durations, triggers, disposal methods, and disposal records.
Retention is justified against the framework floors that apply to each artefact class.
Privacy retention bounds are layered on top of security retention bounds.
Legal hold procedures, roles, and release conditions are documented.
The policy names the data owner, retention administrator, and audit liaison.

At scan creation and execution

The scan configuration minimises personal data capture where the test does not require it.
Findings are written to the engagement record so the lifecycle is auditable.
Activity log entries record the scan execution with timestamp and actor.
Sensitive evidence (request bodies, screenshots) is scoped to the finding it supports rather than retained as standalone artefacts.

During the retention window

Records are protected by access controls scoped to the roles that need them.
Audit observation periods are tracked so records are not disposed during a sampling window.
Legal holds pause disposal on the affected scope and the hold record persists.
Subject access and deletion requests are served against the same record the audit reads.

At disposal

Disposal runs against the documented schedule, not against storage pressure.
Disposal events are recorded with artefact class, count, date, and triggering rule.
Disposal does not touch records under legal hold, including dependent records (a finding under hold blocks disposal of the supporting scan executions).
The disposal method follows the policy and the framework guidance for the storage tier.

For internal security and vulnerability management teams

Internal security teams and vulnerability management teams operate retention as part of continuous monitoring, not as an annual policy refresh. The disciplines that hold up under audit and under remediation pressure are the same: per-artefact retention, trigger-based overrides on top, legal hold as a first-class lifecycle state, and disposal as a controlled activity recorded in the same audit trail the operations run on.

Set retention per artefact class rather than as a blanket policy across all scan output.
Wire the retention schedule into the storage layer so disposal is automatic and recorded, not manual at audit week.
Hold the chain-of-custody record (creation, modification, closure, disposal) on the same activity log the operators read.
Track legal hold as a state on the affected scope so disposal jobs honour it without manual intervention.
Review the retention policy whenever a framework, regulation, or business obligation changes the floor.

For internal security teams, vulnerability management teams, AppSec teams, and GRC and compliance teams, the operating commitment is to keep retention visible on the same record the audit reads, with disposal recorded as a controlled event rather than as a storage housekeeping job. The audit evidence half-life research covers how retention duration interacts with evidence quality across the audit observation window, and the audit evidence retention and disposal workflow covers the broader retention discipline that scan evidence is one input into.

How SecPortal handles scan evidence retention and governance

SecPortal retains scan executions and code scan executions with a configurable retention window, retains findings independently of scan execution lifetime, and records every state change in the activity log so the chain of custody persists through retention and disposal.

Scan execution retention

Scan executions, scan jobs, and code scan executions are retained for the window set by the `SCAN_RETENTION_DAYS` environment variable (default 90 days). A weekly cron (Sunday 04:00 UTC) runs the `purge-old-scans` job, which deletes completed and failed records older than the cutoff. The schedule is documented and operates automatically rather than as a manual task. The external scanning feature, authenticated scanning feature, and code scanning feature cover the scan classes that fall under the retention window.

Findings persist through scan execution disposal

Findings are retained independently of scan execution retention. Closing or purging a scan execution does not remove the findings derived from it; the lifecycle record remains intact through closure and audit. The findings management feature holds the finding lifecycle, evidence, and closure record.

Activity log retention by plan

The activity log records every finding, engagement, scan, document, comment, invoice, and team change with a timestamp and acting user. Retention is plan-based: 30 days on Starter, 90 days on Pro, 365 days on Team. A daily cron (03:00 UTC) runs the `cleanup-activities` job, which removes activity records older than the workspace plan retention. The activity log feature covers the chain-of-custody record auditors read.

Compliance tracking maps retained evidence

Compliance tracking maps findings and controls to ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST so the retained evidence aligns to the framework view assessors read. The compliance tracking feature covers the framework crosswalks the retained record feeds.

Storage controls during retention

Encrypted credential storage uses AES-256-GCM, MFA enforcement promotes sessions to AAL2 before sensitive operations, and RBAC scopes access to the retention actions per role. The encrypted credential storage feature and multi-factor authentication feature bracket the retention model so records are protected during the window.

The schedule, the runs, and the disposal events land on the same record the operators run on, so the audit view reads from the live record rather than from a backfilled evidence pack. The continuous monitoring feature covers the schedule cadence the retention model bookends.

Related scanner discipline

Retention depends on the upstream and downstream disciplines that bracket it. The pages below cover the surrounding decisions.

Scan scheduling and baseline cadence covers the cadence the retention window has to span end to end.
Scan baseline and trend comparison covers how the retained scan record feeds the multi-cycle trend leadership and audit read across the observation window.
Scanner output deduplication covers the upstream merge discipline that keeps the retained record clean across scans and tools.
Scanner coverage and limits covers what each scanner class can and cannot reach so retained evidence does not imply coverage that did not happen.
Scanner output formats covers the formats retained evidence can be exported in for handover, audit, or legal hold.
Scanner credential rotation and lifecycle covers the credential lifecycle that is retained alongside the scan record so the credential state at scan time is reproducible.
Scanner evidence chain from scan execution to closed finding covers the seven evidence layers retention preserves end to end so the audit read of any closed finding traces back to the scan that produced it.
Audit evidence retention and disposal workflow covers the broader audit retention discipline that scan evidence is one input into.
Audit evidence retention policy template covers the policy framework retention is documented under.
Audit evidence tracker covers the tracking artefact retained evidence is logged in.
Cybersecurity risk assessment guide covers the risk view that retention duration is justified against.

For the wider operating model retention plugs into, the audit evidence half-life research covers how evidence ages between assessments, and the continuous control monitoring cadence research covers how the cadence and retention combine to produce the operating-effectiveness evidence auditors read.

Scope and limitations of this guide

Scan evidence retention is a programme discipline, not a configuration setting. No retention duration makes the underlying scan output more useful than it was at capture; no disposal schedule replaces the access controls that protect the records during retention. The retention question is which artefacts are worth keeping, for how long, and under what conditions disposal is allowed. The answer is per artefact class, per framework floor, per privacy obligation, and per legal hold state.

Retention claims that depend on a single duration almost always overstate the uniformity of the data inside the scan output. Retention claims that decompose by artefact, that pair the schedule with documented disposal, that hold legal hold as a first-class lifecycle state, and that record the disposal events on the same activity log the operations run on are the claims that survive the audit and the privacy review.

Frequently Asked Questions

Sources

Run retention on the live engagement record, not on a quarterly spreadsheet

SecPortal retains scan executions on a configurable cadence, retains findings through closure and audit, records every state change on the activity log, and maps the retained evidence to the framework view auditors read so retention operates as evidence rather than as a stack of static reports.

Start free See activity log