Which regulations require vulnerability scanning? Two regimes require scanning explicitly: PCI DSS (internal and external ASV scans at least every 3 months) and DORA (through RTS 2024/1774 – automated scans at least weekly for assets supporting critical functions). NIS2, the Cyber Resilience Act, ISO 27001:2022 and SOC 2 set no frequency but require a documented process for identifying and fixing vulnerabilities, for which scanning is the only scalable source.
An organisation under several regimes does not need several scanning programmes – it needs one, designed to the strictest requirement and evidenced for every audit. What a vulnerability scan is and how to configure it is covered in the hub Infrastructure vulnerability scanning.
Canonical definition: A vulnerability management programme is a documented, continuous set of procedures covering asset inventory, scanning, prioritisation, remediation and verification of vulnerabilities, required in varying forms by PCI DSS, DORA, NIS2, the CRA, ISO 27001 and SOC 2.
Vulnerability scanning and compliance – key takeaways:
- PCI DSS v4.0.1 (requirements 11.3.1-11.3.2) is the only standard with a numerically defined scan frequency for all in-scope entities: every 3 months and after significant change, with internal scans authenticated from 31 Mar 2025.
- DORA, via RTS 2024/1774 Article 10, requires scans at least weekly for assets supporting critical or important functions, plus tracking of open-source libraries.
- NIS2 (Article 21(2)(e)) and ISO 27001:2022 (A.8.8) require a vulnerability handling process without a stated frequency – the auditor assesses whether the frequency follows from risk analysis.
- The CRA shifts obligations to software manufacturers: SBOM, vulnerability handling across the product lifecycle, and from 11 Sep 2026 reporting of actively exploited vulnerabilities to ENISA and CSIRTs within 24 hours.
- One scanning programme designed to DORA (weekly rhythm, authentication, register, SBOM) simultaneously satisfies PCI DSS, NIS2, ISO 27001 and SOC 2 – only the evidence differs.
- Patronusec, as an accredited QSA and ISO 27001 auditor, designs scanning programmes so that one set of reports serves every audit, and delivers internal, external and ASV scans.
Table of Contents
Which regulations require vulnerability scanning, and what exactly do they say?
Six regimes address vulnerability scanning in three different modes: PCI DSS and DORA specify frequency and scope, NIS2 and ISO 27001 require a risk-based process, and the CRA and SOC 2 require documented vulnerability handling without naming a tool. The table maps each requirement to a specific article or control.
| Regime | Provision / control | Requirement | Frequency | Authentication | Rescan / verification |
|---|---|---|---|---|---|
| PCI DSS v4.0.1 | 11.3.1, 11.3.1.1, 11.3.1.2, 11.3.1.3 | internal scans of all in-scope components; high and critical vulnerabilities resolved; others per risk analysis | every 3 months + after significant change | required from 31 Mar 2025 | required for high and critical |
| PCI DSS v4.0.1 | 11.3.2, 11.3.2.1 | external scans by an ASV; after significant change may be internal | every 3 months + after significant change | n/a (external) | until passing (no CVSS ≥ 4.0) |
| PCI DSS v4.0.1 | 6.3.1, 6.3.2, 6.3.3 | identify software vulnerabilities, component inventory (SBOM), critical and high patches within one month | continuous | – | – |
| DORA | Regulation 2022/2554, Art. 25 | testing programme including vulnerability assessments and scans | at least annually for systems supporting critical functions (testing) | – | – |
| DORA | RTS (EU) 2024/1774, Art. 10(2) | vulnerability management procedures; automated scanning proportionate to asset classification; tracking third-party libraries; verifying ICT providers; vulnerability register | at least weekly for assets supporting critical or important functions | implied (full scan of the asset) | monitor and verify remediation |
| NIS2 | Directive 2022/2555, Art. 21(2)(e) | security in acquisition, development and maintenance, including vulnerability handling and disclosure | risk-based | – | – |
| NIS2 | Implementing Regulation (EU) 2024/2690 (digital service providers) | vulnerability management procedures including scanning and assessment | “regularly”, proportionate to risk | – | – |
| CRA | Regulation (EU) 2024/2847, Annex I Part II | manufacturers: component identification (SBOM), regular security testing and review, remediation, coordinated disclosure | across the product lifecycle | – | – |
| CRA | Art. 14 | reporting actively exploited vulnerabilities: early warning in 24 h, notification in 72 h, final report in 14 days | from 11 Sep 2026 | – | – |
| ISO/IEC 27001:2022 | Annex A, A.8.8 | obtain information on technical vulnerabilities, evaluate exposure, take appropriate measures | risk-based | – | – |
| ISO/IEC 27001:2022 | A.8.9, A.8.29 | configuration management; security testing in development and acceptance | – | – | – |
| SOC 2 (AICPA TSC 2017, 2022 revision) | CC7.1 | procedures to detect and monitor vulnerabilities and configuration changes | organisation-defined | – | – |
| CIS Controls v8 | 7.1-7.7 | vulnerability management process, authenticated internal scans, external scans, remediation | at least quarterly (7.5, 7.6) | yes (7.5) | yes (7.7) |
| Cyber Essentials (UK) | Security update management | critical and high patches within 14 days of release; unsupported software removed | continuous | – | – |
| TISAX (VDA ISA 6) | vulnerability management control | identify and remediate vulnerabilities in IT systems | risk-based | – | – |
Of the main compliance regimes, only PCI DSS and DORA define scan frequency numerically – every 3 months and at least weekly for assets supporting critical or important functions respectively – while the others require a frequency justified by risk analysis.
Two observations. First, DORA is strictest on rhythm, PCI DSS on evidence (rescans, passing ASV results). Second, “risk-based” requirements are not lenient: an ISO 27001 auditor or a NIS2 supervisor will ask why you scan quarterly and expects an answer grounded in asset classification, not convenience.
How do you build one scanning programme that satisfies every regime at once?
You build one programme using the strictest common denominator: weekly rhythm for critical assets (DORA), quarterly for everything else with rescans of high findings (PCI DSS), authentication wherever possible (PCI DSS, CIS), a component inventory and SBOM (PCI DSS 6.3.2, DORA, CRA), and a vulnerability register with owners and deadlines (DORA, ISO 27001). Differences between regimes are handled in the evidence layer, not with separate scans.
Eight elements of the common programme and the regimes each satisfies:
| Programme element | PCI DSS | DORA | NIS2 | CRA | ISO 27001 | SOC 2 |
|---|---|---|---|---|---|---|
| 1. Asset register with classification (critical / in scope / other) | 12.5.1 | DORA Art. 8 | Art. 21 | – | A.5.9 | CC6.1 |
| 2. Weekly scan of critical assets | exceeds requirement | RTS Art. 10 | evidence of “regularity” | – | A.8.8 evidence | CC7.1 evidence |
| 3. Quarterly scan of all in-scope assets + after change | 11.3.1, 11.3.1.3 | complements | yes | – | yes | yes |
| 4. Quarterly external ASV scan | 11.3.2 | perimeter evidence | yes | – | yes | yes |
| 5. Authenticated internal scans | 11.3.1.2 | full asset scan | yes | – | yes | yes |
| 6. Component inventory / SBOM | 6.3.2 | RTS Art. 10(2)(d) | Art. 21(2)(e) | Annex I Part II | A.8.8 | yes |
| 7. Prioritisation and remediation SLAs (CVSS + EPSS + KEV + context) | 11.3.1.1, 6.3.3 | RTS Art. 10(2)(f) | yes | Annex I Part II | A.8.8 | CC7.1 |
| 8. Vulnerability register, rescan, management report | 11.3.1 (rescan) | RTS Art. 10(2)(g)-(h) | Art. 20 (management accountability) | – | 9.1, 9.3 | CC4.1 |
A scanning programme designed to the strictest regime – DORA’s weekly rhythm and vulnerability register plus PCI DSS’s rescans and ASV scans – simultaneously satisfies NIS2, ISO 27001 and SOC 2, because those require a risk-based process rather than a specific frequency.
For organisations outside DORA and PCI DSS, the “strictest denominator” is CIS Controls v8: quarterly authenticated and external scans with a remediation process (controls 7.1-7.7). That is a sufficient reference for ISO 27001, SOC 2 and NIS2 – provided the frequency is recorded in the risk analysis. UK organisations should add Cyber Essentials’ 14-day patch window for critical and high updates.
Patronusec Insight: In our project experience, organisations under both PCI DSS and DORA most often run two parallel processes: a quarterly one “for the QSA” and a weekly one “for DORA”, with two report sets and two owners. The result is double cost and divergent results. As an accredited QSA and ISO 27001 auditor, we design the programme so that the weekly scan also produces a quarterly snapshot with rescans in the format requirement 11.3.1 expects – and the DORA management report doubles as the ISO 27001 management review evidence (clause 9.3). Patronusec delivers such vulnerability scanning as a service with a ready evidence pack per regime.
How do PCI DSS and DORA differ in evidence practice?
PCI DSS and DORA differ less in what you scan than in what you must show: a QSA expects four quarterly reports covering every in-scope address, rescan evidence for every high vulnerability and passing ASV reports; DORA supervision expects a procedure, a vulnerability register with monitoring, evidence of the weekly rhythm for critical functions and evidence that ICT providers report critical vulnerabilities.
| Evidence area | PCI DSS v4.0.1 (QSA assessment) | DORA (supervisory review / internal audit) |
|---|---|---|
| Scope | all components in the CDE and connected; host list reconciled with the network diagram (1.2.4) | ICT assets classified under DORA Art. 8, especially those supporting critical or important functions |
| Frequency evidence | 4 quarterly reports from 12 months + scans after significant changes | scanner schedule and logs confirming the weekly rhythm |
| Authentication evidence | authentication success report; documented exceptions (11.3.1.2) | completeness of the asset scan (RTS Art. 10(2)(b)) |
| Remediation evidence | rescan confirming removal of high and critical; risk analysis for the rest (11.3.1.1) | vulnerability register with detection date, priority, owner, status ((g)-(h)) |
| External evidence | four passing ASV reports; ASV attestation | verification that ICT providers handle and report vulnerabilities ((c)) |
| Software evidence | component inventory (6.3.2), patches within 30 days (6.3.3) | tracking of open-source libraries in critical services ((d)) |
| Accountability | requirement owner (12.4) | management body approves the ICT risk management framework (DORA Art. 5) |
In a PCI DSS assessment, evidence of compliance with requirement 11.3.1 consists of four quarterly scan reports covering all in-scope components and rescans confirming removal of high and critical vulnerabilities, whereas under DORA the evidence is the vulnerability management procedure and a register with remediation monitoring.
The biggest practical difference concerns vulnerabilities below “high”: PCI DSS allows them to be managed under a targeted risk analysis, while DORA requires every detected vulnerability to be recorded and its resolution monitored. An organisation under both therefore keeps the full register (DORA) and shows which items are covered by risk analysis (PCI DSS).
Facing a PCI DSS assessment, a DORA supervisory review or ISO 27001 certification within the next 6 months?
Patronusec runs an audit-readiness review of your scanning programme: within 10 working days you receive an evidence gap map against specific requirements (PCI DSS 11.3.x, RTS Art. 10, A.8.8), a list of missing reports and rescans, and a plan to close the gaps before the audit date.
Request an audit-readiness review
Is your organisation subject to scanning requirements – and which ones?
What determines the requirements is activity, not size: handling card payments triggers PCI DSS, financial entity status triggers DORA, membership of a NIS2 annex sector triggers essential or important entity obligations, manufacturing products with digital elements triggers the CRA, and ISO 27001 certification or a SOC 2 report triggers the respective controls. Most organisations fall under two or three regimes at once.
Decision tree – which scanning requirements apply to you?
- Do you store, process or transmit cardholder data (or affect its security)?
→ YES: PCI DSS 11.3 – quarterly authenticated internal and ASV scans. Scope is set by the CDE – see PCI DSS scope and segmentation. Go to step 2. - Are you a financial entity under Article 2 of DORA (bank, payment institution, insurer, investment firm, crypto-asset service provider, etc.)?
→ YES: RTS 2024/1774 Art. 10 – weekly scans of critical assets, register, SBOM, provider verification. Go to step 3. - Do you operate in a NIS2 Annex I or II sector (energy, transport, health, digital infrastructure, manufacturing, food, etc.) with ≥ 50 staff or ≥ EUR 10 million turnover?
→ YES: essential or important entity obligations, including Art. 21(2)(e) – check classification in NIS2 essential or important entity. Go to step 4. - Do you manufacture or place on the EU market software or devices with digital elements?
→ YES: CRA – SBOM, vulnerability handling, reporting from 11 Sep 2026; see CRA for software houses. Go to step 5. - Do you hold or plan ISO 27001 certification, a SOC 2 report, Cyber Essentials or a TISAX label?
→ YES: controls A.8.8 / CC7.1 / patch windows / VDA ISA – frequency from risk analysis, CIS 7.5-7.6 as the floor.
→ NO (and none of 1-4): no hard requirement, but quarterly authenticated scans remain baseline hygiene.
The obligation to scan for vulnerabilities follows from the nature of an organisation’s activity – card processing, financial entity status, NIS2 sector or manufacturer role under the CRA – not from its size, which is why most mid-sized companies fall under at least two regimes at once.
In practice, a fintech handling card payments falls under PCI DSS, DORA and often NIS2 (digital infrastructure) at once – and its programme should be the reference for the strictest denominator described above.
How do ICT provider and supply-chain requirements change the scope of scanning?
Provider requirements extend scanning beyond your own systems: DORA (RTS Art. 10(2)(c)) requires verifying that ICT providers handle vulnerabilities and report critical ones, NIS2 (Art. 21(2)(d)) requires supply-chain security, PCI DSS (12.8-12.9) requires oversight of service providers, and the CRA requires SBOMs from manufacturers. You scan what you manage; from everyone else you demand evidence.
Three models by provider type:
| Provider type | What you scan yourself | What you demand from the provider | Basis |
|---|---|---|---|
| Colocation / IaaS | operating systems, applications, configuration of your own resources | vulnerability management reports for the physical and hypervisor layer; certifications (SOC 2, ISO 27001, PCI DSS AOC) | PCI DSS 12.8.4-12.8.5, DORA Art. 28-30 |
| SaaS / managed service | integrations, configuration on your side, identities | evidence of regular scans and pentests, remediation SLAs, reporting of critical vulnerabilities | DORA RTS Art. 10(2)(c), NIS2 Art. 21(2)(d) |
| Software / component supplier | the software in your environment (SCA on delivered artefacts) | SBOM, vulnerability handling process, reporting channel, patch timelines | CRA Annex I Part II, PCI DSS 6.3.2 |
Under Article 10(2)(c) of RTS 2024/1774, a financial entity verifies whether its ICT third-party service providers handle vulnerabilities related to the services provided and report to it, in a timely manner, at least critical vulnerabilities together with statistics and trends.
The provider contract should contain a scanning clause: the right to scan your own resources hosted by the provider (or the provider’s duty to scan and report), a definition of critical vulnerability, a notification deadline and a remediation deadline. Clause patterns and a provider classification model are covered in third-party risk management, and the assessment of a new provider in vendor security due diligence.
In practice, the scope of your scanning programme is defined by a responsibility map per provider, not by an IP list – and that map is the first thing a DORA reviewer or QSA will ask to see.
What deadlines apply in 2026-2027, and what do they change in the scanning programme?
Three dates matter most in 2026-2027: 11 Sep 2026 (CRA – manufacturers’ obligation to report actively exploited vulnerabilities), 11 Dec 2027 (full application of the CRA, including SBOM and vulnerability handling as a condition of CE marking), and the ongoing application of DORA and PCI DSS v4.0.1, whose future-dated requirements have all applied since 31 Mar 2025. National NIS2 transpositions add their own deadlines for essential and important entities.
| Date | Regime | What changes | Impact on the scanning programme |
|---|---|---|---|
| 17 Jan 2025 | DORA | full application of the regulation and RTS 2024/1774 | weekly scans of critical assets, vulnerability register, SBOM for critical services |
| 31 Mar 2025 | PCI DSS v4.0.1 | future-dated requirements become mandatory: 11.3.1.2 (authentication), 6.3.2 (component inventory), 6.4.2 (application protection) | internal scans authenticated only; SBOM for applications in the CDE |
| 31 Oct 2025 | ISO/IEC 27001:2022 | end of transition from the 2013 version | audits only against A.8.8 (new control numbering) |
| 11 Sep 2026 | CRA Art. 14 | obligation to report actively exploited vulnerabilities and severe incidents (24 h / 72 h / 14 days) | manufacturers: vulnerability triage process combining own scans and external reports, ready for the ENISA reporting platform |
| 11 Dec 2027 | CRA – full application | Annex I requirements (including SBOM, vulnerability handling, security updates) as a condition of CE marking | manufacturers: SCA and SBOM in the pipeline as compliance evidence; scanning across the product lifecycle |
| varies by Member Country | NIS2 national transpositions | entity registration deadlines and implementation of Art. 21 measures | documented scan frequency in the risk analysis; vulnerability handling and disclosure |
From 11 Sep 2026 the Cyber Resilience Act obliges manufacturers of products with digital elements to report an actively exploited vulnerability within 24 hours of becoming aware of it – which requires that own scan results and external reports feed one triage process.
For most organisations the DORA and PCI DSS deadlines have passed – the scanning programme either meets them today or generates a non-compliance at the next audit. The CRA deadline is the only one still ahead and concerns those who make software; the preparation list is in Cyber Resilience Act obligations and deadlines, and the CRA-NIS2 relationship in CRA vs NIS2 obligations mapping.
Patronusec Insight: In our project experience, since 31 Mar 2025 the most common requirement 11 non-compliance in PCI DSS assessments is missing evidence of authenticated internal scans – organisations moved to v4.0.1 formally, but the scanner configuration stayed as it was under v3.2.1. The second is the absence of a component inventory (6.3.2) for in-house applications. Both can be fixed within a quarter, provided they are found before the assessment rather than during it – which is why our audit-readiness review verifies scanner configuration, not just reports.
Which beliefs about vulnerability scanning and compliance are myths?
MYTH: ISO 27001 requires quarterly vulnerability scans.
FACT: ISO/IEC 27001:2022 (A.8.8) sets no frequency; it requires obtaining vulnerability information and taking appropriate measures. Frequency must follow from the organisation’s risk analysis.MYTH: A passing ASV scan means compliance with PCI DSS requirement 11.3.
FACT: An ASV scan satisfies only 11.3.2 (external). Requirement 11.3.1 concerns authenticated internal scans with rescans – a separate obligation.MYTH: DORA requires weekly scans of all systems.
FACT: RTS 2024/1774 Article 10 requires the weekly rhythm for assets supporting critical or important functions; for others, frequency must be proportionate to classification and risk profile.MYTH: NIS2 does not concern scanning because Article 21 does not mention it.
FACT: Article 21(2)(e) requires “vulnerability handling and disclosure” as a risk management measure; the supervisor will assess whether the organisation identifies vulnerabilities regularly and with documentation – scans are the primary evidence.MYTH: The CRA applies only to hardware manufacturers.
FACT: The CRA covers products with digital elements, including software placed on the EU market as a standalone product – software houses and SaaS providers with a distributed component included.
FAQ – which regulations require vulnerability scanning
Can one scan satisfy PCI DSS and DORA at the same time?
Yes, if the programme is designed to DORA (weekly rhythm, register, authentication) and produces quarterly snapshots with rescans for PCI DSS. The difference lies in evidence: the QSA needs four quarterly reports and ASV reports, DORA supervision needs the procedure and a register with monitoring.
How often does ISO 27001 require vulnerability scans?
ISO 27001:2022 sets no frequency. Control A.8.8 requires obtaining vulnerability information and appropriate action, and the auditor expects the frequency to follow from risk analysis. The reference is CIS Controls v8: at least quarterly, authenticated internal and external.
Does NIS2 require vulnerability scanning?
Not explicitly, but Article 21(2)(e) requires vulnerability handling and disclosure as a risk management measure. A supervisory inspection will assess regularity and documentation; for digital service providers, Implementing Regulation 2024/2690 details vulnerability management requirements.
What does the CRA change for a company that only buys software?
Directly, little – CRA obligations rest with manufacturers. Indirectly: from 11 Dec 2027 you can demand an SBOM and a vulnerability handling process as a purchase condition, and the manufacturer must provide security updates for the support period. That strengthens your position in contract clauses under DORA RTS Art. 10 and NIS2 Art. 21.
Must scan reports be retained, and for how long?
Yes. PCI DSS requires evidence from the past 12 months (four quarters), DORA a vulnerability register without a time limit, ISO 27001 documented information as evidence the ISMS operates. Practice: reports and rescans for at least 3 years, the vulnerability register indefinitely.
How much does a Patronusec audit-readiness review cost?
The review takes 10 working days; the price depends on the number of regimes, environment size and number of scanning tools. After a free scoping call we provide a fixed price. For clients who commission scanning or a PCI DSS assessment from us, the review is part of the package.
Recommended reading
- Infrastructure vulnerability scanning – the definition hub; scan types, authentication, CVSS/EPSS/KEV prioritisation.
- Application vulnerability scanning – DAST, SAST, SCA – the application layer, SBOM and CI/CD gates.
- NIS2 essential or important entity – classification and Article 21 obligations.
- CRA vs NIS2 obligations mapping – how manufacturer and user obligations connect in the supply chain.
- ISO 27001 vs PCI DSS – which certification – how the two regimes overlap in testing and scanning.
- TLPT under DORA – how to start – the top tier of the DORA testing programme, for which scanning is the baseline layer.
Vulnerability scanning and compliance – free consultation
As an accredited QSA and ISO 27001 auditor, Patronusec designs vulnerability scanning programmes so that one evidence set serves the PCI DSS assessment, the DORA supervisory review and ISO 27001 certification – and delivers internal, external and ASV scans as a service. We work with fintech, financial services, e-commerce and retail clients.
In a free 30-minute consultation we will help you:
- establish which regimes apply to your organisation and which sets the programme’s “strictest denominator”,
- map your current scans and reports to specific requirements (11.3.x, RTS Art. 10, A.8.8, CC7.1),
- identify the evidence gaps an auditor will find first,
- plan the move to one scanning programme with an evidence pack per audit.
Book a free consultation | Vulnerability scanning | ASV scanning | DORA implementation | ISO 27001
