Digital Operational Resilience Testing Programme
Plans the risk-based testing programme across vulnerability assessments, scenario tests and, where applicable, TLPT.
Available soon
- Format
- Excel
- Size
- 90 KB
- Length
- 12 sheets
- Version
- 1.1
- Updated
Follow this documentFree account. We can email you when it changes.
What's inside
What changed
- 1.1
The mappings note no longer says the CISO Times Library shows a verification state; it says what a mapping shows and to confirm it against both texts.
- 1.0
Published.
Preview
The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.
Instructions
How to use this workbook
| Step | What to do |
|---|---|
| 1 | What this workbook is. It is the testing programme DORA Article 24 asks the entity to keep (A resilience testing programme, RQ-32) and the yearly test list of Article 24(6) (RQ-33). The resilience testing lead keeps it. It does not decide whether DORA binds you: take your answers from the DORA Proportionality & Scope Assessment. |
| 2 | Start on the Profile and counts sheet. Set the as-at date and the programme start. Choose the entity type, the framework (full, simplified or out of scope), whether you are a microenterprise, and whether a TLPT authority has identified you. A TLPT authority cannot identify an Article 16 entity or a microenterprise; the sheet says so if you try (DR-01, DR-16). |
| 3 | Read the frequency rules TR-1 to TR-6 on the same sheet. Each shows whether it applies to you. A microenterprise tests on its own risk-based plan (TR-5, RQ-35): the dates here are still a good discipline, but your plan sets the frequency. |
| 4 | Check the test types, DT-01 to DT-16. Set the months between tests for the types shaded yellow, which are house defaults. Where a type has no test planned, write why (RQ-34: say why each type was chosen or left out). |
| 5 | List the systems on the Systems sheet. Mark each Yes if it supports a critical or important function. Mark a system Yes until its function has been assessed (DR-10). Enter the date it went into service: that starts the clock for a system that has never been tested. |
| 6 | Record every test of a system on the Test log sheet: system, test type, date, whether it was held, whether an independent party did it, the tester and the result. Enter a test that did not count too, with its reason. Only a held test by an independent party, dated on or before the as-at date, counts (DR-12, DORA Art 24(4)). |
| 7 | An exercise or tabletop under P10 is an exercise. It is not a test of a system and is never counted as one. P22 RR-14 owns the recovery test and P23 BR-13 owns the restore test. P21 counts a P22 or P23 test as a continuity test (DT-14) when its record meets their rules, and restates neither. |
| 8 | Plan the recurring tests on the Programme sheet: one row per test, its type, its scope, the date of the last test that counts and who keeps it. The sheet works out the next due date and the state. A test of the continuity, response and recovery plans (DT-14) quotes the P22 or P23 record it comes from. |
| 9 | Read the states. Current: not yet due. Overdue: due before the as-at date. Never tested: a system with no test that counts and a first test that fell due. An overdue system or test is a gap: enter it in the DORA Gap & Remediation Tracker with an owner, a priority and a due date (DR-06). |
| 10 | Enter every test finding in the DORA Gap & Remediation Tracker, with an owner, a priority and a due date. A person other than the one who fixed a weakness confirms that it is fully addressed (DR-14, DORA Art 24(5)). Write the tracker IDs in the Test log's findings column. |
| 11 | Use the TLPT sheet only if a TLPT authority has identified the entity (DR-16). It checks your plan against Delegated Regulation (EU) 2025/1190, works out the deadlines from the dates you enter, and lists the file to keep. |
| 12 | Read the counts on the Profile and counts sheet, such as "4 of 5 systems tested in time". The DORA Readiness Self-Assessment uses them for readiness items RT-02 and RM-06. Report counts with names to the management body. Never report a percentage (DR-04). |
| 13 | Review the programme at least every [[12]] months, and after a substantive change to the systems behind a critical or important function (DORA Art 11(6)). Keep the records behind each test for the period in DR-19. The DORA Documentation & Evidence Checklist lists them (EV-21 to EV-24). |
| 14 | To clear the EXAMPLE, delete the EXAMPLE rows on the Programme, Systems and Test log sheets once your own are entered, and replace the settings on the Profile and counts sheet. The formulas stay. |
Legend
Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.
| EXAMPLE | Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval. |
Limitations: This document helps you see what DORA asks of an entity like yours and what you can show. It is not legal advice, and following it is not a statement that you comply with DORA or any standard. Whether DORA binds you, and which of its duties apply to you, depends on what you are, how you are authorised and how your Member State and your supervisor apply it: confirm it with counsel or your competent authority.
Who this is for: DORA is one regulation with five pillars: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, the management of ICT third-party risk, and information sharing. Every financial entity meets the same five pillars, and the depth of each depends on what the entity is. A microenterprise, a small investment firm, an exempted payment institution and a large bank each owe a different part of each pillar, and the Regulation says which. So the first question is what you are, the second is which duties that makes yours, and only then is it worth asking how ready you are. Being ready is a count of duties in place and duties still open. It is never one score.
P09 owns incident response and every decision right, clock and recovery criterion (DR-15). P22 RR-14 owns the recovery test and P23 BR-13 owns the restore test. This workbook cites them by ID and counts a P22 or P23 test as a continuity test (DT-14) only when its own record meets their rules (DR-13).
EXAMPLE: Lantern Pay Services (EXAMPLE), a small authorised payment institution in an EU Member State, with 64 staff, as at 30 Sep 2026. Its profile is the full framework; it is not a microenterprise and no TLPT authority has identified it. 4 of 5 systems behind its critical function have a test that counts in the last 12 months; SYS-02 fell due on 29 Aug 2026. The programme was approved on 2026-01-28, uses independent testers and has a finding register with validated closure.
What counts as a test:
• A test counts towards the yearly test of a system behind a critical or important function when it was held, was done by an independent party and is dated on or before the as-at date.
• Independent means a party apart from the people who built or operate the system, internal or external (DORA Art 24(4)). An internal tester needs enough resources and no conflict of interest.
• A planned test, a cancelled test and a test run by the system's own team do not count. Enter them with Held or Independent set to No to keep the record.
Adapting this template:
• Replace the [[placeholders]] with your own values, and delete the EXAMPLE rows on the Programme, Systems and Test log sheets once you have entered your own. The formulas stay.
• Change the months between tests for the house defaults on the Profile and counts sheet only if your testing programme sets different ones. Never set an interval longer than the one your approved programme sets. The two intervals that DORA sets (DT-14, DT-15) and the TLPT interval (DT-13) are not shaded: change them only if your competent authority tells you to, and say so in the document control table.
• Use your own system IDs if your asset inventory or your register of information already has them. Keep one ID for each system for its whole life, so the test log stays linked to it.
• Add your own columns to the right of the calculated ones, so the layout stays the same as the formulas expect.
• If your approved testing programme is a document, keep it with this workbook. This workbook holds the dates, the tests and the states. The document holds the reasoning (DORA Art 24(3): the risk-based approach).
This workbook is your own record. Keep it with your approved testing programme and the test reports behind each row.
Profile and counts
Profile, rules, counts and test types
Enter the entity's answers (yellow). The white cells apply the facts to them: which frequency rules apply, the TLPT status, the counts and, for each test type, how many tests are planned or recorded. Counts only: no score and no percentage (DR-04).
Profile and settings
| As-at date | 30 Sep 2026 | States are worked out at this date. EXAMPLE: 30 Sep 2026. Type a date, never a formula. | ||||||
| Programme start | 1 Jan 2026 | The clock for a test that has never been run starts here. The EXAMPLE uses 1 Jan 2026. Use the date your programme was approved, or the date DORA applied to you. | ||||||
| Entity type (DORA Art 2(1)) | Payment institution (including an exempted payment institution) | From the DORA Proportionality & Scope Assessment. Used for the TLPT status below. | ||||||
| Framework | Full ICT risk management framework (DORA Articles 5 to 15) | From the scope assessment. An entity outside DORA, or a supplier to a financial entity, has no duty from this workbook (DR-22). | ||||||
| Microenterprise (DORA Art 3(60)) | No | Fewer than 10 persons and turnover or balance sheet total of EUR 2 million or less, and not a trading venue, central counterparty, trade repository or central securities depository. | ||||||
| A TLPT authority has identified the entity | No | Answer Yes only if the authority has told you in writing (DORA Art 26(8)). Being regulated does not make it Yes (PF-08). | ||||||
| Framework key (calc) | full | Full, simplified, or other (outside DORA, or a supplier). | ||||||
| TLPT applies to you (calc) | No | Yes only for an entity under the full framework, not a microenterprise, that a TLPT authority has identified (DORA Art 26(1)). | ||||||
| TLPT status (calc) | Not required unless a TLPT authority identifies the entity (Article 26(8)). Delegated Regulation 2025/1190 Article 2(2) names payment institutions that exceeded EUR 150 billion of total value of payment transactions in each of the 2 calendar years before the assessment; the authority may decide that the assessment does not justify TLPT. | |||||||
| Check on the identification (calc) | No conflict | |||||||
The frequency rules DORA sets (TR-1 to TR-6)
| Rule | Who it binds | What it asks | Applies to you (calc) | Months | Source |
|---|---|---|---|---|---|
| TR-1 | Every financial entity in scope other than microenterprises | At least yearly, appropriate tests on all ICT systems and applications that support critical or important functions, by independent parties (every 12 months). | Yes | 12 | DORA 24(6) |
| TR-2 | Entities under the full framework (not the Article 16 entities) | Test the continuity plans and the response and recovery plans for the systems that support all functions at least yearly (every 12 months), and after a substantive change to the systems behind critical or important functions; test the crisis communication plans. | Yes | 12 | DORA 11(6) |
| TR-3 | Entities under the simplified framework (Article 16) | Entities under the simplified framework test the business continuity plans at least once every year for the backup and restore procedures, or on every major change to the plan (every 12 months). | No | 12 | RTS 40(1) |
| TR-4 | Entities that a TLPT authority has identified | An entity that a TLPT authority has identified performs TLPT at least every 3 years; the authority may raise or lower the frequency. | No | 36 | DORA 26(1) |
| TR-5 | Microenterprises | Microenterprises test on a risk basis with a strategic plan for testing, and set their own frequency. | No | Your plan | DORA 25(3) |
| TR-6 | Every financial entity in scope | Exit plans for arrangements that support critical or important functions are tested and reviewed periodically. The period is the entity's: the default here is a house default. | Yes | 12 | DORA 28(8) |
Counts
| Systems behind a critical or important function | 5 | DORA Art 24(6), RQ-33. | ||||||
| of them with a test that counts inside the last 12 months | 4 | The state is Current. | ||||||
| In words | 4 of 5 systems tested in time | Report this to the management body. Never a percentage (DR-04). | ||||||
| Overdue or never tested | SYS-02 | System IDs, in the order of the Systems sheet. Each is a gap for the tracker (DR-06). | ||||||
| Suggested level for readiness item RT-02 (DORA Readiness Self-Assessment) | In place | Operating only if every system is Current. The self-assessment sets the level; this is the evidence. | ||||||
| Recurring tests in the programme that apply to you | 7 | Programme sheet, rows where the test applies. | ||||||
| of them with an interval | 7 | Compatibility testing (DT-09) has none: it is "Run on change". | ||||||
| of those overdue | 1 | The next due date is before the as-at date. | ||||||
| In words | 1 of 7 dated tests overdue | |||||||
|---|---|---|---|---|---|---|---|---|
| Tests that run when something changes | 0 | |||||||
| Suggested level for readiness item RM-06 (DORA Readiness Self-Assessment) | In place | From the DT-14 row: the yearly test of the continuity, response and recovery plans (DORA Art 11(6)). | ||||||
| Test types that apply to you | 15 | DT-13 (TLPT) applies only when a TLPT authority has identified you. | ||||||
| Test types with a test planned or recorded | 10 of 15 test types | RQ-34: say why each type was chosen or left out. The reasons are below. | ||||||
Test types (DT-01 to DT-16)
| Test | Test type | What it is | Source | Months between tests | Where the interval comes from | Planned or recorded tests (calc) | Applies to you (calc) | Reason if no test is planned (RQ-34) |
|---|---|---|---|---|---|---|---|---|
| DT-01 | Vulnerability assessments and scans | Finds known weaknesses in systems, applications and networks. | Article 25(1) | 3 | House default | 2 | Yes | |
| DT-02 | Open source analyses | Checks the open source components the entity's software uses for known weaknesses and licence risks. | Article 25(1) | 12 | House default | 0 | Yes | [[Why this type is not in the programme, or when it will be]] |
| DT-03 | Network security assessments | Reviews network design, segmentation and configuration against the entity's own rules. | Article 25(1) | 12 | House default | 0 | Yes | [[Why this type is not in the programme, or when it will be]] |
| DT-04 | Gap analyses | Compares what exists with what the policy or the rule asks for. | Article 25(1) | 12 | House default | 1 | Yes | |
| DT-05 | Physical security reviews | Checks the premises, data centres and sensitive areas that hold ICT assets. | Article 25(1) | 12 | House default | 1 | Yes | |
| DT-06 | Questionnaires and scanning software solutions | Collects answers or automated scan results from system owners or providers. | Article 25(1) | 12 | House default | 1 | Yes | |
| DT-07 | Source code reviews (where feasible) | Reads the code of the entity's own applications for security flaws. | Article 25(1) | 12 | House default | 1 | Yes | |
| DT-08 | Scenario-based tests | Runs a defined disruption or attack scenario against a system or process. | Article 25(1) | 12 | House default | 0 | Yes | [[Why this type is not in the programme, or when it will be]] |
| DT-09 | Compatibility testing | Checks that a change works with the systems around it. | Article 25(1) | No fixed interval | 0 | Yes | [[Why this type is not in the programme, or when it will be]] | |
| DT-10 | Performance testing | Checks capacity and behaviour under load (DORA Art 7). | Article 25(1) | 12 | House default | 0 | Yes | [[Why this type is not in the programme, or when it will be]] |
| DT-11 | End-to-end testing | Follows a business transaction through every system that handles it. | Article 25(1) | 12 | House default | 1 | Yes | |
| DT-12 | Penetration testing | An authorised attempt to break into a system, run by someone independent of its builders and operators. | Article 25(1) | 12 | House default | 2 | Yes | |
| DT-13 | Threat-led penetration testing (TLPT) | A red team test of critical live production systems that copies real threat actors. Only for entities a TLPT authority identifies. | Article 26 | 36 | Set by DORA | 0 | No: needs a TLPT authority's identification | |
| DT-14 | Test of the continuity, response and recovery plans | Tests the plans for the systems that support all functions, and again after a substantive change to the systems behind critical or important functions. Recovery tests are P22 RR-14; restore tests are P23 BR-13. | Article 11(6) | 12 | Set by DORA | 1 | Yes | |
| DT-15 | Test of the crisis communication plans | Tests the plans of Article 14. | Article 11(6)(b) | 12 | Set by DORA | 1 | Yes | |
| DT-16 | Test and review of an exit plan | Tests and reviews the exit plan of an arrangement that supports a critical or important function. DORA says 'periodically'. | Article 28(8) | 12 | House default | 1 | Yes |
EXAMPLE: DT-01 to DT-12 are the twelve kinds of test DORA Article 25(1) lists, in its order. DT-13 to DT-16 are the tests Articles 26, 11(6) and 28(8) add. DORA fixes the interval only for DT-13, DT-14 and DT-15 (and the yearly test of Article 24(6) for each system); the other intervals are house defaults you set.
Entities that Delegated Regulation 2025/1190 Article 2(2) names for TLPT
| Entity type | Named by the Delegated Regulation | ||||||
|---|---|---|---|---|---|---|---|
| Credit institution | global or other systemically important credit institutions, and credit institutions that are part of one | ||||||
| Payment institution (including an exempted payment institution) | payment institutions that exceeded EUR 150 billion of total value of payment transactions in each of the 2 calendar years before the assessment | ||||||
| Electronic money institution (including an exempted one) | electronic money institutions that exceeded EUR 150 billion of payment transactions, or EUR 40 billion of outstanding electronic money, in each of the 2 calendar years before the assessment | ||||||
| Central securities depository | central securities depositories | ||||||
| Central counterparty | central counterparties | ||||||
| Trading venue | trading venues above the market-share criteria of Article 2(2)(f) | ||||||
| Insurance or reinsurance undertaking | insurance and reinsurance undertakings above the premium, provisions and asset criteria of Article 2(2)(g) | ||||||
The authority may decide that its assessment does not justify TLPT for an entity on this list (DORA Art 26(8)).
Programme
EXAMPLE: 7 recurring tests, as at 30 Sep 2026. Yellow columns are inputs; white columns calculate from the Profile and counts sheet. One row per recurring test. Systems have their own rows on the Systems sheet.
| Example | Plan ID | Test type | Test type name (calc) | Scope | Source (calc) | Months between tests (calc) | Where the interval comes from (calc) | Latest test that counts | Applies to you (calc) | Next test due (calc) | State (calc) | Owner | Independent tester or provider | Related test record (report, P22 RR-14, P23 BR-13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | T-01 | DT-01 | Vulnerability assessments and scans | All internet-facing and payment systems, quarterly | Article 25(1) | 3 | House default | 18 Sep 2026 | Yes | 18 Dec 2026 | Current | Security Assurance Lead | ||
| EXAMPLE | T-02 | DT-04 | Gap analyses | Gap analysis against the framework | Article 25(1) | 12 | House default | 10 Feb 2026 | Yes | 10 Feb 2027 | Current | Security Assurance Lead | ||
| EXAMPLE | T-03 | DT-05 | Physical security reviews | Office and the two hosting suites | Article 25(1) | 12 | House default | 20 Jan 2026 | Yes | 20 Jan 2027 | Current | Security Assurance Lead | ||
| EXAMPLE | T-04 | DT-06 | Questionnaires and scanning software solutions | Supplier questionnaires for the seven arrangements | Article 25(1) | 12 | House default | 30 Jun 2026 | Yes | 30 Jun 2027 | Current | Security Assurance Lead | ||
| EXAMPLE | T-05 | DT-14 | Test of the continuity, response and recovery plans | Continuity, response and recovery plans for all functions (P22 RR-14, P23 BR-13 for the recovery and restore tests) | Article 11(6) | 12 | Set by DORA | 26 Aug 2025 | Yes | 26 Aug 2026 | Overdue | Head of Information Security | ||
| EXAMPLE | T-06 | DT-15 | Test of the crisis communication plans | Crisis communication plan | Article 11(6)(b) | 12 | Set by DORA | 24 Feb 2026 | Yes | 24 Feb 2027 | Current | Head of Information Security | ||
| EXAMPLE | T-07 | DT-16 | Test and review of an exit plan | Exit plan for CA-001 | Article 28(8) | 12 | House default | Yes | 1 Jan 2027 | Current | Head of Procurement |
Systems
EXAMPLE: 6 systems, 5 of them behind a critical or important function, as at 30 Sep 2026. Yellow columns are inputs; white columns calculate from the Test log sheet. One row per system (DORA Art 24(6), DR-12).
| Example | System ID | System or application | Supports a critical or important function | In service since | Latest test that counts (calc) | Test type (calc) | Tester (calc) | Result (calc) | Next test due (calc) | State (calc) | Order if overdue (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | SYS-01 | Payment processing platform (run by Platform Provider A, CA-001) | Yes | 1 May 2022 | 24 Mar 2026 | DT-11 | Internal quality assurance, apart from the platform team | No findings | 24 Mar 2027 | Current | |
| EXAMPLE | SYS-02 | Settlement API gateway | Yes | 1 Jun 2021 | 29 Aug 2025 | DT-12 | External tester | Two medium findings, closed | 29 Aug 2026 | Overdue | 1 |
| EXAMPLE | SYS-03 | Payments ledger database | Yes | 1 Jun 2021 | 2 Sep 2026 | DT-01 | Security team, apart from the database administrators | One low finding | 2 Sep 2027 | Current | |
| EXAMPLE | SYS-04 | Fraud rules engine | Yes | 1 Mar 2023 | 12 May 2026 | DT-07 | External tester | One medium finding, closed | 12 May 2027 | Current | |
| EXAMPLE | SYS-05 | Customer authentication service | Yes | 1 May 2022 | 21 Apr 2026 | DT-12 | External tester | No findings | 21 Apr 2027 | Current | |
| EXAMPLE | SYS-06 | Back-office reporting server (legacy) | No | 1 Mar 2016 | Not behind a critical or important function |
Test log
EXAMPLE: 5 tests of the 6 systems. One row per test. A P10 exercise or tabletop is not a test of a system and is never entered here (DR-13). P22 RR-14 recovery tests and P23 BR-13 restore tests are plan-level tests: enter them on the Programme sheet as DT-14, with their record.
| Example | System ID | Test type | Test date | Held | By an independent party | Tester | Result | Report or record reference | Findings in the tracker (A09 IDs) | Counts towards Art 24(6) (calc) | Lookup key (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | SYS-01 | DT-11 | 24 Mar 2026 | Yes | Yes | Internal quality assurance, apart from the platform team | No findings | Yes | SYS-01|46105 | ||
| EXAMPLE | SYS-02 | DT-12 | 29 Aug 2025 | Yes | Yes | External tester | Two medium findings, closed | Yes | SYS-02|45898 | ||
| EXAMPLE | SYS-03 | DT-01 | 2 Sep 2026 | Yes | Yes | Security team, apart from the database administrators | One low finding | Yes | SYS-03|46267 | ||
| EXAMPLE | SYS-04 | DT-07 | 12 May 2026 | Yes | Yes | External tester | One medium finding, closed | Yes | SYS-04|46154 | ||
| EXAMPLE | SYS-05 | DT-12 | 21 Apr 2026 | Yes | Yes | External tester | No findings | Yes | SYS-05|46133 |
TLPT
Threat-led penetration testing (TLPT): only if identified
An entity that the competent authority identifies carries out TLPT at least every 3 years, which may be raised or lowered. Each test covers several or all critical or important functions on live production systems, with the scope validated by the authority. The entity ensures that its ICT third-party providers in scope take part and stays responsible. It uses testers that meet Article 27 and contracts external testers every three tests. TLPT is planned only after a TLPT authority has identified the entity. An Article 16 entity or a microenterprise never plans one. When identified, the entity follows Delegated Regulation 2025/1190 and Article 27 for its testers.
Your status
| TLPT applies to you | No | From the Profile and counts sheet. | ||
| Not required unless a TLPT authority identifies the entity (Article 26(8)). Delegated Regulation 2025/1190 Article 2(2) names payment institutions that exceeded EUR 150 billion of total value of payment transactions in each of the 2 calendar years before the assessment; the authority may decide that the assessment does not justify TLPT. | ||||
Planning checks (Delegated Regulation 2025/1190)
| Check | Your plan | The rule | Result | Source |
|---|---|---|---|---|
| Active red team testing phase, in weeks | At least 12 weeks, and proportionate to the scope and scale | Enter your plan | RTS 1190 11 | |
| Scenarios the control team lead selects | At least 3 | Enter your plan | RTS 1190 10 | |
| of them not threat-led | No more than 1 | Enter your plan | RTS 1190 10 |
Dates and deadlines (Delegated Regulation 2025/1190)
| Event | Date | Deadline | Deadline date (calc) | Source |
|---|---|---|---|---|
| The authority notifies you that you must perform TLPT | Initiation information to the test managers, within 3 months | RTS 1190 9 | ||
| The active red team testing phase ends | Red team test report from the testers, within 4 weeks | RTS 1190 12 | ||
| (same date) | Blue team report, replay and purple teaming, no later than 10 weeks after it | RTS 1190 12 | ||
| The authority notifies you that the reports are adequate | Summary report of findings to the TLPT authority, within 8 weeks | RTS 1190 12 | ||
| (same date) | Remediation plans and documentation under DORA Art 26(6), within 8 weeks | RTS 1190 13 | ||
| The deadlines count from the dates you enter. The authority's own notices and the test managers set the dates in practice: check each against them. Enter the date of the last TLPT on the DT-13 row of the Programme sheet; the next one falls due 3 years later unless the authority changes the frequency (DORA Art 26(1)). | ||||
The TLPT file: what to have ready
| Record | Status | Source | Requirement |
|---|---|---|---|
| The authority's identification letter and the validated scope | Article 26(1) to (3), (8) | RQ-37 | |
| The TLPT plan, the test managers' approvals and the provider participation terms | Article 26(1) to (3), (8) | RQ-37 | |
| The summary report, the remediation plans and the attestation | Article 26(6), (7); Delegated Regulation 2025/1190 Articles 12 and 13 | RQ-38 | |
| Tracking of each finding to closure | Article 26(6), (7); Delegated Regulation 2025/1190 Articles 12 and 13 | RQ-38 | |
| The tester selection record against each criterion | Article 27 | RQ-39 | |
| The contract terms for handling the results | Article 27 | RQ-39 |
0 of 6 records ready
Lists
| YesNo | EntityType | RegimeList | EvidenceStatus |
|---|---|---|---|
| Yes | Credit institution | Full ICT risk management framework (DORA Articles 5 to 15) | Ready |
| No | Payment institution (including an exempted payment institution) | Simplified ICT risk management framework (DORA Article 16) | Partly ready |
| Account information service provider | Out of scope of DORA | Not ready | |
| Electronic money institution (including an exempted one) | Not applicable |
Investment firm
Crypto-asset service provider, or issuer of asset-referenced tokens
Central securities depository
Central counterparty
Trading venue
Trade repository
Manager of alternative investment funds
Management company
Data reporting service provider
Insurance or reinsurance undertaking
Insurance, reinsurance or ancillary insurance intermediary
Institution for occupational retirement provision
Credit rating agency
Administrator of critical benchmarks
Crowdfunding service provider
Securitisation repository
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| Test (DT-nn) | One of the test types DT-01 to DT-16. DT-01 to DT-12 are the kinds of test in DORA Article 25(1). DT-13 is TLPT. DT-14 to DT-16 are the tests of the plans, the crisis communication plans and an exit plan. |
| Test that counts | A test of a system that was held, was done by an independent party and is dated on or before the as-at date (DR-12). Only these start the yearly clock of Article 24(6). |
| Independent party | A party apart from the people who built or operate the system, internal or external (DORA Art 24(4)). |
| Behind a critical or important function | A system or application that supports a critical or important function. Function: critical or important function (DORA Art 3(22)). Treat a system as behind one until its function is assessed (DR-10). |
| Critical or important function | A function whose disruption would materially impair the entity's financial performance, or the soundness or continuity of its services and activities, or its continuing compliance with the conditions of its authorisation (DORA Art 3(22)). The entity decides, records why, and reviews the decision (DR-09). |
| TLPT | Threat-led penetration testing: a controlled, intelligence-led red team test of the entity's critical live production systems that copies real threat actors (DORA Art 3(17)). Only entities that a TLPT authority identifies perform it, and then at least every 3 years (Art 26). |
| Microenterprise | A financial entity, other than a trading venue, a central counterparty, a trade repository or a central securities depository, with fewer than 10 persons and an annual turnover or balance sheet total of EUR 2 million or less (DORA Art 3(60)). |
| Simplified framework | The lighter framework of DORA Article 16 for small and non-interconnected investment firms, exempted payment and electronic money institutions, and similar entities. Articles 5 to 15 do not apply to them. |
| Programme start | The date the clock starts for a test that has never been run. A setting of this workbook, not a date set by DORA. |
| House default | An interval this workbook proposes where DORA says only that tests happen. You set your own in the test types table (DT-16 and the others shaded yellow). |
| Exercise (P10) | A tabletop or other exercise run under P10. It is never a test of a system and is never counted (DR-13). |
| Recovery test, restore test | The recovery test is P22 RR-14 and the restore test is P23 BR-13. This workbook counts a P22 or P23 test as a continuity test (DT-14) when its record meets their rules (DR-13). |
| Gap, finding | A gap is a duty below the level it should be at; a finding is a weakness a test found. Both go in the gap tracker with an owner, a priority and a due date (DR-06, DR-14). |
| Current | The latest test that counts is inside its interval: the next test is not yet due. |
| Overdue | The next test was due before the as-at date. A system with an old test, or a programme row with an old last test. |
| Never tested | A system behind a critical or important function has no test that counts, and its first yearly test fell due before the as-at date. The clock runs from the date the system went into service. |
| Run on change | A test type with no fixed interval (compatibility testing, DT-09). Run it when a change needs it. |
| Not required | A test the profile does not require. TLPT (DT-13) is required only when a TLPT authority has identified the entity. |
| Not behind a critical or important function | The system supports no critical or important function, so the yearly test of DORA Article 24(6) does not apply to it. Test it on your risk-based plan. |
| (calc) | A column or cell the workbook calculates. Do not type or paste over it. |
| EXAMPLE | A worked example: Lantern Pay Services (EXAMPLE), a small fictional payment institution, as at 30 Sep 2026. Delete before use. |
Framework References
Framework references
These references indicate relevance only and do not reproduce the text of any standard.
| Framework | Reference | Supported by |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 5.30 — ICT readiness for business continuity | Programme sheet, DT-14: the tests of the continuity, response and recovery plans, and the dates they fall due |
| ISO/IEC 27001:2022 | Annex A 8.8 — Management of technical vulnerabilities | Programme and Systems sheets: vulnerability assessments and scans (DT-01) and the other tests that find technical weaknesses, and when each falls due |
| NIST CSF 2.0 | ID.IM-02 — “Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties” | Test log sheet: each test and its result, with the findings entered in the gap tracker so improvements follow from them |
| DORA — Regulation (EU) 2022/2554 | Article 4 — financial entities implement the rules of Chapter II in line with proportionality, taking into account their size and overall risk profile, and the nature, scale and complexity of their services, activities and operations; Chapters III, IV and V, Section I, apply proportionately “as specifically provided for in the relevant rules of those Chapters”; competent authorities consider how the entity applied proportionality when they review its ICT risk management framework on the reports submitted under Articles 6(5) and 16(2) | Profile and counts sheet: the framework and microenterprise answers set which rules apply, so depth follows size and risk. A microenterprise tests on its own risk-based plan |
| DORA — Regulation (EU) 2022/2554 | Article 11(6) — test the ICT business continuity plans and the ICT response and recovery plans “in relation to ICT systems supporting all functions at least yearly, as well as in the event of any substantive changes to ICT systems supporting critical or important functions”, and test the crisis communication plans (Article 14); financial entities other than microenterprises include in the testing plans “scenarios of cyber-attacks and switchovers between the primary ICT infrastructure and the redundant capacity, backups and redundant facilities”; the policy and plans are regularly reviewed taking into account test results and recommendations from audit checks or supervisory reviews | Programme sheet, DT-14 and DT-15: the yearly test of the continuity, response and recovery plans and of the crisis communication plans. Recovery tests are P22 RR-14 and restore tests are P23 BR-13, entered by ID |
| DORA — Regulation (EU) 2022/2554 | Article 24(1) — “For the purpose of assessing preparedness for handling ICT-related incidents, of identifying weaknesses, deficiencies and gaps in digital operational resilience, and of promptly implementing corrective measures”, financial entities other than microenterprises establish, maintain and review a digital operational resilience testing programme | Programme and Systems sheets: the programme, its schedule and when each test falls due, to be kept as part of the ICT risk management framework |
| DORA — Regulation (EU) 2022/2554 | Article 24(3) — financial entities other than microenterprises follow a risk-based approach in the testing programme, considering the evolving landscape of ICT risk, specific risks to which the entity is or might be exposed, the criticality of information assets and of services provided, and any other factor the entity deems appropriate | Test types table on the Profile and counts sheet: the reason each test type is chosen or left out, so the programme follows risk |
| DORA — Regulation (EU) 2022/2554 | Article 24(4) — financial entities other than microenterprises ensure that tests are undertaken by independent parties, internal or external; where an internal tester is used, sufficient resources are dedicated and conflicts of interest are avoided throughout the design and execution of the test | Test log sheet: the independent-party column. Only a held test by an independent party counts |
| DORA — Regulation (EU) 2022/2554 | Article 24(5) — procedures and policies to prioritise, classify and remedy all issues revealed by the tests, and internal validation methodologies to ascertain that all identified weaknesses, deficiencies or gaps are fully addressed | Test log sheet: the findings column points to the gap tracker (DORA Gap & Remediation Tracker), where each finding has a priority, an owner, a due date and a validated closure |
| DORA — Regulation (EU) 2022/2554 | Article 24(6) — at least yearly, appropriate tests on all ICT systems and applications supporting critical or important functions | Systems sheet: each system behind a critical or important function, its latest test that counts, the next due date and its state; the count on the Profile and counts sheet |
| DORA — Regulation (EU) 2022/2554 | Article 25(1) — the testing programme provides for appropriate tests, among them “scenario-based tests” | Test types table on the Profile and counts sheet: the twelve kinds of test DT-01 to DT-12, and the count of tests planned or recorded for each |
| DORA — Regulation (EU) 2022/2554 | Article 25(2) — central securities depositories and central counterparties perform vulnerability assessments before any deployment or redeployment of new or existing applications and infrastructure components, and of ICT services supporting critical or important functions | Test types table: DT-01, vulnerability assessments. A central securities depository or central counterparty also assesses before any deployment or redeployment: record those in the Test log sheet |
| DORA — Regulation (EU) 2022/2554 | Article 25(3) — microenterprises perform the Article 25(1) tests by combining a risk-based approach with a strategic planning of ICT testing, balancing the resources and time allocated to testing against the urgency, type of risk, criticality of information assets and of services provided, and any other relevant factor, including the entity’s ability to take calculated risks | Profile and counts sheet: the microenterprise answer and rule TR-5, so a microenterprise sets its own frequency from a risk-based plan |
| DORA — Regulation (EU) 2022/2554 | Article 26(1) — financial entities, other than the entities of Article 16(1) first subparagraph and other than microenterprises, that the competent authority identifies under Article 26(8) carry out advanced testing by TLPT “at least every 3 years”; the authority may, on the entity’s risk profile and operational circumstances, ask it to reduce or increase that frequency | Profile and counts sheet (TLPT status), the DT-13 row of the Programme sheet and the TLPT sheet: TLPT applies only when a TLPT authority has identified the entity, at least every 3 years unless the authority changes it |
| DORA — Regulation (EU) 2022/2554 | Article 26(2) — each TLPT covers several or all critical or important functions and is performed on live production systems supporting them; the entity identifies all relevant underlying ICT systems, processes and technologies, including those outsourced to ICT third-party service providers, and assesses which critical or important functions the TLPT must cover; that assessment sets the precise scope and is validated by the competent authorities | TLPT sheet, the file: the scope validated by the authority and the plan |
| DORA — Regulation (EU) 2022/2554 | Article 26(3) — where ICT third-party service providers are in the scope of a TLPT, the financial entity takes the necessary measures and safeguards to ensure their participation and “shall retain at all times full responsibility for ensuring compliance with this Regulation”; Article 26(4) allows pooled testing, directed by one designated financial entity, in defined circumstances | TLPT sheet, the file: the terms that bring the ICT third-party service providers in scope into the test |
| DORA — Regulation (EU) 2022/2554 | Article 26(6) and (7) — at the end of the test, once reports and remediation plans are agreed, the entity and any external testers give the TLPT authority a summary of the relevant findings, the remediation plans and the documentation showing the test followed the requirements; the authority then provides an attestation, which allows mutual recognition between authorities | TLPT sheet, the file: the summary report, the remediation plans and the attestation; and the deadlines for them |
| DORA — Regulation (EU) 2022/2554 | Article 26(8) — financial entities contract testers under Article 27; where they use internal testers they contract external testers every three tests; competent authorities identify the entities required to perform TLPT on impact-related factors, possible financial stability concerns and the specific ICT risk profile, level of ICT maturity or technology features involved | Profile and counts sheet: the TLPT identification answer and the entities the Delegated Regulation names; TLPT sheet: the testers contracted |
| DORA — Regulation (EU) 2022/2554 | Article 27(1) — testers for TLPT are of the highest suitability and reputability; have technical and organisational capabilities and specific expertise in threat intelligence, penetration testing and red team testing; are certified by an accreditation body in a Member State or adhere to formal codes of conduct or ethical frameworks; provide independent assurance or an audit report on the sound management of the risks of carrying out TLPT; and are covered by professional indemnity insurance, including against misconduct and negligence | TLPT sheet, the file: the tester selection record against each criterion |
| DORA — Regulation (EU) 2022/2554 | Article 27(2) — internal testers must in addition be approved by the competent authority or the single public authority designated under Article 26(9) and (10), which has verified that the entity has sufficient dedicated resources and has avoided conflicts of interest; the threat intelligence provider is external to the entity | TLPT sheet, the file: the contract terms for the testers, internal or external, and the external threat intelligence provider |
| DORA — Regulation (EU) 2022/2554 | Article 30(3)(d) — contracts for ICT services supporting critical or important functions include “the obligation of the ICT third-party service provider to participate and fully cooperate in the financial entity’s TLPT as referred to in Articles 26 and 27” | TLPT sheet, the file: the provider's duty to take part in the entity's TLPT. The contract term itself is checked in the ICT Third-Party Arrangements Register — Working Copy and the DORA Documentation & Evidence Checklist |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 25(1) — “When testing the ICT business continuity plans in accordance with Article 11(6), of Regulation (EU) 2022/2554, financial entities shall take into account the financial entity’s business impact analysis (BIA) and the ICT risk assessment referred to in Article 3(1), point (b), of this Regulation.” | Programme sheet, DT-14: the test takes the business impact analysis and the ICT risk assessment into account (Delegated Regulation 2024/1774 Article 25) |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 25(2) — the testing assesses whether the entity can ensure the continuity of its critical or important functions, “performed on the basis of test scenarios that simulate potential disruptions, including an adequate set of severe but plausible scenarios”, includes ICT services provided by ICT third-party service providers where applicable, includes switchover scenarios for entities other than microenterprises, and is “designed to challenge the assumptions on which the business continuity plans are based, including governance arrangements and crisis communication plans” | Programme sheet, DT-14: the scenarios, including switchover scenarios for entities that are not microenterprises, and any services of ICT third-party providers |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 25(5) — “Financial entities shall document the results of the testing referred to in paragraph 1. Any identified deficiencies resulting from that testing shall be analysed, addressed, and reported to the management body.” | Test log and Programme sheets: the results are documented, and deficiencies are analysed, addressed and reported to the management body through the gap tracker |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 36 — for the entities of DORA Article 16(1), an ICT security testing plan that validates the effectiveness of the ICT security measures and considers the threats and vulnerabilities identified in the simplified framework; the results are monitored and evaluated, and the measures updated without undue delay for systems supporting critical or important functions | Profile and counts sheet and Systems sheet: for an Article 16 entity, the security testing plan and its results for systems that support critical or important functions |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 40(1) — the entities under the simplified framework test their business continuity plans, including the scenarios referred to in Article 39, “at least once every year for the back-up and restore procedures, or upon every major change of the business continuity plan” | Programme sheet, DT-14: for an Article 16 entity, the yearly test of the business continuity plans for the backup and restore procedures |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 40(3) — the results of the testing are documented, and identified deficiencies “shall be analysed, addressed, and reported to the management body” | Programme sheet: the results of the testing are documented and deficiencies are reported to the management body |
| DORA — Delegated Regulation (EU) 2025/1190 | Article 2 — TLPT authorities assess whether a financial entity must perform TLPT on impact and systemic character (size, interconnectedness, criticality and substitutability of its services, complexity, group) and on ICT risk factors (risk profile, threat landscape, dependence on ICT, complexity of architecture, third-party arrangements, supervisory reviews, maturity of continuity plans and of detection and mitigation); they require TLPT, unless the assessment shows it is not justified, of credit institutions that are G-SIIs, O-SIIs or part of them, payment institutions that exceeded EUR 150 billion of total payment transactions in each of the 2 calendar years before the assessment, electronic money institutions above EUR 150 billion of payment transactions or EUR 40 billion of outstanding electronic money, central securities depositories, central counterparties, trading venues above set market-share criteria, and insurance and reinsurance undertakings above set premium, provisions and asset criteria | Profile and counts sheet: the entities the Delegated Regulation names for TLPT, and the authority's assessment (DORA Art 26(8)) |
| DORA — Delegated Regulation (EU) 2025/1190 | Article 9(1) and (2) — an entity identified to perform TLPT starts after the TLPT authority notifies it; within 3 months of the notification it submits the TLPT initiation information to the test managers: a project charter and plan, the control team lead’s contact details, the intended use of internal or external testers, the communication channels and a code name | TLPT sheet: the date of the authority's notice and the 3-month deadline for the initiation information |
| DORA — Delegated Regulation (EU) 2025/1190 | Article 10(3) and (4) — the control team lead selects at least three scenarios on the threat intelligence provider’s recommendation, the test managers’ input, feasibility and the entity’s size and risk profile; no more than one of them may be non-threat-led | TLPT sheet: the planning check for at least three scenarios, no more than one of them non-threat-led |
| DORA — Delegated Regulation (EU) 2025/1190 | Article 11(5) — the active red team testing phase is proportionate to the scope and scale, and “in any case shall last for at least 12 weeks”; testers report at least weekly to the control team and test managers (Article 11(7)) | TLPT sheet: the planning check for an active red team phase of at least 12 weeks |
| DORA — Delegated Regulation (EU) 2025/1190 | Article 12 — within 4 weeks of the end of the active red team testing phase the testers submit the red team test report; no later than 10 weeks after it the blue team submits its report and the blue team and testers replay the actions and hold a purple teaming exercise; within 8 weeks of the TLPT authority’s notification that the reports are adequate, the entity submits the summary report of findings to the TLPT authority | TLPT sheet: the deadlines for the red team report, the blue team report and replay, and the summary report |
| DORA — Delegated Regulation (EU) 2025/1190 | Article 13 — within 8 weeks of that notification the entity provides the remediation plans and the documentation under DORA Article 26(6); for each finding the plan gives the shortcoming, the measures with priority and expected completion, a root cause analysis, the staff or functions responsible, and the risks of not implementing the measures | TLPT sheet: the deadline for the remediation plans and the documentation |
Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Regulation (EU) 2022/2554 (DORA); Delegated Regulations (EU) 2024/1772, 2024/1773, 2024/1774, 2025/301, 2025/532 and 2025/1190; Implementing Regulations (EU) 2024/2956 and 2025/302; as published in the Official Journal and read on 8 October 2026
ISO/IEC 27001 references name the clause or control this document relates to, by number and title only. They do not say that meeting one meets any DORA requirement.
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard.
This library does not say which ISO/IEC 27001 controls or NIST CSF outcomes meet a DORA requirement. It gives each article's own words, what an entity must be able to show, and the CISO Times documents that help with the work. Where the CISO Times Library holds a mapping between a DORA requirement and a control, it shows it there with how closely the two match and where they differ; confirm it against both texts before relying on it. A document listed here helps with the work a requirement describes. Using it does not by itself show that the requirement is met.
Say which text asks for what. No P21 document says that a CISO Times document, an ISO/IEC 27001 control or a NIST CSF outcome meets or maps to a DORA requirement.