What is scanner output replay from archived inputs?

Scanner output replay from archived inputs is the scanner-side discipline that preserves the inputs of a recorded scan execution so the analysis the original scan produced can be reproduced at any later point in time. The leadership question "the November scan said this host had a critical SQL injection, the recurring scan in February did not, prove which call is right" only resolves cleanly when the November scan inputs (the target, the credential context, the module set, the rule pack version, the scope policy) and the November scan outputs (the per-module results, the per-finding rows, the per-finding evidence) are both preserved as a coherent record. The audit question "show me how this false-positive call was reached" only resolves cleanly when the original detection inputs are still on file. The reproducibility discipline is not a separate copy of the scan; it is a read on the structured per-execution and per-job records the scanner output writes once at scan time. This guide covers what those records have to look like for the replay surface to answer the rebuttal, audit, and forensic questions defensibly.

How is replay different from baseline and trend comparison?

Baseline and trend comparison reads cycle-to-cycle metric movement: how the open-finding count, the median age, and the severity mix moved across the last N cycles. The metric surface lives above the per-finding identity and answers programme-shape questions. Replay reads the per-execution input substrate and reproduces the per-finding output an individual prior scan produced. Replay sits underneath the baseline-and-trend metrics and answers reproducibility questions about how a single point on the trend line was reached. The two disciplines compose: a baseline-and-trend surface that shows a sudden November-to-February drop in open critical findings is one question; a replay against the November inputs that confirms the November critical was correctly detected against the rule pack in effect at that moment is a different question. Programmes that conflate the two end up either re-scanning live targets to investigate metric movement (which changes the substrate) or treating baseline drift as evidence of detection failure (which mistakes operating-state change for analysis error).

How is replay different from chain of custody and attestation?

Chain of custody and attestation make a recorded scan execution verifiable as unchanged after the fact. The discipline produces three required artefacts: a canonical record of the scan execution, a tamper-evidence anchor that lets a reader confirm the record was not modified, and a verification procedure that operates the check. Replay sits on top of chain of custody and reads the canonical record to reproduce the analysis. The two disciplines are complementary: chain of custody answers "was this scan record unchanged since the original execution"; replay answers "given the unchanged scan record, can the analysis be reproduced from the inputs that were captured". A workspace whose chain of custody is sound but whose payload retention is shallow cannot replay even though the attestation is intact. A workspace whose payload retention is deep but whose chain of custody is loose can replay but cannot prove the inputs are unchanged. The defensible programme runs both disciplines and reads each at the correct point in the audit conversation.

What inputs actually have to be preserved for a defensible replay?

Seven input classes carry the replay load. The target identity records the canonical asset reference the scan ran against (the verified domain, the connected repository, the authenticated target URL), so the replay binds the prior analysis to the same asset register entry the recall surface reads against. The credential context records which encrypted credential the scan used (the credential identifier, not the secret material itself), so the replay reads the authentication context against the credential lifecycle history. The module set records which scanner modules were enabled for the scan and which completed against which targets, so the replay reproduces the coverage profile the original scan had rather than a current coverage profile. The rule pack version records which scanner rule version was in effect at the scan moment, so the replay reproduces the per-finding detection against the rules that wrote the finding rather than against current rules that may have been retuned. The scope policy records the blocklist and allowlist state at the scan moment, so the replay reads the scope against the policy in effect at the time. The per-job payload records the input each scanner module received (the target list, the authentication payload, the rate-limit envelope), so the replay reproduces what the module was asked to run against. The per-job result records the output each scanner module produced (the raw response summary, the detection signal, the evidence section), so the replay reads the original output rather than a regenerated current output. A workspace whose recorded execution preserves all seven input classes can answer the rebuttal, audit, and forensic questions from one record; a workspace that preserves only the per-finding outputs has to reconstruct most of the substrate from chat logs and operator memory.

How long should the replay substrate be retained?

