DORA vulnerability scanning and patch rules: what to prove

DORA vulnerability scanning and patch management requirements: what the answer depends on

Article 10 of Delegated Regulation (EU) 2024/1774 requires automated vulnerability scans and assessments of ICT assets, at least weekly for assets supporting critical or important functions, and a patch management process that prioritizes fixes by criticality and risk, tests patches before deployment, sets installation deadlines and escalates missed ones. A financial entity or ICT provider preparing for DORA therefore needs to know which assets fall under that weekly cadence before choosing tools or writing procedures. The regulation does not fix an asset count, a scanner product or a patch window. Those depend on how the organization has mapped its critical or important functions, how many systems support them, how its change process runs and how much downtime its services can absorb. The organization owns these controls and the decisions behind them, including the scan scope, the risk criteria used to rank findings and the emergency patching conditions. An implementation partner such as DeployOpen can plan, deploy and document self-hosted scanning and patch workflows inside the client's own infrastructure, and prepare the records that show the process running. Only an independent auditor or assessor issues a report on whether the controls meet the requirement. DORA does not create a certification scheme. Competent authorities supervise compliance under Article 50 of DORA, so a supervisory review is not a certificate, and no partner can supply one.

Before budgeting, confirm three points with your own teams and any outside party. First, which systems are in scope for weekly scanning, using your critical or important function register. Second, whether your current tools produce asset-level records of detected vulnerabilities and remediation status, since those records are what a reviewer will ask to see. Third, how you will track third-party and open-source libraries used by ICT services that support critical or important functions, and how you will verify that ICT third-party providers handle and report critical vulnerabilities in good time. Each answer changes the scope of work, the people involved and the ongoing effort to keep the process running after go-live. Ask any implementation partner to state in the written scope which assets, tools and evidence are included, and which remain with your team. A fixed scope agreed in writing before work starts makes it clear who prepares what and who signs off the policies. Review the primary text in Regulation (EU) 2022/2554 (DORA) on EUR-Lex and the technical standard in Delegated Regulation (EU) 2024/1774 on EUR-Lex with your legal and security leads before setting the final programme.

Which Article 10 duties apply to scanning, third-party code and patching

Article 10 of the ICT risk management RTS sets out how an entity finds vulnerabilities, watches the code it depends on, and fixes what it finds. The six duties below are meant to run together: scanning finds the gaps, third-party and open-source tracking shows where the gaps sit, and records prove that each finding was handled.

Weekly automated scanning of critical assets

Article 10(2) of Delegated Regulation (EU) 2024/1774 expects automated vulnerability scans and assessments of ICT assets that support critical or important functions, at least weekly. The entity must be able to show the asset list the scans cover, the scan schedule, and the results of each run. Check that scan scope follows the function inventory, so a new server or container that supports a critical function is not silently left out. Scans that skip assets are the most common gap.

Tracking third-party and open-source libraries

Article 10(2) also requires the entity to track the third-party and open-source libraries used by ICT services that support critical or important functions. The entity must be able to show a current component inventory, such as a software bill of materials, for each such service, along with a way to match those components against known vulnerabilities. Check who owns the inventory when a library is pulled in during a build, because libraries added outside the normal release path often go untracked.

Verifying provider vulnerability handling

For ICT third-party service providers, Article 10(2) expects the entity to verify that providers handle vulnerabilities and report critical ones in a timely way. The entity should be able to show the contractual reporting duties, the provider's notification record for critical issues, and the entity's own follow-up on each notice. Ask providers how they notify customers, how quickly, and through which channel, and record the answers so the entity can prove the check was done.

Responsible disclosure procedures

Article 10(2) requires documented responsible disclosure procedures for vulnerabilities. The entity must be able to show how an outside researcher or internal staff member can report a flaw, who receives the report, how it is acknowledged, and how it moves into the remediation queue. A written procedure that names owners and a contact channel is the evidence an assessor looks for first. Confirm that the procedure is reviewed and that reports actually reach the people who triage them.

Prioritizing patches by criticality and risk

Article 10(2) asks that patches be prioritized by criticality and risk, and Article 10(3) and (4) require procedures that use automated tools where possible, define emergency patching, test patches before deployment, set installation deadlines, and escalate missed deadlines. The entity must be able to show the prioritization rule, the emergency patch path, pre-deployment test records, and escalation records for any deadline that was missed. Confirm that the rule accounts for exposure of the asset, not only the vendor severity score.

Vulnerability records and remediation monitoring

