DORA penetration testing requirements outside TLPT

What DORA penetration testing requirements apply outside TLPT?

A board, customer or supervisor now expects evidence of DORA testing, and threat-led penetration testing (TLPT) may not apply to your organization at all. Article 24(6) requires every entity other than a microenterprise to conduct appropriate tests at least yearly on all ICT systems and applications that support critical or important functions, and Article 25(1) lists penetration testing among the permitted test types. TLPT is a narrower, separate regime that only applies to entities a competent authority identifies, so most firms owe yearly testing whether or not they are ever selected for TLPT. The organization owns its testing programme, including its scope, schedule, test selection and the decisions taken on the results. Under Article 24(4), tests must be performed by independent parties, whether internal or external, and internal testers need sufficient resources and must avoid conflicts of interest throughout design and execution.

Three inputs decide what you owe. The first is your ICT system and application inventory, which must be complete enough to show every asset in scope. The second is the mapping from those systems to your critical or important functions, which determines which systems must be tested every year and which can follow a lighter, risk-based plan. The third is whether you qualify as a microenterprise, which changes the yearly requirement. Confirm each of these with your competent authority's guidance and your own legal review before you set a plan, because a weak mapping is the most common reason a test programme looks complete on paper but misses the systems a supervisor will ask about.

An implementation partner can help plan, run and document these tests, prepare the scope and collect evidence, but the organization remains accountable for the results and for acting on them. No testing vendor issues a DORA certificate, and DORA does not provide a certification scheme for testing. Ask any provider to state in writing which tests they will perform, who will perform them, how their independence from your internal teams is ensured, and which deliverables you will own at the end. The DORA regulation text is available on EUR-Lex and should be the reference point for these discussions.

Which test types Article 25 allows and where penetration testing fits

Article 25(1) lists test types an entity may use, not a fixed set. Entities choose among them by risk, and each card below maps one test family to the parts of the estate it best examines, with penetration testing as one tool among several.

Vulnerability assessments and scans

Automated and manual checks that identify known weaknesses in ICT assets. Article 10(2) of Delegated Regulation (EU) 2024/1774 requires automated vulnerability scanning and assessments at least weekly for assets supporting critical or important functions. Check that scan scope matches the asset inventory, that authenticated scans run where they can, and that results feed the remediation process rather than sitting in a dashboard.

Open source analyses and network assessments

Open source analyses examine publicly available information about the entity and its exposed services, while network security assessments test segmentation, firewall rules and traffic paths. Together they show what an outside attacker can see and whether internal zones are truly separated. Confirm the network assessment covers the zones that host critical or important functions and document the sources used in the open source work.

Gap analyses and questionnaires

Gap analyses compare documented controls against what is actually implemented, and questionnaires collect structured answers from system owners and providers. Neither exercises a system directly, but both reveal where policy, configuration and practice diverge. Use them to decide where technical tests should focus, and record which gaps were closed and which were accepted by the management body.

Physical security reviews

Physical security reviews assess data centers, server rooms, network closets and equipment storage where ICT assets sit. For self-hosted platforms, this includes the facilities of the entity's own data centers or the colocation space it contracts for. Ask the review to cover access logs, environmental controls and media disposal, and confirm which parts a hosting provider covers under its own assurance.

Source code reviews where feasible

Article 16 of Delegated Regulation (EU) 2024/1774 requires source code reviews using static and dynamic testing for relevant systems. Open-source platforms still need review of the customizations, integrations and configuration code the entity owns. Check that reviewers can access the build pipeline, that findings include dependency issues, and that the review is scoped to the entity's own code rather than the upstream project alone.

Scenario-based, compatibility, performance and end-to-end tests

These tests check whether systems behave as intended under realistic failure, load and integration conditions. Scenario-based tests simulate an attack or outage, compatibility tests confirm new versions work with existing dependencies, performance tests measure capacity, and end-to-end tests follow a full business process across systems. Link each test to a critical or important function so results can be traced to resilience objectives.

Penetration testing as one tool

Penetration testing attempts to exploit weaknesses to show how far an attacker could get, and it is one of the test types listed in Article 25(1). It complements scanning and gap analysis but does not replace them. Define the scope, the independence of the testers under Article 24(4), and the systems covered, including internet-exposed systems under Article 16 of Delegated Regulation (EU) 2024/1774. Confirm the scope in writing before testing starts.

Which systems must be tested every year, and which must be tested before go-live

