The Resilience Testing module enables your organisation to plan, execute, and track digital operational resilience tests as required by DORA Chapter IV (Articles 24–27). It covers the full lifecycle from scheduling tests through to documenting findings and tracking remediation, with support for all test types including Threat-Led Penetration Testing (TLPT).
Regulatory Context
Article 24 — General Requirements
Article 24 requires every financial entity in scope of DORA to establish, maintain, and review a digital operational resilience testing programme. This programme must be risk-based and proportionate to the entity's size, business profile, and risk profile. It must cover all critical ICT systems and applications that support important business functions.
The testing programme must be reviewed at least annually and updated to reflect changes in the entity's risk landscape, ICT infrastructure, and operational environment. Test results must be documented, reported to management, and used to improve the ICT risk management framework.
Article 25 — Testing of ICT Tools and Systems
Article 25 specifies the testing types entities must perform, including: vulnerability assessments and scans, open-source analysis, network security assessments, penetration testing, source code reviews, scenario-based testing (ransomware, DDoS, failover to DR), and performance testing.
Article 26 — Advanced Testing (TLPT)
Article 26 introduces Threat-Led Penetration Testing (TLPT) for significant financial entities. TLPT is an advanced form of testing based on the TIBER-EU framework that simulates the tactics, techniques, and procedures (TTPs) of real-world threat actors. Key requirements include:
- TLPT must be performed at least every 3 years on critical and important functions
- Testing must target live production systems, not test environments
- The scope must be based on current threat intelligence specific to the entity
- The competent authority determines which entities must perform TLPT based on systemic importance, criticality, and risk profile
- ICT third-party providers supporting critical functions may be included in the TLPT scope (with appropriate controls)
Article 27 — Requirements for Testers
Testers must be independent from the areas being tested and possess appropriate expertise. For TLPT, external testers must hold recognised certifications, carry professional indemnity insurance, and have no conflicts of interest. Internal testers may conduct TLPT only with competent authority approval.
TIBER-EU Framework
TIBER-EU is the European framework for TLPT, providing a standardised methodology for threat-intelligence-driven red team testing. DORA references this framework as the basis for TLPT.
Dashboard
The Resilience Testing main page opens with a dashboard view comprising stat cards, tab navigation, and test/schedule tables.
Six Stat Cards
A row of six cards provides an overview of your testing programme:
| Card | Colour | What It Shows |
|---|---|---|
| Total Tests | Default (heading colour) | Total number of resilience tests recorded |
| Completed | Green | Number of tests with status "Completed" |
| In Progress | Amber | Number of tests currently underway |
| Overdue | Red | Number of tests past their scheduled date that are not yet completed |
| Open Findings | Default (heading colour) | Total number of test findings with open remediation status |
| Critical Findings | Red | Number of findings rated as Critical severity |
Tab Navigation
Below the stats, two tabs allow you to switch between views:
- Tests — Shows the list of individual resilience tests (default view)
- Schedule — Shows recurring testing schedule entries
Tests Tab
Filters
The Tests tab provides three filter controls:
| Filter | Options | Description |
|---|---|---|
| Type | TLPT, Vulnerability Assessment, Scenario-Based, Red Team, Tabletop Exercise, Other | Filter by test methodology. Each type has a colour-coded badge (TLPT=purple, Vulnerability Assessment=blue, Scenario-Based=teal, Red Team=red, Tabletop=amber, Other=grey). |
| Status | Planned, In Progress, Completed, Cancelled, Overdue | Filter by current test status. Badges are colour-coded (Planned=blue, In Progress=amber, Completed=green, Cancelled=grey, Overdue=red). |
| Search | Free text | Search by test title or description. |
Tests Table
The table displays the following columns: Title (with testing provider name if linked), Type (colour-coded badge), Scheduled Date, Status (badge), Risk Rating (if set), Findings (total count with open findings highlighted in red), and an Actions column with a navigation chevron to the test detail page.
New Test Form
Clicking New Test opens a form to create a new resilience test. All fields are grouped under a "Test Details" section.
| Field | Type | Required | Description |
|---|---|---|---|
| Title | Text input | Required | A descriptive name for the test (e.g., "Q1 2026 Vulnerability Assessment") |
| Test Type | Dropdown | Required | TLPT, Vulnerability Assessment, Scenario-Based, Red Team, Tabletop Exercise, or Other |
| Status | Dropdown | Optional | Planned (default), In Progress, Completed, or Cancelled |
| Description | Textarea | Optional | Purpose and objectives of the test |
| Testing Provider | Dropdown | Optional | Select from your registered ICT providers (from the RoI). Use for external testing firms. |
| Scheduled Date | Date picker | Optional | The planned date for the test execution |
| Scope | Textarea | Optional | Systems, applications, and processes included in the test scope |
| Methodology | Textarea | Optional | Testing methodology and standards (e.g., TIBER-EU, CBEST, OWASP, NIST SP 800-115) |
Test Detail Page
The detail page for a test presents a rich view with header badges, content cards, a sidebar, and a findings management section.
Header
The header displays the test title alongside colour-coded badges for test type, current status, and overall risk rating (if set). Below the title, the creator name and creation date are shown. Action buttons (for users with edit permissions) include a status dropdown for quick status changes, an Edit button, and for admins a Delete button.
Content Cards and Sidebar
The main content area (left column) shows up to four cards: Description, Scope, Methodology, and Findings Summary. The right sidebar shows a Details card (Testing Provider, Scheduled/Started/Completed Dates, Report URL) and a Metadata card (Created and Last Updated timestamps).
Findings Management
Below the detail cards, a dedicated Findings section allows you to record, edit, and track individual test findings.
Adding a Finding
Click Add Finding to expand an inline form with the following fields:
| Field | Type | Required | Description |
|---|---|---|---|
| Title | Text input | Required | Short description of the finding |
| Severity | Dropdown | Optional | Critical, High, Medium, Low, or Informational. Each level has a colour-coded badge. |
| Description | Textarea | Optional | Detailed description of the vulnerability or issue |
| Affected Systems | Text input | Optional | Systems or components affected by the finding |
| Remediation Status | Dropdown | Optional | Open, In Progress, Remediated, Accepted Risk, or False Positive |
| Remediation Plan | Textarea | Optional | Planned steps to address the finding |
| Assigned To | Text input | Optional | User responsible for remediation |
| Due Date | Date picker | Optional | Target date for remediation completion |
Findings Table and Inline Editing
Existing findings are listed in a table with columns for Severity (badge), Title, Affected Systems, Remediation Status (badge: Open=red, In Progress=amber, Remediated=green, Accepted Risk=blue, False Positive=grey), Assigned To, Due Date, and Actions. Clicking a finding row expands an inline edit panel with all fields editable. Changes save when you click Save Changes. Admins can delete findings using the trash icon.
Edit Test Page
The Edit page groups all fields into three sections: Test Details (Title, Test Type, Status, Description, Testing Provider, Overall Risk Rating, Scope, Methodology), Dates (Scheduled, Started, Completed), and Results (Findings Summary textarea and Report URL). Results fields are typically populated after the test completes.
Schedule Tab
The Schedule tab manages recurring testing requirements. It helps ensure your testing programme meets the periodic frequencies mandated by DORA and identified in your risk assessment.
Schedule Table
The table shows: Title, Type (badge), Frequency, Next Due Date, Last Completed Date, Mandatory (Yes/No badge), Regulatory Reference, and Actions (delete, admin only). The table highlights overdue entries with a red-tinted background row and the next due date is shown in bold red with an alert triangle icon.
Frequency Options
| Frequency | Description | Typical Use Case |
|---|---|---|
| Monthly | Every month | Automated vulnerability scans |
| Quarterly | Every 3 months | Penetration testing of externally-facing systems |
| Semi-Annual | Every 6 months | Comprehensive vulnerability assessments |
| Annual | Once per year | Full-scope penetration testing, BCP/DRP testing |
| Biennial | Every 2 years | Source code reviews of stable systems |
| Ad Hoc | As needed | Event-driven testing (post-incident, post-migration) |
Overdue Highlighting
When a schedule entry's Next Due Date has passed, the row receives a red-tinted background and the date displays in bold red with an alert triangle icon.
New Schedule Form
The New Testing Schedule form (available to admin users only) creates a recurring schedule entry with the following fields:
| Field | Type | Required | Description |
|---|---|---|---|
| Title | Text input | Required | Name for the recurring test (e.g., "Annual TLPT Exercise") |
| Test Type | Dropdown | Required | Same options as individual tests |
| Frequency | Dropdown | Required | Monthly, Quarterly, Semi-Annual, Annual, Biennial, or Ad Hoc |
| Description | Textarea | Optional | Purpose and scope of the recurring test |
| Next Due Date | Date picker | Optional | When the next instance of this test is due |
| Regulatory Reference | Text input | Optional | The DORA article or other regulation requiring this test (e.g., "DORA Art. 26(1)") |
| Mandatory | Checkbox | Optional | Mark if this test is legally required. Mandatory entries receive a blue "Yes" badge in the schedule. |