DORA Testing Hierarchy: What You Need

Bottom Line

Confirm your TLPT designation status with your competent authority in writing. Then build a testing programme that covers all the levels below your designation threshold — not just the headline requirement. Level 6 (TLPT) gets the attention, but Levels 1–3 are where most entities have the most gaps. Every level must be documented, scheduled, executed, and followed through to remediation.

What Auditors Will Actually Look For

• A written testing programme or calendar covering all six levels appropriate to your designation — not just a list of what was done last year.
• Evidence of continuous or near-continuous vulnerability scanning for critical systems — not a single annual snapshot.
• BCP and DRP test results that show real failover was executed, not just a tabletop exercise with no infrastructure component.
• Penetration test findings with remediation evidence: critical findings closed within 30–60 days and re-tested.
• For TLPT-designated entities: a CA closure letter from a test within the last 3 years. Without it, you are non-compliant.

Common Mistakes

• Self-declaring simplified regime eligibility without CA confirmation — eligibility is the CA's call, not yours.
• Running a single annual vulnerability scan and treating it as continuous monitoring.
• Documenting BCPs and DRPs but never testing whether failover actually works within the stated RTO.
• Confusing a penetration test with TLPT — they are related but legally and operationally distinct (see the Red Team vs. TLPT guide).
• No testing calendar or owner assignments — testing that happens ad hoc is testing that has gaps.

The Testing Hierarchy at a Glance

Level 1 — Vulnerability Assessments

The baseline requirement for every entity in scope, regardless of size. Auditors treat absence of continuous scanning as a critical gap.

• Automated scanning of ICT assets for known vulnerabilities (CVEs) using recognised scanning tools.
• Covers: servers, endpoints, network devices, cloud configurations, web applications, and APIs.
• Critical vulnerabilities (CVSS 9.0+) must be remediated within defined SLAs — typically 24–72 hours for internet-facing systems.
• Results must be tracked, prioritised, and reported to management — a scan with no documented follow-up fails the test.
• Scanning must be continuous or near-continuous for critical systems — a single annual scan is not sufficient.

Level 2 — Source Code Reviews

Required where the entity develops or significantly customises its own ICT systems. Applies more widely than most entities realise — any bespoke configuration of third-party systems may trigger it.

• Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) for in-house code.
• Review should occur before major releases and after significant changes — not just annually.
• Third-party code components (libraries, open-source dependencies) must also be assessed — Software Composition Analysis (SCA).
• Findings must feed into the development pipeline and be tracked to closure, not siloed as a compliance output.

Level 3 — Network and Infrastructure Security Testing

• Covers: firewall rule reviews, network segmentation validation, wireless security, VPN and remote access testing.
• Must be conducted at least annually for systems supporting significant functions.
• Firewall rule audits must verify that only required ports and services are exposed — "deny all except" not "allow unless blocked".
• Network segmentation testing must confirm critical systems are isolated from general corporate networks as designed — not just as documented.

Level 4 — Scenario-Based Testing and BCP Exercises

• Tests the entity's ability to maintain or rapidly restore critical functions under adverse conditions — ransomware, major outage, third-party failure.
• BCPs and DRPs must be tested against reality, not just reviewed on paper. Tabletop exercises alone are not sufficient.
• Failover testing must demonstrate the entity can switch to backup systems within its stated RTO — not that it believes it can.
• Results must drive BCP/DRP updates — a test with no documented follow-up action is a test with no compliance value.

Level 5 — Penetration Testing

More targeted than vulnerability scanning — a human tester attempts to exploit weaknesses to reach a defined objective. Not a substitute for TLPT; not satisfied by a vulnerability scan.

• Scope typically covers systems and applications supporting critical or important functions.
• Can be black-box (no prior knowledge), grey-box (limited knowledge), or white-box (full access to architecture) — approach should be agreed based on the objective.
• Annual penetration testing is strongly recommended for all significant entities, even where not explicitly mandated.
• Critical findings must be re-tested after remediation — a finding closed on paper but not re-tested is a finding that may still be open.

Level 6 — TLPT (Threat-Led Penetration Testing)

The most demanding testing requirement — reserved for entities designated as significant by their competent authority. Designation is not self-assessed.

• TLPT is intelligence-led: attack scenarios are built from a Targeted Threat Intelligence (TTI) report specific to the entity — not generic adversary scenarios.
• Scope covers critical functions and all people, processes, and technology supporting them — including material third parties.
• Tests are conducted on production systems. Isolated replicas are only permitted where production testing poses unacceptable systemic risk.
• Duration: typically 3–6 months of active testing within a 9–12 month overall programme.
• Outputs: Red Team Report, Blue Team Report, Remediation Plan, and CA closure letter. Without the closure letter, the test is not complete.
• Mandatory for designated entities at least every 3 years — the clock starts from the CA closure letter date.

The Simplified Regime (Art. 16)

Small, non-interconnected entities may qualify for reduced testing requirements — but qualification is the CA's determination.

• Entities eligible for the simplified ICT risk management framework (Art. 16) also benefit from reduced testing requirements.
• Simplified entities are not required to conduct TLPT.
• They are still expected to conduct baseline vulnerability assessments and some form of scenario-based testing — simplified does not mean exempt.
• Eligibility is determined by the competent authority based on size, interconnectedness, and systemic importance — not self-declared.

3-Step Action Checklist

• 1. This week: confirm your TLPT designation status with your competent authority in writing if you have not already done so. Then map your current testing activities against all six hierarchy levels.
• 2. This month: identify gaps at Levels 1–4 — these are typically the weakest areas and the ones auditors check first. Assign owners and remediation dates.
• 3. This quarter: publish a testing calendar covering all applicable levels, with named owners, scheduled dates, and a process for tracking findings to closure. Report the programme to the board.