Replay retention horizons are read against three audiences. The operational audience reads replay across recent cycles to support false-positive rebuttal, re-tuning decisions, and developer pushback within the active backlog window. The retention horizon for this audience is typically 90 to 180 days; the operational replay reads have to live long enough to cover the active SLA conversation and the rebuttal lifecycle. The audit audience reads replay across the audit reporting window plus the look-back the framework requires; ISO 27001 internal and external audits typically read 12 months of evidence, SOC 2 Type II reads 12 months, PCI DSS reads 12 months for in-scope evidence, and DORA reads up to 15 months for ICT-related incident evidence. The retention horizon for this audience is typically 12 to 24 months and is bounded by the framework reading the workspace is built against. The forensic audience reads replay after a confirmed incident to reconstruct what the scanner programme knew and when. The retention horizon for this audience is typically 12 to 36 months and is bounded by the longer of the regulatory notification window and the incident investigation window. A defensible retention policy reads the three audiences against the operating cost of storing the substrate and sets a single retention horizon (often 24 months) that covers the longest read; programmes that try to read across all three audiences against ad-hoc retention policies end up either storing forever (operating-cost burden) or dropping the substrate before the audit reading window closes (audit failure mode).

How does replay support false-positive rebuttal and developer pushback?

False-positive rebuttal is the most common trigger for replay. A developer pushes back on a finding that says the application is exposed to a specific weakness; the rebuttal asks for the inputs that produced the finding so the development team can verify the detection independently. Replay reads the per-job payload (which payload did the scanner module send), the per-job result (what response did the scanner module observe), and the per-finding evidence (which detection signal triggered the rule). The development team reads the inputs against the application code and either confirms the detection (the finding stands) or identifies a mismatch between the input context and the live application context that makes the detection a false positive in the live context. The false-positive override the workspace then records reads against the same replay substrate the rebuttal conversation operated against, so the audit trail of the override (cited reason, named approver, scope, hard expiry) lands on the same recorded execution rather than as a separate analyst note. Programmes that cannot replay end up either accepting the developer pushback without verification (which weakens the finding catalogue) or re-scanning the live target (which mixes operating-state change with the rebuttal evidence). The defensible pattern records the rebuttal against the original replay substrate and the override against the same record.

How does replay support post-incident forensic reconstruction?

Post-incident forensic reconstruction runs after a confirmed incident and asks what the scanner programme detected before the incident moment and whether the detection was acted on. The investigator picks the incident date and asks "of the scan executions that ran against this asset in the 90 days before the incident, what was the finding catalogue, what was the open backlog, what overrides were in effect, what scan modules ran, what scan modules were missing, what credential lifecycle events landed in the window, and what rule pack versions were in effect". Replay reproduces each scan execution against the inputs captured at that moment; the activity log reads the per-finding decisions in the pre-incident window; the override register reads which suppressions or accepted-risk overrides were in effect. The investigator reads the combined record to determine whether the incident was visible to the scanner programme, whether the detection was missed, whether the detection was correctly recorded but operationally deferred, and whether the suppression of a related finding contributed to the missed signal. The post-incident reading is one of the harder audit-grade reconstructions and is bounded by the depth of the replay substrate.

How should imported third-party scanner output enter the replay surface?

Imported findings from Nessus, Burp Suite, CSV exports of CSPM tools, container scanner exports, and manual entry from consultancy deliverables enter the replay surface through the same per-execution and per-job record shape the native scanner output writes. The import workflow records the source-emitted artefact (the original Nessus .nessus file, the Burp Suite issue export, the CSPM CSV, the consultancy report file) against the document management surface so the audit chain reads the original third-party output alongside the workspace-translated per-finding rows. The import workflow records the import event itself (the importing actor, the timestamp, the source identifier, the row count, the resolution rules) against the activity log so the audit trail reads how the third-party output entered the workspace. Replay against imported findings reads the source artefact for the original detection inputs and the activity log for how the workspace translated them; the workspace cannot re-execute the third-party scanner against the original target because that capability lives in the third-party tool, but the workspace can reproduce the per-finding identity that the import created and the override decisions that have landed since. The honest scope is that replay for imported output reads the preserved source artefact rather than re-running the imported tool itself.

What failure modes break the replay surface?

