Digital Operational Resilience Testing Program (DORA)

Example Conversation

Below is an example session designing a DORA resilience testing program for a mid-sized payment institution that has been identified for TLPT.

You: We need to design our DORA digital operational resilience testing program. We’re a licensed payment institution in the Netherlands, processing about 2 million transactions per day. Our competent authority (DNB) has identified us for TLPT under Art. 26(8). We currently run quarterly vulnerability scans and an annual penetration test, but we don’t have a structured testing program that covers all of the DORA Art. 25 test types.

Agent: I’ll help you build a comprehensive testing program that covers both your basic testing obligations under Art. 25 and the advanced TLPT requirement. Let me confirm a few details about your ICT landscape:

1. Critical and important functions: What business functions have you identified as critical under your ICT risk management framework (Art. 8)? For a payment institution, this typically includes payment processing, fraud detection, customer authentication, and settlement.
2. ICT systems: How many distinct ICT systems support these functions? Do you operate your own data center or use cloud providers?
3. Third-party ICT providers: Which critical functions rely on third-party service providers? These will need to be included in your TLPT scope under Art. 26(3).
4. Source code access: For your critical applications, do you have access to source code for review, or are some vendor-supplied?
5. Previous TLPT experience: Has your organization ever participated in a TIBER-NL exercise?

You: Our critical functions are: payment processing, instant payments (SEPA Instant), customer authentication (SCA), fraud detection, and AML transaction monitoring. We run about 15 core systems — 8 are developed in-house and 7 are vendor-supplied. We use AWS for infrastructure and two key vendors: one for the fraud detection engine and one for our AML screening platform. We have source code for all in-house applications but not for the vendor systems. We have never done TLPT before.

Agent: Thank you. Based on your profile, here’s the testing program structure I’ll build:

Basic testing program (Art. 25) — Annual cycle covering all 12 test types. For source code reviews, we’ll document feasibility: full SAST for your 8 in-house applications, and compensating controls (enhanced dynamic testing, vendor SOC 2 attestations) for the 7 vendor systems. Your current quarterly vulnerability scans already exceed the annual minimum — we’ll formalize those.

TLPT program (Art. 26) — Since DNB has identified you, your first TLPT must cover all five critical functions on live production systems, including the infrastructure hosted by your fraud detection and AML vendors. I’ll structure this per TIBER-NL (the Dutch implementation of TIBER-EU).

Let me start with the entity profile and basic testing schedule. I’ll then build the TLPT section with the three phases: threat intelligence, red team, and closure.

For the basic testing schedule, here’s the annual plan:

• Q1: Vulnerability assessments and scans (all 15 systems), open-source analyses (SBOM for in-house apps), gap analysis (DORA + ISO 27001 mapping)
• Q2: Network security assessment, physical security review (AWS shared responsibility + office access controls), scenario-based tests (ransomware, DDoS, supply chain)
• Q3: Source code reviews (8 in-house apps via SAST + manual review for payment processing core), compatibility testing (pre-release cycle), performance testing (peak load simulation)
• Q4: End-to-end testing (payment processing failover, DR site activation), penetration testing (this year — then every 3 years minimum), questionnaire assessment (SIG for both vendors)

For the TLPT program, the key decision is tester selection. Under Art. 27 and RTS 2025/1190, you need an external threat intelligence provider and an external red team. Neither can have provided you ICT security services in the past 12 months. Shall I draft the tester qualification checklist and the competent authority engagement timeline?

You: Yes, let’s document the full tester requirements and the TLPT timeline. Also, our fraud detection vendor says they can’t allow us to test directly on their production system. How do we handle that?

Agent: This is addressed in Art. 26(3-4). When a third-party ICT provider cannot accommodate direct testing, you must still include their infrastructure in the TLPT scope. You should formally request the vendor’s participation in writing. If they refuse, you document the refusal and explore two options:

1. Mutual recognition (Art. 26(5)): Check whether your vendor has undergone TLPT by another financial entity that DNB recognizes. If so, those results can be accepted.
2. Pooled testing (Art. 26(4)): You may agree with other financial entities using the same vendor to conduct a joint TLPT, sharing costs and results.

Either way, DNB must approve the approach. I’ll document both options in the competent authority engagement section.

