How to plan DORA resilience testing using AI

Overview

You'll learn how to design and implement a digital operational resilience testing program that satisfies DORA Articles 24-27 using AI. This guide covers the general testing program (vulnerability assessments, penetration testing, scenario-based testing), advanced Threat-Led Penetration Testing (TLPT) requirements, testing scope and frequency, reporting results to your management body, and integrating testing with your ICT risk management framework, with specific ISMS Copilot prompts for generating each component.

Who this is for

This guide is for:

• CISOs and security managers responsible for designing and overseeing resilience testing programs

• IT risk managers integrating testing results into ICT risk assessments

• Penetration testing coordinators managing internal and external testing activities

• Compliance officers ensuring testing programs meet regulatory expectations

• Consultants helping financial entities prepare for TLPT or general resilience testing

Before you begin

You will need:

• An ISMS Copilot account (free trial available)

• Your ICT risk management framework and ICT asset inventory from How to build a DORA ICT risk management framework using AI

• Your incident classification and response procedures from How to implement DORA incident reporting using AI

• Understanding of your current testing activities (vulnerability scans, penetration tests, DR tests)

• Knowledge of whether your entity has been designated for TLPT by your competent authority

• Budget authorization for external testing services (particularly for TLPT)

Understanding DORA's resilience testing requirements

Article-by-article breakdown

DORA Chapter IV (Articles 24-27) establishes a structured approach to digital operational resilience testing:

Article

Title

Key requirements

Applicability

Art 24

General requirements for digital operational resilience testing

Establish testing program as part of ICT risk management, risk-based approach

All financial entities (proportionate)

Art 25

Testing of ICT tools and systems

Specific testing types: vulnerability assessments, penetration testing, scenario-based testing, compatibility testing, performance testing, source code reviews

All financial entities (proportionate)

Art 26

Advanced testing through TLPT

Threat-led penetration testing based on TIBER-EU framework, every 3 years

Designated entities only

Art 27

Requirements for testers

Qualifications, independence, and standards for testers (internal and external)

All entities conducting testing

General testing vs. TLPT

Understanding the distinction between general testing and TLPT is critical for scoping your program:

Aspect

General testing (Art 24-25)

TLPT (Art 26-27)

Key difference

Who

All financial entities

Designated entities only

Competent authority designates TLPT entities

Frequency

Risk-based; critical systems at least annually

At least every 3 years

TLPT is less frequent but far more intensive

Scope

All ICT systems (proportionate)

Critical and important functions, live production systems

TLPT tests live systems, not just test environments

Methodology

Various (vulnerability scans, pen tests, scenario tests)

TIBER-EU framework, threat intelligence-led

TLPT simulates real-world adversary tactics

Testers

Internal or external (with independence requirements)

External testers required (with limited exceptions)

TLPT requires certified external red team

Reporting

Internal (management body, ICT risk function)

To competent authority, with attestation

TLPT results go to the regulator

Step 1: Design your general testing program (Articles 24-25)

Testing program framework

Article 24 requires a testing program that is integral to your ICT risk management framework, follows a risk-based approach, and is proportionate to your entity's size and risk profile.

1. Open your DORA workspace in ISMS Copilot

2. Generate the testing program document:

   "Create a Digital Operational Resilience Testing Program for a [entity type] satisfying DORA Articles 24-25. Include: program purpose and objectives, governance (management body oversight, program owner, roles and responsibilities), risk-based approach to test planning (how risks determine what is tested and how often), testing scope (mapped to ICT asset inventory and critical/important functions), testing types to be conducted (vulnerability assessments, network security testing, penetration testing, scenario-based testing, compatibility testing, performance testing, source code reviews, open source software testing, end-to-end testing), testing frequency by asset criticality and test type, internal vs external tester requirements, independence requirements per Article 27, results reporting and management body communication, remediation tracking process, integration with ICT risk management framework updates, annual testing calendar template, and budget and resource planning. Apply proportionality for a [entity size] organization."

