How often should I run vulnerability scans?

There is no single right cadence; the defensible answer is per asset class and per scanner class. External attack surface should be scanned at least monthly, with weekly cadence for assets that change frequently and a one-time scan triggered on every significant change. Authenticated DAST should be scanned at least quarterly with a tighter cadence (monthly or biweekly) on high-value applications, plus an on-change scan after every release that touches authentication, authorisation, or input handling. SAST and SCA should run on every pull request or push to a tracked branch, with a weekly or monthly full scan as a baseline. Compliance frameworks layer their own minimums on top: PCI DSS Requirement 11.3 expects internal and external vulnerability scans at least quarterly and after any significant change. The cadence has to satisfy the strictest requirement that applies to each asset.

What is the PCI DSS scan frequency requirement?

PCI DSS v4.0 sets cadence per requirement rather than as a single rule for the standard. Requirement 11.3 expects internal vulnerability scans at least every three months and after any significant change to the cardholder data environment. External scans must be performed by an Approved Scanning Vendor (ASV) at least every three months, with re-scans after high or critical findings. Daily log review under 10.4, weekly anti-malware checks under 5.3, and annual penetration testing under 11.4 carry their own cadence rules. A scan record that meets the 90-day quarterly bar but lacks the change-triggered scan after a release does not satisfy the requirement; the cadence operates per axis (calendar plus change), not per axis alone.

How is scan cadence different from continuous monitoring?

Scheduled scanning runs the same scan profile against the same target on a recurring interval (daily, weekly, biweekly, monthly) with the goal of producing a comparable baseline at each tick. Continuous monitoring is the wider programme discipline that combines scheduled scans, on-change scans, alerting on regressions, retest workflows for closed findings, and exception tracking for accepted risk. A scheduled scan is one input into continuous monitoring, not the whole programme. Programmes that confuse the two ship a weekly scan and call it continuous monitoring; programmes that operate continuous monitoring read the scheduled scan as one signal alongside change events, threat intelligence, and finding lifecycle state.

When should an on-change scan run instead of waiting for the schedule?

Six change classes warrant a scan ahead of the next scheduled tick. A new asset is added to the in-scope inventory (a new domain, subdomain, repository, or service). An existing asset is significantly modified (architecture change, framework upgrade, authentication or authorisation change, dependency upgrade with security implications). A finding is remediated and needs verification (a retest, not a full re-scan). A new vulnerability is published in a class the scanner has rules for and the asset is plausibly exposed. An exception is approved with a compensating control that needs evidence the control operates. A scope boundary moves so the previous scan no longer covers the in-scope estate. Scheduled cadence handles the steady state; change-triggered cadence handles the events the schedule cannot anticipate.

How should I read the diff between two scans?

A scan baseline is one snapshot. A baseline diff between two scans separates findings into four categories: new findings (present in the later scan, absent from the earlier), fixed findings (present in the earlier scan, absent from the later), unchanged findings (present in both), and removed targets (modules or routes that ran in the earlier scan and not the later). Diff reading is a triage discipline because absence in the later scan is not always a fix; it can be a coverage drop. A finding that disappears because the route is no longer reachable, the module timed out, or the authentication failed silently is not remediation. The defensible read pairs the diff with the scan-coverage record so the new and fixed counts are anchored to the surface that actually ran in each cycle.

How do I avoid scan fatigue from too-frequent scheduling?

Scan fatigue is the failure mode where the team stops triaging output because the volume exceeds the available triage capacity. Three controls keep scheduled scans useful instead of overwhelming. The first is per-target cadence rather than blanket cadence: noisy assets do not need daily scans if their findings stabilise, and stable assets do not need weekly scans if no findings have changed in twelve weeks. The second is suppression with evidence: a confirmed false positive should suppress on the finding identifier so the next scheduled scan does not resurface it as a new finding. The third is diff-led triage: the next scheduled scan opens with the new and changed findings rather than the full output, so the cadence does not turn into a re-triage of every cycle. The fix is operational discipline, not a slower schedule.

How does authenticated scan cadence differ from external scan cadence?

External scans run against publicly reachable surface and tend to be cheap, parallelisable, and low-risk. They can run daily on high-change estates without disturbing the application. Authenticated scans run with valid credentials against the application surface behind login, can produce side effects (creating data, hitting rate limits, triggering rate-aware blocks), and need a stable test environment. The cadence trade-off is execution cost versus regression-detection latency. Most programmes settle on weekly or biweekly authenticated scans on high-value applications, with on-change scans after releases that touch authentication, authorisation, or input handling. The credential lifecycle is part of the cadence: stored credentials should be rotated on a documented interval, and a scan that runs against a stale credential is a coverage failure dressed up as a successful run.

