Article 24 DORA testing programme: requirements and evidence

What DORA Article 24 asks a financial entity to run

Article 24 requires a financial entity other than a microenterprise to run a sound, documented, risk-based digital operational resilience testing programme as an integral part of its ICT risk management framework. If you are the compliance lead or CIO, the programme must show that you assess preparedness, find weaknesses and fix them promptly, and that appropriate tests run at least yearly on every ICT system and application supporting a critical or important function. The regulation does not dictate a single test type. It expects a mix of assessments, tests and tools chosen according to the evolving threat landscape, your specific risks and the criticality of each asset and service.

The requirement targets three recurring weaknesses. The first is testing that is ad hoc: a penetration test commissioned once for an audit, with no schedule and no link to the risk register. The second is testing that lacks independence. Article 24 allows internal testers, but only if they have sufficient resources and no conflicts of interest in designing and executing the tests, so the team that built a system should not be the only one that certifies it. The third is findings that never close. The programme must prioritise, classify and remediate every issue that testing and internal validation reveal, and confirm that each weakness is actually fixed.

What makes this hard in practice is usually the inventory, not the tooling. Yearly coverage cannot be planned until you know which systems support critical or important functions, and many entities have not mapped that link cleanly to applications, hosts and cloud accounts. Validation is the other common gap. Teams record a remediation ticket but never retest, so the evidence shows activity rather than closure. Before scoping a programme, confirm with your business function owners which services are critical or important, then decide who validates each fix and how that proof is retained for the competent authority.

Which systems, teams and providers fall under DORA Article 24 scope

Scope under Article 24 is decided before any test is booked. Four questions drive most of the testing workload: whether the entity is a microenterprise, which systems support critical or important functions, how shared platforms are treated, and where provider-operated systems sit in the programme.

Microenterprise status

Article 24(1) and 24(6) exempt microenterprises from the duty to run a full testing programme, but the exemption depends on the entity's actual classification, not its intent to stay small. Confirm the classification with the competent authority's criteria and document the basis for it. If the entity is not a microenterprise, the full programme and yearly testing duty apply to every in-scope system, so the workload changes entirely.

Systems supporting critical or important functions

The yearly testing duty in Article 24(6) covers all ICT systems and applications that support critical or important functions. The first task is to map each function, then trace the systems, applications, data stores and network paths that support it. A function that looks small can depend on identity services, logging or message queues, and each of those dependencies enters the test scope. Record the mapping so an assessor can follow it.

Shared and intra-group platforms

A single identity provider, container platform or database cluster may serve several business lines or group entities. Decide whether the entity tests its own configuration, the shared platform, or both, and document who owns each part. Shared components used for critical functions stay in scope even when another group entity runs them. Agree test access, notification and remediation responsibilities in writing before the testing year starts.

Provider-operated and hosted systems

When an ICT third-party provider runs a system that supports a critical or important function, the entity still needs the testing programme to cover it. Check contract terms for test rights, scope limits and reporting of findings. Where the provider does not permit direct testing, the entity may need to rely on the provider's own testing evidence, and that reliance should be reviewed and recorded as a gap if it falls short. Confirm these terms with the provider and counsel.

Internal and external testing teams

Article 24(4) requires tests to be performed by independent parties, whether internal or external. Scope decisions determine which team can test which system, since an internal team that built or runs a system may lack independence for it. Map each in-scope system to a tester, then check resourcing and conflicts of interest for both design and execution. Gaps here often surface late, when a system is assigned to a team that operated it.

Findings remediation and validation scope

Article 24(5) requires procedures to prioritize, classify and remedy every issue that testing reveals, and to confirm that identified weaknesses are fully addressed. Each in-scope system therefore carries a retest and validation obligation, not only a test. Plan who verifies fixes, how closure is evidenced, and how findings in shared or provider systems are tracked. Open-source findings platforms such as DefectDojo can record this lifecycle, but the process and owners remain the entity's own.

How an assessor tests the DORA Article 24 testing programme

This table lists the points a competent authority or independent reviewer typically examines when testing an Article 24 programme, the approach used at each point, the evidence requested and where programmes most often fall short. Read it as a pre-assessment checklist: each row should have a named owner and a dated artifact before an inspection begins.

