Vulnerability assessment frequency: what regulators expect vs what audits check
Sienna VanceApril 29, 2026
Key takeaways
PCI DSS 4.0 requires quarterly internal and external vulnerability scans at minimum, but also mandates rescans after significant changes, a triggered requirement that most compliant organizations are not operationalizing.
GDPR Article 32 does not specify scan frequency but requires regular testing of technical measures, a standard regulators interpret based on what the organization found and when during post-breach investigations.
In Vulnox assessments, the median time between a significant infrastructure change and the next scheduled vulnerability scan was 74 days, meaning new attack surfaces introduced by deployments routinely go untested for over two months.
Annual penetration tests satisfy many compliance audit requirements but produce a point-in-time snapshot that regulators in breach investigations treat as evidence of a specific date, not evidence of ongoing diligence.
Organizations that align scan frequency to calendar dates rather than change events create a structural gap: the period immediately after a deployment is when new vulnerabilities are most likely to exist and least likely to be scanned.
TL;DR
The question of how often to run vulnerability assessments has two different answers depending on who is asking. Auditors check whether you met the minimum frequency in the standard. Regulators investigating a breach reconstruct your detection timeline and ask whether your program would have found a vulnerability before an attacker did. Designing a scan schedule to satisfy the first question while ignoring the second is the most common mistake in vulnerability program design.
The quarterly scan that covered the wrong quarter
A payment processing company running under PCI DSS scope had quarterly vulnerability scans on schedule, clean QSA reports for two years, and a documented remediation workflow. In a post-incident review following a card data compromise, the forensic timeline showed the attacker had entered through a vulnerability in a load balancer configuration updated six weeks after the last quarterly scan. The next scheduled scan was three weeks away when the breach was detected.
The organization was compliant. The scan schedule met PCI DSS 11.3.1 requirements for quarterly internal scanning. What it did not meet was the companion requirement in PCI DSS 4.0 to perform rescans after significant changes. The load balancer update qualified as a significant change under their own change management policy. Nobody had connected that policy to the scan trigger. The QSA had not tested whether triggered scans were being executed. The gap between the compliance checkbox and the operational reality was nine weeks of unscanned attack surface.
How regulators read scan frequency evidence after a breach
Compliance audits verify that scans occurred at the required interval. A QSA reviewing PCI DSS compliance looks for evidence that quarterly scans ran and that critical findings were remediated. That review is backward-looking and document-based. A regulator or forensic investigator examining the same organization after a breach asks a structurally different question: given the timeline of events, would your scanning program have detected this vulnerability before the attacker exploited it? The answer depends not on whether quarterly scans ran but on when the last scan covered the affected system and what it found.
Example
Under GDPR Article 32, organizations must implement a process for regularly testing, assessing, and evaluating the effectiveness of technical and organizational measures. The word regularly has no defined frequency in the regulation. What it has is enforcement history. In post-breach investigations, data protection authorities have examined the interval between the last assessment of the affected system and the date of compromise. An organization that assessed a system annually and suffered a breach nine months later has a harder evidentiary position than one that assessed quarterly. The frequency standard that matters is not the one in the audit checklist. It is the one that holds up when the timeline is reconstructed.
The triggered scan requirement is where most programs fall apart operationally. PCI DSS 4.0 Requirement 11.3.1.1 explicitly requires internal vulnerability scans after any significant change. ISO 27001:2022 Annex A 8.8 requires organizations to identify vulnerabilities in a timely manner, a standard that implicitly includes change-driven assessment. DORA, applicable to financial entities in the EU from January 2025, requires vulnerability assessments as part of ICT risk management with no fixed interval but with a continuous monitoring expectation. The pattern across frameworks is consistent: minimum periodic intervals plus change-triggered assessment. Most programs implement the interval and skip the trigger.
What the assessment data shows about scan cadence in practice
Assessment base: Vulnox vulnerability assessment data across SMB and mid-market clients, 2023-2024
Median gap between infrastructure changes and next scan is 74 days
Across client environments where Vulnox performed vulnerability assessments and reviewed prior scan history, the median interval between a documented significant infrastructure change and the next vulnerability scan covering the affected systems was 74 days. In organizations on quarterly scan schedules, changes made shortly after a scan completed would routinely go unassessed until the following quarter. The change management logs existed. The scan trigger did not.
A 74-day gap between a change event and the next scan is not a frequency problem. It is a trigger problem. The fix is not more frequent scheduled scans but a documented process that connects change management approvals to scan initiation for the affected scope.
Annual penetration tests scoped to prior-year architecture
A mid-market professional services firm with ISO 27001 certification conducted annual penetration tests as required by their ISMS. Review of the last two test scopes showed both were defined based on the system inventory documented at the start of the engagement. Cloud infrastructure added in the 12 months between tests was out of scope in both cases because the scope definition process used the prior year architecture diagram as the baseline. New services, a customer-facing API and a data analytics platform, had never been assessed.
Annual penetration test scope that derives from static documentation rather than a live asset inventory assessment will systematically exclude the assets most likely to contain unreviewed vulnerabilities. The compliance evidence shows an annual test occurred. It does not show what was covered.
Triggered scans required by policy but absent from operational records
In organizations that had written policies requiring vulnerability scans following significant changes, operational records of triggered scans were absent or incomplete in the majority of cases reviewed. The policies existed. The process for initiating a triggered scan, defining what qualified as significant, and documenting the result had not been operationalized. In several cases the policy had been written to satisfy an audit requirement and had never been tested in practice.
A policy requiring triggered assessments that is not operationalized is not a compensating control. It is a documented gap. In a post-breach investigation, a written policy that was not followed is worse evidentiary ground than having no policy, because it demonstrates the organization knew what was required and did not do it.
Remediation windows exceed scan intervals in high-change environments
A SaaS company with weekly deployment cycles and monthly vulnerability scans had a median critical vulnerability remediation time of 34 days. Their scan interval was 30 days. New vulnerabilities introduced by deployments in the final week of a scan cycle would not appear in a scan result until the following month and would not be remediated until at least two cycles later. The scan frequency looked adequate on a calendar. Against the deployment velocity, it produced a consistent gap.
Scan frequency should be benchmarked against deployment frequency, not against the compliance standard minimum. Organizations deploying weekly need scan cadences that can detect vulnerabilities introduced by those deployments within a materially shorter window than the next compliance checkpoint.
More frequent scans without triggered scans produce worse coverage
Common belief
Increasing scan frequency, moving from quarterly to monthly or monthly to weekly, improves vulnerability detection coverage proportionally. The logic is straightforward: more scans mean shorter windows of exposure.
What we found
In assessments where we reviewed both scan history and change management logs, the vulnerabilities that had been present longest were almost uniformly introduced by changes that occurred in the days immediately following a scheduled scan. The scheduled scan had just run. The change introduced a new surface. The next scheduled scan was weeks away. Frequency was not the variable. Trigger coverage was.
Scan frequency improvements reduce the average time between scheduled assessments. They do not reduce the gap between a change event and the next scan unless the scan schedule happens to align with the change. An organization running weekly scans that deploys a vulnerable configuration on a Wednesday will have that configuration unscanned until the following week. An organization running monthly scans with a functioning triggered scan process will have the same configuration scanned within hours of the change. The triggered process produces faster detection for the highest-risk moment, which is immediately after a change, regardless of the scheduled interval.
What major frameworks actually require on frequency
PCI DSS 4.0
Quarterly internal and external scans are the documented minimum. Requirement 11.3.1.1 adds mandatory rescans after significant changes. Requirement 11.4.1 requires penetration testing at least annually and after significant changes or upgrades. The quarterly scan satisfies the audit. The after-significant-change requirement is where operational programs diverge from compliant ones.
QSAs typically verify that quarterly scans occurred and that high and critical findings were remediated. Most do not verify whether triggered scans after changes were executed. Organizations that treat quarterly compliance as full coverage are one deployment away from a gap that would be visible to a forensic investigator but not to an auditor.
GDPR Article 32
No defined frequency. Requires a process for regularly testing, assessing, and evaluating the effectiveness of technical and organizational measures. Regulators have interpreted this based on enforcement history rather than a fixed interval. The evidentiary standard is whether the frequency was appropriate to the risk, which is reconstructed post-breach using the organization's own risk assessment documentation.
An organization that documented high-risk assets and assigned them monthly scans has a defensible position if a breach occurs between scans. An organization that applied quarterly scans uniformly to all assets without a risk classification rationale does not. The frequency is less important than the documented reasoning behind it.
ISO 27001:2022 Annex A 8.8
Requires timely identification of vulnerabilities in information systems and evaluation of exposure. No defined interval. Certification auditors look for a documented process and evidence that it ran. The definition of timely is not specified and is interpreted by the auditor.
ISO 27001 certification can be achieved with annual scans if the auditor accepts the frequency as appropriate to the risk. The same annual scan schedule that satisfies certification will not satisfy a post-breach regulatory investigation if a vulnerability was present for ten months before exploitation.
DORA (EU Digital Operational Resilience Act)
Applies to financial entities and ICT service providers in the EU from January 2025. Requires vulnerability assessments as part of ICT risk management with no fixed interval but with expectations for continuous monitoring of ICT systems. Threat-led penetration testing requirements apply to significant financial entities on a three-year cycle.
DORA introduces an expectation of continuous monitoring alongside periodic assessment that most financial entities have not operationalized. The combination of continuous monitoring and periodic deep assessment is the direction most frameworks are moving, with or without explicit frequency mandates.
The coverage gaps compliance schedules do not capture
Cloud resource provisioning outside change management
Development teams provisioning cloud resources directly, outside formal change management processes, create scan coverage gaps by definition. If triggered scans depend on change management approvals as the initiation event, resources provisioned without approvals are never in scope for triggered scans and may not appear in the asset inventory used to define scheduled scan scope. Shadow IT in cloud environments is an assessment frequency problem as much as a discovery problem.
Third-party integration updates
Updates to third-party APIs, SDKs, and embedded scripts are not always processed through internal change management. A vendor updating a JavaScript library version, an API endpoint behavior, or an authentication mechanism may introduce vulnerability changes that the organization's scan schedule does not cover because the trigger event occurred on the vendor side.
Decommissioned systems with residual network access
Systems removed from active use are frequently removed from scan scope before network access is fully revoked. An asset that no longer appears in the inventory is not scanned. If that asset retains network connectivity, it represents an unscanned attack surface. Post-decommission scan coverage is not addressed in any major framework's frequency requirements.
Compliance scope creep between audit cycles
Systems added to compliance scope between audit cycles, because of new data flows, new integrations, or business changes, may not be added to scan scope until the following audit cycle. The compliance perimeter expands continuously. The scan scope is redefined periodically. The gap between the two is an undocumented coverage absence.
Where frequency requirements are heading
Within three years, at least two major compliance frameworks will introduce explicit triggered scan requirements that specify maximum elapsed time between a defined change event and a required assessment of the affected scope.
PCI DSS 4.0 already requires rescans after significant changes without specifying a maximum interval. DORA requires continuous monitoring without defining what that means operationally. The next iteration of these frameworks and their successors will close the ambiguity by specifying that a significant change must trigger an assessment within a defined window, likely 30 days for critical systems. The enforcement pressure to define this precisely comes from post-breach investigations that consistently find the gap between change events and scans.
Confidence: highPCI DSS 4.x or DORA implementing guidance specifying a maximum interval between significant change events and required vulnerability assessment of affected systems by 2027.Continuous automated vulnerability monitoring will become a baseline expectation rather than a differentiator for regulated financial and healthcare entities within two years, driven by DORA implementation and HIPAA enforcement patterns.
DORA implementation guidance emphasizes continuous ICT risk monitoring. Recent HIPAA enforcement actions have cited failure to conduct periodic technical and non-technical evaluations in breach settlements. The combination of these pressures will push regulated entities to implement continuous scanning infrastructure that most currently treat as an optional enhancement over periodic scans.
Confidence: mediumDORA supervisory guidance or HHS enforcement guidance explicitly citing absence of continuous vulnerability monitoring as a contributing factor in at least three enforcement actions by end of 2026.
The compliance calendar is the wrong unit of measurement
Vulnerability assessment frequency is discussed almost entirely in terms of calendar intervals: quarterly, monthly, annual. Those intervals come from the compliance frameworks, which set minimums that auditors can verify with document review. The problem is that attackers do not operate on calendar intervals. They operate on opportunity. The interval that matters is the one between a vulnerability being introduced and a scan detecting it. That interval is determined by the combination of deployment velocity and trigger coverage, not by the scheduled scan cadence. Organizations that optimize for the calendar interval are solving the audit problem. Organizations that optimize for the change-to-detection interval are solving the security problem. Those are related but not the same.
Counterargument
The counterargument is that continuous scanning or very high-frequency scanning eliminates the gap entirely, making the triggered scan question irrelevant. That is true for organizations with the infrastructure and analyst capacity to act on continuous scan output. For most SMBs and mid-market organizations, continuous scanning produces more findings than the remediation team can process, and the noise degrades the signal. The triggered scan model, where a specific change event initiates a focused assessment of the changed scope, produces actionable output without the volume problem. It requires operational discipline rather than tool investment.
One thing to do this week
Pull your change management log for the last 90 days and identify every entry that would qualify as a significant change under your own policy definition. Then check whether a vulnerability scan was initiated for the affected scope within 30 days of each change. Do not check whether a scheduled scan happened to run during that period. Check whether a scan was triggered by the change. If your change management process does not have a field that connects a change record to a scan initiation record, the triggered scan process does not exist operationally regardless of what the policy document says. That gap is visible to a forensic investigator and invisible to an auditor. Closing it is a process change, not a tool purchase.
Further Reading
Vulnerability Assessment
comprehensive vulnerability assessmentDigital Footprint
digital footprint analysisNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionPCI Security Standards Council
PCI DSS compliance standardsOWASP Web Security Testing Guide
OWASP security testing guide
Frequently Asked Questions
How often does PCI DSS 4.0 require vulnerability scans and what do most organizations miss?
PCI DSS 4.0 requires quarterly internal and external vulnerability scans as a minimum, plus rescans after significant changes under Requirement 11.3.1.1. Most organizations operationalize the quarterly schedule and do not operationalize the triggered rescan requirement. In Vulnox assessment data, the median gap between a significant infrastructure change and the next vulnerability scan was 74 days in organizations on quarterly schedules. The quarterly compliance checkbox is met. The change-triggered requirement is not. QSAs typically verify that quarterly scans ran; they rarely verify that triggered scans after changes were executed.
What does GDPR require for vulnerability assessment frequency?
GDPR Article 32 does not specify a scan frequency. It requires a process for regularly testing, assessing, and evaluating the effectiveness of technical and organizational measures. Regulators interpret this standard post-breach by reconstructing the detection timeline: when was the affected system last assessed, what was found, and what was done. An organization with a documented risk classification that assigned higher-risk systems to more frequent scans has a defensible evidentiary position. An organization that applied a uniform quarterly schedule to all systems without a risk-based rationale does not. The frequency that matters is the one you can justify against your own risk assessment.
Why do triggered vulnerability scans after system changes matter more than scan frequency?
Scheduled scan frequency reduces the average time between assessments. It does not reduce the gap between a change event and the next scan unless the schedule aligns with the change. An organization with weekly scans that deploys a vulnerable configuration on the day after a scan has that configuration unscanned for nearly a week. An organization with monthly scans and a functioning triggered scan process will assess the same configuration within hours of the change. The highest-risk moment for a new vulnerability is immediately after the change that introduced it. Triggered scans cover that moment. Scheduled scans do not.
How should vulnerability assessment frequency be set for organizations with frequent deployments?
Scan frequency should be benchmarked against deployment frequency, not compliance minimums. Organizations deploying weekly need a scan cadence that detects vulnerabilities introduced by those deployments within a materially shorter window than the next compliance checkpoint. In Vulnox assessment data, a SaaS company with weekly deployments and monthly scans had a median critical vulnerability remediation time of 34 days against a 30-day scan interval, creating a consistent detection gap for vulnerabilities introduced late in each scan cycle. Triggered scans on deployment events, even automated lightweight scans, close that gap more effectively than increasing the scheduled frequency.
What does a post-breach regulatory investigation actually examine about scan frequency?
Post-breach regulatory investigations reconstruct a detection timeline. Investigators examine when the affected system was last assessed before the breach, what the assessment found, how findings were remediated, and whether the assessment frequency was appropriate to the documented risk level of the system. Annual penetration test reports are treated as evidence of a specific date, not evidence of ongoing diligence. A clean annual report followed by a breach nine months later is not a defense. The evidentiary question is whether the program would have detected the vulnerability before an attacker did, given the organization's own risk classification of the affected system.
What vulnerability assessment coverage gaps does a compliance-driven scan schedule typically miss?
Compliance-driven schedules miss cloud resources provisioned outside change management processes, third-party integration updates made on the vendor side without triggering internal change records, decommissioned systems with residual network access that have been removed from scan scope before access was revoked, and systems added to compliance scope between audit cycles that are not added to scan scope until the following audit review. Each of these creates an undocumented coverage absence that is invisible to an auditor reviewing scheduled scan records and visible to an investigator reconstructing an attack timeline.
Related Articles
API security assessment: what automated tools miss and manual testing finds
Automated API security tools find the vulnerabilities they were designed to look for. The findings that matter in real assessments, broken object-level authorization, JWT algorithm confusion, and unauthenticated internal endpoints, require a tester who understands what the API is supposed to do before probing what it actually does.
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.