How does SAST and SCA cadence work in CI/CD?

SAST and SCA fit naturally into the pull request and push lifecycle of the source repository rather than a calendar schedule. The standard pattern is: full SAST and SCA on the default branch, incremental SAST on each pull request to surface new findings inline with code review, full weekly or monthly SAST on the default branch as a baseline, and SCA on every dependency change (lockfile diff). The schedule discipline shifts from "when does the scan run" to "what triggers a scan and what does the scan represent". A weekly full scan baseline lets the diff between baselines flag dependencies that picked up CVEs since the last cycle without a code change, which is the regression class continuous build-time scans miss.

How do compliance frameworks read scan cadence evidence?

Auditors read cadence as the pairing of a documented schedule and the evidence the schedule actually operated. PCI DSS 11.3 expects quarterly scans plus change-triggered scans. ISO 27001 Annex A 8.8 expects technical vulnerability management at a documented cadence justified by the risk assessment. SOC 2 CC7.1 expects ongoing detection of new vulnerabilities with evidence the detection operated across the observation period. None of those frameworks accept a single annual scan as quarterly cadence operation; the cadence is read as the count of scans inside the window, not as the recency of the most recent scan. Programmes that operate the cadence in real time 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 cadence operation.

How does SecPortal handle scan scheduling and baseline diff?

SecPortal supports scheduled scans across external, authenticated, and code scan types with daily, weekly, biweekly, and monthly cadence, gated by the continuous monitoring plan feature. Schedules are created against a verified domain (for external and authenticated scans) or a connected GitHub, GitLab, or Bitbucket repository (for code scans). Authenticated schedules require a stored credential that has been encrypted with AES-256-GCM. Each scheduled run produces a scan execution that lands as draft findings on the engagement record. The scan diff endpoint compares two scan executions for the same target and reports new findings, fixed findings, and unchanged findings, annotating each with any override (suppression, accepted risk) the team has applied. The platform records the cadence, the runs, and the diff so the audit conversation can read the cadence operation rather than only the latest scan.

← Back to Scanner Information

Scanner guide15 min read

Vulnerability Scan Scheduling and Baseline Cadence

Scan cadence is two questions, not one, and most programmes answer only the first. The first question is how often a scheduled scan runs against each asset. The second question is how the next scan reads against the previous scan. Programmes that pick a single calendar interval and ship the same output cycle after cycle hit the cadence requirement on paper and miss the regression-detection value the cadence is supposed to deliver. The scan that runs every Tuesday is one signal; the diff between this Tuesday and last Tuesday is the signal that drives remediation.

This guide covers how to set scheduled scan cadence per asset class and per scanner class, when to override the schedule with an on-change scan, how compliance frameworks read cadence evidence (PCI DSS Requirement 11.3, ISO 27001 Annex A 8.8, SOC 2 CC7.1, NIST SP 800-53 RA-5), how to read the diff between two scan baselines, and how internal security, AppSec, vulnerability management, and GRC teams operate cadence as part of continuous monitoring rather than as a calendar artefact.

Cadence is per asset class and per scanner class

Most cadence policies fail by being too uniform. A single weekly schedule across a mixed estate either over-scans the stable assets and burns triage capacity, or under-scans the high-change assets and lets regressions slip past detection. The defensible policy decomposes cadence by asset volatility and scanner class.

Asset class	External scan cadence	Authenticated scan cadence
High-change customer-facing app	Weekly schedule plus on-change scan after every release.	Biweekly schedule plus on-change scan after auth, AuthZ, or input changes.
Internal-facing business app	Monthly schedule plus on-change scan after architecture changes.	Monthly schedule plus on-change scan after release.
Marketing and content sites	Weekly schedule for TLS, headers, DNS, and CDN posture drift.	Quarterly schedule (or out of scope) where there is no real authenticated surface.
PCI in-scope cardholder estate	Quarterly ASV scan minimum plus monthly internal scan plus on-change.	Monthly schedule on application surface plus on-change after release.
Stable internal infrastructure	Monthly to quarterly schedule plus on-change after deployment.	Quarterly schedule where authenticated surface exists.

The same logic applies to source-side scanning. SAST and SCA fit best on the pull request and push lifecycle of the source repository rather than a calendar schedule, with a weekly or monthly full default-branch scan as the regression baseline. The page below covers code-scan cadence in more detail later in the guide.¹⁴