Article 10(2) requires records of detected vulnerabilities and monitoring of their remediation until the issue is closed. The entity must be able to show each finding with its asset, severity, owner, due date, and closure evidence, including any accepted risk and who approved it. Check that the register is kept in one place and that open items are reviewed on a set cadence, because an assessor will sample findings from scan output and trace each one to its closure.

Why weekly automated scans on critical assets, and how to define the asset scope

The weekly scanning cadence in Article 10(2) of Delegated Regulation (EU) 2024/1774 applies to ICT assets that support critical or important functions, so the scope decision comes before any tool is configured. Start by listing every system that supports those functions, then trace each one to its hosts, databases, middleware, appliances, containers and cloud resources. Ask who owns each asset and whether it is reachable from the scanner's network. The boundary is set by your own risk assessment, not by a template, so record the reasoning for each exclusion. This inventory depends on the asset register and function mapping described in the DORA policies and documentation work, and an assessor will expect the two to agree.

Scope questions are mostly practical. Confirm whether the scanner can reach assets in each cloud account, subnet and data center segment, and whether authenticated scans are possible for systems that expose little over the network. Container images, ephemeral workloads and vendor-managed appliances often fall outside a network scan unless you plan for them separately. Decide which findings are yours to fix and which must be raised with an ICT third-party provider, since Article 10(2) also requires you to verify that providers handle vulnerabilities and report critical ones in time.

Article 25(1) of Regulation (EU) 2022/2554 lists vulnerability assessments and scans, open source analyses, network security assessments and penetration testing among appropriate tests, so scanning is one component of a wider testing programme rather than the whole of it. Greenbone Community Edition (OpenVAS), licensed under AGPL-3.0-or-later, is an open-source scan engine that runs vulnerability tests from the daily updated Greenbone Community Feed, with gvmd controlling scans over the Open Scanner Protocol. Before relying on it, confirm with the project documentation and your own tests whether it meets your coverage, authenticated scanning, reporting and retention needs.

How an assessor tests the scan and patch cycle, phase by phase

This sequence shows how an independent assessor or competent authority moves from the asset scope down to individual patches and third-party clauses, so the organization can see which evidence each step will ask for before the review starts.

Confirm scope against the asset inventory
The assessor starts by checking which ICT assets the organization has classified as supporting critical or important functions, and compares that list with the asset inventory and the scanner's target list. Gaps usually appear here, such as a production database or a remote management interface that sits outside the scan scope. The step is complete when the assessor can trace each in-scope asset to at least one scan target and to a documented owner. Ask your assessor to confirm how they want the inventory exported and dated.
Sample scan configuration and schedules
Next, the assessor samples scan jobs and their configuration, looking at the scanner's feed update records, the scan schedule and whether automated scans run at least weekly for assets supporting critical or important functions. They also check that authenticated scanning is used where the platform allows it, and that the scope settings match the inventory. The output is a set of scan logs and job histories that show the schedule actually ran, not only that it was configured.
Review vulnerability records and remediation tracking
The assessor reviews the vulnerability register, looking for records of each detected finding, its severity and risk rating, its owner, and its remediation status. They trace a sample of high-severity findings from the scan report to the ticket, the fix and the retest result. A finding closed without a retest, or one that disappears from the register without a recorded decision, is typically raised as a question. The step closes when the assessor has a view of how findings move from detection to verified remediation.
Examine the patch policy and emergency path
The assessor reads the patch and update policy and checks that it describes automated tooling where it is used, the prioritization of patches by criticality and risk, the definition of emergency patching, and the rules for testing before deployment. They compare the written emergency path with how the team actually handled a recent urgent fix, if one exists. The output is a documented gap or confirmation that the policy matches practice. Ask the assessor whether they expect a walkthrough or a document review.
Sample patches with test and deployment evidence
The assessor selects a sample of patches from the period under review and asks for the evidence chain for each: the change record, the test result from a non-production environment, the approval, the deployment record and the post-deployment verification. Patches that reached production without a test record are a common finding. The step is complete when each sampled patch can be followed from the vulnerability record through testing to verified installation.
Review escalation for missed deadlines
The assessor checks the deadlines the organization has set for patch installation and then looks for evidence of escalation where those deadlines were missed. They ask for the escalation rules, the people or committees who receive them, and records showing that exceptions were approved and tracked to closure. A deadline that is written down but never enforced, with no exception records, is usually treated as a control weakness. Confirm with your assessor which period of records they will request.
Test third-party vulnerability handling clauses
Finally, the assessor reviews the contracts and service documentation for ICT providers that support critical or important functions, and checks whether they contain provisions for vulnerability handling and for timely reporting of critical vulnerabilities. They also check whether the organization tracks third-party and open-source libraries used by those services, and whether it verifies provider performance against those clauses. The output is a list of contract clauses mapped to providers, with any gaps recorded. Ask your legal and procurement teams to confirm which contracts are in scope before the review begins.