3. Define the risk-based testing methodology:

   "Create a risk-based testing methodology for DORA resilience testing. Define how we determine: which systems and functions to test (based on ICT asset criticality, business impact, threat landscape, previous incidents), what type of testing to apply (vulnerability scan vs penetration test vs scenario-based test), testing depth and intensity (basic, standard, advanced), testing frequency (quarterly, semi-annual, annual), and testing priority when resources are constrained. Provide a testing priority matrix that maps asset criticality and threat level to testing type and frequency. Include examples for a [entity type]."

Testing types and their application

Article 25 specifies multiple testing types. Use ISMS Copilot to develop detailed plans for each:

1. Vulnerability assessment program:

   "Create a vulnerability assessment program for DORA Article 25 compliance. Include: scanning scope (all ICT assets by criticality tier), scanning tools and methodology, scanning frequency (at least quarterly for critical assets, monthly recommended), vulnerability classification aligned with CVSS scoring, remediation timelines by severity (critical: 48 hours, high: 7 days, medium: 30 days, low: 90 days), exception management process for vulnerabilities that cannot be immediately remediated, reporting format (technical report and management summary), trend analysis methodology, and integration with patch management procedures. Provide a vulnerability management workflow."

2. Penetration testing program:

   "Create a penetration testing program for DORA Article 25 compliance. Include: testing scope (external perimeter, internal network, web applications, mobile applications, API security, social engineering), testing frequency (at least annual for critical systems, more frequent for high-risk areas), testing methodology (OWASP, PTES, or equivalent), rules of engagement template (scope, timing, escalation, prohibited actions), tester qualification requirements per DORA Article 27 (independence, competence, insurance), pre-test procedures (authorization, scope confirmation, communication), reporting requirements (executive summary, technical findings, risk ratings, remediation recommendations), post-test procedures (remediation verification, re-testing), and management body reporting format. Provide a sample rules of engagement template."

3. Scenario-based testing program:

   "Design a scenario-based resilience testing program for DORA Article 25. Create test scenarios covering: ransomware attack on core banking/payment systems, major cloud provider outage affecting critical services, DDoS attack during peak transaction periods, insider threat compromising sensitive data, supply chain attack through a critical third-party ICT provider, simultaneous failure of primary and backup systems, loss of key ICT personnel during an incident, regulatory data breach requiring client notification. For each scenario, define: test objectives, scope and systems involved, scenario narrative and inject timeline, success criteria, participants and roles, test execution procedures, expected outcomes, evaluation criteria, and reporting template. Include both tabletop and simulated exercise formats."

Step 2: Establish tester requirements (Article 27)

Tester independence and qualifications

Article 27 establishes requirements for testers conducting resilience testing. These apply to both internal and external testers:

"Create a tester requirements and qualification policy for DORA Article 27. Address: internal testers (independence from the areas being tested, relevant certifications such as OSCP/CREST/GPEN, maintained competence, rotation requirements), external testers (professional certifications and accreditations, relevant experience in financial sector testing, professional indemnity insurance, independence verification, reference checking), conflict of interest management, tester vetting and security clearance procedures, non-disclosure and confidentiality requirements, and tester performance evaluation criteria. Provide a tester qualification checklist for both internal and external testers, and a sample statement of work for external testing engagements."

Step 3: Plan for TLPT (Articles 26-27)

Understanding TLPT requirements

Threat-Led Penetration Testing (TLPT) under DORA is based on the TIBER-EU framework and represents the most intensive testing requirement. Even if you have not been designated for TLPT, understanding the requirements is valuable for preparation.

1. Assess TLPT applicability:

   "Assess whether our [entity type] with [size, systemic importance, ICT risk profile] is likely to be designated for DORA TLPT under Article 26. Consider: our systemic importance in the financial sector, criticality of services we provide, our ICT risk profile and complexity, competent authority designation criteria from published guidance. If likely designated, provide a TLPT readiness assessment and preparation timeline. If unlikely, recommend preparatory measures we should take regardless."