The yearly testing obligation and the pre-use testing obligation are separate rules with separate scopes, and the first step is an inventory that serves both. Article 24(6) of DORA requires entities other than microenterprises to run appropriate tests at least yearly on all ICT systems and applications that support critical or important functions. Working out that population starts with the function map: list each critical or important function, then trace every system, application, interface and supporting service it depends on. Confirm the mapping with the business owner of each function before fixing the annual test plan, because the people who run a payment or claims process usually know dependencies that the IT asset register does not show.

A second, broader rule applies to everything else. Article 16 of Delegated Regulation (EU) 2024/1774 requires all ICT systems to be tested and approved before first use and after maintenance, with the depth of testing scaled to criticality. Scaling is a judgment, and the entity owns it. Write down the criteria used to place a system at each level, record who approved the placement, and be ready to defend the reasoning to the competent authority. A system that falls outside the critical or important scope does not escape testing. It still needs a documented pre-use test and a documented post-maintenance test, and a lighter test profile is acceptable only where the written rationale supports it.

Treat the two lists as one register with a criticality field, not as two projects. Each system should carry its function mapping, its criticality rating with the approval record, the date of its last yearly test where one applies, and its change-driven test triggers. Review the register whenever a function is added, a system is replaced or a vendor releases a major change, because a system that moves into critical or important scope picks up the yearly obligation at that point. Ask your internal audit team or an independent reviewer to test a sample of placements, since a gap in this register tends to surface as an audit finding.

Who runs the tests: in-house, external or a mix

This table compares three ways to staff DORA testing outside TLPT: an internal team, an external tester, or a split model. Read each row against your own team size, skills and the conflicts that arise when staff build or run the system under test. The main takeaway is that every option must meet the independence and resourcing test of Article 24(4), and the entity stays accountable for the results whichever option it chooses.

Factor	Internal team	External independent tester	Split model (internal scans, external pen tests)
When it fits	Team has current offensive security skills, enough capacity to test without pulling staff from delivery, and testers who did not design or operate the system under test	Team lacks penetration testing depth, or the system is built or run by the same people who would test it	Team handles frequent automated scanning and routine checks, while deeper testing of critical or important systems goes to an outside party
Conflict of interest risk	High if testers also maintain the system, since they may be reluctant to report flaws in their own work	Low, provided the tester has no role in building, configuring or operating the system	Low for the deep tests, moderate for routine scans run by operators who also fix what the scans find
What the entity must prove	Sufficient resources and documented avoidance of conflicts of interest through design and execution of each test	Scope, tester selection and engagement terms that show independence and that the tester is not part of the system's operation	Separation of duties between scan operators and remediation owners, plus evidence that the external component meets the independence test
What the independent party must show	Not applicable as an external party, but internal testers should show their competence and reporting line	Relevant technical skills, documented methodology, and no conflicting role in the system or its change process	Competence and methodology for the external tests, and clear boundaries with the internal team's routine work
Typical evidence an assessor requests	Test plans, tester role descriptions, reporting lines, records showing testers were not involved in the build	Signed statement of work, tester qualifications, independence declaration, final reports	Test calendar split by owner, scan outputs, external reports, and the conflict-of-interest assessment for each internal role
Accountability for results	Remains with the entity's management body and control owners	Remains with the entity, even though an outside party performed the test	Remains with the entity for both the internal and external components
Points to confirm with the tester or internal lead	Who approves test scope and whether results reach the board or risk committee unedited	Whether the firm has also built, hosted or changed the system in the last period	Which tests are classed as routine scanning and which as independent penetration testing, and who signs off each

How testing changes for internet-exposed, internal and source-code-heavy systems

Systems and APIs reachable from the internet carry the most direct attack surface, so Article 16 of Delegated Regulation (EU) 2024/1774 requires security testing for them, and penetration testing and vulnerability scanning form the core of that work. The entity sets the cadence for these tests within the Article 24 framework, and should document why the chosen frequency fits the system's exposure and criticality.

What to test: Public web applications, customer portals, API gateways, authentication endpoints, remote access services and any DNS, mail or VPN component reachable from outside.
Evidence to produce: Scope statements, tester identity and independence records, tool and method descriptions, a list of findings with severity, and retest results showing closure.
What it commonly misses: Forgotten subdomains, staging hosts left online, APIs documented in old specifications but still active, and authorization flaws that only appear when one user accesses another user's data.
Scanning cadence: Automated vulnerability scanning of critical or important assets is required at least weekly under Article 10(2) of Delegated Regulation (EU) 2024/1774, which complements periodic penetration testing rather than replacing it.
Asset inventory gaps: Tests can only cover what the entity knows exists, so reconcile external scan results against the ICT asset inventory each cycle.

Before signing off, confirm that the external attack surface list is current and that every exposed system has a named owner responsible for remediation.