Six failure modes cover most of what surfaces at fieldwork as a scan history the team cannot reproduce. Shallow payload retention where the per-job payload is dropped after a short retention horizon prevents the replay from reading what the module was asked to run against. Per-execution rule pack drift where the scanner rule version at the prior scan moment is not recorded prevents the replay from reproducing the original detection against the rules that wrote the finding. Per-execution credential lifecycle drift where the credential identifier on the scan execution rotates after the scan is recorded but the prior credential identifier is not preserved makes the replay read against a credential context the original scan did not actually run against. Per-execution scope policy drift where the blocklist or allowlist changes after the scan is recorded but the prior policy is not preserved makes the replay read against a scope the original scan did not operate against. Imported third-party source artefact loss where the original Nessus, Burp Suite, or CSV file is dropped after the import event prevents replay against imported findings entirely. Re-scan-as-replay confusion where the operational pattern is to re-execute a live scan in place of replay mixes operating-state change with the prior analysis and undermines the audit chain. The defensible programme structures the per-execution record to capture each input class deterministically and treats the replay substrate as evidence rather than as cache.

How does SecPortal support scanner output replay from archived inputs?

SecPortal stores each scan execution as a scan_executions row that records the target, the scan type and category, the credential identifier, the module set (modules_total and modules_completed), the initiating user, the start and completion timestamps, and the result_summary. Each scanner module within the execution writes a scan_jobs row that records the module name, the per-job payload (the input the module received), the per-job result (the output the module produced), the attempt count, the start and completion timestamps, and any per-job error. Each finding produced from a scan job is linked to its parent execution and carries the workspace identifier, the engagement identifier, the template identifier, the title, the category, the affected asset reference, the severity band, the CVSS vector, the control reference, and the evidence section. Each credential is stored AES-256-GCM encrypted with the credential identifier (not the secret material) recorded on the scan execution, so the replay reads the credential lifecycle history against the recorded identifier. Domain verification records preserve the verified ownership context at scan time so the replay binds the prior analysis to the same asset register entry. Bulk finding import records preserve the source artefact alongside the workspace-translated rows so imported third-party output replays against the original input file. The activity log records every per-finding event with the named actor, the timestamp, and the engagement reference; CSV export of the activity log is available for evidence packaging. Honest scope: SecPortal scan_jobs preserve the per-job payload and the per-job result as structured records, but the platform does not store full raw HTTP request and response transcripts at the wire level for every request the scanner module sent. SecPortal does not currently auto-replay a prior scan against the archived inputs as a synthetic re-execution; the replay discipline reads the preserved per-execution and per-job records to reproduce the analysis the original scan produced rather than executing a synthetic re-run. SecPortal does not ship packaged Nessus, Burp Suite Enterprise, Tenable.io, Qualys, Rapid7 InsightVM, Defender for Cloud, Snyk, Veracode, Checkmarx, GitHub Advanced Security, GitLab Ultimate, or Bitbucket synchronous re-execution connectors. The replay discipline is operated as a workspace pattern against the structured per-execution and per-job records the platform exposes.

How should a programme operate the replay discipline as a recurring activity?

A defensible replay discipline runs on three rhythms. Per-execution: every scan_executions row writes the target, the scan category, the credential identifier, the module set, and the result summary deterministically; every scan_jobs row writes the module name, the per-job payload, the per-job result, and the timing fields; the rule pack version and the scope policy in effect at scan time are captured against the execution record. Per-import: every bulk import preserves the source artefact (the Nessus file, the Burp Suite export, the CSV) against the document management surface, records the import event in the activity log, and binds the imported rows to the source artefact so replay reads the original third-party input rather than only the translated rows. Per-cycle: a quarterly retention review reconciles the per-execution and per-job record retention against the replay policy and against the longest audit reading window the workspace is built against; the review confirms that the substrate has not been pruned inside the active retention horizon and surfaces any retention exceptions that have to be recorded against the activity log. The review decisions are captured in the activity log so the audit reads the replay maintenance as a controlled operating activity rather than as ad-hoc cleanup before fieldwork.

How does the replay surface interact with finding overrides and exception lifecycle?