Assessment point	Test approach	Evidence requested	Common findings
Programme existence and integration	Check the testing programme sits inside the ICT risk management framework	Approved programme document, link to the ICT risk framework, management body sign-off	Programme is a standalone document with no link to risk decisions
Risk-based selection and rationale	Trace why each system and test type was chosen	Risk-based selection method, asset criticality ratings, documented test rationale	Test choices made without reference to threat landscape or asset criticality
Tester independence	Confirm testers are independent of the teams that built or run the system	Reporting lines, tester appointment records, independence declarations	Internal testers report to the system owner they are testing
Conflict-of-interest controls	Review how conflicts are identified and managed across design and execution	Conflict register, sign-offs at scoping and at test execution, resourcing records	No conflict checks after the initial engagement or during test design
Classification and remediation of findings	Sample findings and follow them from detection to fix	Severity scheme, remediation tickets, owners, due dates, risk acceptance records	Findings logged without severity, owners or deadlines
Validation of closure	Re-test or review a sample of closed findings to confirm the weakness is gone	Retest reports, internal validation records, closure approvals	Findings closed on developer confirmation without independent validation
Yearly coverage of critical or important function systems	Map the systems supporting critical or important functions to tests performed in the last twelve months	Coverage matrix linking systems, functions and test dates, test reports	Inventory incomplete, so some supporting systems were never tested
Programme review and update	Check the programme changes after incidents, new threats and major system changes	Review minutes, version history, lessons-learned records	Programme unchanged for years despite new systems or incidents

Implementing a DORA Article 24 testing programme in sequence

The sequence below takes an entity from identifying the systems behind its critical or important functions to validating that remediated findings stay fixed, with a named record kept at each stage. It is meant to be run as one cycle that repeats every year.

Map critical or important functions to systems
Start by listing the business functions the entity considers critical or important, then trace each one to the ICT systems and applications that support it, including hosting, identity, data stores, interfaces and any self-hosted open-source components. Involve business owners and the teams that operate the systems, because the map is only as good as the people who confirm it. Article 24(6) turns on this map, since yearly testing must cover every system and application supporting a critical or important function. The output is a system-to-function map with named owners, reviewed and approved by the management body or the delegated owner. The step is done when every system in the asset inventory is either mapped to a function or justified as out of scope.
Write and approve the testing programme
Draft the digital operational resilience testing programme as part of the ICT risk management framework. It should state the risk-based approach under Article 24(2) and (3), how criticality of assets and services feeds into test selection, which tests under Article 25 apply to which systems, how TLPT under Article 26 is assessed for applicability, and who is responsible for each activity. Internal ownership sits with the ICT risk function, but the management body must approve the programme. The output is the approved programme document, with version history and a review date. It is done when the approval record exists and the programme links to the system-to-function map.
Select tests for each system tier
For each system or group of systems, choose the assessments and tests the programme requires, such as vulnerability scans, application and API security testing, configuration reviews, scenario tests and penetration tests. Match the depth of testing to the criticality established in the map, and record the reason behind each choice. Open-source scanners such as Greenbone Community Edition, Wazuh vulnerability detection and Fleet can supply part of the evidence for infrastructure and endpoints, but they do not replace the independent testing that Article 24(4) requires. The output is a test plan per system tier, with frequency and tool or method recorded. It is done when every critical or important system has at least one assigned test type and a yearly test date.
Arrange independent testers and collect declarations
Decide which tests run internally and which go to external parties. Article 24(4) allows either, but internal testing needs sufficient resources and must avoid conflicts of interest throughout design and execution. Before each engagement, obtain written independence declarations from testers, covering any role they hold in the systems under test and any reporting line to those who operate them. For external testers, the contract should set scope, rules of engagement, data handling and the evidence the entity will receive. Your team may prepare systems and access for testers, but the entity owns the decision to appoint them. The output is a tester register with independence declarations and signed engagement terms. It is done when each planned test has a named tester whose declaration is on file.
Set up findings intake and triage
Before the first cycle runs, decide where findings land and how they are classified. A consolidation tool such as DefectDojo can import reports from many scanner formats through its interface or API and deduplicate findings using per-tool hashcode fields, which gives one register across tools and testers. Set a classification scheme that lets the team prioritise issues by severity and by the criticality of the affected function, as Article 24(5) requires. Assign an owner to every triage decision. The output is a findings register with classification rules and a triage log. It is done when a test report from each tool in use can be imported and every finding carries a severity, a system link and an owner.
Run the first annual testing cycle
Execute the planned tests on schedule, record the scope, dates, tester and tool version for each run, and keep raw outputs alongside the consolidated register. Track any test that slips, with the reason and the approved revised date. Where a test uncovers a serious weakness, escalate it through the same triage path rather than waiting for the cycle to close. The output is a dated test record for every critical or important system, plus an exceptions log. It is done when each system in the map has a completed test that matches the approved plan for the year.
Remediate findings and validate the fixes
Remedy each prioritised finding with a documented action, an accountable owner and a target date set by the entity. Article 24(5) requires procedures that remedy all identified issues and confirm they are fully addressed, so closing a ticket is not enough. Validate each fix with a retest, a configuration check or an internal validation method, and record the method and result. Findings accepted as residual risk need a documented decision by the appropriate level of management. The output is a remediation and validation record for every finding, with accepted risks signed off. The cycle closes when no open finding lacks a validation record or an approved acceptance, and the results feed the next programme review.