Calendar cadence and change-triggered cadence

Scan cadence has to operate on two axes at once. Calendar cadence answers the steady state question: what does a scan against this asset look like every interval. Change cadence answers the event question: when does an event invalidate the previous scan and require a fresh one ahead of the next scheduled tick. Programmes that watch only the calendar miss the events; programmes that watch only events miss the steady state evidence framework auditors expect.

New asset added to the in-scope inventory

A new domain, subdomain, repository, or service is added to the estate. The previous scan never covered it. The next scheduled scan will pick it up if the inventory is wired into the schedule, but the on-change scan covers the gap between addition and the next tick.

Significant change to an in-scope asset

Architecture, framework version, authentication mechanism, authorisation rules, input handling, or dependency upgrade with security implications all qualify. The previous scan covered an asset that no longer represents the deployed state. PCI DSS Requirement 11.3 names the change-triggered scan as a separate obligation from the quarterly cadence.¹

Finding remediated and verification needed

A retest is a different scan from a full re-scan. The retest verifies the closed finding without re-running the full scope. The full scan still runs at its scheduled interval; the retest runs on the closure event so the finding lifecycle stays auditable.

New vulnerability published in a class the scanner covers

A CVE lands against a service version, library, or framework the scanner has rules for and the asset is plausibly exposed. CISA Binding Operational Directive 22-01 sets the cadence pattern of running against the Known Exploited Vulnerabilities catalogue with bounded remediation windows; the scan that discovers the exposure has to run inside that window, not at the next scheduled tick.^7,8

Compensating control evidence required

An exception is approved for a finding with a compensating control. Evidence the control operates needs a scan against the compensating surface. The scheduled scan might not exercise the path; the change-triggered scan does.

Scope boundary moves

The in-scope estate gains a business unit, geography, tenant, or product line. Previous scans cover the prior boundary. The change-triggered scan is the one that closes the gap before the next scheduled tick.

Reading the diff between two scan baselines

A single scan is one snapshot. Two scans against the same target produce a diff that is the actual signal cadence is supposed to deliver. The diff splits findings into new (present in the later scan, absent earlier), fixed (present earlier, absent later), unchanged (present in both), and modules-only-in-one (a module ran in only one of the two scans).

Diff category	What it usually means	What to check before acting
New findings	A regression has appeared, or a rule pack updated and a previously silent class now fires.	Triage as new work; check whether the finding ID exists in scanner output history under a different module before treating it as truly new.
Fixed findings	A remediation closed the issue, OR the route or module no longer ran (a coverage drop disguised as a fix).	Confirm the asset and route still exist and the module ran successfully before recording the closure as remediation evidence.
Unchanged findings	Open findings that have not moved across the cadence interval.	Cross-reference SLA windows; unchanged findings past their SLA are remediation-gap evidence regardless of scan recency.
Modules only in one scan	A scanner module ran in one cycle and not the other (timeout, auth failure, scope change, blocking).	Treat the diff as partial; the absence of findings from the missing module is not a fix.

The most common diff misread is treating an absent finding as a fix when the underlying cause is a coverage drop. An authenticated scan that silently failed at login produces a diff that looks like every authenticated finding has been remediated. The fix is to pair the diff with the scan-coverage record so the new and fixed counts are anchored to the surface that actually ran in each cycle. The authenticated scanner failure modes guide covers the six failure classes that account for most authenticated coverage gaps.

The second common misread is letting suppression history collapse into the new-finding count. A finding that was suppressed with evidence in cycle N should not return as a new finding in cycle N+1; the diff has to honour the suppression record. The vulnerability scanner false positives guide covers durable suppression so the cadence does not turn into a re-triage of every cycle.

How compliance frameworks read scan cadence

Auditors do not read scan cadence as the date stamp on the most recent scan. They read cadence as the count of scans inside the audit observation period and the evidence that the cadence operated. The framework expectations below set the floor; programmes justify higher cadence on a risk basis when assets warrant it.

