Article 25 testing of ICT tools and systems: what the menu requires
Article 25 of DORA requires a financial entity to run a set of appropriate tests on its ICT tools, systems and processes, chosen according to risk. It does not prescribe one fixed test. The article is a menu: vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing. The risk these tests address is the undetected weakness, particularly in ICT assets that support critical or important functions, where a flaw could disrupt a service that customers or the market depend on. Your task is to decide which tests fit which assets, and to show the regulator why that mix is right for your risk profile.
The hard part is not knowing the menu exists. It is choosing scope, keeping testing current and proving the results were acted on. Scope is difficult because the asset inventory must be complete and accurate before any test can be sensibly targeted, so confirm that your inventory links each system to the critical or important functions it supports. Currency is difficult because systems change, and a test run once a year against a moving estate tells you little about today. Automated tooling helps here. For example, Wazuh vulnerability detection correlates each agent's software inventory with a vulnerability repository, and the Wazuh documentation describes how to run that repository from a locally hosted offline copy. Confirm with your own environment whether an offline feed suits your network. Closing the loop means recording each finding, its owner, its remediation and the retest that validated the fix.
Two related articles sit beside this one and should not be confused with it. Article 24 sets the wider testing programme that every entity other than a microenterprise must run, including tester independence and remediation tracking. Article 26 covers threat-led penetration testing for the entities that must run it, with its own scope and supervisory attestation. Article 25(3) gives microenterprises a lighter route: a risk-based approach combined with strategic planning of ICT testing, balancing resources and time against urgency, risk type and asset criticality. Article 25(2) adds a specific duty for central securities depositories and central counterparties to run vulnerability assessments before deploying or redeploying applications, infrastructure and ICT services that support critical or important functions. Ask your competent authority or legal advisers how these provisions apply to your entity type.
Which entities and systems Article 25 applies to
Article 25 applies to the testing programme that Article 24 requires, so scope starts with who must run it and which systems fall inside it. The decisions below change how much testing an entity carries and how quickly it must run it.
Entities inside the testing programme
Every financial entity in scope of DORA must run the testing programme, except that Article 25(3) gives microenterprises a different route. Confirm your entity type against Article 2(1) first, because the category determines whether you follow the full menu of tests or the risk-based approach. Document the decision in your testing policy so an assessor can trace why each entity type was included or excluded.
Central securities depositories and central counterparties
CSDs and CCPs must run a vulnerability assessment before any deployment or redeployment of applications, infrastructure components and ICT services that support critical or important functions. This is a gate in the change process, not a yearly exercise. Expect the workload to follow your release cadence, so the pipeline needs an assessment step that cannot be skipped.
Microenterprises and the risk-based approach
Microenterprises must combine a risk-based approach with strategic planning of ICT testing under Article 25(3). The plan balances the resources and time you allocate against urgency, type of risk and the criticality of assets and services. Record the rationale for each choice, because a small team with a short plan will be judged on whether the reasoning holds.
Critical or important functions as the scope filter
Several testing duties depend on whether an ICT system supports a critical or important function. Map each function to the systems, applications and services that run it, then tag them in your asset inventory. The tagged list drives the weekly scanning expectation in Article 10 of Delegated Regulation (EU) 2024/1774 and the scope of the yearly testing in Article 24.
ICT assets and third-party-hosted systems
Testing covers the ICT assets you operate, including endpoints, network components and self-hosted platforms, and it also reaches systems that a provider hosts for you. Agree in the contract what testing you may perform, who performs it, and how findings are shared. Where a provider restricts testing, record the compensating evidence you collect instead.
Simplified regime under Article 36
Entities that qualify for the simplified regime follow the ICT security testing requirements set by Article 36 of Delegated Regulation (EU) 2024/1774 instead of the broader programme. Confirm whether your entity qualifies before you size the programme, since the qualification changes which tests you must run. Ask your supervisor or counsel to confirm the category in writing if the boundary is unclear.
How an assessor tests Article 25 compliance
This table compares each test family in the Article 25(1) menu, the approach an assessor takes, the evidence they request and the findings they see most often. Read it as a checklist of what the file must show, with the documented rationale for test selection tying the rows together.
| Test family | Assessor approach | Evidence requested | Common findings |
|---|---|---|---|
| Vulnerability scans and inventories | Confirm scan coverage against the asset inventory, then sample hosts to check scans ran and results were triaged | Scanner configuration, scan schedules, asset inventory reconciliation, triage tickets with dates | Assets missing from scan scope, scans run but findings never triaged, weekly cadence not evidenced for critical functions |
| Open source analyses | Check that third-party and open-source components are inventoried and matched against known vulnerability sources | Software bill of materials or package inventory, advisory matching output, remediation or risk acceptance records | Dependencies with no owner, advisories not linked to affected systems, no record of accepted risk |
| Network security assessments | Review segmentation and exposed services, then test whether the documented network design matches the live network | Network diagrams, firewall rule reviews, scan results of external and internal exposure, change records | Diagrams out of date, rules without business justification, unexpected exposed services |
| Gap analyses | Compare the current ICT controls against the requirements the entity has adopted and check the gaps have owners | Gap analysis report, control mapping, remediation plan with owners and status | Gap analysis performed once and not refreshed, gaps listed without owners or target dates |
| Physical security reviews | Walk through data center or office access controls relevant to ICT assets supporting critical or important functions | Access control records, review reports, photographs or sign-off by facilities owners where applicable | Reviews scoped only to cloud providers with no view of on-premises or hosting sites |
| Questionnaires and scanning software | Test whether questionnaire answers match observed configuration rather than accepting self-assessment alone | Completed questionnaires, sampled evidence supporting answers, reconciliation notes | Answers unsupported by configuration evidence, questionnaires not updated after changes |
| Source code reviews (where feasible) | Check the feasibility decision, then sample repositories for review coverage, protected branch settings and automated scanning in pipelines | Feasibility rationale, review records, branch protection configuration, pipeline scan logs | No documented feasibility decision, reviews skipped for urgent releases, direct pushes to protected branches |
| Scenario-based and compatibility tests | Walk through scenarios tied to the entity's critical functions and verify results were recorded and acted on | Scenario catalogue, test plans, results, lessons learned and corrective actions | Scenarios generic and not tied to critical functions, no compatibility testing after upgrades |
| Performance and end-to-end tests | Check that capacity and end-to-end tests cover systems supporting critical or important functions under load | Test plans, load profiles, results against stated thresholds, sign-off | Tests run on non-representative environments, no thresholds defined, results not compared with requirements |
| Penetration tests | Review scope, tester independence and remediation tracking, then sample findings through to closure | Scope statements, tester qualifications, reports, retest evidence, remediation tickets | Scope excludes critical systems, findings closed without retest, testers without documented independence |
| Pre-deployment vulnerability assessment (CSDs and CCPs) | Check that assessments happen before each deployment or redeployment of relevant applications, infrastructure and services | Change records linked to pre-deployment assessment results, release approvals, assessment scope statements | Assessments completed after go-live, emergency changes with no assessment, scope not covering infrastructure components |
| Microenterprise risk-based testing plan | Check the strategic plan balances resources and time against urgency, type of risk and asset criticality | Written testing plan, risk rationale, resource allocation, dated reviews of the plan | Plan absent or generic, no link between chosen tests and the entity's risk assessment |
How to build an Article 25 testing plan step by step
This sequence turns the Article 25 test menu into a plan an assessor can follow, from knowing which assets matter to proving that every finding was tested, fixed and recorded.
Inventory ICT assets and flag critical or important functions
Start by listing every ICT asset that supports a business function: applications, infrastructure components, endpoints, cloud services and self-hosted platforms. For each asset, record its owner, the function it supports and whether that function is critical or important under your own assessment. The ICT risk owner signs off the inventory and the flagged list. You know this step is done when every asset in scope has an owner and a function, and the flagged subset is approved by management and linked to your ICT asset register.
Map test types to each asset class
Choose which Article 25(1) test types apply to each asset class, such as vulnerability scans, open source analysis, network security assessments, source code reviews where feasible, scenario-based tests, performance testing, end-to-end testing or penetration testing. Record the rationale for each choice, including tests you consider not applicable and why. The output is a testing matrix approved by the information security function. It is complete when every asset class has at least one assigned test type and every exclusion has a written reason.
Set the testing frequency and automated scanning cadence
Define how often each test type runs for each asset class. For assets supporting critical or important functions, configure automated vulnerability scanning to run at least weekly, as Article 10 of Delegated Regulation (EU) 2024/1774 requires. Confirm with your platform and security team that scanner coverage matches the flagged inventory, and that scan schedules and scope are written down. The completed schedule, with the scanner configuration exported, is complete when the weekly cadence is demonstrable for every flagged asset.
Configure scanning and code review tooling
Deploy the tools that generate evidence for the scanning and code review tests. For example, Wazuh vulnerability detection can correlate endpoint software inventories with a vulnerability repository, Fleet can match installed software against advisory sources, and Semgrep can scan repositories in CI/CD pipelines. GitLab protected branches can limit who pushes or merges to production code. Document each tool, its version, its data sources and its scope. The security engineering lead confirms the configuration. The step is done when scan results and code review outputs are retained and can be retrieved for an assessor.
Schedule deeper tests and pre-deployment checks
Schedule scenario-based, performance, end-to-end and penetration tests against the assets where your risk assessment calls for them, and identify any deployments that need a pre-deployment vulnerability assessment. Central securities depositories and central counterparties must run that assessment before deploying or redeploying applications, infrastructure and ICT services supporting critical or important functions under Article 25(2). Microenterprises should instead plan testing on a risk basis under Article 25(3). The output is a dated test calendar tied to the matrix. Confirm with your competent authority or advisers which obligations apply to your entity type.
Define triage and remediation for findings
Write a procedure that tells the team how each finding is classified, who assesses its severity, how it is assigned, and what deadline or escalation path applies. Include how risk acceptance is decided and by whom, and how fixes are validated by retesting. Your triage record should show the decision for each finding, including accepted residual risk approved by the appropriate manager. The procedure is complete when it is approved and the first findings are processed under it, with closure evidence attached.
Maintain a test register linking tests, results and fixes
Create a test register where each row links a test, its asset, its date, its tester, its result, the finding identifiers and the remediation or retest that closed it. Scanner exports, penetration test reports and code review results are stored against their rows. Review the register at a regular cadence set by management and record the review. An assessor should be able to pick any asset in the inventory and trace its tests, findings and fixes through the register. The step is complete when that trace works end to end for a sample of assets.
Which evidence satisfies Article 25 and how to keep it current
Article 25 testing is judged on what an entity can show, not on what it says it does. The cards below cover the artifacts a supervisor or independent assessor is likely to ask for, and the routines that keep each one current between reviews.
Testing plan and risk rationale
The written testing plan states which tests from the Article 25(1) menu apply to which systems, how often they run, and why. The risk rationale should tie each choice to the criticality of the asset and the threats it faces. Check that the plan names an owner, carries a version and approval date, and is revisited when the risk assessment or the systems in scope change. An assessor will compare the plan against what was actually run.
Asset inventory tied to test scope
Testing only means something if it covers the right assets. The inventory should list the systems, applications and infrastructure components that support critical or important functions, with the test types assigned to each. Export it on a fixed schedule and tag entries when they are deployed, retired or moved. Gaps between the inventory and the scan or test scope are the first thing an assessor is likely to probe.
Scan outputs and their history
Vulnerability scan results prove that scanning happened, on which assets, and with what findings. Keep dated exports rather than only the live dashboard, because a dashboard shows the current state and not the trend. Confirm that scan frequency meets the weekly expectation for assets supporting critical or important functions in Delegated Regulation (EU) 2024/1774, and that the retained history covers the period under review. Tools such as Wazuh and Fleet can produce these exports from a self-hosted deployment.
Scenario, performance and penetration test reports
Each scenario-based, performance, compatibility, end-to-end or penetration test should produce a report that records scope, method, tester, dates, findings and severity. Reports should be signed off by someone accountable for the system. Check that the tester's independence is documented, because Article 24 expects testers to be independent. A report with no stated scope or no date is hard to rely on, however detailed the findings look.
Pre-deployment assessment records
For central securities depositories and central counterparties, Article 25(2) requires a vulnerability assessment before any new or changed application, infrastructure component or ICT service supporting critical or important functions goes live. Keep a record for each deployment that links the assessment to the change ticket, the approver and the outcome. Other entities should still apply the same discipline to significant changes, since a pre-deployment record is simple evidence of change control.
Remediation and retest trail
Findings are only closed when the fix is verified. Keep a register that links each finding to its owner, due date, fix, and the retest that confirmed closure. Protected branches in GitLab can enforce that code changes pass review before merging, which gives a traceable record for code-level fixes. Review the register at each governance meeting and record any risk accepted in place of a fix, with the approver's name.
What meeting Article 25 costs in money and effort
This table breaks down the cost components of an Article 25 testing programme, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to structure a written scope and to compare quotes line by line, since no price list applies and the figures depend on your own environment.
| Cost component | One-time or recurring, and who is paid | What drives it up or down | How to keep it down |
|---|---|---|---|
| Tooling and licenses | Recurring for commercial scanners and SaaS testing platforms. One-time setup for self-hosted tools, with recurring infrastructure and maintenance. | Number of endpoints, applications and cloud accounts in scope; commercial per-asset licensing; number of environments scanned. | Use self-hosted open-source tools such as Wazuh, Fleet and Semgrep Community Edition, which carry no license fee; confirm each tool's license terms before adoption. |
| Engineering time for scan configuration and triage | One-time for initial configuration and rule tuning; recurring for triage of findings. Paid through internal staff or an implementation partner's fixed-scope work. | Asset inventory quality, scan frequency, how many false positives the environment generates, and how many teams own findings. | Maintain an accurate software inventory, tune rules once per environment, and agree triage ownership and service levels in writing before work starts. |
| Scan frequency and automated vulnerability scanning | Recurring. Compute and staff time for each scan cycle, plus alert handling. | Article 10 of Delegated Regulation (EU) 2024/1774 requires at least weekly scanning of assets supporting critical or important functions, so scope of those assets sets the floor. | Limit continuous scanning to critical or important functions and run broader scans on a risk-based schedule where the entity's own assessment allows it. |
| Evidence upkeep | Recurring. Internal staff time to store scan outputs, test records, remediation tickets and sign-off trails. | Number of test types run, retention period set by the entity's policy, and how many systems feed the evidence repository. | Generate evidence automatically from tooling, keep one repository per testing programme, and define the evidence list in the testing procedure before the first cycle. |
| External penetration testing or independent review | Recurring, usually per test cycle. Paid to an external tester or assessor, with one-time scoping work for the first engagement. | Number and complexity of systems in scope, depth of testing, whether the tester is internal or external, and retest effort after remediation. | Scope tests to systems supporting critical or important functions, reuse scoping documents across cycles, and ask the tester to separate initial findings from retests in the quote. |
| Pre-deployment vulnerability assessments (CSDs and CCPs) | Recurring for each deployment or redeployment, under Article 25(2). Staff or partner time per change. | Release frequency, number of applications and infrastructure components changed, and whether assessments are integrated into change workflows. | Embed assessments in the change pipeline, for example using GitLab protected branches to enforce review before merge, rather than running separate manual reviews. |
| Source code review | One-time for initial review of critical code; recurring for pipeline scanning. Paid through staff time or a reviewer. | Codebase size, language mix, and whether review is done manually or in CI/CD. | Run automated scanning in CI/CD and reserve manual review for code paths tied to critical or important functions, where feasible under Article 25(1). |
| Auditor or assessor sampling effort | Recurring with each supervisory or independent review cycle. Paid by the entity for the time the reviewer spends sampling evidence. | Number of systems sampled, how complete the evidence is, and how many findings require explanation. | Keep evidence indexed by system and test type, and answer requests from a single repository, which limits the time reviewers spend searching. |
Which open-source tools produce Article 25 evidence
Article 25 asks for a menu of tests, and each test needs a record that shows it ran, what it found and how the findings were handled. The four tools below produce some of that evidence for endpoints, hosts and source code, but none of them covers the full menu, so confirm coverage in your own environment before relying on any output.
Wazuh vulnerability detection
Wazuh (GPL-2.0-only) correlates the software inventory collected by each agent with the Wazuh CTI vulnerability repository, or a locally hosted offline copy, to identify vulnerabilities in the operating system and installed applications of monitored endpoints. The output supports the vulnerability assessment and scanning test named in Article 25(1). Check that agents are deployed on every in-scope endpoint, that the offline copy is refreshed on a schedule you can document, and that the GPL-2.0-only license terms fit how you distribute or modify the software. It does not test networks, physical sites or application logic.
Fleet software vulnerability matching
Fleet (MIT) matches installed software on enrolled hosts against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Its reports give a dated view of which hosts carry which vulnerable packages, which supports the vulnerability assessment evidence Article 25 expects. Confirm that every host in scope is enrolled, that the advisory sources cover your operating systems, and how your team records exceptions. Fleet does not perform penetration tests, scenario exercises or review of physical security.
GitLab protected branches for change evidence
GitLab Community Edition (MIT) protected branches let maintainers restrict which roles can push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. These settings produce evidence that code changes to ICT systems followed a reviewed path, which supports testing of changes before deployment. Confirm the protected branch rules are applied to every release branch, and that exceptions are logged. Protected branches do not test the code itself, so pair them with a scanner and with the test records themselves.
Semgrep code scanning in CI/CD
Semgrep Community Edition (LGPL-2.1-only) scans code in languages including C/C++, C#, Go, Java, JavaScript, TypeScript, Python, Ruby, Rust, PHP, Kotlin, Swift and Terraform, using community or custom rules. Running it in CI/CD pipelines produces a repeatable record of static findings for each commit, which supports the source code review Article 25(1) lists where feasible. Confirm that your languages appear in the supported list, that custom rules reflect your secure coding standard, and that findings are triaged and tracked. It does not cover running applications, dynamic behavior or infrastructure configuration outside Terraform.
Who owns Article 25 testing and what to outsource
The financial entity owns its testing programme. Its management body approves the testing approach, accepts residual risk and signs off the results, and its internal teams decide which tests apply to which systems, how findings are ranked and when remediation is complete. Outsourcing a test does not transfer any of these responsibilities. The entity must be able to explain why a given test type was chosen for a given asset, and why some tests were not performed.
- Test selection: Deciding which Article 25(1) test types apply to each ICT system, based on criticality and the risk assessment.
- Risk acceptance: Recording what is accepted, deferred or mitigated, with a named owner and a date.
- Remediation tracking: Assigning fixes to system owners and confirming they were validated, not just closed.
- Management body sign-off: Documenting that the board or equivalent body reviewed the programme results.
- Asset scope: Keeping the inventory current so scans and tests reach every in-scope system.
Before engaging any partner, confirm internally who holds each of these decisions and how they are minuted.
An implementation partner such as DeployOpen can prepare the technical machinery that Article 25 testing depends on. This includes deploying scanners in the entity's own infrastructure, wiring scanning into delivery pipelines, building test environments that mirror production, and collecting logs, scan outputs and tickets into an evidence set. A partner can also perform security testing within a written scope. The partner prepares systems and evidence. It does not issue reports, attestations or certificates, and it cannot tell a supervisor that the entity complies.
- Scanning deployment: Configuring tools such as Wazuh or Fleet against the entity's asset inventory, inside its own environment.
- Pipeline integration: Adding code review and static analysis steps, for example with Semgrep, and branch protection with GitLab.
- Test environments: Building scenario, performance and end-to-end environments that the entity controls.
- Evidence collection: Structuring scan results, change records and remediation tickets so the entity can hand them over.
- Testing within scope: Running penetration or security tests under a written scope, with agreed deliverables.
The key limit is independence. A firm that builds the controls and then assesses them cannot give the same independent view as a separate tester, so ask how the scope separates building from testing.
An independent auditor or the competent authority examines the testing programme and its evidence and reaches its own conclusions. Neither the entity nor its partner decides the outcome. The supervisor relies on documentation that shows what was tested, how often, by whom, what was found and whether the findings were fixed and validated. Where a threat-led penetration test has been run under Article 26, the supervisor's attestation is the only authority-issued document the Regulation provides for, and it addresses that test alone.
- Sampling: Selecting systems and test records at random or by risk to check the programme works in practice.
- Traceability: Following a finding from scan output through ticket, fix and revalidation.
- Independence checks: Asking who performed each test and whether the tester was separate from the team that built the system.
- Coverage gaps: Comparing the asset inventory with the systems actually scanned or tested.
- Governance evidence: Reviewing management body records and the approved testing policy.
Before the review starts, confirm with the entity's own compliance lead which assessor will examine the evidence and what that assessor expects to receive.
Where Article 25 testing usually falls short
Article 25 testing often looks complete on paper and still leaves gaps that an assessor or supervisor will find. The cards below cover the decisions, records and links to the system inventory that tie individual tests to the systems they are meant to protect.
Scan coverage misses critical assets
Scanning is often configured around the servers the IT team knows about, while systems supporting critical or important functions sit outside the scan scope, such as shared services, legacy integrations or cloud workloads owned by another team. Article 25 tests only build confidence if they reach those systems. Check the scan scope against the list of functions the entity has classified as critical or important, and confirm that every asset supporting those functions is in scope with a stated reason for any exclusion.
Test choices lack documented rationale
The Article 25(1) menu is broad, and teams often run whatever tools they already own without recording why a given test suits a given system. A supervisor will ask why a source code review was skipped for a payment component or why a performance test was never run before a capacity change. Each testing decision should record the risk, the system criticality and the expected evidence, so the programme reads as a deliberate choice rather than habit.
Findings closed without retest evidence
A ticket marked resolved is not proof that the weakness is gone. Many programmes record a patch or configuration change but never rerun the test that found the issue, so the evidence trail stops one step early. Keep a retest result linked to each finding, with the date, the tool version and the person who validated the fix. Ask whether any finding can be closed without a rerun and whether that exception is approved in writing.
Pre-deployment assessments outside change control
For central securities depositories and central counterparties, Article 25(2) requires vulnerability assessments before new or redeployed applications, infrastructure components and ICT services supporting critical or important functions go live. In practice these checks often sit outside the change process, so releases proceed when the assessment is skipped or late. Make the assessment a mandatory gate in the change workflow, and confirm that the change record links to the assessment output before approval.
Reports not tied to the inventory
Test reports that list hostnames or application names without a stable identifier cannot be matched to the register of systems that the entity maintains. When an assessor asks which tests covered a given critical function, the answer requires manual reconciliation that is slow and error-prone. Require every report to reference asset IDs from the inventory and to state the date of the inventory snapshot used, so coverage can be checked in a single query.
Questions buyers ask about Article 25 testing
How much effort does an Article 25 testing plan take, and what drives it?
The effort depends mainly on how many ICT systems and applications the entity runs, how many of them support critical or important functions, and how mature the existing inventory and change process is. Article 25(1) gives a menu of test types, so the plan must decide which tests fit which assets and why. Costs have two parts: the internal time to define scope, assign owners and approve the plan, and the external work to run tests and retest findings. Ask any provider for a fixed written scope listing the systems, test types, frequency and deliverables before agreeing a quote. Confirm with your competent authority how it expects the risk-based rationale to be documented.
Can a small entity run Article 25 testing itself?
A small entity can run many of the tests itself, but it must still show a risk-based plan and sound results. Article 25(3) says microenterprises should combine a risk-based approach with strategic planning, balancing resources and time against urgency, risk type and the criticality of assets and services. For entities under the simplified regime, Article 36 of Delegated Regulation (EU) 2024/1774 sets the ICT security testing requirements, so check that text before choosing tests. Self-run work suits routine scans and configuration reviews. Specialist work such as penetration testing and source code review often benefits from an outside tester, and independence should be considered when the same team builds and tests a system.
How long does it take to get scanning and evidence in place?
The timeline depends on the inventory, the scanner deployment and the number of approvals needed, so no fixed duration applies to every entity. Start by confirming which assets support critical or important functions, because Article 10 of Delegated Regulation (EU) 2024/1774 requires automated vulnerability scanning of those assets at least weekly. Delays usually come from incomplete asset lists, network access for agents, change approvals and agreeing how findings are tracked to closure. Ask for a written scope with milestones and an agreed evidence list, then measure progress against that document rather than a generic estimate.
What does the work need from our own staff?
Your staff must own the decisions that an outside party cannot make for you. These include approving the test plan, confirming which systems are in scope, providing access and change windows, owning remediation of findings and signing off residual risk. Security operations staff will usually run or receive scanner output, while application owners need to review code and test findings for their systems. Plan for a named owner per system and a single person who maintains the evidence register. Agree these responsibilities in the scope document so testing does not stall waiting for access or sign-off.
Can we outsource penetration testing and still keep control?
Yes, provided the entity keeps accountability and decision rights. DORA places responsibility for ICT risk and testing on the financial entity, so the outsourced tester works under your test plan, scope and rules of engagement. Keep control by approving the scope and timing, receiving the full report, deciding on risk acceptance and tracking remediation yourself. Ask the provider how it protects test data, how it handles findings that touch third parties, and who can access the results. DeployOpen plans and runs security testing inside the client's own infrastructure and prepares evidence, but it does not issue attestations, which an independent party provides.
What will an auditor or competent authority not accept as evidence?
Auditors and supervisors generally reject evidence that shows activity without outcomes. A scan report with no remediation tracking, a test with no defined scope, or a penetration test report without validated findings will weaken your position. Screenshots of dashboards, undated documents, and summaries that cannot be traced to the underlying tool output are also weak. Keep raw scanner exports, approved test plans, dated findings with owners and closure records, and evidence that retests confirm fixes. For tests linked to threat-led penetration testing, the attestation route is set by Article 26(7), so confirm the requirements with your competent authority before relying on any document.
How DeployOpen works on this
DeployOpen plans and prepares the systems, testing programme and evidence that an Article 25 testing approach depends on, inside your own cloud accounts, data centers or air-gapped networks. The organization owns its testing decisions, and only independent testers and assessors give findings or attestations.
How we scope
- Agree in writing which ICT tools, systems and applications fall under the Article 25 test menu.
- Record which test types each system needs, such as vulnerability scans, source code review or penetration testing.
- Confirm which systems support critical or important functions and need weekly automated scanning.
How we build
- Deploy and configure open-source scanners such as Wazuh, Fleet and Semgrep within your environment.
- Set up GitLab protected branches and CI pipelines so code scanning runs against every repository.
- Configure scan schedules, asset inventories and result exports so each test produces reviewable records.
How we hand over
- Document each test type, its owner, frequency, tooling and the system it covers.
- Deliver remediation tracking records showing how findings were triaged, fixed and revalidated.
- Provide an evidence index that your internal reviewers and independent assessors can follow.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Review scanner coverage and rule updates when new systems or deployments enter scope.
- Confirm with your competent authority and assessor which evidence formats they expect before work starts.