Run scanning in-house, buy a commercial tool, or outsource it

This table compares three ways to run the weekly vulnerability scanning that Article 10 of Delegated Regulation (EU) 2024/1774 expects for assets supporting critical or important functions. Read each row against your own staffing, evidence needs and contract terms, because the financial entity keeps accountability for scanning and remediation under every option.

Factor	Open-source scanner in-house (for example, Greenbone Community Edition)	Commercial scanning platform operated by your team	Managed scanning and triage by a provider
Who operates the tool	Your security or platform team installs, configures, schedules and maintains the scanner and its feed	Your team operates the vendor's platform, with vendor support for updates and the product itself	The provider runs scans and triage; your team approves scope, reviews results and owns decisions
Who owns the evidence	Your organization owns scan configurations, raw results, records and retention	Your organization owns exports and reports, but confirm how the vendor stores history and whether you can export it	Contract must state that scan records, reports and history are delivered to you and retained for your required period
Recurring effort	Ongoing work on scheduling, credentialed scan accounts, feed updates, capacity and report handling	Licence management, connector upkeep, tuning of scan policies and reviewing findings	Mainly governance: scope changes, reviewing triage, escalation handling and contract oversight
Authenticated scanning	Confirm your team can set up credentialed scans on in-scope systems, since this affects coverage depth	Confirm supported target types and credential handling for your estate	Confirm the provider can scan authenticated and internal targets without weakening your access controls
Coverage of in-scope assets	Confirm weekly scheduling covers every asset supporting critical or important functions	Confirm asset discovery feeds the scan scope so new assets are not missed	Confirm the provider receives your asset inventory and reports scope gaps back to you
Third-party and open-source tracking	Usually needs additional tools or processes; confirm how library tracking is performed	Confirm whether the platform tracks third-party and open-source components used by critical services	Confirm the provider covers library tracking as part of the contract and how it reports findings
Feed updates and support	Community feed updates depend on your own process and timing; confirm your update schedule	Confirm vendor update frequency, support hours and escalation paths in writing	Confirm service levels, response times and the provider's obligations when feeds or scans fail
When this option fits	Teams with in-house security skills, a bounded asset estate and capacity to maintain the tooling	Entities that want vendor support and reporting but keep scanning operations internal	Entities with limited internal staff or peaks in workload, provided they retain strong oversight of results

Who owns scanning and patching, who prepares the evidence, and who assesses it

Your organization remains accountable for every vulnerability and patch decision that affects an ICT asset supporting a critical or important function. Article 10 of the RTS expects the entity to set the rules: how often scans run for which assets, how findings are prioritized by criticality and risk, who accepts residual risk, and how long patches may take before escalation. Those decisions sit with named owners in your governance structure, and the records of them must exist whether or not a partner helped build the tools.

Policy and risk acceptance: Approve the vulnerability and patch policy, define emergency patching, and sign off any finding left open with a documented rationale.
Deadlines and escalation: Set installation deadlines by severity and decide who is escalated to when a deadline is missed.
Records and monitoring: Keep the register of detected vulnerabilities and the record of remediation, including who closed each item and when.
Third-party and open-source tracking: Verify that ICT providers handle vulnerabilities and report critical ones in time, and maintain the list of open-source libraries used by critical or important services.
Contracts: Write vulnerability reporting obligations into provider contracts, since these cannot be delegated away.

Before engaging anyone, confirm that a named owner exists for each of these decisions and that the policy has been approved at the right level of management.

What usually delays patch management work or inflates its cost

Most delays in DORA patch work come from gaps in what the organization knows about its own estate, not from the patching itself. The cards below cover the points where scanning, tracking, deadlines, testing, provider reporting and remediation records most often break down, each with a fix you can check before an assessor or supervisor asks.

Incomplete asset inventory

Scans only cover what is in the scanner's target list. If the asset inventory omits virtual machines, container hosts, network appliances or systems owned by a business unit, those assets never get the weekly scan that Article 10(2) requires for assets supporting critical or important functions. Check that every asset tied to a critical or important function is mapped to a scan target, and reconcile the scanner's target list against the inventory each quarter. Ask who owns that reconciliation and where the result is recorded.

Untracked open-source libraries

Open-source and third-party libraries used by ICT services that support critical or important functions must be tracked. When no component list exists, a vulnerability disclosed in a widely used library cannot be matched to affected systems quickly. Require a software bill of materials or a dependency inventory for each service in scope, and check that it is regenerated at each release. Confirm which team reviews new dependencies before they enter production.