How a yearly DORA test cycle runs from scoping to validated fixes

The cycle turns a list of ICT systems into tested, prioritised and remediated weaknesses, with an evidence file the entity can put in front of its competent authority. Each step closes with a written output that the entity owns and signs.

Define scope and inventory critical systems
The entity identifies every ICT system and application that supports a critical or important function, using its ICT asset inventory and its register of critical or important functions. An implementation partner can compile the first draft from configuration data, network maps and architecture records, but the entity's business owners confirm which functions each system supports. The step closes with a signed scope list that names each system, its owner, its hosting location and its function, so that the yearly obligation under Article 24(6) has a defined perimeter.
Record the independence and resourcing decision
Article 24(4) allows testing by internal or external parties, provided they are independent and the entity has sufficient resources and avoids conflicts of interest throughout design and execution. The entity decides who will test each system, documents why those testers are independent of the teams that built or run the system, and records the resources allocated. An internal tester's reporting line and any conflict checks belong in this record. The output is a written decision approved by the accountable function, which becomes the first item in the evidence file.
Map each system to Article 25 test types
For every system in scope, the test plan states which test types from Article 25(1) apply, such as vulnerability assessments and scans, network security assessments, source code reviews where feasible, scenario-based tests, end-to-end tests or penetration testing. Internet-exposed systems must include security testing as required by Article 16 of Delegated Regulation (EU) 2024/1774. The plan also records the expected test window and any change freeze. The output is a test matrix that a reviewer can read system by system and check against the scope list.
Execute tests under written rules of engagement
Before any test starts, the entity and the testers sign rules of engagement that set permitted techniques, IP ranges, accounts, test data, timing, escalation contacts and stop conditions. Testers run the planned tests and keep dated logs of what was tested, what was observed and what was changed during testing. Operations staff monitor the environment so that a test does not become an unplanned incident. The output is a signed rules of engagement document and a complete execution log for each system.
Classify and prioritise every finding
Article 24(5) requires procedures that prioritise, classify and remedy every issue revealed by testing. Each finding receives a severity rating under the entity's documented method, a link to the affected system and the function it supports, and a priority that reflects that exposure. Findings from automated scanning, which Article 10(2) of Delegated Regulation (EU) 2024/1774 requires at least weekly for assets supporting critical or important functions, feed into the same register so that nothing sits in a separate list. The output is a single findings register with a classification for every item.
Assign remediation owners and dates
Each finding is assigned to a named owner who is accountable for the fix, with a target date set by the entity's own remediation policy. Where a fix is not feasible, the entity records a risk acceptance or a compensating control, approved by a manager with authority to accept that risk. An implementation partner may draft remediation tickets and track progress, but the entity decides priorities and approves exceptions. The output is a remediation plan in which every finding has an owner, a plan and a status.
Validate that each weakness is fully addressed
Article 24(5) requires confirmation that identified weaknesses, deficiencies or gaps are fully addressed, so closure means more than a ticket marked done. A tester or an internal validator who was not involved in the fix retests the affected system with the same method that found the issue, and records the result. Findings that recur or that were accepted as risk are checked again in the next cycle. The output is a validation record for each closed finding that shows the retest date, method and result.
Assemble the evidence file for supervision
The entity compiles one evidence file that runs from the signed scope through independence records, test plans, rules of engagement, execution logs, the findings register, remediation records and validation results. It also notes any open items, risk acceptances and changes to the test programme since the last cycle. The file is kept so that the entity can answer a supervisory request without rebuilding it. The entity owns and signs the file, and an implementation partner can organize and index the artefacts, but no partner or auditor issues a report that replaces the entity's own record.

Where yearly DORA testing usually falls short

Yearly testing under Article 24(6) fails less often on effort than on scope, follow-through and evidence. The six pitfalls below cluster around three questions: did the test cover the right systems, did the right people run it, and can the entity prove what was fixed.

Incomplete inventory of critical systems

The yearly obligation covers all ICT systems and applications supporting critical or important functions, so the test scope is only as good as the list behind it. Entities often test the systems they already know about and miss shared components, legacy applications, integration middleware and cloud workloads that a critical service depends on. Check that the scope starts from a documented mapping of functions to systems, that the mapping is signed off by the owner of each function, and that the asset inventory used for testing matches the one used for risk assessment.

Scans without follow-up

Running vulnerability scans produces output, but Article 24(5) requires procedures to prioritise, classify and remedy the issues testing reveals. A scan report that sits in a shared folder is not a remediation process. Ask for a register that links each finding to a severity rating, an owner, a due date and a closure record. Also check that automated scanning of critical assets runs at the frequency required by Delegated Regulation (EU) 2024/1774 and that the results feed that same register.

