What is a vulnerability scan baseline?

A baseline is a named scan execution that the team treats as the reference state for a target. Future scans of the same target are read against the baseline as a diff: new findings, fixed findings, unchanged findings, and missing coverage. The baseline is not the most recent scan; it is the scan that represents the agreed-upon known state at a moment the programme commits to as the comparison anchor. Baselines change deliberately when the surface changes (a new release, a new asset added to scope, a remediation cycle that closes a batch of findings) rather than on every scheduled run. A baseline that floats with every cycle gives the diff no signal because every change is its own baseline.

How is a scan diff different from scan trend comparison?

A scan diff is a two-point comparison: one scan against another, producing the new, fixed, unchanged, and dropped categories. A scan trend is a multi-point comparison across a window: the count of open findings per severity at each cycle, the new finding rate per cycle, the fix rate per cycle, the mean time to triage, and the coverage stability across the window. The diff answers what changed since the last scan; the trend answers whether the programme is improving, stable, or regressing across the cycle window. Audits, leadership reviews, and remediation governance read the trend; engineering remediation reads the diff. Programmes that report only the diff to leadership produce noise; programmes that report only the trend miss the cycle-by-cycle regression that needs immediate action.

Why does a finding disappear from one scan to the next without being remediated?

Six causes account for most disappearance events that are not remediation. The first is coverage drop: an authenticated scan loses its session mid-cycle, an external scan times out on a route the prior scan reached, or a code scan does not run a rule pack that the prior cycle did. The second is target removal: the asset has been decommissioned, the route has been removed, or the dependency has been pinned out of scope. The third is environment drift: the target is now behind a control that blocks the scanner (rate-limit, WAF rule change, new authentication wall) and the scanner cannot reach it. The fourth is credential rotation gone wrong: the scanner authenticates partially and a subset of the surface is unauthenticated. The fifth is suppression applied between cycles: a finding has been accepted and is no longer surfaced. The sixth is true remediation. Trend reads that conflate these five non-remediation causes with the remediation count overstate fix throughput and understate coverage risk; the disciplined trend pairs the drop with a coverage record so absence is interpretable.

How often should the baseline be reset?

The baseline is reset on scope change, on a deliberate remediation cycle that closes a batch of findings, on a release that materially changes the surface, or on a programme cadence (typically quarterly or after each surveillance audit). Resetting the baseline on every cycle defeats the trend; resetting on no schedule lets the baseline drift far enough from the current state that the diff loses operational meaning. The defensible pattern is per-target baselines that the team names explicitly, with reset events recorded in the activity trail so the trend window is reproducible across audits and leadership cycles.

What does coverage drift mean and why does it distort trend reporting?

Coverage drift is the difference between what the scanner reached in one cycle and what it reached in another. A scan that runs the same scanner class against the same target on a different day can hit different routes, different authentication states, and different module timeouts. The diff between cycles inherits the coverage delta as a finding delta unless the trend reads the coverage record alongside the finding count. A trend report that shows a finding count drop when coverage also dropped is a coverage event masquerading as remediation throughput. The fix is to attach a coverage signature to each scan execution (modules run, modules skipped, routes reached, authentication state) and to read the trend per coverage band rather than as a single number across cycles.

What trend metrics are worth reporting to security leadership?

Five metrics carry signal at the leadership view without overcounting cycle-to-cycle noise. Open finding count per severity at the cycle close gives the inventory view. New finding rate per cycle shows whether the inflow is stable, accelerating, or compressing after a release. Fix rate per cycle (closures inside the window) shows whether remediation operates at the inflow rate. Mean time to triage and mean time to remediate per severity show the operating tempo of the programme. Coverage stability (the percentage of targets the cycle covered at the same depth as the baseline) shows whether the trend is interpretable. Reporting any one of these in isolation distorts the picture; reporting the five together gives leadership a defensible view that an unexpected movement on any axis can be reconciled against the others.

How does PCI DSS read scan trend evidence?

PCI DSS v4.0 Requirement 11.3 expects internal and external vulnerability scans at least quarterly and after any significant change. The assessor reads the cadence as the count of scans across the audit window and the lifecycle of the findings the scans produced. A trend that shows quarterly scan operation, change-triggered scans after release events, finding triage inside the policy timeline, and remediation closure with retest evidence satisfies the operating-effectiveness bar. A trend that shows only the most recent quarterly scan plus a backfilled inventory at audit week passes the document bar and fails the operating bar. Requirement 11.4 (penetration testing) layers an annual cadence on top, with the pentest record contributing to the trend alongside the scan record. The defensible PCI trend is per requirement, per asset class, across the full audit observation window.

