DORA imposes a harmonized framework for digital operational resilience in the European financial sector through Regulation (EU) 2022/2554, defining specific requirements for security testing that go beyond TLPT, involving ordinary and continuous checks on all ICT systems and tools.

Digital operational resilience testing in DORA

Digital operational resilience testing constitutes the fourth pillar of DORA and ensures that financial entities are able to withstand, respond to, and recover operations in the event of ICT threats and disruptions. These obligations apply to over 20 types of financial entities in the EU, with the goal of preventing and mitigating cyber threats through constant validation of defenses.

“Basic” testing and TLPT: differences

• Basic testing (Articles 24 and 25): Required for almost all financial entities, they include a wide spectrum of checks on ICT tools and systems and represent the minimum requirement to evaluate the robustness of defenses.
• TLPT (Threat-Led Penetration Testing – Article 26): These are advanced intelligence-based tests that simulate the tactics of real malicious actors. They are mandatory only for entities identified by authorities as systemically important or with a specific risk profile and must be performed on real, operational production systems.

Tests required by Article 25

Article 25 requires a structured testing program with various methodologies including:

• Source code review: Source code reviews with static and dynamic testing.
• Security testing for exposed systems: Security checks for applications and systems accessible via the internet.
• Vulnerability assessment: Framework for managing and removing vulnerabilities.
• Software package testing: Security checks before the implementation of new software packages.
• Impact and compatibility analysis: Tests to ensure that new systems do not introduce vulnerabilities into existing ICT processes.

Responsibility and testing approach

Financial entities must adopt a risk-based approach, scaling testing resources according to the criticality of ICT assets and business procedures. The checks must be carried out by teams independent of the development or operation of the systems, with testers who possess suitability, reputation, and certified technical skills. In TLPT, the participation of threat intelligence providers external to the bank or group is required.

Minimum frequency of testing on critical systems

• Vulnerability scanning: On systems that support critical or important functions, scans must be carried out at least weekly.
• Business Continuity Plans: ICT business continuity plans must be tested at least annually or after substantial changes.
• General review: At least once a year, it is necessary to verify that any strategic changes are reflected in the testing program.
• TLPT: The frequency is usually triennial, unless otherwise provided by the competent authority.

Connection between testing, remediation, and governance

The testing program must be integrated with the financial entity’s governance. The results must be documented and analyzed to identify deficiencies; for every vulnerability, a detailed remediation plan is required. The management body has the final responsibility for the oversight and approval of the results and risk mitigation plans.

FAQ

• Does DORA always mandate penetration testing?
• Yes, security tests attributable to penetration testing are required for all financial entities, as part of vulnerability management and the security of exposed systems. The advanced TLPT, however, is required only for the most relevant entities.
• Does DORA always mandate TLPT?
• No, the obligation applies only to financial entities that are mature at the ICT level with systemic impact; authorities may exclude entities for which the test is not justified by the risk profile.
• How often must critical systems be tested?
• Vulnerability scans at least weekly, other general resilience and continuity tests at least annually.

Ensure your compliance: request an initial assessment of your DORA testing program to correctly define the verification perimeter of your critical systems.