Deadlines that exist only on paper

Article 10 expects patch procedures to set deadlines for installation and to escalate when they are missed. A policy that states a deadline but has no tracking report, owner or escalation path will not show an assessor that the rule operates. Configure the patch tool or ticketing system to flag overdue items, name the person who receives each escalation, and keep a dated record of every escalation and its outcome. Test the escalation path once with a sample overdue item.

Patches deployed without a recorded test

Article 10 requires patches to be tested before deployment. Teams under pressure often push urgent patches straight to production, and the change record then has no evidence of testing. Define which patch categories may skip a full test cycle, such as emergency patches, and require a short test record for every other patch. Each record should name the test environment, the result and the approver. Keep the record linked to the change ticket so the sequence is visible.

Vendor reports with no contractual path

Article 10 requires entities to verify that ICT third-party providers handle vulnerabilities and report critical ones in a timely way. If the contract does not define how a provider notifies you, what timeframe applies and who receives the report, that verification has no basis. Review the contracts for ICT services supporting critical or important functions, confirm the notification clause, and record a named contact at each provider. Test the path with a tabletop exercise that starts from a provider advisory.

Scan results with no closed-loop record

Scanners produce findings, but the findings only satisfy the monitoring requirement if each one is tracked from detection to remediation or documented risk acceptance. Export of raw scan reports to a shared folder does not show that anyone reviewed or closed a finding. Use a register that records the asset, the finding, the criticality, the owner, the due date, the fix or acceptance decision, and the verification scan that confirmed closure. Check a sample of closed items against a fresh scan.

What must exist before an assessor reviews your patch cycle

Before an assessor looks at your patch cycle, you need a documented vulnerability and patch policy approved by the people who own the risk, typically the management body and the owners of ICT risk and operations. Alongside it, keep a scoped asset inventory that marks which systems support critical or important functions, because that marking drives how often scanning must run. Record the scan schedule and the configuration of your scanner, including which asset groups are covered and which credentials and target lists are used. Then run a dry run: pick one critical function, trace it to its assets, and confirm each asset appears in the scan configuration and in the most recent results. The weekly cadence for those assets is the floor set by Article 10(2) of Delegated Regulation (EU) 2024/1774. Your own policy and risk assessment should confirm the frequency, the deadlines and the escalation rules, and you should agree them with your assessor before the cycle starts.

The second group of items covers how patches move. Define an emergency patching path with named approvers and a route that bypasses the normal queue without bypassing testing or records. Write down deadlines for installation by criticality and risk, and the escalation steps when a deadline is missed, since Article 10(3) and (4) expect both. For dry-run evidence, select a recent patch and confirm the file shows a test step completed before deployment, the approver, and the verification afterwards. Keep a remediation log in which every finding links to its ticket, owner, patch or compensating control, and closure date, so the assessor can follow one vulnerability from detection to closure. Confirm with your assessor how they expect test environments and exceptions to be documented.

Last, build a third-party and open-source tracking register. It should list each ICT third-party provider supporting critical or important functions, the vulnerability reporting commitments in its contract, and the dates on which you last checked those commitments. It should also list the third-party and open-source libraries used by those services, their versions and the source you monitor for advisories. A useful dry run is to choose one open-source component, find where it runs, and show how a new advisory would reach the owner and the remediation log. If the register cannot answer that question quickly, the assessor will likely raise it as a gap. Ask your assessor which level of library detail they expect for your size and risk profile.

Questions buyers ask about DORA scanning and patch management

Does weekly vulnerability scanning under DORA apply to every system or only critical ones?

The weekly cadence applies to assets that support critical or important functions. Article 10(2) of Delegated Regulation (EU) 2024/1774 requires automated vulnerability scanning and assessments of ICT assets, at least weekly for those assets. Other assets still fall under the entity's general vulnerability management process, and the entity sets their scanning frequency through its own risk assessment. Start by mapping which systems support critical or important functions, because that map sets the scope of the weekly obligation. Confirm the boundary with your competent authority or your own legal and risk teams before you finalize it.

Can our own team run DORA vulnerability scanning without an outside firm?

Yes, in principle. DORA does not require an external provider for scanning, and the regulation places responsibility for the ICT risk management framework with the financial entity and its management body. Many entities run scanners in-house and keep the records themselves. An outside firm can plan the scanning setup, configure tooling inside your environment, and prepare evidence, but it cannot issue any DORA report or certificate. The question to answer internally is whether your team has the capacity to run weekly scans, triage results, and track remediation to completion.