Finding overrides and the exception lifecycle sit on top of the replay surface. The override decision (false positive, accepted risk, severity adjustment, deferral) is recorded against the per-finding identity that the replay substrate produced; the same workspace plus template plus asset reference match key carries the override across recurring scans, so the override travels with the recurring detection rather than reset on every cycle, and the replay against an earlier scan execution reads the override state in effect at that moment from the activity log timeline. The cohort question "every false-positive override across the workspace in the audit window" reads the override register joined against the replay substrate; the cohort question "reproduce the inputs that supported this false-positive call" reads the override decision back to the prior scan execution that produced the original finding. When the replay substrate is preserved, the override decisions are defensible from one record; when the replay substrate is shallow, the override register lands with cited reasons but without the prior inputs that supported the reason, which weakens the audit conversation. The defensible pattern keeps both layers reading the same per-execution and per-finding records: the replay substrate for input reproduction, the override register for decision history, the activity log for the trace.

← Back to Scanner Information

Scanner guide16 min read

Scanner Output Replay From Archived Inputs

A scan that ran in November is later asked to defend itself: the developer pushes back on a finding, the auditor samples the scan history at a controlled date, the post-incident investigation asks what the scanner programme knew before the incident moment, the vendor rule pack regresses on a known weakness and the team has to confirm which historical detections were correct against which rule version. Each of these conversations needs the original scan to be reproducible from the inputs that were captured at the prior scan moment, not from a re-scan against a live target whose operating state has moved since. The scanner-side replay discipline preserves the per-execution and per-job inputs so the original analysis can be reproduced from one record.

This guide covers the boundary between replay and re-scanning, the seven input classes the replay surface depends on, how the retention horizon reads against operational, audit, and forensic audiences, how false-positive rebuttal and post-incident reconstruction operate against the replay substrate, how imported third-party scanner output enters the replay surface, the six failure modes that break reproducibility, and how ISO 27001, SOC 2, PCI DSS, NIST SP 800-53, NIST CSF 2.0, DORA, and NIS2 read the replay artefact chain at audit fieldwork.

What replay is and what it is not

Replay is a read on the structured per-execution and per-job records the scanner output writes once at scan time. Each scan execution carries the target identity, the scan category, the credential context identifier, the module set, the modules that actually completed, the rule pack version in effect, the scope policy in effect, and the result summary. Each scanner module within the execution writes a per-job record that carries the input payload the module received, the output result the module produced, the attempt count, and the per-job timing fields. The replay surface reproduces the analysis the original scan produced against the inputs that were captured at the original scan moment.

Replay is not re-scanning the live target. A re-scan runs a new scan against the current state of the asset under the current rule pack with the current credential context across the current network path; a re-scan that produces a different result is not evidence that the prior scan was wrong, because the underlying state has moved. Replay holds the substrate fixed at the prior scan moment and reproduces the analysis the rule pack and the credentials in effect at that moment would have produced. The two surfaces are complementary: replay answers the “was the prior call correct given the prior inputs” question; re-scan answers the “what is the current state” question.

Replay is not cycle-to-cycle baseline and trend comparison either. The scan baseline and trend comparison guide covers the metric movement reading that lives above the per-finding identity. Replay sits underneath the trend metrics and answers the reproducibility question for a single point on the trend line.

The seven input classes that carry the replay load

Seven input classes have to be preserved deterministically against each recorded scan execution for the replay surface to be defensible. Each one binds the replay to the prior scan moment; missing any class forces the replay reader to reconstruct from chat logs or to re-execute against the live target.

Input class	What it preserves	What replay reads it for
Target identity	Canonical asset reference the scan ran against (verified domain, connected repository, authenticated target URL).	Binding the prior analysis to the same asset register entry the recall surface reads.
Credential context	Encrypted credential identifier in effect at scan time (not the secret material itself).	Reading the authentication context against the credential lifecycle history.
Module set	Scanner modules enabled (modules_total) and modules that completed (modules_completed).	Reproducing the coverage profile the original scan had rather than a current coverage profile.
Rule pack version	Scanner rule version in effect at scan time.	Reproducing per-finding detection against the rules that wrote the finding rather than against current rules that may have been retuned.
Scope policy	Blocklist and allowlist state at scan time.	Reading the scope against the policy in effect at the time rather than against current policy.
Per-job payload	Structured input each scanner module received (target list, authentication payload, rate-limit envelope).	Reproducing what each module was asked to run against, on a per-job basis.
Per-job result	Structured output each scanner module produced (detection signal, evidence summary, per-job error).	Reading the original output rather than a regenerated current output.