Testers who built the system

Article 24(4) requires tests to be performed by independent parties, whether internal or external. When the engineering team that built or runs a system also tests it, the entity must show sufficient resources and a conflict-of-interest control throughout design and execution. Check whether the person signing off the test results also approved the system change being tested, and whether the tester has a reporting line independent of the system owner. An internal tester can satisfy the rule, but only with that documented separation.

Internet-exposed services found late

Delegated Regulation (EU) 2024/1774 expects security testing of internet-exposed systems, which makes exposure a live condition rather than a snapshot. New DNS records, forgotten test environments, third-party hosted portals and cloud load balancers often appear between the test window and the next review. Ask how external attack surface discovery runs between tests, who is alerted when a new public endpoint appears, and whether newly exposed services are brought into the next test scope.

Findings closed without validation

A ticket marked resolved is not evidence that a weakness is fixed. Article 24(5) asks for internal validation methodologies that confirm every identified weakness is fully addressed. Check that each closed finding has a retest or equivalent verification by someone other than the person who made the change, and that accepted risks are recorded with approval from the right level of management. Without this step, the same issues tend to return in the next annual cycle.

Reports that do not map tests to systems

Article 25(1) lists test types such as vulnerability assessments, network security assessments, source code reviews and penetration testing, and an assessor will expect to see which type covered which system. A report that lists findings by host but never states the test method, tester, date and system scope makes it impossible to show that each critical system received an appropriate test. Ask for a matrix that maps each in-scope system to the Article 25 test types applied, the tester, and the date, so a reviewer can trace coverage without reconstructing it.

Questions buyers ask before they commission DORA penetration tests

Does DORA require a penetration test every year for every system?

No. DORA does not prescribe one penetration test for every system. Article 24(6) requires entities other than microenterprises to run appropriate tests at least yearly on all ICT systems and applications that support critical or important functions, and the entity chooses the test types it needs. Article 25(1) lists the options, including vulnerability assessments and scans, network security assessments, gap analyses, scenario-based tests, end-to-end testing and penetration testing. A penetration test is one of those options, so the yearly obligation attaches to the systems in scope, not to a single test type. Your risk assessment and your function mapping decide which systems fall in scope and which test types fit each one. Confirm the exact combination with your competent authority and your own documentation before you buy a fixed-scope engagement.

Can our internal security team perform the DORA penetration tests?

Yes, if the conditions in Article 24(4) are met. Tests must be performed by independent parties, and those parties can be internal or external. Internal testing requires sufficient resources and the avoidance of conflicts of interest throughout design and execution. In practice, this means the people who build or operate a system should not be the only people who decide its test scope, run the test and judge the result. Document who tested what, what skills and time they had, and how independence was protected. Many entities combine internal testers for routine scans with external testers for deeper assessments, which keeps the independence argument simple during supervision.

What does our organization need to provide before a penetration test starts?

A tester can only test what you can name, reach and fix. Before work starts, most engagements need an up-to-date inventory of ICT assets, a mapping of which systems support critical or important functions, and the access required for each test, such as test accounts, network paths and change windows. Each in-scope system also needs a named owner who can answer questions and approve remediation. Agree in advance how long fixes may take, because findings must be prioritized, classified and remedied under Article 24(5). Missing inventories and unclear ownership are the most common reasons a test produces findings that cannot be closed, so resolve them in the scoping phase.

Can an external tester issue a DORA certificate after a penetration test?

No. A penetration testing firm cannot issue a DORA certificate, and no testing vendor can, because DORA sets no certification scheme. Competent authorities supervise compliance using their powers under Article 50. The only authority-issued attestation the Regulation provides for concerns a threat-led penetration test that met the requirements under Article 26(7), and that applies only to entities designated for TLPT. For ordinary penetration tests, the output is a test report, evidence of remediation and records you can show a supervisor. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports, attestations or certifications. Ask any provider to state in writing what deliverables it will hand over.

What drives the cost of DORA penetration testing?

Scope drives most of the cost. The main inputs are the number of systems and applications in scope, how many are internet-exposed, how many locations or cloud accounts the tests must cover, how many test types you select under Article 25(1), and how much access the tester needs. Remediation load is a second driver: a test that finds many issues costs more in retesting and validation time, and the work needed to fix them sits largely with your own engineers. Costs are typically one-time for the initial scoped engagement and recur for the yearly cycle and retesting. DORA does not publish a fee for these tests, so request a quote that itemizes systems, test types, environments, retest rounds and any support you want after the report. DeployOpen provides fixed-scope quotes based on a written scope.