Open-source tools that collect and organize testing evidence

Article 24 requires a testing programme that is run, prioritized and remediated over time, which means findings from many sources must end up in one traceable record. The four tools below are self-hosted options that can collect scan output, deduplicate it and track remediation. None of them replaces independent testers or the validation that Article 24(5) requires.

DefectDojo for findings consolidation

DefectDojo imports and reimports findings from more than 500 security tool report formats through its user interface or API, and it also accepts a generic findings import. It deduplicates findings using per-tool hashcode fields, which keeps one weakness from appearing as several open items across scanners. Check which report formats your scanners export, whether your team will feed reimports on a fixed schedule, and how deduplication settings are reviewed. The licence is BSD-3-Clause, and the open source edition includes the import capability.

Greenbone Community Edition scanning

Greenbone Community Edition (OpenVAS) runs scheduled vulnerability scans through the gvmd management service, which stores results in PostgreSQL and manages users and permissions. Operators run scans and review results in the Greenbone Security Assistant web interface, so the scan history becomes a durable record of what was tested and when. Confirm the scan coverage needed for your critical or important functions, the update cadence for vulnerability feeds, and who holds administrative rights. The licence is AGPL-3.0-or-later, so review its obligations with counsel before modifying and distributing the code.

Wazuh vulnerability detection on endpoints

Wazuh correlates the software inventory that each agent collects with the Wazuh CTI vulnerability repository, or with a locally hosted offline copy, to identify vulnerabilities in the operating system and installed applications of monitored endpoints. This provides continuous coverage between scheduled tests, and the inventory data shows which systems were in scope. Check agent coverage against your asset inventory, decide whether your environment can use an offline vulnerability copy, and confirm that the GPL-2.0-only licence fits your deployment. Wazuh findings should feed the same remediation tracking as your other test results.

Fleet software matching on enrolled hosts

Fleet (MIT) detects vulnerable software on enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Each match gives a record that an identified weakness existed on a named host at a given time, which supports prioritization and remediation tracking. Confirm which operating systems your enrolled hosts run, which advisory sources apply to them, and how matches are routed into your findings process. Fleet covers software inventory and matching, so it complements rather than replaces penetration testing.

Keeping the testing evidence current between annual cycles

The annual testing requirement in Article 24(6) is only as defensible as the records that sit around it. An assessor reviewing the programme at the next cycle will want to see that the testing scope still matches reality, so the first recurring task is keeping the critical or important function map current. Each time a system, application or ICT provider supporting such a function is added, changed or retired, the map and the list of systems in scope for testing should be updated together. Record the date of each change and who approved it. If a provider change alters where a function runs, note that too, because a test that covered the old architecture may no longer cover the new one.

Every change to test scope needs a written reason. Keep a dated scope log that states what was added or removed, the risk reasoning behind the decision (for example, why a low-criticality tool was excluded or why a new API was brought in), and the approver. The reasoning matters as much as the decision, because Article 24(2) and (3) tie the programme to a risk-based approach that reflects the evolving ICT risk landscape and the criticality of assets and services. Retain every test report with its date, the tester's identity and the version of the system tested. Where a tool such as DefectDojo is used, its import history and per-tool deduplication hashes help show when a finding first appeared and when it was closed, provided the reimport records are kept rather than overwritten.

Article 24(5) expects all identified weaknesses to be fully addressed, so the remediation trail is the artifact most often challenged. Keep remediation tickets linked to their originating findings, with the priority and classification assigned, the owner, the dates of fix and of internal validation, and the retest result. Track validation outcomes through the year rather than reconstructing them in the weeks before an assessment. Confirm with your assessor which validation method they expect for your environment, since the standard does not prescribe one. A practical check each quarter is to sample a few closed findings and confirm that the retest evidence exists and matches the fix.

What meeting the DORA Article 24 testing programme costs

This table sets out the main cost components of running an Article 24 testing programme, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No price is given here, because a quote follows from the written scope, so use the drivers to ask the right questions when you request one.