A workspace whose recorded execution preserves all seven input classes can answer the rebuttal, audit, and forensic questions from one record. A workspace that preserves only the per-finding outputs has to reconstruct most of the substrate from chat logs and operator memory, and ends up re-scanning live targets in place of replay, which mixes operating-state change with the prior analysis.

How the retention horizon reads against three audiences

Replay retention is not a single number; it is the longest of three readings the workspace has to support. Each audience reads the substrate for a different question and at a different cadence, and the policy that bounds retention has to cover the longest read.

Operational audience

Reads replay across recent cycles to support false-positive rebuttal, detection tuning, and developer pushback inside the active backlog window.

Typical horizon: 90 to 180 days

Audit audience

Reads replay across the audit reporting window plus the look-back the framework requires. ISO 27001 internal and external audits read 12 months; SOC 2 Type II reads 12 months; PCI DSS reads 12 months for in-scope evidence; DORA reads up to 15 months for ICT-related incident evidence.

Typical horizon: 12 to 24 months

Forensic audience

Reads replay after a confirmed incident to reconstruct what the scanner programme detected and when. Bounded by the longer of the regulatory notification window and the incident investigation window.

Typical horizon: 12 to 36 months

A defensible retention policy reads the three audiences against the operating cost of storing the substrate and sets one retention horizon (often 24 months) that covers the longest read. Programmes that try to read across all three audiences against ad-hoc retention either store forever (operating-cost burden) or drop the substrate before the audit reading window closes (audit failure mode). The retention horizon decision is captured in the replay policy and reconciled against the longest audit reading window the workspace is built to support. For the governance side of retention and disposal, the scan evidence retention and governance guide covers the operating discipline that bounds how long the substrate stays available and how disposal is authorised.

Replay scenarios that the discipline has to support

Six scenarios cover most of what triggers a replay read in practice. Each one reads a different combination of inputs and outputs and each one has to land on the same per-execution and per-job record rather than on a re-scan of the live target.

1. False-positive rebuttal and developer pushback

Most common trigger. A developer pushes back on a finding; the rebuttal reads the per-job payload, the per-job result, and the per-finding evidence to verify the detection independently. The false-positive override the workspace then records lands against the same replay substrate the rebuttal operated against, so the cited reason and the named approver are tied to the inputs that produced the finding.

2. Audit-fieldwork reconstruction

The auditor samples the scan history at a controlled date and asks the workspace to reproduce the scan that ran against a specific target. Replay reproduces the inputs and outputs; the activity log reads the per-finding events from creation through closure; the override register reads any false-positive or accepted-risk decisions in effect at the sampled date.

3. Post-incident forensic reconstruction

After a confirmed incident, the investigator reads the scan executions that ran against the affected asset in the pre-incident window. Replay reproduces each execution against its preserved inputs; the activity log reads the per-finding decisions; the override register reads which suppressions were in effect. The combined record answers whether the incident was visible to the scanner programme.

4. Vendor rule pack regression

A scanner rule pack update regresses on a known weakness or retunes a detection that previously fired. Replay reads the per-execution rule pack version and reproduces historical detections under the prior rule pack to confirm which findings stand under the regressed rule and which require re-detection.

5. Credential lifecycle correlation

A credential rotation event changes the authentication context the recurring scan operates under. Replay reads the credential identifier in effect at the prior scan moment and confirms whether earlier coverage gaps were caused by credential lifecycle drift rather than by application-side changes. For the credential side, the scanner credential rotation and lifecycle guide covers the lifecycle events the replay reads against.

6. Third-party scanner re-analysis