How does ISO 27001 read scan trend evidence?

ISO 27001:2022 Annex A 8.8 (technical vulnerability management) expects a documented cadence justified by the risk assessment, with evidence the cadence operates. The assessor reads the trend through the lens of the ISMS: scans aligned to the risk treatment plan, findings tracked through the change management discipline, and remediation evidence reconciling to the control objectives. Annex A 8.16 (monitoring activities) and 8.15 (logging) require evidence that the trend is observable on the same record the operations run on. ISO 27001 surveillance audits run annually with a recertification audit every three years; the trend window the assessor reads is the full surveillance period, not just the months immediately preceding the audit. A trend report assembled from spreadsheets at audit week is read as document operation, not control operation.

How does the trend interact with risk acceptance and exceptions?

Accepted risks and exceptions sit in the open finding count but should not contribute to the new-finding rate or the fix-rate denominator. A trend that lumps accepted risk with active findings overstates the inventory and understates remediation throughput. The disciplined pattern reports accepted risks as a separate band on the inventory view, tracks expiry dates so the trend captures when an exception lapses back into the active count, and pairs the exception view with the compensating control evidence so the assessor can read the accepted risk as a controlled state rather than as ignored work. The exception trend is its own signal: a programme that accumulates exceptions faster than it closes them has a trend toward unmanaged debt regardless of what the active finding count shows.

← Back to Scanner Information

Scanner guide17 min read

Vulnerability Scan Baseline and Trend Comparison: A Production Guide

A scan baseline is a discipline, not the most recent scan. Programmes that float the baseline with every cycle lose the trend signal. Programmes that hold an outdated baseline lose the diff. The defensible operating model names the baseline per target, resets it on deliberate events, and reads the trend across the window with coverage stability anchored alongside the finding counts so the new and fixed numbers are interpretable rather than noisy.

This guide covers how to define a baseline, how to read the diff between two scans, how to read the trend across many scans, how to separate real change from coverage drift, which trend metrics carry signal for security leadership and audit, and how internal security, AppSec, vulnerability management, and GRC teams operate baseline and trend comparison as a continuous discipline rather than as a quarterly slide deck.

Baseline, diff, and trend are three different artefacts

The vocabulary collapses in many programmes, which is why the reporting collapses too. Each artefact answers a different question and lives on a different cadence.

Artefact	Question it answers	Cadence
Baseline	What is the agreed reference state of the target?	Reset on deliberate events (release, remediation cycle close, scope change, audit boundary).
Diff	What changed between two specific scan executions?	Per scan execution, against the baseline or against the immediately previous scan.
Trend	Is the programme improving, stable, or regressing across the window?	Per cycle window (weekly leadership, monthly programme, quarterly audit, annual surveillance).

Programmes that report only the diff to leadership produce cycle-by-cycle noise and no programme view. Programmes that report only the trend lose the cycle-level regressions that need immediate engineering action. Programmes that float the baseline lose both because every change becomes its own baseline. The discipline is to operate all three on their own cadence and to read each through the audience the cadence serves. The scan scheduling and baseline cadence guide covers the upstream cadence the trend reads from.

Defining a baseline that holds up

A baseline is a named scan execution the team treats as the reference state for a target. The baseline holds until a deliberate event resets it. Five rules keep the baseline operational rather than ceremonial.

Baselines are per target, not per programme

A programme baseline that aggregates across targets hides the per-target movement that drives engineering action. The baseline lives on the engagement record for the target it covers, with the scan execution identifier, the scanner class, the module set that ran, and the date the baseline was committed.

The baseline carries a coverage signature

The baseline records which modules ran, which timed out, which authentication state the scanner reached, and which routes the scanner did not exercise. Without the coverage signature, future diffs against the baseline conflate finding change with coverage change.

Reset events are documented

Baseline resets happen on a defined trigger (release, remediation cycle close, scope change, audit boundary), not on operator preference. Each reset is recorded with the trigger, the prior baseline scan execution, and the new baseline scan execution so the trend window is reproducible across audits.

Suppressed and accepted findings carry forward

