DORA does not turn compliance into a penetration test

The Digital Operational Resilience Act makes testing an important part of financial-sector resilience. That does not mean a penetration test, even a technically strong one, proves DORA compliance. DORA also addresses ICT risk management, incident management and reporting, resilience testing, third-party risk, information sharing, and governance responsibilities.

Offensive security supplies evidence about how systems and controls behave under challenge. GRC defines why the test matters, which critical or important functions are in scope, who accepts the risk, how findings affect control claims, and when remediation is complete. The value sits in the connection between them.

A report that lists exploitable weaknesses without that context is difficult to govern. A control register that never exposes its claims to realistic technical challenge is difficult to trust.

The bridge is the resilience testing programme

DORA requires financial entities to maintain a sound and comprehensive digital operational resilience testing programme as an integral part of their ICT risk management framework. The programme is risk-based and proportionate. The regulation distinguishes the broader testing obligations from advanced threat-led penetration testing, or TLPT, which applies to financial entities identified by competent authorities under the applicable criteria.

The broader programme can draw on different assessment and testing methods. A vulnerability assessment answers a different question from a scenario-based exercise, source-code review, recovery test, or penetration test. Selecting an activity because it appears in a catalogue is not enough. The test must match the control claim and the failure mode that matters to the business service.

This is where governance becomes practical. Testing priorities should follow critical functions, material dependencies, recent changes, threat information, incidents, known exposure, and control uncertainty.

Start with the critical function and the decision

A useful engagement begins with the business function that must remain resilient. Identify the process, supporting systems, data, identities, infrastructure, service providers, and recovery dependencies. Then define the decision the test must support.

For example, management may need to know whether an attacker who compromises a normal user account can disrupt a payment process, whether a cloud control prevents movement between tenants, or whether the security operation can detect and contain an attack before a critical service is affected. Each question produces a different scope and evidence plan.

Testing should not begin with a generic target list and search for a business story afterward. The story is the reason the test exists.

Scope and authorization are governance controls

Rules of engagement are not administrative decoration. They establish the legal and operational authority to test, the systems and entities covered, exclusions, data handling, testing windows, escalation contacts, stop conditions, evidence protection, and the treatment of third-party services.

The scope must also reflect dependencies. A critical function may rely on an outsourced application, cloud platform, identity provider, telecommunications service, or shared operational team. If a dependency cannot be tested, the limitation should be recorded and the conclusion narrowed. Silence is not evidence that the dependency is resilient.

Independence and competence need to be considered when selecting testers. For advanced TLPT, DORA and its regulatory technical standards establish a distinct governed process, including criteria for identifying entities, requirements for testers, scope, methodology, and test phases. It should not be marketed as an ordinary red-team package.

A finding needs control context

An offensive finding describes what the tester could do and the evidence observed. A governance record should connect that fact to the affected control objective, critical function, assets, threat scenario, owner, severity criteria, and residual risk decision.

That connection prevents two common failures. The first is treating every technical issue as equally important. The second is closing a material control failure because a narrow technical symptom was patched. If an attack path exists because of weak identity design, incomplete asset coverage, poor segmentation, or missing detection, the remediation plan should address the underlying condition.

Good reporting distinguishes confirmed facts, reasonable inferences, limitations, and untested paths. This makes the evidence usable by technical teams, risk owners, management, and supervisors without overstating what the test proved.

Remediation is incomplete until closure is evidenced

A ticket marked complete is not the same as a remediated risk. Closure should show what changed, who approved it, which systems received the change, whether the original technique still works, whether compensating controls are operating, and what residual exposure remains.

Retesting is therefore part of the evidence chain. The depth of retesting should match the finding. A configuration correction may need targeted validation. A systemic authorization or segmentation failure may require a wider sample. A response failure may require a scenario replay, telemetry check, or exercise rather than another exploit attempt.

Exceptions also need discipline. They should state the rationale, accountable risk owner, compensating measures, monitoring, expiry date, and trigger for reconsideration. Permanent exceptions are often unresolved design decisions with a different label.

TLPT is a distinct regime

DORA's advanced testing requirements apply to selected financial entities identified by competent authorities, not automatically to every organisation in scope of DORA. Under the regulation, those entities are required to conduct TLPT at least every three years, with the competent authority able to adjust the frequency in light of the entity's risk profile and operational circumstances.

The detailed framework is set out in Commission Delegated Regulation (EU) 2025/1190. It covers identification criteria, internal and external tester requirements, test scope, methodology, and the approach to preparation, testing, closure, and remediation. The process is threat-led and intelligence-informed, but it is also tightly governed.

A normal penetration test can still provide valuable evidence within the broader resilience testing programme. It should not be described as TLPT unless the engagement actually meets the regulatory conditions and is conducted within the required supervisory process.

What good evidence looks like

Before testing, retain the approved objective, scope, critical functions, scenario rationale, authorization, safety rules, tester qualifications, environment assumptions, and known limitations. During testing, preserve a controlled activity record, observations, timestamps, evidence integrity, escalation decisions, and deviations from plan.

After testing, connect findings to affected controls and services, record management decisions, assign remediation, track exceptions, validate closure, and feed lessons into risk assessments, detection coverage, incident playbooks, architecture, supplier management, and future testing.

This does not require a mountain of documents. It requires traceability from requirement to control, from control to test, from test to evidence, and from evidence to decision.

A practical operating model

The GRC function should own the obligation map, critical-function context, risk decisions, control relationships, exception process, and management reporting. Security and technology owners should operate the controls and provide evidence. Offensive specialists should design and execute safe technical challenge. Defensive teams should validate telemetry, investigation, containment, and recovery. Independent assurance should assess whether the combined evidence supports the stated conclusion.

These roles can be performed by small teams, but the decisions should remain explicit. A provider that helps design or remediate a control should disclose that involvement before presenting an independent conclusion about the same work.

Done well, DORA testing is more than a periodic compliance event. It becomes a learning loop: governance selects the risk that matters, technical testing challenges the assumption, operations respond, remediation changes the system, and assurance tests whether the evidence supports reliance.

Official sources

This article provides a security and assurance perspective, not legal advice or a regulated audit opinion. DORA scope, supervisory expectations, and testing obligations should be confirmed with the relevant legal and regulatory specialists.