Imported findings from Nessus, Burp Suite, CSPM exports, container scanners, or consultancy deliverables are re-read against the source artefact preserved at import. Replay against imported findings reads the original input file from the document management surface and the activity log for how the workspace translated the rows; the workspace cannot re-execute the third-party scanner against the original target, but it can reproduce the imported per-finding identity from the source file.

Six failure modes that break the replay surface

Six failure modes cover most of what surfaces at fieldwork as a scan history the team cannot reproduce. Each one collapses the replay substrate into a re-scan-as-proxy pattern that does not survive audit scrutiny.

Shallow payload retention

The per-job payload is dropped after a short retention horizon. Replay cannot read what the module was asked to run against, and the rebuttal conversation falls back on chat logs.

Rule pack drift unrecorded

The scanner rule version at the prior scan moment is not recorded against the execution. Replay cannot reproduce the detection against the rules that wrote the finding, and vendor rule pack regressions cannot be confirmed against historical detections.

Credential lifecycle drift unrecorded

The credential identifier on the scan execution rotates after the scan is recorded, but the prior credential identifier is not preserved. Replay reads against a credential context the original scan did not actually run against, which silently changes the authentication state.

Scope policy drift unrecorded

The blocklist or allowlist changes after the scan is recorded, but the prior policy is not preserved against the execution. Replay reads against a scope the original scan did not actually operate against.

Imported source artefact loss

The original Nessus file, Burp Suite export, CSV, or consultancy deliverable is dropped after the import event. Replay against imported findings cannot read the original third-party input, and the workspace can only reproduce the translated rows rather than the source-emitted detection.

Re-scan-as-replay confusion

The operational pattern is to re-execute a live scan in place of replay. The re-scan produces a different result because the underlying state has moved; the rebuttal, audit, and forensic conversations end up reading operating-state change as evidence of analysis error.

How compliance frameworks read the replay artefact chain

Auditors read replay through three artefact classes: the replay policy that bounds which input classes are preserved and at what retention horizon; the replay sample that the auditor reproduces at fieldwork; and the replay trace that ties the reproduced execution to the activity log and the override register. The framework readings below cover the controls that most often land on the replay discipline at scoped fieldwork.

Framework	Controls that read replay evidence
ISO 27001:2022	Annex A 8.16 monitoring activities (reproducibility of monitoring events); Annex A 8.15 logging (per-execution record carries controls required for forensic reconstruction); Annex A 8.8 technical vulnerability management (recurring detection reproducibility).
SOC 2 (TSC 2017)	CC7.2 system operations (detection events reproducible against operating substrate); CC7.3 incident communication (incident-related detections reconstructable); CC4.1 monitoring of controls (control monitoring evidence reproducible).
PCI DSS v4.0	Requirement 10 (audit log capture across the cardholder data environment); Requirement 11.4 (vulnerability scanning evidence preserved for the in-scope reporting window); Requirement 12.10 (incident response procedure reads reproducible detection history).
NIST SP 800-53 r5	SI-4 information system monitoring (monitoring events carry sufficient input substrate); AU-2 audit events (event records reproducible); AU-12 audit record generation (per-execution audit record preserved); SI-2 flaw remediation (flaw detection reproducible across cycles).
NIST CSF 2.0	DE.AE adverse event analysis (detection events analytically reproducible); DE.CM continuous monitoring (continuous detection records preserved); RS.AN response analysis (incident response reads reproducible pre-incident detection history).
DORA	Article 17 ICT-related incident management (incident response reads preserved pre-incident detection substrate); Article 9 protection and prevention (detection evidence reproducible across operational events).
NIS2	Article 21 risk management measures (detection records preserved as part of risk-management evidence); Article 23 incident reporting (incident evidence chain reads reproducible detection history).

How SecPortal supports the replay discipline

SecPortal stores each scan execution as a scan_executions row that records the target, the scan type and category, the credential identifier (encrypted credential material is stored separately under AES-256-GCM), the module set as modules_total and modules_completed arrays, the initiating user, the start and completion timestamps, and a structured result_summary. Each scanner module within the execution writes a scan_jobs row that records the module name, the per-job payload (the input the module received), the per-job result (the output the module produced), the attempt count, the start and completion timestamps, and any per-job error. The platform exposes these records as the replay substrate the discipline operates against.