The baseline includes the override state for each finding (suppressed false positive, accepted risk with expiry, deferred with compensating control). Without the override state, the next diff resurfaces overrides as new findings and burns triage capacity on settled work.

The baseline is the audit anchor

Audit observation periods read the trend against the baseline that opened the window. A baseline reset inside the audit window is itself an evidence event: what triggered the reset, what closed in the prior baseline, what carried into the new baseline, and how the cumulative remediation reads across the audit period.

Reading the diff between two scans

A two-point diff classifies findings into four buckets and reads each one as a separate question. The bucket counts are not the answer; the rationale per bucket is.

New findings (present in current, absent from baseline)

The current scan reaches a finding the baseline did not. The new finding is triaged as a real new exposure, a regression of a previously fixed item, a finding the baseline missed because of coverage drift, or a finding the baseline missed because the rule pack changed. The triage path is different per cause, which is why the new bucket cannot be reported as a single number to leadership without the cause split.

Fixed findings (present in baseline, absent from current)

The current scan does not reach a finding the baseline did. Fixed is the optimistic read; the disciplined read pairs the absence with the coverage record. If the current scan covered the same routes at the same authentication state, the absence is consistent with remediation. If the coverage dropped, the absence is a coverage event reported as remediation. The fix bucket needs a verification step (a targeted retest) before closure.

Unchanged findings (present in both)

The finding persists across the cycle. Unchanged is the inventory view: the open backlog, the aging cohort, and the items the next remediation cycle picks from. The unchanged bucket is the trend view of debt accumulation; the count, the age distribution, and the severity mix matter more than the individual finding state.

Dropped coverage (modules or routes that ran in baseline, not in current)

The fourth bucket is the one most teams omit. Modules that ran in the baseline and not in the current cycle, routes the baseline reached and the current scan did not, authentication states the baseline tested and the current scan skipped: each is a coverage gap that turns the diff into a partial picture. Reporting dropped coverage as a fifth axis on the diff is what makes the new and fixed counts interpretable.

For the broader discipline behind the dropped coverage axis, the scanner coverage and limits guide covers what each scanner class can and cannot reach. The scanner output deduplication guide covers the merge discipline that keeps the diff comparable across scanner classes.

Five trend metrics that carry signal

Trend reporting that lists every count from every cycle becomes a noise feed. Reporting carries signal when a small set of metrics is paired so an unexpected movement on one axis can be reconciled against the others.

Open finding count per severity at cycle close

The inventory view. Reported per severity (critical, high, medium, low) and separated from accepted risk so the active backlog is distinct from the controlled exception list. The trend reads as inventory growth, stability, or compression across the window.

New finding rate per cycle

The inflow view. New findings per cycle, ideally normalised against the surface size and the cadence so a weekly cycle is not compared raw against a monthly cycle. The inflow trend signals whether releases are introducing new exposure faster than remediation closes it.

Fix rate per cycle

The closure view. Findings closed and verified per cycle, with the verification method recorded (retest, scan absence with coverage check, evidence review). The fix rate paired with the inflow rate is the throughput view; the gap between them is the debt accumulation rate. The vulnerability remediation throughput research covers how the inflow and fix rate combine to set the steady-state backlog size.

Mean time to triage and to remediate per severity

The tempo view. Time from finding creation to triage decision, time from triage to remediation start, and time from remediation start to verified closure. Tracked per severity because the operating SLAs differ. A trend that compresses on triage but extends on closure has a remediation operating problem rather than a triage operating problem; the split is what makes the metric actionable.

Coverage stability across cycles

The interpretation view. The percentage of targets where the cycle covered the same modules, the same routes, and the same authentication state as the baseline. Coverage stability under 90 percent makes the other four metrics noisy; coverage stability under 70 percent makes them uninterpretable. Reporting coverage alongside finding counts is what separates real trend movement from coverage drift dressed up as movement.

Separating real change from coverage drift

The most expensive trend reading mistake is reporting a coverage event as a finding event. Six causes account for most disappearance and apparent-improvement events that are not remediation.

Authenticated session loss mid-cycle

The scanner authenticates at the start of the cycle and the session expires before the scan completes. The unauthenticated tail of the scan reaches a smaller surface than the baseline. The diff reads as findings fixed; the truth is that the authenticated routes were not retested. The scanner authentication failure modes guide covers the patterns that produce this class of drift.

Module timeout or rate-limit on the current cycle