PCI DSS v4.0 Requirement 11.3 expects internal vulnerability scans at least every three months and after any significant change. External scans are performed by an Approved Scanning Vendor at least every three months, with re-scans required for high or critical findings until the issues are addressed.^1,9
ISO 27001:2022 Annex A 8.8 (management of technical vulnerabilities) expects vulnerabilities to be identified and addressed at a documented cadence justified by the risk assessment. The cadence has to operate continuously across the surveillance interval; a single annual scan rarely survives the audit read for a quarterly-rated risk.²
SOC 2 Trust Services Criteria CC7.1expects ongoing detection of new vulnerabilities and security events. Evidence of the detection has to populate the observation period rather than cluster at audit week.³
NIST SP 800-53 control RA-5(Vulnerability Monitoring and Scanning) expects a defined frequency or random schedule for scanning, plus update-driven scans when new vulnerabilities are identified and reported. The control is satisfied by both calendar and event-driven cadence.⁵
CISA BOD 22-01 sets the pattern of continuous monitoring against the Known Exploited Vulnerabilities catalogue with bounded remediation windows. Cadence is implicit in the obligation to detect and remediate within the window the directive sets.^7,8
NIST SP 800-40 Rev. 4 (Patch Management) treats vulnerability scanning and patching as paired disciplines with a documented cadence per asset. The cadence is justified by the asset is criticality and the exposure window the programme is willing to accept.⁴

The shared pattern across these frameworks is that cadence is operational, not ceremonial. A scan record with quarterly date stamps and no diff between cycles satisfies the calendar bar and fails the operating-effectiveness bar. The audit read converges on cadence operation, change-triggered scans, finding lifecycle through remediation, and reproducible evidence drawn from the live record rather than from a static evidence pack.

SAST and SCA cadence in CI/CD

Source-side scanning fits the pull request and push lifecycle better than a calendar schedule. The cadence model that produces the most defensible coverage runs four scans of different granularity on different triggers.

Pull request SAST scan (incremental)

Runs against the diff of the pull request, surfaces new findings inline with code review, and blocks on critical findings according to the policy gate. The incremental scan is fast, scoped, and developer-actionable. It is not a complete view of the codebase; it is a regression gate on the change.

Default-branch SAST scan (full)

Runs on every push to the default branch, covers the full codebase, and produces the baseline the next cycle reads against. The full scan catches the findings the incremental scan structurally cannot (cross-file dataflow that touches pre-existing code as well as the diff).

SCA on dependency change

Runs on every change to a lockfile or manifest, plus a scheduled weekly or monthly run on the default branch. The scheduled run catches dependencies that pick up CVEs after the merge without a code change, which is the regression class a build-time-only scan misses.

Scheduled full SAST baseline

Runs weekly or monthly on the default branch as the regression baseline. The diff between baselines flags rule-pack updates, environmental changes, and findings that surface only when the full scan re-evaluates pre-existing code.

Operational checklist for a defensible scan cadence

At policy design

The scan policy names cadence per asset class and per scanner class, not as a single rule.
The change-trigger policy names the events that override the schedule.
The cadence is justified against the framework floors that apply to each asset.
The credential rotation cadence for authenticated scans is documented alongside the scan cadence.

At schedule creation

Each schedule names the target, the scanner class, the frequency, and the next run timestamp.
Authenticated schedules are paired to a stored credential and a verified domain.
Code schedules are paired to a connected repository and a scan type (SAST, SCA, or both).
The plan limit on schedules per workspace is checked before creation.

At scan execution

Each scheduled run lands as a scan execution on the engagement record, not as an isolated artefact.
Scan coverage is recorded so the next diff can distinguish a fix from a coverage drop.
Failed or skipped modules are recorded with a reason, not silently dropped.
The credential used (for authenticated scans) is recorded for the audit trail without storing plaintext.

At baseline diff

The diff is computed between comparable scans (same target, same scanner class, comparable scope).
New findings are triaged before the next scheduled tick, not deferred indefinitely.
Fixed findings are verified against the coverage record before being recorded as remediation evidence.
Suppression history is honoured so confirmed false positives do not resurface as new findings.

For internal security and vulnerability management teams

Internal security teams and vulnerability management teams operate cadence as part of continuous monitoring, not as a calendar artefact. The disciplines that hold up under audit and under remediation pressure are the same: per-asset cadence, change-triggered cadence on top, diff-led triage at each tick, and finding lifecycle on the same record the cadence operates against.

Set cadence per asset volatility rather than as a blanket policy across the estate.
Wire on-change scans into the change management process so the trigger is automatic, not manual.
Read the diff first at each scheduled tick; the new and changed findings drive the work, not the full output.
Pair scan coverage to the diff so a coverage drop is not misread as remediation.
Track suppression state across cycles so the cadence does not regress into a re-triage exercise.

For internal security teams, vulnerability management teams, AppSec teams, and GRC and compliance teams, the operating commitment is to keep the cadence visible on the engagement record so both the operator view and the audit view read from the same source. The vulnerability remediation throughput research covers the closure-side discipline that scheduled cadence has to feed; the audit evidence half-life research covers how cadence evidence ages between assessments and what auditors actually read.