Let me now build the complete testing program JSON and run the validation. After I generate the document structure, I’ll use the dora_testing_program_checker to verify all elements are covered before producing the final program document.

The checker found 0 errors and 1 warning — it flagged that the competent authority reporting section could be more detailed on anonymized findings sharing with ESAs. I’ll expand that section. The program now covers all 12 basic test types, TLPT with all three phases, tester qualifications, remediation tracking, and management body reporting.

Sample Output Excerpt

Below is a representative excerpt from the testing program document, showing the basic testing schedule, TLPT scope, and tester qualification requirements — the sections supervisors focus on during review.

Digital Operational Resilience Testing Program

Entity: PayFlow B.V. Entity type: Payment institution (Art. 2(1)(d)) Competent authority: De Nederlandsche Bank (DNB) Significant entity for TLPT: Yes — identified under Art. 26(8) Program effective date: January 2026

1. Basic Testing Schedule (Art. 25)

2. TLPT Program (Art. 26) — First Exercise

Frequency: At least every three years Methodology: TIBER-NL (Dutch implementation of TIBER-EU, recognized under Art. 26(2)) Scope: All five critical and important functions on live production systems

Phases:

1. Threat intelligence (RTS 2025/1190, Art. 3-5) — External provider: ThreatView BV. Targeted threat intelligence report covering APT groups targeting EU payment institutions, supply chain attack vectors, and credential-based attacks on SCA systems.
2. Red team (RTS 2025/1190, Art. 6-8) — External red team: RedOps Security. Covert engagement over 12 weeks simulating identified threat scenarios against live production systems.
3. Closure — Purple team debrief, remediation plan, competent authority summary report, anonymized findings for ESA sharing.

3. Tester Qualification Requirements (Art. 27)

4. Remediation Tracking Framework (Art. 24(5-6))

All findings tracked in central register with: finding ID, severity, affected system, description, owner, target date, actual closure date, re-test confirmation, and management body sign-off.

Built-in Validation Tools

The skill includes one extension tool that automates completeness checking of the testing program against all DORA Arts. 24-27 requirements.

dora_testing_program_checker

Validates that a DORA digital operational resilience testing program JSON covers every required element. The checker reads the program file and verifies:

Severity levels

• ERROR — A missing required element that must be present for DORA compliance (e.g., missing entity type, missing basic testing types, no TLPT program for a significant entity, no remediation tracking).
• WARNING — A recommended element that strengthens the program but whose absence is not a hard compliance failure (e.g., testing frequency phrasing that may not clearly indicate annual cadence, missing re-testing requirement, absent competent authority engagement process).

Example validation output

========================================================================
DORA Digital Operational Resilience Testing Program — Completeness Check
Arts. 24-27, RTS 2025/1190
========================================================================

--- Errors (must fix) ---
  [ERROR] Missing 3 of 12 basic testing types from Art. 25(1):
    - Open-source analyses (Art. 25(1)(b))
    - Physical security reviews (Art. 25(1)(e))
    - Source code reviews where feasible (Art. 25(1)(g))
  [ERROR] Missing tester qualification documentation (Art. 27 and
          RTS 2025/1190, Art. 9-11). Must document: suitability/
          reputability, technical capabilities, certification/
          accreditation, professional indemnity insurance, independence,
          and 12-month cooling-off period.

--- Warnings (recommended) ---
  [WARNING] Missing re-testing requirement. Remediated vulnerabilities
            must be verified through re-testing.
  [WARNING] Missing competent authority engagement process for TLPT.
            The competent authority must validate scope and approve
            the red team test plan.

========================================================================

The agent runs the checker after building the testing program structure and iterates on any errors before producing the final document.

Getting Started

Add your existing testing documentation, ICT risk assessments, or previous penetration test reports to the project workspace. Then activate the Digital Operational Resilience Testing Program (DORA) skill. The agent will walk you through entity classification, design the basic and TLPT testing programs, validate completeness, and produce the full program documentation.

Useful source materials to upload:

• Your ICT risk management framework identifying critical and important functions (Art. 8)
• Previous vulnerability assessment or penetration test reports
• List of ICT systems and third-party providers supporting critical functions
• Any existing testing policies or schedules
• Competent authority correspondence regarding TLPT identification (if applicable)