A scan module times out under load or hits a rate limit the prior cycle did not. The module-specific findings disappear from the diff; the cause is module failure, not remediation.

Target removal or scope change

A subdomain, repository, or route is removed from scope between cycles. Findings bound to the removed asset disappear; the disappearance is a scope event recorded separately from remediation throughput.

WAF or rate-limit configuration change

A control that the prior cycle bypassed (allowlisted scanner, exempted source IP) is reconfigured between cycles. The scan reaches less surface than the baseline. The diff reads as remediation; the truth is that scanner traffic is being blocked.

Rule pack version change

A SAST or SCA rule pack updates between cycles. New rules surface findings the baseline could not detect; retired rules drop findings the baseline could. The diff reads as inflow or fix; the cause is rule pack drift, recorded as a separate axis on the trend.

Suppression and acceptance applied between cycles

A finding is suppressed as a confirmed false positive or accepted as a risk with a compensating control. The finding leaves the active count and joins the override count. Reading the diff without the override state shows the finding as fixed; the programme has moved the finding to a controlled state, not closed it.

How compliance frameworks read scan trend

Auditors read trend evidence as the operating-effectiveness view of the technical vulnerability management control. The framework expectations below set the floor; programmes justify higher cadence and broader trend metrics on a risk basis when assets warrant it.

PCI DSS v4.0 Requirement 11.3 expects internal and external scans at least quarterly and after any significant change. The assessor reads the cadence as the count of scans across the audit window and the lifecycle of the findings, which the trend evidences directly.¹
ISO 27001:2022 Annex A 8.8 (technical vulnerability management) expects a documented cadence justified by the risk assessment, with evidence the cadence operates. The trend across the surveillance window is the operating evidence.²
ISO 27001:2022 Annex A 8.16 (monitoring activities) extends the operating evidence expectation to ongoing monitoring, including the trend reads that bracket the technical scan record.³
SOC 2 Trust Services Criteria CC7.1 expects ongoing detection of new vulnerabilities. The audit observation period is typically 6 to 12 months, and the trend across the period is the operating-effectiveness evidence.⁵
NIST SP 800-53 control RA-5 (vulnerability monitoring and scanning) expects scans at the organisationally-defined frequency with results analysed for trends and remediated within the organisationally-defined response time. The trend axis is named explicitly in the control language.⁶

The shared pattern is that retention duration is the floor and trend operation is the evidence. A trend report assembled at audit week from spreadsheets satisfies the documentation bar and fails the operating-effectiveness bar. A trend that reads from the live engagement record across the observation window passes both. The scan evidence retention and governance guide covers the retention discipline the trend window depends on.

Operational checklist for a defensible trend report

At baseline definition

Each in-scope target has a named baseline scan execution.
The baseline records the modules run, the coverage reached, and the authentication state.
Override state (suppression, accepted risk, compensating control) is captured at the baseline.
Reset triggers are documented and the reset events are recorded with the prior and new baseline identifiers.
The audit anchor is the baseline that opens the observation window.

At each scheduled scan

The scan execution records the modules that ran, the modules that timed out, and the routes reached.
The diff against the baseline classifies findings into new, fixed, unchanged, and dropped coverage.
The fix bucket is verified before the trend report includes it as remediation throughput.
Override changes between cycles are recorded separately from finding state changes.
Coverage stability is computed and reported alongside the finding counts.

At trend report assembly

Open finding count per severity is reported separately from accepted risk count.
New finding rate is normalised against cadence and surface size.
Fix rate is paired with the verification method (retest, scan absence with coverage check).
Mean time to triage and to remediate are tracked per severity.
Coverage stability is reported as the interpretation lens for the other four metrics.
Trend movement that exceeds a threshold is reconciled against coverage, scope, and rule-pack changes.

At leadership and audit review

The trend window matches the audience cadence (weekly leadership, monthly programme, quarterly audit, annual surveillance).
Each axis on the trend has a documented data source and a documented refresh cadence.
The trend reads from the live record rather than from a backfilled deck assembled for the meeting.
Baseline reset events inside the window are explained as part of the trend narrative.
Coverage drift events are surfaced as their own item rather than buried in the finding counts.

For internal security, AppSec, and vulnerability management teams