2. Generate the TLPT framework:

   "Create a TLPT preparation and execution framework for DORA Article 26, aligned with the TIBER-EU methodology. Include: Phase 1 - Preparation: scope definition (critical and important functions to test on live production systems), competent authority engagement and notification, threat intelligence provider selection, red team provider selection, white team formation (internal team aware of the test), internal governance approvals. Phase 2 - Threat Intelligence: threat intelligence report (targeted threat landscape analysis), threat scenarios based on current threat actors and techniques, attack surface analysis, and competent authority review of threat scenarios. Phase 3 - Red Team Testing: red team engagement (simulated attacks on live production systems), test execution over [typical duration: 8-12 weeks], controlled testing with safety mechanisms, purple team activities (if agreed), and findings documentation. Phase 4 - Closure: red team report with findings and evidence, blue team response assessment, remediation plan development, management body briefing, competent authority attestation process. Provide timeline estimates and resource requirements for each phase."

TLPT provider selection

TLPT requires both a threat intelligence provider and a red team provider. Use ISMS Copilot to develop selection criteria:

"Create a TLPT provider selection framework for DORA Article 26-27. For the Threat Intelligence Provider: required qualifications (sector-specific financial threat expertise, recognized certifications), evaluation criteria (quality of previous threat reports, understanding of EU financial sector threats, data sources and collection capabilities), and selection checklist. For the Red Team Provider: required qualifications (CREST, CBEST, or equivalent accreditation, experience with TIBER-EU testing, financial sector experience), evaluation criteria (technical capabilities, methodology, team composition, safety track record), independence verification (no current advisory relationship with entity), insurance requirements, and selection checklist. Provide an RFP template for both provider types."

TLPT scoping

Proper scoping is critical for a successful TLPT. Use ISMS Copilot to define the testing scope:

"Help us define the scope for our DORA TLPT exercise. Our critical and important functions include: [list functions]. For each critical function, identify: the supporting ICT systems and infrastructure that should be in scope, data flows and integrations that could be attack paths, third-party ICT providers that support the function (and whether they should be included in testing per Article 26(3)), potential attack surfaces (external, internal, physical, social engineering), and systems that should be explicitly excluded for safety reasons. Produce a TLPT scope document suitable for competent authority review."

Step 4: Results reporting and remediation tracking

Reporting testing results to management

DORA requires that testing results are reported to the management body and used to update the ICT risk management framework:

1. Generate testing result report templates:

   "Create a resilience testing results report template for management body reporting under DORA Article 24. Include: executive summary (overall resilience posture, key findings, trend comparison), testing program execution summary (tests conducted, scope, timing), findings by severity (critical, high, medium, low) with business impact context, comparison with previous testing cycles (improvement or degradation), remediation status for previously identified vulnerabilities, new remediation recommendations with risk-based prioritization, testing program effectiveness assessment, budget and resource utilization, and recommendations for testing program adjustments. The report should be suitable for non-technical board members while maintaining sufficient detail for risk oversight."

2. Create TLPT attestation documentation:

   "Create a TLPT attestation documentation package for submission to our competent authority under DORA Article 26(6). Include: TLPT summary report (scope, methodology, timeline), anonymized red team findings (critical and high-severity), remediation plan with timeline and status, management body acknowledgment and approval, organizational lessons learned, and any requests for mutual recognition with other competent authorities. Follow the format guidance from [competent authority] and TIBER-EU framework."

Remediation tracking

Testing is only valuable if findings lead to improvements. Establish robust remediation tracking:

"Create a resilience testing remediation tracking procedure for DORA compliance. Include: how findings are translated into remediation actions, prioritization methodology (critical: remediate within 30 days, high: 60 days, medium: 90 days, low: next testing cycle), remediation owner assignment and accountability, progress tracking and escalation for overdue remediations, verification testing (confirming fixes are effective), exception process for findings that cannot be remediated (compensating controls, risk acceptance with management body approval), integration with the ICT risk register (updating risk assessments based on test findings), and reporting cadence to management body. Provide a remediation tracking register template."

Step 5: Integrate testing with your ICT risk management framework

Feeding results into risk management

DORA requires that testing results inform and update your ICT risk management framework. Use ISMS Copilot to formalize this integration:

"Define how resilience testing results integrate with our DORA ICT risk management framework. Include: how testing findings update the ICT risk register (new risks identified, risk ratings adjusted, control effectiveness reassessed), how testing results inform the annual ICT risk management framework review under Article 6(5), how TLPT results influence our ICT risk strategy and risk appetite, how scenario-based testing results update our business continuity and disaster recovery plans, how vulnerability assessment trends inform our protection and prevention measures under Article 9, and how incident simulation results validate or challenge our incident classification and reporting procedures. Provide a process flow showing the feedback loop between testing and risk management."

Continuous testing improvement

Your testing program itself should evolve based on results and changing threats:

"Create an annual testing program review process for DORA compliance. The review should assess: testing coverage (did we test all critical systems and functions as planned?), testing effectiveness (did tests identify real vulnerabilities? how do findings compare to actual incidents?), testing efficiency (are we using resources effectively? are there overlapping or redundant tests?), threat landscape changes (do our test scenarios reflect current threats?), new systems or services added since last review (are they included in the testing scope?), regulatory feedback or guidance on testing expectations, and recommended program adjustments for the next cycle. Produce an annual testing program review report template for management body approval."

Step 6: Manage testing logistics and governance

Testing calendar and coordination

Establish a structured annual testing calendar to ensure all testing activities are planned, resourced, and coordinated:

"Create an annual resilience testing calendar for our [entity type]. Map all required testing activities across the year: vulnerability scans (quarterly for critical, monthly for internet-facing), penetration tests (annual external, annual internal, annual application), scenario-based exercises (semi-annual tabletop, annual simulation), business continuity tests (annual failover, annual backup restoration), and TLPT preparation activities (if applicable). Include: resource requirements for each activity, coordination requirements (change freeze windows, business unit involvement), dependencies between testing activities, budget allocation by quarter, and management body reporting milestones. Format as a calendar view with Gantt-chart structure."

Third-party ICT provider testing

Article 26(3) addresses testing that involves ICT third-party service providers. Coordinate testing requirements with your vendors:

"Create procedures for coordinating resilience testing with ICT third-party providers under DORA. Include: contractual requirements for provider participation in testing (link to Article 28 contract clauses), provider notification and coordination procedures, shared responsibility testing (what we test vs what the provider tests), handling provider refusal to participate in testing, alternative testing approaches when direct provider testing is not possible (synthetic testing, provider-supplied test reports), TLPT involving third-party provider systems (Article 26(3) pooled testing arrangements), and evidence collection from provider testing activities. Address scenarios for cloud providers, managed service providers, and critical infrastructure providers."

Next steps

You now have a comprehensive digital operational resilience testing program:

• Testing program framework with risk-based methodology

• Detailed plans for vulnerability assessments, penetration testing, and scenario-based testing

• Tester qualification and independence requirements

• TLPT preparation framework (if designated or likely to be designated)

• Results reporting templates for management body and competent authority

• Remediation tracking procedures

• Integration with ICT risk management framework

Continue with the final guide in this DORA series:

• How to manage DORA third-party ICT risk using AI -- Ensure your third-party providers are included in your testing program and that contracts support your testing obligations

For the foundational setup, see How to get started with DORA implementation using AI. For the ICT risk framework, see How to build a DORA ICT risk management framework using AI. For incident reporting integration, see How to implement DORA incident reporting using AI.

For ready-to-use prompts, see the DORA Compliance Prompt Library. For the complete regulatory overview, refer to the DORA Compliance Guide for Financial Entities.

Getting help

For additional support planning your resilience testing program:

• Ask ISMS Copilot: Use your DORA workspace to generate test scenarios specific to your entity type and ICT environment

• Upload existing test reports: Get gap analysis by uploading previous penetration test or vulnerability assessment reports for comparison against DORA requirements

• TLPT preparation: Use ISMS Copilot to develop your TLPT scope document and provider selection criteria before engaging with your competent authority

• Validate outputs: Review all testing plans against DORA Articles 24-27, relevant RTS, and the TIBER-EU framework before management body approval