What does the scanning and patching work need from internal staff?

The work needs clear ownership more than a large team. Expect four recurring roles:

An asset owner who confirms which systems support critical or important functions
An operator who runs and tunes scans and reviews results each week
A patch owner who tests patches before deployment and tracks installation deadlines
A risk owner who approves exceptions and handles escalation when deadlines are missed

In small teams, one person may hold more than one role, but the responsibilities must still be documented and assigned. Ask any implementation partner to name which roles stay with your staff after handover.

How do we verify that a third-party provider handles vulnerabilities properly?

Article 10(2) of Delegated Regulation (EU) 2024/1774 asks you to verify that ICT third-party service providers handle vulnerabilities and report critical ones in a timely way. Verification usually combines contract terms, a defined notification process, and evidence you can review, such as the provider's patch cadence, vulnerability reports for services you use, and its response times for critical issues. Write the expected notification window into the contract where you can. If a provider will not share evidence, record that gap as a risk and decide how to handle it. For background on the broader third-party rules, see the DORA regulation on EUR-Lex.

Do open-source scanning and patching tools satisfy the DORA requirement?

DORA does not name products, so the question is whether a tool produces the outcome the rules require. Greenbone Community Edition (OpenVAS) is an open-source scan engine that runs vulnerability tests from a daily updated feed against target systems, which can support automated scanning and assessment. Open-source tools can also help track third-party and open-source libraries, although that needs a dependency inventory and a process to review findings. Confirm that the tool covers your asset types, that feeds are kept current, and that results are stored as records you can show an assessor. The tool does not replace your procedures or evidence trail.

What drives the cost of DORA scanning and patch management?

Cost depends on five drivers: the number of assets in scope, the complexity of your environment, the tooling you choose, the staff time needed to triage and patch, and the effort required to verify third-party reporting. Some costs are one-time, such as initial scanner setup, asset inventory cleanup, and procedure writing. Others recur, including weekly scan operation, feed maintenance, patch testing, and periodic reviews. Ask any quote to split these components, name who performs each task, and state which evidence it will produce. No DeployOpen price is published, and a quote follows from a written scope.

How long does DORA scanning and patch management work take?

The duration depends on scope and the state of your current environment. An entity with a current asset inventory and existing scanning will usually need less time than one starting from scratch, and the number of critical or important functions drives the workload. DeployOpen does not publish fixed timelines. Most engagements are fixed-scope, so request a written plan that lists deliverables, dependencies on your staff and third parties, and milestones before work starts. If a provider cannot give a written plan that ties tasks to deliverables, treat that as a warning sign.

Can anyone issue a DORA certificate for vulnerability management?

No. DORA sets no certification scheme, so no auditor, consultant or vendor can issue a DORA certificate for scanning or patching. Competent authorities supervise compliance using the powers in Article 50 of the regulation. An implementation partner such as DeployOpen can prepare systems, procedures and evidence, but it does not issue audit reports, attestations or certifications. Any claim of a DORA certificate for this area should prompt a question about what the document actually is and who issued it.

How DeployOpen scopes, implements and prepares patch evidence for DORA

DeployOpen plans and implements self-hosted open-source scanning and patch tooling inside the client's own infrastructure, then prepares the records that show how vulnerabilities were found, prioritized and fixed. The organization keeps ownership of its controls, and an independent auditor or competent authority reviews the evidence.

How we scope

Engagements are fixed-scope, with the in-scope ICT assets and critical or important functions agreed in writing before work starts.
The written scope lists which scanners, feeds, asset sources and patch channels are covered, and which are excluded.
We confirm with your team which third-party and open-source libraries feed services that support critical or important functions.

How we build

We deploy and configure automated vulnerability scanning on a schedule that matches the weekly expectation for critical or important assets.
We set up patch testing stages, emergency patch paths and deadline tracking with escalation when installation dates are missed.
We connect scan results to a vulnerability register so detected issues, owners and remediation status stay recorded and traceable.

How we hand over

We document the vulnerability and patch procedures, including responsible disclosure steps and criticality-based prioritization rules.
We deliver sample scan reports, remediation logs and patch test records so your team can show the process works in practice.
We walk your staff through the tooling, runbooks and evidence locations, and note any gaps that need your own decisions.

How we support

Ongoing support, upgrades and continuous testing are available as retainers once the initial scope is delivered.
Retainers can cover feed updates, scanner maintenance and periodic review of patch deadlines and exception records.
Questions about the independent assessment itself should go to your auditor or competent authority, since DeployOpen does not issue reports or certificates.

DORA vulnerability scanning and patch management requirements