Internal security teams operate trend reading as part of continuous monitoring rather than as a quarterly slide deck. The disciplines that hold up under audit and under remediation pressure are the same: per-target baselines, diff with coverage anchored alongside, trend metrics that pair so an unexpected movement is interpretable, and override state tracked separately from active finding state.

Hold the baseline per target with the coverage signature, not as a single programme baseline.
Read the diff against the baseline rather than against the immediately previous scan when the audit window is open.
Wire the trend report to the live record so leadership reads the same numbers operators read.
Track override state on its own axis so accepted risk and suppression do not pollute the active finding trend.
Report coverage stability alongside finding counts so trend movement is interpretable.

For internal security teams, vulnerability management teams, AppSec teams, and GRC and compliance teams, the operating commitment is to read the trend on the same record the cycle runs on. The security leadership reporting workflow covers how the trend feeds the leadership cadence, and the vulnerability reopen rate research covers the regression class trend reading is built to detect.

How SecPortal handles scan baseline and trend comparison

SecPortal records each scan execution against the verified domain, authenticated target, or connected repository, and persists the metadata, modules run, findings produced, and activity trail entries that bracket the run. The platform supports the baseline, diff, and trend operations on the same record the cycle runs on.

Two-scan diff endpoint

The /api/scans/diff endpoint compares two scan executions for the same target and reports new, fixed, and unchanged findings, with override state (suppression, accepted risk) annotated per finding. The endpoint is the building block trend reports compose; the per-cycle diff is recorded against the baseline, and the aggregate trend is read across the diff history.

Continuous monitoring schedules drive cadence

Scheduled scans run on daily, weekly, biweekly, or monthly cadence against external, authenticated, and code scan targets. The schedule produces the cycle stream the trend window reads from. The continuous monitoring feature covers the schedule mechanics.

Findings persist beyond scan execution retention

Findings persist independently of scan execution retention through the configurable SCAN_RETENTION_DAYS window (default 90 days). The lifecycle record auditors and leadership read survives scan execution disposal, so the trend window is anchored to the durable finding record rather than to the transient scan execution.

Activity log records every state change

The activity log records every finding, scan, comment, document, and team change with timestamp and acting user. CSV export supports leadership and audit review against the trend window. The activity log feature covers the chain-of-custody record the trend reads against.

Compliance tracking maps trend to frameworks

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

The baseline lives on the engagement record, the diff runs against the baseline on every cycle, and the trend reads across the diff history on the same record the operators run on. The findings management feature holds the durable finding lifecycle the trend depends on.

Related scanner discipline

Trend reading depends on the upstream scan cadence, the coverage discipline, and the retention window the trend reads across. The pages below cover the surrounding decisions.

Scan scheduling and baseline cadence covers the cadence the trend reads from cycle to cycle.
Scan evidence retention and governance covers the retention window the trend reads across.
Scanner coverage and limits covers what each scanner class can and cannot reach so coverage drift is interpretable.
Scanner output deduplication covers the merge discipline that keeps the diff comparable across scanner classes.
Scanner authentication failure modes covers the authentication patterns that produce coverage drift dressed up as remediation.
Scanner false positives covers the false-positive discipline trend reads need to keep the override state clean.
Vulnerability backlog management covers the operating discipline the trend movement informs.
Security leadership reporting covers how the trend report feeds the leadership cadence.

For the wider operating model trend reading plugs into, the vulnerability remediation throughput research covers how the inflow and fix rate combine to set the steady-state backlog. The audit evidence half-life research covers how the trend evidence ages between assessments.

Scope and limitations of this guide

Trend reading is a programme discipline, not a chart. No single metric carries the programme view; no single dashboard makes the underlying scan output more useful than it was at capture. The trend question is which metrics pair to make movement interpretable, which baselines anchor the comparison, and which coverage signals keep the diff honest.

Trend claims that depend on a single number across a window almost always overstate the homogeneity of the cycles inside the window. Trend claims that decompose by severity, that pair finding counts with coverage stability, that hold override state on its own axis, and that read from the live engagement record rather than from a backfilled deck are the claims that survive the audit, the leadership review, and the engineering retrospective.

Frequently Asked Questions

Sources

Read the trend on the live engagement record, not on a backfilled deck

SecPortal records every scan execution against the engagement, supports the two-scan diff endpoint as the building block of trend reads, persists findings beyond scan execution retention, and maps the trend to the framework view leadership and auditors read so trend operation is the evidence rather than the slide.

Start free See continuous monitoring