Per-execution and per-job record retention

The scan_executions and scan_jobs rows are preserved against the workspace and are available to the workspace as the replay substrate. The external scanning feature covers the 16-module external execution surface; the authenticated scanning feature covers the 17-module authenticated execution surface; the code scanning feature covers Semgrep-based code scan execution against connected repositories.

Credential identifier preserved against the execution

Credentials are stored AES-256-GCM encrypted with the credential identifier (not the secret material) recorded on the scan execution. The credential lifecycle is read against the recorded identifier so the replay can reproduce the authentication context the original scan operated under. The encrypted credential storage feature covers the credential surface.

Imported third-party source artefact retention

Bulk finding import records preserve the source artefact (the Nessus file, the Burp Suite export, the CSV, the consultancy deliverable) against the document management surface alongside the workspace-translated per-finding rows; the import event itself is captured in the activity log with the importing actor, the timestamp, and the source identifier. The bulk finding import feature covers the import surface; the third-party scanner results import guide covers the wider intake discipline replay reads against.

Activity log carries the replay trace

The activity log records every per-finding event (creation, assignment, status change, severity adjustment, override, comment, retest) with the named actor, the timestamp, and the engagement reference. The replay trace at audit fieldwork reads the activity log against the per-execution and per-job records to reproduce how each finding in the replay sample was created, decided, and closed. CSV export is available for evidence packaging. The activity log feature covers the audit trail mechanism.

Overrides travel with the replay substrate

False-positive overrides, accepted-risk decisions, severity adjustments, and deferrals are keyed to the same workspace plus template plus asset reference match key as the recurring detection identity. The override travels with the recurring detection across cycles, and a replay against an earlier scan execution reads the override state in effect at that moment from the activity log timeline. The finding overrides feature covers the override mechanism that reads against the replay substrate.

Honest scope: SecPortal scan_jobs preserve the per-job payload and the per-job result as structured records, but the platform does not store full raw HTTP request and response transcripts at the wire level for every request the scanner module sent. SecPortal does not currently auto-replay a prior scan against the archived inputs as a synthetic re-execution; the replay discipline reads the preserved per-execution and per-job records to reproduce the analysis the original scan produced rather than executing a synthetic re-run. SecPortal does not ship packaged Nessus, Burp Suite Enterprise, Tenable.io, Qualys VMDR, Rapid7 InsightVM, Defender for Cloud, Snyk, Veracode, Checkmarx, GitHub Advanced Security, GitLab Ultimate, or Bitbucket synchronous re-execution connectors. SecPortal does not synchronously push the replay substrate to ticketing systems through packaged Jira, ServiceNow, Slack, PagerDuty, or Opsgenie connectors. The replay discipline is operated as a workspace pattern against the structured per-execution and per-job records the platform exposes; the replay surface itself is constructed at query time from those records rather than as a separate index that has to be kept in sync.

An operational checklist

When designing the scanner execution record

The execution row records the target, scan category, credential identifier, module set, scope policy, and rule pack version at scan time as deterministic fields rather than as free-text notes.
The per-job row records the module name, the per-job payload, the per-job result, the attempt count, and the per-job timing; the payload and result fields carry structured records the replay reader can parse.
The credential identifier on the execution binds to the credential lifecycle history through the credential register; rotation events are recorded against the credential identifier and read at replay time.
The rule pack version is captured against the execution at scan time and is preserved alongside the per-job rows so replay can reproduce the detection against the rules that wrote the finding.

When importing third-party scanner output

The source artefact (original Nessus file, Burp Suite export, CSV, consultancy deliverable) is preserved against the document management surface alongside the workspace-translated rows; the source artefact is the replay substrate for imported findings.
The import event is captured in the activity log with the importing actor, the timestamp, the source identifier, and the row count; the audit trail reads the import event alongside the source artefact.
The workspace-translated per-finding rows carry the vendor-native identifier (Burp Suite issue id, Nessus plugin id, vendor finding id) on the evidence section so the source-to-workspace mapping is reproducible.