How does TLPT differ from the penetration tests covered here?

TLPT is threat-led penetration testing for entities identified by their competent authority under Article 26(8). It follows a threat-intelligence-based scenario and is subject to its own regulatory technical standards, including Delegated Regulation (EU) 2025/1190, which sets default categories of entities. The tests in this page apply to every entity in scope, outside that designation. They cover the Article 25(1) test types, the yearly testing of systems supporting critical or important functions under Article 24(6), independent testers under Article 24(4) and remediation under Article 24(5). An entity that is later designated for TLPT still needs the baseline programme. If you are unsure whether you fall under TLPT, confirm the designation with your competent authority.

What to check before you hire an external tester or implementation partner

An external tester or implementation partner can strengthen your DORA testing programme, but the financial entity keeps responsibility for its testing, its findings and its remediation. The cards below set out what to verify in writing before work starts, so that the partner's reports can support your own assessment of ICT systems supporting critical or important functions.

Independence from build and operation

Article 24(4) requires testers to be independent, whether internal or external, and internal testing must avoid conflicts of interest throughout design and execution. Ask whether the partner built, configured, hosted or operates the system under test, and whether any of its staff hold administrative access to it. A partner that also runs the platform should explain how it separates the people who fix from the people who test, and who signs off the results.

Documented method covering Article 25 tests

Ask for a written method that maps each test type to the systems in scope. Article 25(1) lists options such as vulnerability assessments, open source analyses, network security assessments, gap analyses, source code reviews where feasible, scenario-based tests, compatibility and performance testing, end-to-end testing and penetration testing. The method should explain which types apply to which systems and why, so that the entity can show its selection was risk-based.

Evidence handling and confidentiality terms

Testing produces credentials, exploit details, customer data samples and network maps that are sensitive in their own right. Check how the partner stores, transmits and deletes this material, which staff can access it, and how long it is retained after the engagement closes. Confirm that the contract includes confidentiality obligations, incident notification if the partner's own systems are compromised, and a defined process for returning or destroying test data.

Experience with financial-sector and API systems

Ask for evidence of work on payment, core banking, trading or insurance platforms, and on internet-exposed APIs and authentication flows. Security testing of internet-exposed systems is expected under Delegated Regulation (EU) 2024/1774, so the tester should be able to explain its approach to API authorisation, rate limits, session handling and third-party integrations. Ask for named experience categories rather than general claims, and check whether the people assigned are the people who did that work.

Written scope and deliverables first

Agree the systems, environments, test types, testing windows, rules of engagement and deliverables in writing before any testing begins. The scope should list which systems support critical or important functions, which are out of bounds, and what happens when the tester finds something outside scope. Deliverables should include a report that separates findings by severity, reproduction steps and recommended fixes, so that your team can prioritise and validate remediation.

Ownership of findings and remediation

Decide in advance who owns each finding, who prioritises it, and who confirms that it is fixed. Under Article 24(5), the entity must have procedures to classify and remedy every issue revealed by testing, so the partner's role is to report and retest, not to close findings on the entity's behalf. Ask the partner to state in writing that its reports support your own assessment and that no partner issues a DORA attestation or certificate. Ask who receives reports, how retesting is recorded and what evidence goes to your auditor or competent authority.

How DeployOpen scopes, tests and prepares DORA testing evidence

DeployOpen plans, implements and tests self-hosted open-source platforms inside the client's own infrastructure, and prepares the testing records DORA asks for. The organization keeps ownership of its testing programme, and independent testers and auditors remain responsible for their own conclusions.

How we scope

Engagements are fixed-scope, with systems, test types and deliverables agreed in writing before work starts.
The written scope lists which ICT systems support critical or important functions and therefore fall under the yearly testing expectation.
Internet-exposed systems, their owners and the test types Article 25 names are confirmed with the client before any test is planned.

How we build

Security testing covers applications, APIs, cloud and infrastructure, with testers kept independent of the teams that built or run the system.
Vulnerability scanning and source code review results are recorded against each asset so the testing record stays traceable.
Test environments are set up inside the client's own cloud accounts, data centers or air-gapped networks so no client data leaves its control.

How we hand over

Each test produces a written report with prioritised findings, affected systems, reproduction steps and suggested remediation owners.
Remediation tracking records how each finding was fixed and how the fix was validated, which is the evidence an assessor will request.
Every deliverable is handed over to the client, who decides what to share with its competent authority and independent auditor.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so the yearly testing cycle can run without rebuilding the record each year.
Ask us to confirm which test results, scan logs and remediation records will be ready for your next supervisory request.
DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do.