Cost component	One-time or recurring	What drives it up	How to keep it down
Tooling and licences	Recurring	Commercial scanner and test platform licences priced per host, asset or user, and the number of environments in scope	Use open-source scanners and findings platforms where they fit the scope, and confirm each licence type with the vendor before assuming zero spend
Internal engineering time for scoping	One-time per cycle, recurring yearly	Large or poorly inventoried estates, many systems supporting critical or important functions, and unclear ownership	Keep an accurate asset inventory and a current list of critical or important functions so scope is fixed in writing early
Internal remediation effort	Recurring	High finding volumes, duplicate findings across tools, and weak prioritisation of issues	Deduplicate findings in one place, classify by criticality, and set owners and deadlines for each class of issue
External testing or independent review	Recurring, usually yearly per test	Number of systems tested, depth of manual testing, retesting after remediation, and tester independence requirements	Define test objectives and scope in a written statement of work, and ask for retest terms in the initial quote
Evidence upkeep	Recurring	Manual collection of scan reports, sign-offs and remediation records across several tools	Automate report export and keep test records in one system with consistent naming and retention rules
Responding to assessor sampling	Recurring, unpredictable	Gaps in records, missing validation of fixes, and evidence scattered across teams	Keep a per-finding trail from detection to validated closure so samples can be answered quickly

Who does what for Article 24: your team, a partner and the auditor

Your organization owns the testing programme required by Article 24(1). Usually this stays in-house: the management body approves the programme and its resources, a named owner maintains it inside the ICT risk management framework, and staff decide which systems support critical or important functions. Internal testers, where you use them, must have enough resources and must avoid conflicts of interest throughout design and execution.

Programme ownership: keeps the programme current and reviews it on a defined cycle, so it reflects the evolving ICT risk landscape.
Risk basis and criticality: decides which assets and services are critical or important, and documents why, under the risk-based approach in Article 24(2) and (3).
Yearly coverage: confirms that every system and application supporting critical or important functions receives appropriate tests at least yearly, as Article 24(6) requires.
Remediation decisions: prioritizes, classifies and assigns an owner to each finding, then accepts closure only after validation.
Tester independence: sets the rules that keep internal test design and execution free of conflicts.

Check that a named person can explain the risk basis, the criticality list and the remediation record without relying on a vendor.

Where Article 24 programmes usually fall short and how to close each gap

Most Article 24 programmes fail on paperwork and follow-through rather than on the tests themselves. The gaps below cluster around four questions an assessor asks: why was this tested, who tested it, what happened to the findings, and did the testing reach every system that matters.

Testing with no documented risk rationale

Article 24(2) and (3) expect a risk-based programme, so a yearly calendar that runs the same scans on the same systems does not show why each test exists. Document a short rationale per test that links to the threat landscape, the asset's criticality and recent changes. Ask for the programme document to name the test type, the system, the trigger and the owner for each entry, and check that the rationale changes when the risk picture changes.

Internal testers without independence safeguards

Article 24(4) allows internal testers, but only with sufficient resources and no conflicts of interest during design and execution. Teams that build a system also test it, and the assessor will ask who approved the test scope. Separate the role that designs and runs the test from the role that accepts the result, record that separation in the test plan, and keep a written conflict-of-interest declaration for each internal tester.

Findings logged but never validated

Article 24(5) requires procedures to prioritise, classify and remedy every issue a test reveals, and to confirm that each weakness is actually fixed. A ticket marked closed by the engineer who fixed it is not validation. Require a retest or an internal validation step before closure, and keep the retest result alongside the original finding. Tools such as DefectDojo can track deduplicated findings from many report formats, which makes it easier to show each finding's full history.

Critical function maps that are out of date

Article 24(6) requires yearly testing of all ICT systems and applications that support critical or important functions, so the testing scope is only as good as the function map behind it. Maps often lag behind new integrations, retired applications and shifted dependencies. Tie the map to the change process so that any new system or dependency triggers a scope review, and ask for a dated map signed by the function owner.

Yearly coverage that misses systems behind ICT providers

Systems that support a critical function often sit partly with an ICT third-party provider, such as a hosted platform, a managed database or a SaaS integration. If the test scope stops at the entity's own perimeter, the yearly requirement is not met for the whole function. Confirm in each ICT contract whether the provider permits testing or supplies independent assurance, and record any component that cannot be tested directly.

Questions buyers ask about the DORA Article 24 testing programme

Does a small entity or microenterprise have to run a DORA testing programme?