How SecPortal handles scan scheduling and baseline diff

SecPortal supports scheduled scans across three scanner classes with four frequency options, gated by the continuous monitoring plan feature. The schedule is one record; each run produces a scan execution on the engagement so the cadence is auditable rather than a one-off output.

External scan schedules

Scheduled against a verified domain with daily, weekly, biweekly, or monthly cadence. Each run executes the external scanner modules covering TLS, headers, ports, DNS, subdomains, banner-based CVE correlation, cloud exposure indicators, and email authentication. The external scanning feature covers the modules in detail.

Authenticated scan schedules

Scheduled against a verified domain plus a stored credential encrypted with AES-256-GCM. Schedules support cookie, bearer token, basic auth, and form login credential types. The authenticated scanning feature covers the credential lifecycle and the modules; the encrypted credential storage feature covers the credential encryption and rotation model.

Code scan schedules

Scheduled against a repository connected through GitHub, GitLab, or Bitbucket OAuth. Supports SAST, SCA, or combined SAST and SCA scan types. The code scanning feature covers the scanner integration and the rule packs.

Scan diff between executions

The scan diff endpoint compares two scan executions for the same target and returns new findings, fixed findings, unchanged findings, and modules that ran in only one scan. The diff annotates each finding with any override (suppression, accepted risk) the team has applied so the cadence reads suppression history rather than re-surfacing closed false positives.

The schedule, the runs, and the diffs land on the engagement record alongside the findings, so the audit view reads from the same record the operators run on. The findings management feature holds the finding lifecycle, the continuous monitoring feature holds the schedule, and the activity log feature holds the timestamped chain of state changes by user. The compliance tracking feature maps findings and controls to ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST frameworks so the cadence evidence aligns to the framework view auditors read.

Related scanner discipline

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

Scan scoping and target selection covers the upstream scope decisions that shape what the cadence operates against.
Scanner coverage and limits covers what each scanner class can and cannot reach so cadence does not paper over structural gaps.
Vulnerability scanner false positives covers durable suppression that lets the cadence read clean diff output rather than re-surfacing closed false positives.
Scanner output deduplication covers how to merge findings across tools and cycles so the diff stays clean across multi-tool engagements.
Scan baseline and trend comparison covers how to read the multi-cycle trend the cadence produces, separate real change from coverage drift, and report regression defensibly to leadership and audit.
Authenticated scanner failure modes covers the six failure classes that account for most authenticated coverage drops that look like remediation in the diff.
Scanner rate limiting and throttling covers how the rate decision interacts with the cadence (a scan that hit a rate limit and silently truncated produces a diff that reads like remediation and is a coverage drop).
Scanner credential rotation and lifecycle covers the rotation cadence the credential lifecycle has to feed alongside the scan schedule, so a credential drift event does not silently turn an authenticated scan diff into a coverage drop dressed as remediation.
Scan evidence retention and governance covers how long the scan executions, findings, and activity records the cadence produces are retained, when they are disposed, and how compliance frameworks read the retention as evidence the cadence operated across the audit window.
Remediation tracking workflow covers the closure side of the cadence loop.
Vulnerability SLA management workflow covers the SLA windows the cadence has to satisfy.

For the wider operating model the cadence plugs into, the security workflow orchestration research covers how scheduled scans, manual testing, remediation, retest, and reporting fit together, and the continuous security monitoring guide covers the programme-level discipline that scheduled cadence is one input into.

Scope and limitations of this guide

Scan cadence is a programme discipline, not a configuration setting. No cadence policy makes the underlying scanner classes more capable than they are; no schedule replaces the manual testing the scanner cannot reach. The cadence question is what volume of scans is enough to operate detection across the observation period and what triggers a scan ahead of the next tick. The answer is per asset class, per scanner class, per change axis, and per framework floor that applies.

Cadence claims that depend on a single calendar interval almost always understate the change axis. Cadence claims that decompose into calendar plus change, that pair the schedule with diff reading, and that hold the runs on the same record the operators and the auditor read from are the claims that survive the audit and the remediation cycle.

Frequently Asked Questions

Sources

Run cadence on the live engagement record, not on a calendar artefact

SecPortal supports daily, weekly, biweekly, and monthly schedules across external, authenticated, and code scanning, holds the runs on the engagement record, and computes the diff between scan executions so the cadence reads as remediation evidence rather than as a stack of static reports.

Start free See continuous monitoring