At replay-read time

The replay reader picks the scan execution by execution id or by target plus date; the per-execution record carries the seven input classes plus the per-job rows; the activity log reads the per-finding decisions in the same window.
The replay sample reads the inputs and outputs as one record; the rebuttal, audit, or forensic conversation lands on the same record rather than on a re-scan of the live target.
The override register is joined against the replay substrate so the cited reason and the named approver read alongside the inputs that produced the original finding.

At replay hygiene review

A quarterly retention review reconciles per-execution and per-job retention against the replay policy and against the longest audit reading window the workspace is built against; the review confirms the substrate has not been pruned inside the active retention horizon.
The review samples recent imported third-party findings against their source artefacts to confirm the artefact resolution still holds after document management changes or template catalogue updates.
The review decisions are captured in the activity log so the audit reads the replay maintenance as a controlled operating activity rather than as ad-hoc cleanup before fieldwork.

Where this fits in the wider scanner evidence chain

Replay sits on top of the per-execution and per-job records that the scanner output writes once at scan time, and underneath the metric, attestation, and recall surfaces the operating programme reads against the substrate. The discipline composes with several adjacent scanner-side disciplines and reads alongside them in the audit conversation.

For the integrity discipline that makes the recorded execution verifiable as unchanged after the fact, the scanner output attestation and chain of custody guide covers the canonical record, tamper-evidence anchor, and verification procedure that replay reads against. For the structural layers from scan to finding to closure, the scanner evidence chain from scan to finding guide covers the layered evidence the replay reader walks through.

For the operating discipline that bounds how long the substrate stays available and how disposal is authorised, the scan evidence retention and governance guide covers the retention policy framework. For the metric surface that reads the substrate at the programme-shape level rather than at the per-execution level, the scan baseline and trend comparison guide covers cycle-to-cycle metric movement.

For the recall surface that reads the per-finding identity across engagements, the scanner finding cross-engagement search and recall guide covers the per-finding fields the recall surface depends on. For the workflow side that operates retesting against the replay substrate, the retesting workflows feature covers the per-finding retest mechanism that pairs to the original finding the replay substrate produced.

Scope and limitations

Replay only works when the per-execution and per-job records are preserved with all seven input classes intact. Programmes that store findings in spreadsheets, in scanner UIs that overwrite per-job records on rule pack updates, or in workflow tools without per-job payload retention cannot operate the replay surface at all. The leverage point is consolidating scan executions into a workspace with structured per-execution and per-job retention before attempting to govern replay.

SecPortal scan_jobs preserve the per-job payload and the per-job result as structured records, but the platform does not store full raw HTTP request and response transcripts at the wire level for every request the scanner module sent. Programmes that need wire-level transcript replay currently operate that capability outside the platform (typically through a packet capture or HTTP intercepting proxy alongside the scanner) and attach the transcript artefact to the finding using document management so the audit chain stays in one record. SecPortal does not currently auto-replay a prior scan against the archived inputs as a synthetic re-execution; the replay discipline reads the preserved per-execution and per-job records to reproduce the analysis the original scan produced rather than executing a synthetic re-run.

For the operating economics of how replay reads pair with deduplication and merge economics that govern finding inflow hygiene, the security finding deduplication economics research covers the per-target carrying cost analysis the replay reader sees alongside the substrate. For the broader analytical view of how recurring detections move through the finding state machine, the vulnerability fix verification fidelity research covers the verification economics that read replay alongside retesting.

Frequently Asked Questions

Run scanner replay on a record that survives developer pushback, audit fieldwork, and post-incident review

SecPortal stores every scan execution and every scanner module job as structured records the workspace can read against later. Credentials are referenced by identifier and stored AES-256-GCM encrypted; imported third-party scanner output preserves the source artefact alongside the workspace-translated rows; the activity log captures every per-finding event so the replay trace is reproducible at audit fieldwork without re-scanning live targets.

Start free See the attestation discipline