Article 24(1) exempts microenterprises from the requirement to establish a digital operational resilience testing programme, and the yearly testing duty in Article 24(6) also applies to entities other than microenterprises. Every other financial entity in scope must run a programme, although its size and complexity shape how far it goes. Smaller firms should confirm with their competent authority how proportionality applies to their own entity type, and should check the lighter regime that Article 25 describes for microenterprises before assuming a reduced scope.

Can our own staff perform the tests required under Article 24?

Yes, Article 24(4) allows internal testers as well as external ones, provided the tests are performed by independent parties. The entity must give internal testing sufficient resources and avoid conflicts of interest throughout design and execution. In practice this means the people who build or run a system should not be the only people who test it, and the testing function should be able to report findings without pressure from the teams it reviews. Confirm how your supervisor expects independence to be shown in your own governance documents.

How much effort and time does the first testing cycle take?

No supplied source gives a duration or cost for the first cycle, so any figure you hear should be treated as a vendor estimate until you check it against your own scope. The main drivers are the number of systems and applications that support critical or important functions, how many of them are new or poorly documented, how much testing already happens, and how many findings need remediation and revalidation. Ask for a written scope that lists each system, the test types planned under Article 25, the testers, the deliverables and the dates, and compare quotes on that basis.

What does the work need from our own staff?

Your own staff keep ownership of the programme, the risk decisions and the remediation. Typical inputs include an up-to-date inventory of systems that support critical or important functions, access to environments and logs, named system owners who can confirm scope and accept findings, and a change process that tracks how each weakness is fixed. Staff also need time to triage results, decide priorities under Article 24(5), and confirm that fixes address the root cause. Ask any partner to show in writing which of these tasks they perform and which remain with you.

Can we run the Article 24 programme without an outside partner?

A financial entity can run the programme in-house if it has enough qualified and independent people, sufficient resources and a documented process, because Article 24 allows internal testing. Many entities still find that a gap exists in tooling, specialist skills or independence. Open-source tools can produce much of the evidence, for example by importing scanner output into DefectDojo, which the supplied sources describe as importing findings from more than 500 security tool report formats and deduplicating them. Tools do not satisfy the requirement on their own, so you will still need a documented programme and people to act on the results.

When does an outside partner add real value to the programme?

An outside partner is most useful when your team lacks specialist testing skills, needs an independent view of its own systems, or must deliver a testing cycle on a fixed timeline. Partners can also set up scanning, findings tracking and evidence collection so your staff can focus on decisions. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms in your own infrastructure, and runs security testing of applications, APIs, cloud and infrastructure. It prepares systems and evidence but does not issue reports or attestations. Most engagements are fixed-scope, with the scope and deliverables agreed in writing before work starts.

How does Article 24 relate to threat-led penetration testing under Article 26?

Article 24 sets a general testing programme that applies to most entities, while Article 26 covers threat-led penetration testing, which only certain entities must run and which is more advanced. Article 24(2) and (3) connect the programme to the test types in Article 25 and the advanced methods in Article 26. A TLPT is one part of a wider programme, not a replacement for yearly testing of critical or important systems under Article 24(6). Check with your competent authority whether TLPT applies to your entity, and read the Article 26 requirements before planning how the two sets of tests fit together.

How DeployOpen scopes and prepares Article 24 evidence

DeployOpen plans and implements the testing programme inside your own infrastructure, using self-hosted open-source platforms to run, track and document tests. Your organization owns the programme and its risk decisions, while DeployOpen prepares the systems, test records and remediation evidence that an independent tester or assessor can review.

How we scope

Scope is agreed in writing before work starts, listing the ICT systems and applications supporting critical or important functions.
We map which systems fall under the yearly testing expectation and record the reason each one is in or out of scope.
Scope documents name who is independent of the systems being tested, so conflicts of interest are visible from the start.

How we build

We deploy self-hosted scanning and findings tools in your environment, such as DefectDojo for consolidating results from many tool formats.
Vulnerability scanning with Greenbone and endpoint software inventory checks through Wazuh or Fleet are configured to run on defined schedules.
Deduplication and severity rules are set so findings are prioritized, classified and tracked to closure in one place.

How we hand over

Deliverables include the testing programme document, scope records, test schedules and tool configurations, all stored in your environment.
Remediation records show each finding, its priority, owner, fix and the internal validation step that confirms it is closed.
Your staff receive documented runbooks so the programme can continue after the engagement ends, and you confirm the handover in writing.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer if your team wants help running the yearly cycle.
Retainer scope, response expectations and service levels should be confirmed in writing, since they vary by agreement.
Ask any auditor or assessor which evidence formats they accept, so the records DeployOpen prepares match their review needs.

Article 24 Digital operational resilience testing programme