DORA Article-to-Control Mapping Library
Gives each DORA article's own text, what an entity must be able to show and the CISO Times documents that help. It maps nothing to ISO 27001 or NIST CSF (D-51).
Available soon
- Format
- Excel
- Size
- 91 KB
- Length
- 12 sheets
- Version
- 1.4
- Updated
Follow this documentFree account. We can email you when it changes.
What's inside
What changed
- 1.4
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.3
The Supporting Documents sheet no longer repeats each document's pack name in a column of its own, which the document ID already gives.
- 1.2
A financial entity that sells ICT services is also a supplier, and any Priority 1 gap goes to the chair route.
Earlier versions (2)
- 1.1
Lists the P26 documents among the supporting documents.
- 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 contains. The Requirement Library has one row for each of the 52 requirements (RQ-01 to RQ-52), grouped by the pillars of DORA: scope and proportionality; ict risk management; ict-related incident management, classification and reporting; digital operational resilience testing; management of ict third-party risk; information sharing. Each row gives the provision, what it asks of the entity in our words, what you should be able to show a supervisor, who it applies to, and the published CISO Times documents that help. The Applies To sheet shows which requirement applies to which kind of entity. The Supporting Documents sheet lists the documents one per row so you can filter them. The Supplier Flow-Down sheet is for suppliers of ICT services to a financial entity. |
| 2 | What it does not contain. 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. |
| 3 | Why the title names controls. "DORA Article-to-Control Mapping Library" is this workbook's name in the CISO Times catalogue. The two columns headed "your own entry" are where you record the ISO/IEC 27001 controls and NIST CSF outcomes you use for each requirement, if you run either. The workbook leaves them blank. What you write there is your own record and your own judgement: check it against the standards, and with your auditor or counsel where you rely on it. |
| 4 | Start with what you are. Complete the DORA Proportionality & Scope Assessment first, then mark each row in "Applies to us (from your scope assessment)" as Yes, No or Not yet assessed. Read every requirement from your own profile. A requirement that does not apply to you is marked Not applicable with the reason the profile gives. A requirement is never marked Not applicable because it is hard or costly. |
| 5 | For each row that applies, fill "Your policies, procedures and records" with the documents and records that put it in place for you, and name one owner. |
| 6 | Use "What to be able to show" as the test: could you hand a supervisor each of those records today? Where you cannot, record the gap in the DORA Gap & Remediation Tracker, and list the record in the DORA Documentation & Evidence Checklist. The "Readiness item" and "Evidence" codes in the last fixed column point to the matching rows in the DORA Readiness Self-Assessment and the DORA Documentation & Evidence Checklist. |
| 7 | Open a supporting document from its CISO Times page. A CISO Times document is listed against a requirement when its own framework references cite that article or technical standard. Where fewer than three documents do, those that belong to the work the requirement's pillar describes are added (PILLAR_SUPPORT). Only published documents are listed. The list says a document helps. It says nothing about compliance. A document marked (pillar) helps with the work of the whole pillar. It does not cite that provision. |
| 8 | Read the Summary: how many requirements sit in each pillar, how many documents help, and which of your own columns are still empty. It counts what is filled in. It does not judge whether a requirement is in place: the DORA Readiness Self-Assessment does that, with its own counts. |
| 9 | Review the library when your scope assessment changes and at least every 12 months. To clear the EXAMPLE, delete the contents of the 'Row' column and of every yellow column. The requirements 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. |
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 DORA binds. Regulation (EU) 2022/2554 binds the financial entities of its Article 2(1), points (a) to (t), except those Article 2(3) excludes and any that a Member State excludes under Article 2(4). Articles 5 to 15 do not apply to the entities of its Article 16(1), which follow Article 16 and Title III of Delegated Regulation (EU) 2024/1774. Several duties do not apply to microenterprises, and the Regulation says where. It reaches an ICT third-party service provider through the contract with a financial entity and, for a provider designated as critical, through the oversight framework of Chapter V, Section II.
The technical standards. The Delegated and Implementing Regulations bind the same financial entities as the Regulation they supplement, for the articles each applies to. Title II of Delegated Regulation (EU) 2024/1774 is for the entities that follow Articles 5 to 15; its Title III is for the entities of DORA Article 16(1). Delegated Regulation (EU) 2025/1190 binds only the entities that a TLPT authority identifies.
National law and your authority. The competent authority for each financial entity is the one DORA Article 46 names for its type. National law and the authority's own instructions set the dates and channels for the register of information and for reports. None of them is stated here. The competent authority, its channels, the dates and the format for the register and for reports, the language, and anything national law adds, are placeholders filled from your authority's own instructions. None is stated in this pack.
If you are a supplier. DORA lists ICT third-party service providers in Article 2(1), point (u), and defines financial entities as points (a) to (t) only. Its duties for the contract fall on the financial entity. A supplier is reached by DORA mainly through the terms its customers must ask for (the supplier flow-down list) and the information they must collect. A supplier designated as critical is also overseen by a Lead Overseer. Use the Supplier Flow-Down sheet and An organisation that is not a financial entity does not run the readiness assessment. If it supplies ICT services to a financial entity, it uses the flow-down list to check its contracts and the information it must give.
EXAMPLE: Lantern Pay Services (EXAMPLE), a small authorised payment institution in an EU Member State, with 64 staff; under the full framework, not a microenterprise, as at 30 Sep 2026. "Applies to us (from your scope assessment)", "Your policies, procedures and records" and "Owner" show its answers and records. The example leaves the two "your own entry" columns blank, as you receive them. Its figures are invented and identify no real company.
Tailoring — small financial entity: one owner may hold several requirements, and one document may serve several. Keep each row filled, so a supervisor can follow each requirement to its records.
Tailoring — microenterprise or Article 16 entity: the rows that do not apply to you stay in the library with the answer No, so the reason is on file.
Tailoring — IT run by a service provider: where the provider runs a control for you, the requirement is still yours. Name the provider and the contract in your records, and name your own owner.
Requirement Library
The 52 requirements. The wording of "What the text asks" is ours, from the texts read on 8 October 2026. Yellow columns are yours.
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.
| Row | ID | Pillar | Provision | Requirement | Applies to | Duty or option | What the text asks | What to be able to show | If you are a microenterprise | CISO Times documents that help | Where it appears in the other P21 documents | Applies to us (from your scope assessment) | Your policies, procedures and records | Owner | ISO/IEC 27001:2022 controls you use for it (your own entry) | NIST CSF 2.0 outcomes you use for it (your own entry) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | RQ-01 | Scope and proportionality | Article 2(1), (3), (4) | Know whether DORA binds you | Every financial entity in scope | Duty | DORA binds the financial entities of Article 2(1), points (a) to (t), except the entities Article 2(3) excludes and those a Member State excludes under Article 2(4). ICT third-party service providers are listed in point (u) and are not financial entities. | • A written scope assessment that names the entity type, any exclusion and any simplified-framework status, approved by the management body • The size figures behind the microenterprise test, with their source, reviewed at least yearly and whenever they change | — | No published CISO Times document yet. | Readiness item: SC-01 Evidence: EV-01 | Yes | Scope assessment approved by the board on 21 Nov 2024 and reviewed on 4 Mar 2026; confirmed by counsel; no trigger since. | Head of Compliance | ||
| EXAMPLE | RQ-02 | Scope and proportionality | Article 4 | Apply the rules in proportion | Every financial entity in scope | Duty | The Chapter II rules apply in proportion to size, overall risk profile and the nature, scale and complexity of services, activities and operations. Chapters III, IV and V, Section I apply proportionately where they say so. The competent authority considers how the entity applied proportionality when it reviews the framework. | • For each place the entity applies a lighter or a heavier measure, the reason, in the framework document • The size, risk profile and complexity factors the framework used | — | No published CISO Times document yet. | Readiness item: SC-01 Evidence: EV-01 | Yes | Scope assessment approved by the board on 21 Nov 2024 and reviewed on 4 Mar 2026; confirmed by counsel; no trigger since. | Head of Information Security | ||
| EXAMPLE | RQ-03 | Scope and proportionality | Article 16(1)(a) to (d); Delegated Regulation 2024/1774 Articles 29 to 38 | Run the simplified framework | Entities under the simplified framework (Article 16) | Duty | Articles 5 to 15 do not apply to the Article 16 entities. They put in place and keep a sound, documented ICT risk management framework, monitor the security and functioning of all ICT systems, use sound, resilient and updated systems, and detect sources of ICT risk and anomalies promptly and handle incidents swiftly. Title III of the Delegated Regulation sets out the security policy and measures. | • A documented simplified framework with an information security policy and security measures • Evidence that the entity monitors its systems and detects anomalies | — | P22-A02 Business Continuity & ICT Resilience Policy | Readiness item: RM-02 Evidence: EV-04 | No | Not applicable: For entities under the simplified framework: the entity follows Articles 5 to 15. | |||
| EXAMPLE | RQ-04 | ICT risk management | Article 5(1), (2) | The management body owns ICT risk | Entities under the full framework (not the Article 16 entities) | Duty | The management body defines, approves, oversees and is responsible for all arrangements of the ICT risk management framework and bears ultimate responsibility for ICT risk. It sets the policies that protect the availability, authenticity, integrity and confidentiality of data, sets roles and responsibilities, approves the digital operational resilience strategy and the risk tolerance, approves the continuity policy and recovery plans, approves the ICT audit plans, and allocates the budget. | • Minutes that show the management body approving the framework, the strategy and the risk tolerance, and naming what it approved • The budget it allocated for digital operational resilience, and the date it last reviewed it | — | P11-A07 Executive Committee Security Report Deck P11-A08 Key Risk Indicator Threshold & Escalation Model P19-A03 Internal Security Assessment Procedure P19-A07 Maturity Assessment Report Template P19-A09 Maturity Results Executive Summary Deck P20-A09 Annual Control Testing Plan P20-A10 Control Assurance Dashboard P22-A02 Business Continuity & ICT Resilience Policy P22-A09 Resilience Readiness Dashboard | Readiness item: RM-01 Evidence: EV-02 | Yes | 4 of 5 members trained in the last 12 months; the member appointed on 15 Jul 2026 is booked for 8 Oct 2026, inside the 3 months. | The board | ||
| EXAMPLE | RQ-05 | ICT risk management | Article 5(2)(i) | Reporting channels to the management body | Entities under the full framework (not the Article 16 entities) | Duty | The management body puts in place reporting channels that keep it informed of ICT third-party arrangements, planned material changes to providers, the impact of those changes on critical or important functions, and at least major ICT-related incidents and the response, recovery and corrective measures. | • A reporting calendar and the reports the management body received, with its questions and decisions • The incident and third-party items in those reports | — | P03-A03 Board Cybersecurity Report Deck Template (pillar) P04-A02 Policy Framework Standard (pillar) P05-A02 Risk Assessment Methodology & Scoring Model (pillar) P05-A04 Cyber Risk Appetite Statement Template (pillar) P05-A05 Information Security Risk Register (pillar) | Readiness item: RM-01 Evidence: EV-02 | Yes | 4 of 5 members trained in the last 12 months; the member appointed on 15 Jul 2026 is booked for 8 Oct 2026, inside the 3 months. | Head of Compliance | ||
| EXAMPLE | RQ-06 | ICT risk management | Article 5(4) | Members keep their ICT knowledge current | Entities under the full framework (not the Article 16 entities) | Duty | Members of the management body actively keep up to date with enough knowledge and skills to understand and assess ICT risk and its effect on operations, including through specific training on a regular basis that matches the ICT risk managed. | • A training record for every member, with dates and topics • A plan for any member who is new or not yet trained | — | P03-A03 Board Cybersecurity Report Deck Template (pillar) P04-A02 Policy Framework Standard (pillar) P05-A02 Risk Assessment Methodology & Scoring Model (pillar) P05-A04 Cyber Risk Appetite Statement Template (pillar) P05-A05 Information Security Risk Register (pillar) P16-A03 Role-Based Security Training Matrix | Readiness item: RM-01 Evidence: EV-03 | Yes | 4 of 5 members trained in the last 12 months; the member appointed on 15 Jul 2026 is booked for 8 Oct 2026, inside the 3 months. | The board | ||
| EXAMPLE | RQ-07 | ICT risk management | Article 6(1) to (3) | A documented ICT risk management framework | Entities under the full framework (not the Article 16 entities) | Duty | The entity has a sound, comprehensive and well-documented framework within its overall risk management system, with strategies, policies, procedures, ICT protocols and tools that protect all information assets and ICT assets, including the physical premises and infrastructure. It gives complete and updated information on ICT risk and the framework to the authority on request. | • The framework document, approved by the management body • The policies, procedures and tools it names, each with an owner | — | P19-A05 Assessment Evidence Request Checklist P20-A03 Control Inventory & Ownership Register P20-A06 Control Test Workpaper Template P20-A07 Control Evidence Standards Checklist | Readiness item: RM-02 Evidence: EV-04 | Yes | Framework, strategy and risk tolerance approved by the board on 12 Mar 2026, with the review report in the Regulation's format. | Head of Information Security | ||
| EXAMPLE | RQ-08 | ICT risk management | Article 6(4), (6), (7) | Control function, three lines and ICT audit | Entities under the full framework, other than microenterprises | Duty | The entity assigns responsibility for managing and overseeing ICT risk to a control function with enough independence to avoid conflicts of interest, and separates ICT risk management, control and internal audit. The framework is audited regularly by auditors with ICT risk skills and independence, and a formal follow-up process verifies and remedies critical audit findings in time. | • The control function's mandate and reporting line • The ICT audit plan, the audit reports and the follow-up of critical findings | — | P19-A02 Security Maturity Model & Scoring Method P19-A03 Internal Security Assessment Procedure P19-A06 Maturity Findings & Improvement Tracker P19-A07 Maturity Assessment Report Template P20-A02 Control Testing Methodology P20-A05 Control Test Execution Procedure P20-A08 Control Deficiency & Remediation Tracker P20-A09 Annual Control Testing Plan | Readiness item: RM-03 Evidence: EV-07 | Yes | The second-line risk function oversees ICT risk; internal audit reviewed the framework in 2025 and its critical finding was closed. | Risk and Compliance (second line) | ||
| EXAMPLE | RQ-09 | ICT risk management | Article 6(5) | Review the framework every year and report on it | Entities under the full framework (not the Article 16 entities) | Duty | The framework is documented and reviewed at least once a year (periodically for a microenterprise), after a major ICT-related incident, and after supervisory instructions or conclusions from resilience testing or audit. It is improved continuously on lessons learned. A report on the review goes to the authority on request, in a searchable electronic format, with the content Delegated Regulation 2024/1774 Article 27 lists. | • The latest review report, approved by the management body, with its findings and measures • The triggers since the last review (incidents, tests, audits) and how each was handled | A microenterprise reviews the framework periodically, not necessarily every year (Article 6(5)). | P19-A02 Security Maturity Model & Scoring Method P19-A04 Security Programme Maturity Assessment P19-A06 Maturity Findings & Improvement Tracker P19-A07 Maturity Assessment Report Template P19-A08 Target-State Maturity Roadmap P20-A02 Control Testing Methodology P20-A03 Control Inventory & Ownership Register P20-A04 Unified Control Framework Mapping Workbook P20-A10 Control Assurance Dashboard | Readiness item: RM-02 Evidence: EV-05 | Yes | Framework, strategy and risk tolerance approved by the board on 12 Mar 2026, with the review report in the Regulation's format. | Head of Information Security | ||
| EXAMPLE | RQ-10 | ICT risk management | Article 6(8) | A digital operational resilience strategy | Entities under the full framework (not the Article 16 entities) | Duty | The framework includes a strategy that explains how it supports the business strategy, sets the risk tolerance and impact tolerance, sets information security objectives with indicators, describes the ICT reference architecture and the detection and protection mechanisms, evidences the current position, implements resilience testing and outlines the communication strategy for incidents. | • The strategy, approved by the management body • The indicators and metrics it uses, with their latest values | — | P11-A02 Security Metric Definition & Measurement Method P11-A03 Security KPI & KRI Catalogue P11-A04 Metric Definition Card Template P11-A08 Key Risk Indicator Threshold & Escalation Model P19-A08 Target-State Maturity Roadmap | Readiness item: RM-02 Evidence: EV-06 | Yes | Framework, strategy and risk tolerance approved by the board on 12 Mar 2026, with the review report in the Regulation's format. | Head of Information Security | ||
| EXAMPLE | RQ-11 | ICT risk management | Article 7 | Reliable, resilient systems | Entities under the full framework (not the Article 16 entities) | Duty | The entity uses and maintains updated ICT systems, protocols and tools that suit the magnitude of its operations, are reliable, have enough capacity to process data accurately and handle peak volumes, and are technologically resilient under stress. | • Capacity and performance records for the systems that support critical or important functions • Plans to replace or upgrade systems that are unsupported or near their limits | — | P03-A03 Board Cybersecurity Report Deck Template (pillar) P04-A02 Policy Framework Standard (pillar) P05-A02 Risk Assessment Methodology & Scoring Model (pillar) P05-A04 Cyber Risk Appetite Statement Template (pillar) P05-A05 Information Security Risk Register (pillar) | Readiness item: RM-05 Evidence: none | Yes | Information security, access, authentication, change and patch policies operate with records; detection alerts are tested each quarter. | Head of Information Security | ||
| EXAMPLE | RQ-12 | ICT risk management | Article 8(1), (2), (4) to (6) | Know your functions, assets and dependencies | Entities under the full framework (not the Article 16 entities) | Duty | The entity identifies, classifies and documents its ICT-supported business functions, the information assets and ICT assets that support them and their dependencies, and reviews them at least yearly. It identifies sources of ICT risk continuously, maps critical assets and the links between them, identifies processes that depend on ICT third-party providers, and keeps inventories current. | • Inventories of functions, information assets, ICT assets and ICT third-party dependencies, with the critical or important functions marked • The date of the last yearly review of the classification and of the risk scenarios | — | P15-A02 Information Classification & Handling Policy P15-A04 Classification & Labelling Procedure P15-A05 Information Asset Register P15-A06 Information Asset Classification Workbook P15-A09 Information Ownership Responsibility Matrix | Readiness item: RM-04 Evidence: EV-08 | Yes | Inventories are current and reviewed. The legacy back-office reporting server (SYS-06) has no ICT risk assessment in the last 12 months. | Head of Information Security | ||
| EXAMPLE | RQ-13 | ICT risk management | Article 8(3), (7) | Risk assessments on change and on legacy systems | Entities under the full framework, other than microenterprises | Duty | The entity carries out a risk assessment on each major change in its network and information system infrastructure or in the processes that affect its ICT-supported functions, and at least yearly a specific ICT risk assessment on all legacy ICT systems, and before and after connecting technologies, applications or systems. | • Risk assessments for the major changes since the last review • A list of legacy ICT systems with a dated risk assessment for each | — | P03-A03 Board Cybersecurity Report Deck Template (pillar) P04-A02 Policy Framework Standard (pillar) P05-A02 Risk Assessment Methodology & Scoring Model (pillar) P05-A04 Cyber Risk Appetite Statement Template (pillar) P05-A05 Information Security Risk Register (pillar) P17-A07 End-of-Life Software & Unsupported System Register | Readiness item: RM-04 Evidence: EV-09 | Yes | Inventories are current and reviewed. The legacy back-office reporting server (SYS-06) has no ICT risk assessment in the last 12 months. | Head of Information Security | ||
| EXAMPLE | RQ-14 | ICT risk management | Article 9 | Protection and prevention | Entities under the full framework (not the Article 16 entities) | Duty | The entity monitors and controls its ICT systems and deploys security tools, policies and procedures that keep data available, authentic, intact and confidential. It has a documented information security policy, network and infrastructure management that can isolate affected assets, access limited to what is needed, strong authentication and key protection, controlled ICT change management, and documented patch and update policies. | • The information security policy and the policies for access, authentication, cryptography, change and patching • Records that show them operating, such as access reviews, change records and patch status | — | P13-A02 Access Control Policy P13-A03 Joiner-Mover-Leaver Operating Procedure P13-A04 Role-Based Access Profile Matrix P13-A09 Leaver Timeliness & Orphaned Account Report P14-A02 Privileged Access Standard P14-A03 Privileged Access Request, Elevation & Revocation Procedure P14-A04 Privileged & Service Account Inventory P14-A06 Privileged Access Control Review Workbook P14-A07 Privileged Session Review Record P14-A09 Privileged Access Metrics Dashboard P15-A02 Information Classification & Handling Policy P15-A03 Classification Level Handling Rules Matrix P17-A02 Patch Management Standard P17-A03 Monthly Patch Cycle Operating Procedure P17-A04 Patch Deployment Ring & Maintenance Window Plan P17-A05 Emergency Out-of-Band Patching Procedure P17-A06 Patch Deployment Verification Checklist P17-A08 Patch Compliance Dashboard P17-A09 Patch Deferral Request Form | Readiness item: RM-05 Evidence: EV-10 | Yes | Information security, access, authentication, change and patch policies operate with records; detection alerts are tested each quarter. | Head of Information Security | ||
| EXAMPLE | RQ-15 | ICT risk management | Article 10 | Detection | Entities under the full framework (not the Article 16 entities) | Duty | The entity has mechanisms to detect anomalous activity promptly, including network performance issues and incidents, and to identify material single points of failure. They are tested regularly, have layered controls, alert thresholds and automatic alerts, and are backed by enough resources to monitor user activity and incidents. | • A description of the detection mechanisms, alert thresholds and escalation criteria • Test records for them, and the alerts handled in the period | — | P03-A03 Board Cybersecurity Report Deck Template (pillar) P04-A02 Policy Framework Standard (pillar) P05-A02 Risk Assessment Methodology & Scoring Model (pillar) P05-A04 Cyber Risk Appetite Statement Template (pillar) P05-A05 Information Security Risk Register (pillar) | Readiness item: RM-05 Evidence: EV-11 | Yes | Information security, access, authentication, change and patch policies operate with records; detection alerts are tested each quarter. | Head of Information Security | ||
| EXAMPLE | RQ-16 | ICT risk management | Article 11(1) to (5), (8) | Continuity policy, response and recovery plans | Entities under the full framework (not the Article 16 entities) | Duty | The entity has an ICT business continuity policy, implemented through documented arrangements that keep critical or important functions running, respond to and resolve incidents, activate containment, estimate impacts and manage communication. It has response and recovery plans, which for entities other than microenterprises are subject to independent internal audit review, a business impact analysis, and readily accessible records of what happened before and during a disruption. | • The continuity policy, the plans and the business impact analysis, approved by the management body • Records of plan activations and the audit review of the plans | The independent internal audit review of the response and recovery plans (Article 11(3)) does not apply to a microenterprise. | P22-A02 Business Continuity & ICT Resilience Policy P22-A03 Cyber Recovery Operating Procedure P22-A04 Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) P22-A05 Cyber Recovery Plan Template P22-A07 Resilience Dependency Register P23-A02 Restore Testing Methodology | Readiness item: RM-06 Evidence: EV-12 | Yes | Continuity policy, plans and business impact analysis approved; the plan test for all functions was last run on 26 Aug 2025 and fell due on 26 Aug 2026. The crisis communication plan was tested on 24 Feb 2026. | Head of Information Security | ||
| EXAMPLE | RQ-17 | ICT risk management | Article 11(6) | Test the plans at least yearly | Entities under the full framework (not the Article 16 entities) | Duty | The entity tests the continuity plans and the response and recovery plans for the ICT systems that support all functions at least yearly, and after substantive changes to the systems that support critical or important functions, and tests its crisis communication plans. Entities other than microenterprises include scenarios of cyber-attacks and switchovers to redundant capacity, backups and facilities. Results are documented, and deficiencies are analysed, addressed and reported to the management body. | • Test plans, results and findings for the last 12 months • The management body's receipt of the deficiencies, and their tracking to closure | The cyber-attack and switchover scenarios (Article 11(6), second subparagraph) are for entities other than microenterprises. | P10-A02 Tabletop Exercise Design Methodology P10-A03 Exercise Planning & Facilitation Procedure P10-A04 Tabletop Scenario — Ransomware Encryption of Core Systems P10-A05 Tabletop Scenario — Critical Supplier Outage P10-A08 Tabletop Scenario — Executive Payment Fraud P10-A10 Exercise Logistics & Participant Readiness Checklist P10-A11 Exercise Observations & Improvement Tracker P10-A12 Exercise After-Action Report Template P22-A02 Business Continuity & ICT Resilience Policy P22-A05 Cyber Recovery Plan Template P22-A09 Resilience Readiness Dashboard P23-A02 Restore Testing Methodology | Readiness item: RM-06 Evidence: EV-14 | Yes | Continuity policy, plans and business impact analysis approved; the plan test for all functions was last run on 26 Aug 2025 and fell due on 26 Aug 2026. The crisis communication plan was tested on 24 Feb 2026. | Head of Information Security | ||
| EXAMPLE | RQ-18 | ICT risk management | Article 11(7) | A crisis management function | Entities under the full framework, other than microenterprises | Duty | The entity has a crisis management function that, when the continuity or recovery plans are activated, sets out clear procedures for internal and external crisis communication. | • The function's mandate, members and procedures • Evidence that it was exercised or used | — | P03-A03 Board Cybersecurity Report Deck Template (pillar) P04-A02 Policy Framework Standard (pillar) P05-A02 Risk Assessment Methodology & Scoring Model (pillar) P05-A04 Cyber Risk Appetite Statement Template (pillar) P05-A05 Information Security Risk Register (pillar) P22-A08 Crisis & Recovery Responsibility Matrix | Readiness item: RM-06 Evidence: none | Yes | Continuity policy, plans and business impact analysis approved; the plan test for all functions was last run on 26 Aug 2025 and fell due on 26 Aug 2026. The crisis communication plan was tested on 24 Feb 2026. | Head of Information Security | ||
| EXAMPLE | RQ-19 | ICT risk management | Article 12 | Backup, restoration and recovery | Entities under the full framework (not the Article 16 entities) | Duty | The entity has backup policies and procedures that set the scope of data and how often it is backed up, and restoration and recovery procedures and methods. Backup systems can be activated without jeopardising security. Restoration on its own systems uses systems physically and logically segregated from the source. Recovery time and recovery point objectives are set for each function, and recovery includes the checks that keep data integrity highest. Entities other than microenterprises keep redundant ICT capacity. | • The backup policy and the restoration procedures • Restore test records, and the recovery objectives for each critical or important function (P22, P23) | A microenterprise assesses the need for redundant ICT capacity on its risk profile (Article 12(4)). | P22-A02 Business Continuity & ICT Resilience Policy P22-A03 Cyber Recovery Operating Procedure P22-A04 Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) P22-A05 Cyber Recovery Plan Template P22-A06 Clean-Room Recovery & Rebuild Checklist P23-A02 Restore Testing Methodology P23-A03 Backup Operations & Restore Test Procedure P23-A04 Backup Coverage & Retention Matrix P23-A05 Restore Test Workbook P23-A06 Immutable & Offline Backup Protection Checklist P23-A07 Backup Failure & Restore Findings Tracker P23-A08 Restore Test Evidence Report Template P23-A09 Backup Assurance Dashboard | Readiness item: RM-06 Evidence: EV-13 | Yes | Continuity policy, plans and business impact analysis approved; the plan test for all functions was last run on 26 Aug 2025 and fell due on 26 Aug 2026. The crisis communication plan was tested on 24 Feb 2026. | Head of Information Security | ||
| EXAMPLE | RQ-20 | ICT risk management | Article 13(1) to (3), (5) | Learn from incidents and tests | Entities under the full framework (not the Article 16 entities) | Duty | The entity gathers information on vulnerabilities and cyber threats, reviews major incidents after they disrupt core activities, and builds the lessons from resilience tests, real incidents and supervisory reviews into its ICT risk assessment. Senior ICT staff report at least yearly to the management body on the findings, with recommendations. | • Post-incident review records and the changes they led to • The yearly report of senior ICT staff to the management body | A microenterprise need not tell the authority, on request, which changes followed a post-incident review (Article 13(2)). | P03-A03 Board Cybersecurity Report Deck Template (pillar) P04-A02 Policy Framework Standard (pillar) P05-A02 Risk Assessment Methodology & Scoring Model (pillar) P05-A04 Cyber Risk Appetite Statement Template (pillar) P05-A05 Information Security Risk Register (pillar) P11-A07 Executive Committee Security Report Deck P11-A08 Key Risk Indicator Threshold & Escalation Model | Readiness item: RM-07 Evidence: EV-15 | Yes | Post-incident reviews feed the risk register; all staff completed the compulsory module; a named person speaks for the entity in a crisis. | Head of Information Security | ||
| EXAMPLE | RQ-21 | ICT risk management | Article 13(6) | Awareness and resilience training for all staff | Entities under the full framework (not the Article 16 entities) | Duty | The entity makes ICT security awareness programmes and digital operational resilience training compulsory modules in staff training, for all employees and senior management, at a level that suits their role. It includes ICT third-party service providers where appropriate. | • The programme, the attendance record and the list of people not yet trained • The content of the training for staff and for senior management | — | P16-A02 Annual Security Awareness Plan P16-A03 Role-Based Security Training Matrix P16-A06 New Joiner Security Induction Deck P16-A07 Training Completion & Evidence Register P16-A09 Human Risk Metrics Dashboard | Readiness item: RM-07 Evidence: EV-16 | Yes | Post-incident reviews feed the risk register; all staff completed the compulsory module; a named person speaks for the entity in a crisis. | Head of Information Security | ||
| EXAMPLE | RQ-22 | ICT risk management | Article 14 | Crisis communication | Entities under the full framework (not the Article 16 entities) | Duty | The entity has crisis communication plans that allow responsible disclosure of at least major ICT-related incidents or vulnerabilities to clients, counterparts and the public, communication policies for staff and external stakeholders, and at least one person tasked with the public and media function. | • The crisis communication plan and the name of the person tasked • Evidence that the plan was tested (Article 11(6)(b)) | — | P03-A03 Board Cybersecurity Report Deck Template (pillar) P04-A02 Policy Framework Standard (pillar) P05-A02 Risk Assessment Methodology & Scoring Model (pillar) P05-A04 Cyber Risk Appetite Statement Template (pillar) P05-A05 Information Security Risk Register (pillar) P22-A08 Crisis & Recovery Responsibility Matrix | Readiness item: RM-07 Evidence: EV-17 | Yes | Post-incident reviews feed the risk register; all staff completed the compulsory module; a named person speaks for the entity in a crisis. | Head of Information Security | ||
| EXAMPLE | RQ-23 | ICT risk management | Article 16(1)(e); Delegated Regulation 2024/1774 Article 30 | Key dependencies and critical functions | Entities under the simplified framework (Article 16) | Duty | The entity identifies, classifies and documents its critical or important functions, the information assets and ICT assets that support them and their interdependencies, identifies the critical or important functions that ICT third-party service providers support, and identifies its key dependencies on those providers. | • An inventory of critical or important functions and the assets and providers behind each • The date it was last reviewed | — | P03-A03 Board Cybersecurity Report Deck Template (pillar) P04-A02 Policy Framework Standard (pillar) P05-A02 Risk Assessment Methodology & Scoring Model (pillar) P05-A04 Cyber Risk Appetite Statement Template (pillar) P05-A05 Information Security Risk Register (pillar) P22-A07 Resilience Dependency Register | Readiness item: RM-04 Evidence: EV-08 | No | Not applicable: For entities under the simplified framework: the entity follows Articles 5 to 15. | |||
| EXAMPLE | RQ-24 | ICT risk management | Article 16(1)(f), (g); Delegated Regulation 2024/1774 Articles 39 and 40 | Continuity, backup and restoration, and their tests | Entities under the simplified framework (Article 16) | Duty | The entity ensures the continuity of critical or important functions through business continuity plans and response and recovery measures that include at least backup and restoration measures. It tests those plans and measures, and the effectiveness of its controls, regularly: its business continuity plans at least once every year for the backup and restore procedures, or on every major change to the plan. Results are documented and deficiencies are analysed, addressed and reported to the management body. | • The business continuity plan, approved by the management body, with the backup and restore procedures • Yearly test records and the report of deficiencies to the management body | — | P19-A03 Internal Security Assessment Procedure P20-A02 Control Testing Methodology P20-A04 Unified Control Framework Mapping Workbook P20-A05 Control Test Execution Procedure P20-A06 Control Test Workpaper Template P22-A02 Business Continuity & ICT Resilience Policy P22-A05 Cyber Recovery Plan Template P22-A09 Resilience Readiness Dashboard P23-A02 Restore Testing Methodology P23-A05 Restore Test Workbook P23-A07 Backup Failure & Restore Findings Tracker P23-A08 Restore Test Evidence Report Template P23-A09 Backup Assurance Dashboard | Readiness item: RM-06 Evidence: EV-12, EV-14 | No | Not applicable: For entities under the simplified framework: the entity follows Articles 5 to 15. | |||
| EXAMPLE | RQ-25 | ICT risk management | Article 16(1)(h), 16(2); Delegated Regulation 2024/1774 Article 41 | Lessons, training and the review report | Entities under the simplified framework (Article 16) | Duty | The entity feeds the conclusions of its tests and post-incident analysis into its ICT risk assessment, and develops awareness and resilience training for staff and management as its needs and risk profile require. The framework is documented, reviewed periodically and after major incidents, and improved continuously. A report on the review goes to the authority on request, in a searchable electronic format, with the content Article 41 lists. | • The review report with its findings, self-assessed severity and remedying measures • Training records | — | P19-A03 Internal Security Assessment Procedure P19-A07 Maturity Assessment Report Template P20-A02 Control Testing Methodology P20-A04 Unified Control Framework Mapping Workbook P20-A05 Control Test Execution Procedure P20-A06 Control Test Workpaper Template | Readiness item: RM-02 Evidence: EV-05 | No | Not applicable: For entities under the simplified framework: the entity follows Articles 5 to 15. | |||
| EXAMPLE | RQ-26 | ICT risk management | Delegated Regulation 2024/1774 Article 28 | Governance under the simplified framework | Entities under the simplified framework (Article 16) | Duty | The management body bears overall responsibility for the simplified framework, sets roles and responsibilities for ICT tasks and information security objectives, approves, oversees and periodically reviews the classification of information assets, the main risks, the business impact analysis and the continuity plans, allocates the budget yearly and sets its own reporting arrangements. Control and internal audit functions are kept separate and independent, and the framework is internally audited. | • Minutes that show the management body approving the items listed • The budget and the internal audit of the framework | — | P03-A03 Board Cybersecurity Report Deck Template (pillar) P04-A02 Policy Framework Standard (pillar) P05-A02 Risk Assessment Methodology & Scoring Model (pillar) P05-A04 Cyber Risk Appetite Statement Template (pillar) P05-A05 Information Security Risk Register (pillar) P22-A02 Business Continuity & ICT Resilience Policy | Readiness item: RM-01 Evidence: EV-02 | No | Not applicable: For entities under the simplified framework: the entity follows Articles 5 to 15. | |||
| EXAMPLE | RQ-27 | ICT-related incident management, classification and reporting | Article 17 | An incident management process | Every financial entity in scope | Duty | The entity defines, establishes and implements a process to detect, manage and notify ICT-related incidents, records all of them and significant cyber threats, and makes sure root causes are identified, documented and addressed. The process has early warning indicators, procedures to log, categorise and classify incidents, roles for each incident type, communication plans, and escalation of major incidents to senior management and the management body. | • The incident management procedure and a log of every incident and significant cyber threat • Root-cause records and the reports of major incidents to the management body (P09) | — | P09-A02 Security Incident Management Policy (pillar) P09-A03 Incident Response Plan (pillar) P09-A04 Incident Classification, Severity & Escalation Matrix (pillar) P09-A09 Incident Case & Action Log (pillar) P09-A11 Post-Incident Review Template (pillar) P18-A07 Regulatory Notification Log | Readiness item: IM-01 Evidence: EV-18 | Yes | Every incident is logged and classified against the criteria; the Q3 log has no major incident. | Information Security Manager | ||
| EXAMPLE | RQ-28 | ICT-related incident management, classification and reporting | Article 18; Delegated Regulation 2024/1772 | Classify incidents by the criteria | Every financial entity in scope | Duty | The entity classifies ICT-related incidents by clients and transactions affected, reputational impact, duration and downtime, geographical spread, data losses, criticality of services affected and economic impact, using the thresholds of Delegated Regulation 2024/1772, which decide whether an incident is major. | • A classification record for each incident, showing the criteria met and the result • A monthly check for recurring incidents, except where the entity does not have to do it (P18) | — | P09-A02 Security Incident Management Policy (pillar) P09-A03 Incident Response Plan (pillar) P09-A04 Incident Classification, Severity & Escalation Matrix (pillar) P09-A09 Incident Case & Action Log (pillar) P09-A11 Post-Incident Review Template (pillar) P18-A03 Reportability Decision Model | Readiness item: IM-01 Evidence: EV-19 | Yes | Every incident is logged and classified against the criteria; the Q3 log has no major incident. | Information Security Manager | ||
| EXAMPLE | RQ-29 | ICT-related incident management, classification and reporting | Article 19(1), (3), (4) | Report major incidents on time | Every financial entity in scope | Duty | The entity reports major ICT-related incidents to the competent authority with an initial notification, an intermediate report and a final report, on the templates and by the time limits of Delegated Regulation 2025/301 and Implementing Regulation 2025/302, and informs clients without undue delay where the incident affects their financial interests. The entity stays responsible if it outsources the reporting. | • Reporting channels, signatories and templates ready, and a log of every report with its time (P18) • A tested route for the client notice | — | P18-A02 EU Incident Notification Timeline Matrix (NIS2, DORA, GDPR) P18-A04 Regulatory Notification Operating Procedure P18-A07 Regulatory Notification Log P18-A08 Notification Readiness Checklist | Readiness item: IM-02 Evidence: EV-20 | Yes | Authority, channel, templates and signatories are ready (P18). The signatories' access to the authority's channel was last tested on 2025-08-12, more than 12 months ago. | Information Security Manager | ||
| EXAMPLE | RQ-30 | ICT-related incident management, classification and reporting | Article 19(2) | Significant cyber threats (optional) | Every financial entity in scope | Option | The entity may notify the competent authority voluntarily of a significant cyber threat that it considers relevant to the financial system, service users or clients. Where applicable it tells clients who may be affected of protection measures. | • A decision rule for when to notify a threat, and a record of each decision | — | P09-A02 Security Incident Management Policy (pillar) P09-A03 Incident Response Plan (pillar) P09-A04 Incident Classification, Severity & Escalation Matrix (pillar) P09-A09 Incident Case & Action Log (pillar) P09-A11 Post-Incident Review Template (pillar) P18-A02 EU Incident Notification Timeline Matrix (NIS2, DORA, GDPR) P18-A03 Reportability Decision Model | Readiness item: IS-01 Evidence: EV-34 | Yes | The board decided on 10 Jun 2026 not to join an information-sharing community yet; the decision is recorded. Significant cyber threats are notified only on the incident manager's judgement (Article 19(2) is optional). | Information Security Manager | ||
| EXAMPLE | RQ-31 | ICT-related incident management, classification and reporting | Article 23 | Payment-related incidents | Every financial entity in scope; these types only | Duty | The incident reporting requirements also apply to operational or security payment-related incidents, and major ones, that concern credit institutions, payment institutions, account information service providers and electronic money institutions. | • Evidence that the classification and reporting process covers payment-related incidents as well as ICT-related ones | — | P09-A02 Security Incident Management Policy (pillar) P09-A03 Incident Response Plan (pillar) P09-A04 Incident Classification, Severity & Escalation Matrix (pillar) P09-A09 Incident Case & Action Log (pillar) P09-A11 Post-Incident Review Template (pillar) | Readiness item: IM-02 Evidence: EV-20 | Yes | Authority, channel, templates and signatories are ready (P18). The signatories' access to the authority's channel was last tested on 2025-08-12, more than 12 months ago. | Information Security Manager | ||
| EXAMPLE | RQ-32 | Digital operational resilience testing | Article 24(1) to (5) | A resilience testing programme | Every financial entity in scope other than microenterprises | Duty | The entity establishes, maintains and reviews a sound and comprehensive digital operational resilience testing programme as part of its framework. It follows a risk-based approach, has the tests done by independent parties, and sets procedures and policies to prioritise, classify and remedy every issue the tests reveal and to confirm that each weakness is fully addressed. | • The approved programme with its scope, schedule and tester independence • A register of test findings with priority, owner and due date, and the validation that each is closed | — | P10-A02 Tabletop Exercise Design Methodology P10-A11 Exercise Observations & Improvement Tracker P10-A12 Exercise After-Action Report Template | Readiness item: RT-01 Evidence: EV-21, EV-22 | Yes | The programme was approved on 2026-01-28, uses independent testers and has a finding register with validated closure. | Security Assurance Lead | ||
| EXAMPLE | RQ-33 | Digital operational resilience testing | Article 24(6) | Test the systems behind critical functions every year | Every financial entity in scope other than microenterprises | Duty | The entity ensures that appropriate tests are conducted at least yearly on all ICT systems and applications that support critical or important functions. | • A list of those systems and applications, each with its latest test, date, tester and result • No system on the list whose latest test is older than 12 months | — | P01-A02 Vulnerability & Exposure Management Standard (pillar) P01-A03 Vulnerability Triage & Remediation Operating Procedure (pillar) P10-A02 Tabletop Exercise Design Methodology (pillar) P20-A09 Annual Control Testing Plan (pillar) | Readiness item: RT-02 Evidence: EV-23 | Yes | 4 of 5 systems behind the critical function have a counting test in the last 12 months; SYS-02 fell due on 29 Aug 2026. | Security Assurance Lead | ||
| EXAMPLE | RQ-34 | Digital operational resilience testing | Article 25(1) | A range of tests | Every financial entity in scope | Duty | The programme provides for appropriate tests, such as vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing. | • The test types in the programme and the reason each was chosen or left out | — | P01-A02 Vulnerability & Exposure Management Standard (pillar) P01-A03 Vulnerability Triage & Remediation Operating Procedure (pillar) P10-A02 Tabletop Exercise Design Methodology P20-A09 Annual Control Testing Plan (pillar) | Readiness item: RT-01 Evidence: EV-21 | Yes | The programme was approved on 2026-01-28, uses independent testers and has a finding register with validated closure. | Security Assurance Lead | ||
| EXAMPLE | RQ-35 | Digital operational resilience testing | Article 25(3) | Microenterprises: risk-based testing | Microenterprises | Duty | A microenterprise performs the Article 25(1) tests by combining a risk-based approach with a strategic plan for testing, balancing the resources and time it spends against the urgency, type of risk, criticality of its assets and services, and its ability to take calculated risks. | • A short testing plan with the reasoning for what is tested and what is not | — | P01-A02 Vulnerability & Exposure Management Standard (pillar) P01-A03 Vulnerability Triage & Remediation Operating Procedure (pillar) P10-A02 Tabletop Exercise Design Methodology (pillar) P20-A09 Annual Control Testing Plan (pillar) | Readiness item: RT-01 Evidence: EV-21 | No | Not applicable: For microenterprises only. | |||
| EXAMPLE | RQ-36 | Digital operational resilience testing | Article 25(2) | Vulnerability assessments before deployment | Every financial entity in scope; these types only | Duty | Central securities depositories and central counterparties perform vulnerability assessments before any deployment or redeployment of applications and infrastructure components, and of ICT services that support critical or important functions. | • A vulnerability assessment record for each deployment | — | P01-A02 Vulnerability & Exposure Management Standard (pillar) P01-A03 Vulnerability Triage & Remediation Operating Procedure (pillar) P10-A02 Tabletop Exercise Design Methodology (pillar) P20-A09 Annual Control Testing Plan (pillar) | Readiness item: RT-01 Evidence: EV-21 | No | Not applicable: For central securities depository, central counterparty only. | |||
| EXAMPLE | RQ-37 | Digital operational resilience testing | Article 26(1) to (3), (8) | Threat-led penetration testing (if identified) | Entities that a TLPT authority has identified | Duty | 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. | • The authority's identification letter and the validated scope • The TLPT plan, the test managers' approvals and the provider participation terms | — | P01-A02 Vulnerability & Exposure Management Standard (pillar) P01-A03 Vulnerability Triage & Remediation Operating Procedure (pillar) P10-A02 Tabletop Exercise Design Methodology (pillar) P20-A09 Annual Control Testing Plan (pillar) | Readiness item: RT-03 Evidence: EV-24 | No | Not applicable: A TLPT authority has not identified the entity. | |||
| EXAMPLE | RQ-38 | Digital operational resilience testing | Article 26(6), (7); Delegated Regulation 2025/1190 Articles 12 and 13 | TLPT closure, remediation and attestation | Entities that a TLPT authority has identified | Duty | When the test ends and the reports and remediation plans are agreed, the entity gives the TLPT authority a summary of findings, the remediation plans and documentation showing the test followed the rules, and receives an attestation. The remediation plan gives, for each finding, the shortcoming, the measures, a root cause analysis, who is responsible and the risks of not acting. | • The summary report, the remediation plans and the attestation • Tracking of each finding to closure | — | P01-A02 Vulnerability & Exposure Management Standard (pillar) P01-A03 Vulnerability Triage & Remediation Operating Procedure (pillar) P10-A02 Tabletop Exercise Design Methodology (pillar) P20-A09 Annual Control Testing Plan (pillar) | Readiness item: RT-03 Evidence: EV-24 | No | Not applicable: A TLPT authority has not identified the entity. | |||
| EXAMPLE | RQ-39 | Digital operational resilience testing | Article 27 | Testers for TLPT | Entities that a TLPT authority has identified | Duty | Testers are of the highest suitability and reputability, have specific expertise in threat intelligence, penetration testing and red team testing, are certified or adhere to a code of conduct, give independent assurance on their management of the risks of TLPT, and carry professional indemnity insurance. Internal testers need the authority's approval and the threat intelligence provider is external. Contracts require sound management of the results. | • The tester selection record against each criterion • The contract terms for handling the results | — | P01-A02 Vulnerability & Exposure Management Standard (pillar) P01-A03 Vulnerability Triage & Remediation Operating Procedure (pillar) P10-A02 Tabletop Exercise Design Methodology (pillar) P20-A09 Annual Control Testing Plan (pillar) | Readiness item: RT-03 Evidence: EV-24 | No | Not applicable: A TLPT authority has not identified the entity. | |||
| EXAMPLE | RQ-40 | Digital operational resilience testing | Article 16(1)(g); Delegated Regulation 2024/1774 Article 36 | ICT security testing under the simplified framework | Entities under the simplified framework (Article 16) | Duty | The entity establishes and implements an ICT security testing plan that validates the effectiveness of its security measures and considers the threats and vulnerabilities it has identified. It monitors and evaluates the results and updates its measures without undue delay for systems that support critical or important functions. | • The security testing plan and the results • The measures changed as a result | — | P19-A03 Internal Security Assessment Procedure P20-A02 Control Testing Methodology P20-A04 Unified Control Framework Mapping Workbook P20-A05 Control Test Execution Procedure P20-A06 Control Test Workpaper Template | Readiness item: RT-01 Evidence: EV-21 | No | Not applicable: For entities under the simplified framework: the entity follows Articles 5 to 15. | |||
| EXAMPLE | RQ-41 | Management of ICT third-party risk | Article 28(1) | You stay responsible | Every financial entity in scope | Duty | The entity manages ICT third-party risk as an integral part of ICT risk, in proportion to the nature, scale, complexity and importance of its ICT dependencies. It remains fully responsible for compliance with the Regulation and financial services law at all times, whatever it contracts out. | • The framework's treatment of ICT third-party risk • The risk assessment of each arrangement | — | P06-A02 Third-Party Security Policy (pillar) P06-A03 Supplier Security Assessment Procedure (pillar) P06-A04 Supplier Criticality & Tiering Model (pillar) P06-A07 Supplier Contract Security Clause Library (pillar) P06-A08 Supplier Security Risk Register (pillar) P26-A02 Questionnaire Response Governance Method | Readiness item: TP-02 Evidence: none | Yes | Strategy and policy approved by the board on 10 Jun 2026; the Head of Procurement is the designated manager. | Head of Procurement | ||
| EXAMPLE | RQ-42 | Management of ICT third-party risk | Article 28(3); Implementing Regulation 2024/2956 | The register of information | Every financial entity in scope | Duty | The entity maintains and updates a register of information on all contractual arrangements for ICT services, at entity level and, for groups, at sub-consolidated and consolidated level, in the templates of Implementing Regulation 2024/2956, distinguishing arrangements that support critical or important functions. It ranks every provider in the supply chain and identifies each legal person by a valid LEI or EUID. | • The register in the official templates, with no open validation finding • The function list, the supply chain and the assessments for critical or important arrangements | — | P06-A02 Third-Party Security Policy (pillar) P06-A03 Supplier Security Assessment Procedure (pillar) P06-A04 Supplier Criticality & Tiering Model (pillar) P06-A07 Supplier Contract Security Clause Library (pillar) P06-A08 Supplier Security Risk Register (pillar) | Readiness item: TP-01 Evidence: EV-25 | Yes | 7 arrangements in the register, submitted on 27 Mar 2026; 1 open data finding (RV-03: the code of Hosting Subcontractor G). | Head of Procurement | ||
| EXAMPLE | RQ-43 | Management of ICT third-party risk | Article 28(3), third to fifth subparagraphs | Report on the register and tell the authority first | Every financial entity in scope | Duty | The entity reports at least yearly to the competent authority on new arrangements, categories of providers, types of arrangement and the services and functions provided, makes the full register available on request, and tells the authority in good time about any planned arrangement for a critical or important function and when a function becomes critical or important. | • The yearly submission and its acknowledgement, in the form and by the date the authority sets • A record of each planned critical or important arrangement and when the authority was told | — | P06-A02 Third-Party Security Policy (pillar) P06-A03 Supplier Security Assessment Procedure (pillar) P06-A04 Supplier Criticality & Tiering Model (pillar) P06-A07 Supplier Contract Security Clause Library (pillar) P06-A08 Supplier Security Risk Register (pillar) | Readiness item: TP-01 Evidence: EV-25, EV-33 | Yes | 7 arrangements in the register, submitted on 27 Mar 2026; 1 open data finding (RV-03: the code of Hosting Subcontractor G). | Head of Procurement | ||
| EXAMPLE | RQ-44 | Management of ICT third-party risk | Article 28(2); Delegated Regulation 2024/1773 | A third-party risk strategy and a policy | Entities under the full framework, other than microenterprises | Duty | The entity adopts and regularly reviews a strategy on ICT third-party risk that includes a policy on ICT services supporting critical or important functions. The management body approves the policy, reviews it at least yearly and regularly reviews the risks of those arrangements. The policy covers the life cycle of an arrangement from planning and due diligence to monitoring and exit. | • The strategy and the policy, with the management body's approval in the last 12 months • The management body's review of the risks of critical or important arrangements | The strategy and the policy are for entities other than microenterprises and other than the Article 16 entities (Article 28(2)). | P06-A02 Third-Party Security Policy (pillar) P06-A03 Supplier Security Assessment Procedure (pillar) P06-A04 Supplier Criticality & Tiering Model (pillar) P06-A07 Supplier Contract Security Clause Library (pillar) P06-A08 Supplier Security Risk Register (pillar) | Readiness item: TP-02 Evidence: EV-26 | Yes | Strategy and policy approved by the board on 10 Jun 2026; the Head of Procurement is the designated manager. | The board | ||
| EXAMPLE | RQ-45 | Management of ICT third-party risk | Article 5(3) | A role to monitor the arrangements | Entities under the full framework, other than microenterprises | Duty | The entity establishes a role to monitor its arrangements with ICT third-party service providers, or designates a member of senior management to oversee the related risk exposure and documentation. | • The role or the named manager, with the reporting line to the management body | — | P06-A02 Third-Party Security Policy (pillar) P06-A03 Supplier Security Assessment Procedure (pillar) P06-A04 Supplier Criticality & Tiering Model (pillar) P06-A07 Supplier Contract Security Clause Library (pillar) P06-A08 Supplier Security Risk Register (pillar) | Readiness item: TP-02 Evidence: EV-27 | Yes | Strategy and policy approved by the board on 10 Jun 2026; the Head of Procurement is the designated manager. | The board | ||
| EXAMPLE | RQ-46 | Management of ICT third-party risk | Article 28(4) to (6); Article 29(1) | Assess before you contract, then audit | Every financial entity in scope | Duty | Before contracting, the entity assesses whether the arrangement covers a critical or important function, whether the supervisory conditions are met, all relevant risks including concentration risk, the provider's suitability by due diligence, and conflicts of interest. It contracts only with providers that follow appropriate information security standards. It sets the frequency and areas of its audits on a risk basis. It checks whether a provider is easily substitutable and whether it has several arrangements with the same or closely connected providers. | • A pre-contract assessment for each critical or important arrangement • An audit and assurance plan for each, with its latest result | — | P06-A02 Third-Party Security Policy (pillar) P06-A03 Supplier Security Assessment Procedure (pillar) P06-A04 Supplier Criticality & Tiering Model (pillar) P06-A07 Supplier Contract Security Clause Library (pillar) P06-A08 Supplier Security Risk Register (pillar) P26-A09 Standard Security Commitments Schedule | Readiness item: TP-03 Evidence: EV-28 | Yes | The pre-contract assessment and concentration check for CA-001 are on file; the provider was checked against the ESAs' list on 2026-09-21. | Head of Procurement | ||
| EXAMPLE | RQ-47 | Management of ICT third-party risk | Article 30(1), (2) | Contract terms for every arrangement | Every financial entity in scope | Duty | The rights and obligations are set out in writing, in one document that includes the service levels. The contract describes the services and whether subcontracting is allowed, the locations of services and data and advance notice of change, data protection, access to and return of data on insolvency or termination, service levels, assistance in incidents, cooperation with authorities, termination rights and notice periods, and participation in the entity's awareness and resilience training. | • The contract for each arrangement, checked against the list of terms | — | P06-A02 Third-Party Security Policy (pillar) P06-A03 Supplier Security Assessment Procedure (pillar) P06-A04 Supplier Criticality & Tiering Model (pillar) P06-A07 Supplier Contract Security Clause Library (pillar) P06-A08 Supplier Security Risk Register (pillar) P26-A02 Questionnaire Response Governance Method P26-A06 Response Quality & Over-Commitment Checklist P26-A09 Standard Security Commitments Schedule | Readiness item: TP-04 Evidence: EV-30 | Yes | CA-001, signed in 2022, lacks the unrestricted audit and access wording and the TLPT participation term of Article 30(3). An amendment was drafted on 2026-09-12 and is not signed. | General Counsel | ||
| EXAMPLE | RQ-48 | Management of ICT third-party risk | Article 30(3) | More terms for critical or important functions | Every financial entity in scope | Duty | Contracts for services that support critical or important functions also include full service levels with precise targets, notice and reporting duties on developments that could affect the service, the provider's duty to implement and test contingency plans, to take part in the entity's TLPT and to allow unrestricted access, inspection and audit by the entity and the authorities, and exit strategies with a mandatory transition period. | • The contract for each such arrangement, checked against the list of additional terms • The amendment record where an older contract lacked a term | A microenterprise and the provider may agree that audit and inspection rights are delegated to an independent third party the provider appoints (Article 30(3), last subparagraph). | P06-A02 Third-Party Security Policy (pillar) P06-A03 Supplier Security Assessment Procedure (pillar) P06-A04 Supplier Criticality & Tiering Model (pillar) P06-A07 Supplier Contract Security Clause Library (pillar) P06-A08 Supplier Security Risk Register (pillar) P10-A05 Tabletop Scenario — Critical Supplier Outage P26-A05 Evidence & Attestation Library Index P26-A09 Standard Security Commitments Schedule | Readiness item: TP-04 Evidence: EV-30 | Yes | CA-001, signed in 2022, lacks the unrestricted audit and access wording and the TLPT participation term of Article 30(3). An amendment was drafted on 2026-09-12 and is not signed. | General Counsel | ||
| EXAMPLE | RQ-49 | Management of ICT third-party risk | Article 28(7), (8) | Exit plans and the right to end the contract | Every financial entity in scope | Duty | The entity ensures it can end an arrangement for a significant breach, for circumstances found in monitoring that could alter performance, for evidenced weaknesses of the provider and where the authority can no longer supervise. For services supporting critical or important functions it has an exit strategy and a comprehensive, documented exit plan, tested and reviewed periodically, with alternatives, transition plans and contingency measures. | • An exit plan for each critical or important arrangement, with the date of its last review and test • Termination rights in the contracts | — | P06-A02 Third-Party Security Policy (pillar) P06-A03 Supplier Security Assessment Procedure (pillar) P06-A04 Supplier Criticality & Tiering Model (pillar) P06-A07 Supplier Contract Security Clause Library (pillar) P06-A08 Supplier Security Risk Register (pillar) | Readiness item: TP-05 Evidence: EV-31 | Yes | CA-001 has no exit plan (B_07.01.0080 is No). The approach is agreed; the plan is not written. Hosting Subcontractor G has no LEI yet. | Head of Procurement | ||
| EXAMPLE | RQ-50 | Management of ICT third-party risk | Article 29(2); Delegated Regulation 2025/532 | Subcontracting of critical or important services | Every financial entity in scope | Duty | Before allowing a provider to subcontract a service that supports a critical or important function, the entity weighs the benefits and risks, including insolvency law, third-country subcontractors and the length of the chain. The contract states what may be subcontracted and on what conditions, keeps the provider responsible, passes down access and audit rights, and requires notice of material changes with time to approve or object. | • The subcontracting assessment for each critical or important arrangement • The contract terms and the record of notified changes | — | P06-A02 Third-Party Security Policy (pillar) P06-A03 Supplier Security Assessment Procedure (pillar) P06-A04 Supplier Criticality & Tiering Model (pillar) P06-A07 Supplier Contract Security Clause Library (pillar) P06-A08 Supplier Security Risk Register (pillar) | Readiness item: TP-05 Evidence: EV-32 | Yes | CA-001 has no exit plan (B_07.01.0080 is No). The approach is agreed; the plan is not written. Hosting Subcontractor G has no LEI yet. | Head of Procurement | ||
| EXAMPLE | RQ-51 | Management of ICT third-party risk | Articles 31 and 28(3) | Know whether a provider is designated as critical | Every financial entity in scope | Duty | The ESAs designate critical ICT third-party service providers and update the list yearly. A designated provider is overseen by a Lead Overseer. The entity may use a designated provider established in a third country only if it has set up a subsidiary in the Union within 12 months of the designation. | • A check of each provider against the ESAs' current list, with the date checked | — | P06-A02 Third-Party Security Policy (pillar) P06-A03 Supplier Security Assessment Procedure (pillar) P06-A04 Supplier Criticality & Tiering Model (pillar) P06-A07 Supplier Contract Security Clause Library (pillar) P06-A08 Supplier Security Risk Register (pillar) | Readiness item: TP-03 Evidence: EV-29 | Yes | The pre-contract assessment and concentration check for CA-001 are on file; the provider was checked against the ESAs' list on 2026-09-21. | Head of Procurement | ||
| EXAMPLE | RQ-52 | Information sharing | Article 45 | Information sharing (optional) | Every financial entity in scope | Option | Financial entities may exchange cyber threat information and intelligence among themselves, within trusted communities and under arrangements that protect sensitive information. An entity that takes part tells the competent authority once its membership is validated, and when it ends. | • The decision whether to take part, and, if it does, the arrangement and the notice to the authority | — | No published CISO Times document yet. | Readiness item: IS-01 Evidence: EV-34 | Yes | The board decided on 10 Jun 2026 not to join an information-sharing community yet; the decision is recorded. Significant cyber threats are notified only on the incident manager's judgement (Article 19(2) is optional). | Head of Information Security |
Applies To
Which requirement applies to which kind of entity, from the text of Articles 2, 3(60), 16 and 26. Read every requirement from your own profile. A requirement that does not apply to you is marked Not applicable with the reason the profile gives. A requirement is never marked Not applicable because it is hard or costly. The columns are examples of kinds of entity. Your own answer is in the Requirement Library.
| ID | Requirement | Who the text applies to | Full framework | Full framework, microenterprise | Simplified framework (Article 16) | Full framework, identified for threat-led testing | Payment institution, full framework |
|---|---|---|---|---|---|---|---|
| RQ-01 | Know whether DORA binds you | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-02 | Apply the rules in proportion | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-03 | Run the simplified framework | Entities under the simplified framework (Article 16) | No | No | Yes | No | No |
| RQ-04 | The management body owns ICT risk | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-05 | Reporting channels to the management body | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-06 | Members keep their ICT knowledge current | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-07 | A documented ICT risk management framework | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-08 | Control function, three lines and ICT audit | Entities under the full framework, other than microenterprises | Yes | No | No | Yes | Yes |
| RQ-09 | Review the framework every year and report on it | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-10 | A digital operational resilience strategy | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-11 | Reliable, resilient systems | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-12 | Know your functions, assets and dependencies | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-13 | Risk assessments on change and on legacy systems | Entities under the full framework, other than microenterprises | Yes | No | No | Yes | Yes |
| RQ-14 | Protection and prevention | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-15 | Detection | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-16 | Continuity policy, response and recovery plans | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-17 | Test the plans at least yearly | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-18 | A crisis management function | Entities under the full framework, other than microenterprises | Yes | No | No | Yes | Yes |
| RQ-19 | Backup, restoration and recovery | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-20 | Learn from incidents and tests | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-21 | Awareness and resilience training for all staff | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-22 | Crisis communication | Entities under the full framework (not the Article 16 entities) | Yes | Yes | No | Yes | Yes |
| RQ-23 | Key dependencies and critical functions | Entities under the simplified framework (Article 16) | No | No | Yes | No | No |
| RQ-24 | Continuity, backup and restoration, and their tests | Entities under the simplified framework (Article 16) | No | No | Yes | No | No |
| RQ-25 | Lessons, training and the review report | Entities under the simplified framework (Article 16) | No | No | Yes | No | No |
| RQ-26 | Governance under the simplified framework | Entities under the simplified framework (Article 16) | No | No | Yes | No | No |
| RQ-27 | An incident management process | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-28 | Classify incidents by the criteria | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-29 | Report major incidents on time | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-30 | Significant cyber threats (optional) | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-31 | Payment-related incidents | Every financial entity in scope; these types only | No | No | No | No | Yes |
| RQ-32 | A resilience testing programme | Every financial entity in scope other than microenterprises | Yes | No | Yes | Yes | Yes |
| RQ-33 | Test the systems behind critical functions every year | Every financial entity in scope other than microenterprises | Yes | No | Yes | Yes | Yes |
| RQ-34 | A range of tests | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-35 | Microenterprises: risk-based testing | Microenterprises | No | Yes | No | No | No |
| RQ-36 | Vulnerability assessments before deployment | Every financial entity in scope; these types only | No | No | No | No | No |
| RQ-37 | Threat-led penetration testing (if identified) | Entities that a TLPT authority has identified | No | No | No | Yes | No |
| RQ-38 | TLPT closure, remediation and attestation | Entities that a TLPT authority has identified | No | No | No | Yes | No |
| RQ-39 | Testers for TLPT | Entities that a TLPT authority has identified | No | No | No | Yes | No |
| RQ-40 | ICT security testing under the simplified framework | Entities under the simplified framework (Article 16) | No | No | Yes | No | No |
| RQ-41 | You stay responsible | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-42 | The register of information | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-43 | Report on the register and tell the authority first | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-44 | A third-party risk strategy and a policy | Entities under the full framework, other than microenterprises | Yes | No | No | Yes | Yes |
| RQ-45 | A role to monitor the arrangements | Entities under the full framework, other than microenterprises | Yes | No | No | Yes | Yes |
| RQ-46 | Assess before you contract, then audit | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-47 | Contract terms for every arrangement | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-48 | More terms for critical or important functions | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-49 | Exit plans and the right to end the contract | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-50 | Subcontracting of critical or important services | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-51 | Know whether a provider is designated as critical | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
| RQ-52 | Information sharing (optional) | Every financial entity in scope | Yes | Yes | Yes | Yes | Yes |
Supporting Documents
One row per requirement and CISO Times document. A CISO Times document is listed against a requirement when its own framework references cite that article or technical standard. Where fewer than three documents do, those that belong to the work the requirement's pillar describes are added (PILLAR_SUPPORT). Only published documents are listed. The list says a document helps. It says nothing about compliance.
| ID | Pillar | Requirement | CISO Times document | Why it is listed |
|---|---|---|---|---|
| RQ-01 | Scope and proportionality | Know whether DORA binds you | — | No published CISO Times document yet |
| RQ-02 | Scope and proportionality | Apply the rules in proportion | — | No published CISO Times document yet |
| RQ-03 | Scope and proportionality | Run the simplified framework | P22-A02 Business Continuity & ICT Resilience Policy | Cites the provision |
| RQ-04 | ICT risk management | The management body owns ICT risk | P11-A07 Executive Committee Security Report Deck | Cites the provision |
| RQ-04 | ICT risk management | The management body owns ICT risk | P11-A08 Key Risk Indicator Threshold & Escalation Model | Cites the provision |
| RQ-04 | ICT risk management | The management body owns ICT risk | P19-A03 Internal Security Assessment Procedure | Cites the provision |
| RQ-04 | ICT risk management | The management body owns ICT risk | P19-A07 Maturity Assessment Report Template | Cites the provision |
| RQ-04 | ICT risk management | The management body owns ICT risk | P19-A09 Maturity Results Executive Summary Deck | Cites the provision |
| RQ-04 | ICT risk management | The management body owns ICT risk | P20-A09 Annual Control Testing Plan | Cites the provision |
| RQ-04 | ICT risk management | The management body owns ICT risk | P20-A10 Control Assurance Dashboard | Cites the provision |
| RQ-04 | ICT risk management | The management body owns ICT risk | P22-A02 Business Continuity & ICT Resilience Policy | Cites the provision |
| RQ-04 | ICT risk management | The management body owns ICT risk | P22-A09 Resilience Readiness Dashboard | Cites the provision |
| RQ-05 | ICT risk management | Reporting channels to the management body | P03-A03 Board Cybersecurity Report Deck Template | Helps with the pillar |
| RQ-05 | ICT risk management | Reporting channels to the management body | P04-A02 Policy Framework Standard | Helps with the pillar |
| RQ-05 | ICT risk management | Reporting channels to the management body | P05-A02 Risk Assessment Methodology & Scoring Model | Helps with the pillar |
| RQ-05 | ICT risk management | Reporting channels to the management body | P05-A04 Cyber Risk Appetite Statement Template | Helps with the pillar |
| RQ-05 | ICT risk management | Reporting channels to the management body | P05-A05 Information Security Risk Register | Helps with the pillar |
| RQ-06 | ICT risk management | Members keep their ICT knowledge current | P03-A03 Board Cybersecurity Report Deck Template | Helps with the pillar |
| RQ-06 | ICT risk management | Members keep their ICT knowledge current | P04-A02 Policy Framework Standard | Helps with the pillar |
| RQ-06 | ICT risk management | Members keep their ICT knowledge current | P05-A02 Risk Assessment Methodology & Scoring Model | Helps with the pillar |
| RQ-06 | ICT risk management | Members keep their ICT knowledge current | P05-A04 Cyber Risk Appetite Statement Template | Helps with the pillar |
| RQ-06 | ICT risk management | Members keep their ICT knowledge current | P05-A05 Information Security Risk Register | Helps with the pillar |
| RQ-06 | ICT risk management | Members keep their ICT knowledge current | P16-A03 Role-Based Security Training Matrix | Cites the provision |
| RQ-07 | ICT risk management | A documented ICT risk management framework | P19-A05 Assessment Evidence Request Checklist | Cites the provision |
| RQ-07 | ICT risk management | A documented ICT risk management framework | P20-A03 Control Inventory & Ownership Register | Cites the provision |
| RQ-07 | ICT risk management | A documented ICT risk management framework | P20-A06 Control Test Workpaper Template | Cites the provision |
| RQ-07 | ICT risk management | A documented ICT risk management framework | P20-A07 Control Evidence Standards Checklist | Cites the provision |
| RQ-08 | ICT risk management | Control function, three lines and ICT audit | P19-A02 Security Maturity Model & Scoring Method | Cites the provision |
| RQ-08 | ICT risk management | Control function, three lines and ICT audit | P19-A03 Internal Security Assessment Procedure | Cites the provision |
| RQ-08 | ICT risk management | Control function, three lines and ICT audit | P19-A06 Maturity Findings & Improvement Tracker | Cites the provision |
| RQ-08 | ICT risk management | Control function, three lines and ICT audit | P19-A07 Maturity Assessment Report Template | Cites the provision |
| RQ-08 | ICT risk management | Control function, three lines and ICT audit | P20-A02 Control Testing Methodology | Cites the provision |
| RQ-08 | ICT risk management | Control function, three lines and ICT audit | P20-A05 Control Test Execution Procedure | Cites the provision |
| RQ-08 | ICT risk management | Control function, three lines and ICT audit | P20-A08 Control Deficiency & Remediation Tracker | Cites the provision |
| RQ-08 | ICT risk management | Control function, three lines and ICT audit | P20-A09 Annual Control Testing Plan | Cites the provision |
| RQ-09 | ICT risk management | Review the framework every year and report on it | P19-A02 Security Maturity Model & Scoring Method | Cites the provision |
| RQ-09 | ICT risk management | Review the framework every year and report on it | P19-A04 Security Programme Maturity Assessment | Cites the provision |
| RQ-09 | ICT risk management | Review the framework every year and report on it | P19-A06 Maturity Findings & Improvement Tracker | Cites the provision |
| RQ-09 | ICT risk management | Review the framework every year and report on it | P19-A07 Maturity Assessment Report Template | Cites the provision |
| RQ-09 | ICT risk management | Review the framework every year and report on it | P19-A08 Target-State Maturity Roadmap | Cites the provision |
| RQ-09 | ICT risk management | Review the framework every year and report on it | P20-A02 Control Testing Methodology | Cites the provision |
| RQ-09 | ICT risk management | Review the framework every year and report on it | P20-A03 Control Inventory & Ownership Register | Cites the provision |
| RQ-09 | ICT risk management | Review the framework every year and report on it | P20-A04 Unified Control Framework Mapping Workbook | Cites the provision |
| RQ-09 | ICT risk management | Review the framework every year and report on it | P20-A10 Control Assurance Dashboard | Cites the provision |
| RQ-10 | ICT risk management | A digital operational resilience strategy | P11-A02 Security Metric Definition & Measurement Method | Cites the provision |
| RQ-10 | ICT risk management | A digital operational resilience strategy | P11-A03 Security KPI & KRI Catalogue | Cites the provision |
| RQ-10 | ICT risk management | A digital operational resilience strategy | P11-A04 Metric Definition Card Template | Cites the provision |
| RQ-10 | ICT risk management | A digital operational resilience strategy | P11-A08 Key Risk Indicator Threshold & Escalation Model | Cites the provision |
| RQ-10 | ICT risk management | A digital operational resilience strategy | P19-A08 Target-State Maturity Roadmap | Cites the provision |
| RQ-11 | ICT risk management | Reliable, resilient systems | P03-A03 Board Cybersecurity Report Deck Template | Helps with the pillar |
| RQ-11 | ICT risk management | Reliable, resilient systems | P04-A02 Policy Framework Standard | Helps with the pillar |
| RQ-11 | ICT risk management | Reliable, resilient systems | P05-A02 Risk Assessment Methodology & Scoring Model | Helps with the pillar |
| RQ-11 | ICT risk management | Reliable, resilient systems | P05-A04 Cyber Risk Appetite Statement Template | Helps with the pillar |
| RQ-11 | ICT risk management | Reliable, resilient systems | P05-A05 Information Security Risk Register | Helps with the pillar |
| RQ-12 | ICT risk management | Know your functions, assets and dependencies | P15-A02 Information Classification & Handling Policy | Cites the provision |
| RQ-12 | ICT risk management | Know your functions, assets and dependencies | P15-A04 Classification & Labelling Procedure | Cites the provision |
| RQ-12 | ICT risk management | Know your functions, assets and dependencies | P15-A05 Information Asset Register | Cites the provision |
| RQ-12 | ICT risk management | Know your functions, assets and dependencies | P15-A06 Information Asset Classification Workbook | Cites the provision |
| RQ-12 | ICT risk management | Know your functions, assets and dependencies | P15-A09 Information Ownership Responsibility Matrix | Cites the provision |
| RQ-13 | ICT risk management | Risk assessments on change and on legacy systems | P03-A03 Board Cybersecurity Report Deck Template | Helps with the pillar |
| RQ-13 | ICT risk management | Risk assessments on change and on legacy systems | P04-A02 Policy Framework Standard | Helps with the pillar |
| RQ-13 | ICT risk management | Risk assessments on change and on legacy systems | P05-A02 Risk Assessment Methodology & Scoring Model | Helps with the pillar |
| RQ-13 | ICT risk management | Risk assessments on change and on legacy systems | P05-A04 Cyber Risk Appetite Statement Template | Helps with the pillar |
| RQ-13 | ICT risk management | Risk assessments on change and on legacy systems | P05-A05 Information Security Risk Register | Helps with the pillar |
| RQ-13 | ICT risk management | Risk assessments on change and on legacy systems | P17-A07 End-of-Life Software & Unsupported System Register | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P13-A02 Access Control Policy | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P13-A03 Joiner-Mover-Leaver Operating Procedure | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P13-A04 Role-Based Access Profile Matrix | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P13-A09 Leaver Timeliness & Orphaned Account Report | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P14-A02 Privileged Access Standard | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P14-A03 Privileged Access Request, Elevation & Revocation Procedure | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P14-A04 Privileged & Service Account Inventory | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P14-A06 Privileged Access Control Review Workbook | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P14-A07 Privileged Session Review Record | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P14-A09 Privileged Access Metrics Dashboard | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P15-A02 Information Classification & Handling Policy | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P15-A03 Classification Level Handling Rules Matrix | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P17-A02 Patch Management Standard | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P17-A03 Monthly Patch Cycle Operating Procedure | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P17-A04 Patch Deployment Ring & Maintenance Window Plan | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P17-A05 Emergency Out-of-Band Patching Procedure | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P17-A06 Patch Deployment Verification Checklist | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P17-A08 Patch Compliance Dashboard | Cites the provision |
| RQ-14 | ICT risk management | Protection and prevention | P17-A09 Patch Deferral Request Form | Cites the provision |
| RQ-15 | ICT risk management | Detection | P03-A03 Board Cybersecurity Report Deck Template | Helps with the pillar |
| RQ-15 | ICT risk management | Detection | P04-A02 Policy Framework Standard | Helps with the pillar |
| RQ-15 | ICT risk management | Detection | P05-A02 Risk Assessment Methodology & Scoring Model | Helps with the pillar |
| RQ-15 | ICT risk management | Detection | P05-A04 Cyber Risk Appetite Statement Template | Helps with the pillar |
| RQ-15 | ICT risk management | Detection | P05-A05 Information Security Risk Register | Helps with the pillar |
| RQ-16 | ICT risk management | Continuity policy, response and recovery plans | P22-A02 Business Continuity & ICT Resilience Policy | Cites the provision |
| RQ-16 | ICT risk management | Continuity policy, response and recovery plans | P22-A03 Cyber Recovery Operating Procedure | Cites the provision |
| RQ-16 | ICT risk management | Continuity policy, response and recovery plans | P22-A04 Critical Service Recovery Objectives Matrix (RTO, RPO, MTD) | Cites the provision |
| RQ-16 | ICT risk management | Continuity policy, response and recovery plans | P22-A05 Cyber Recovery Plan Template | Cites the provision |
| RQ-16 | ICT risk management | Continuity policy, response and recovery plans | P22-A07 Resilience Dependency Register | Cites the provision |
| RQ-16 | ICT risk management | Continuity policy, response and recovery plans | P23-A02 Restore Testing Methodology | Cites the provision |
| RQ-17 | ICT risk management | Test the plans at least yearly | P10-A02 Tabletop Exercise Design Methodology | Cites the provision |
| RQ-17 | ICT risk management | Test the plans at least yearly | P10-A03 Exercise Planning & Facilitation Procedure | Cites the provision |
| RQ-17 | ICT risk management | Test the plans at least yearly | P10-A04 Tabletop Scenario — Ransomware Encryption of Core Systems | Cites the provision |
| RQ-17 | ICT risk management | Test the plans at least yearly | P10-A05 Tabletop Scenario — Critical Supplier Outage | Cites the provision |
| RQ-17 | ICT risk management | Test the plans at least yearly | P10-A08 Tabletop Scenario — Executive Payment Fraud | Cites the provision |
| Showing the first 100 of 303 rows. The remaining 203 are in the document. | ||||
Supplier Flow-Down
For a supplier of ICT services to a financial entity. DORA lists ICT third-party service providers in Article 2(1), point (u), and defines financial entities as points (a) to (t) only. Yellow columns are yours.
| ID | What a financial entity must ask for or collect | Provisions it comes from | Where it is in your contracts or records | Owner |
|---|---|---|---|---|
| FD-01 | A written contract that describes the services and says whether, and on what terms, subcontracting is allowed; names the locations of the services and of the data, and gives advance notice of a change | DORA 30(1); DORA 30(2) | ||
| FD-02 | Terms on the availability, authenticity, integrity and confidentiality of data, and on access to and return of the entity's data in an accessible format on the provider's insolvency or the end of the contract | DORA 30(2) | ||
| FD-03 | Service levels, and assistance in an incident at no extra cost or at a cost agreed in advance | DORA 30(2) | ||
| FD-04 | Full cooperation with the entity's competent and resolution authorities; termination rights and notice periods; taking part in the entity's awareness and resilience training | DORA 30(2) | ||
| FD-05 | For a service supporting a critical or important function: full service levels with precise targets, notice and reporting duties, contingency plans and security measures that the provider implements and tests, and taking part in the entity's TLPT | DORA 30(3); DORA 30(3)(c); DORA 30(3)(d) | ||
| FD-06 | Unrestricted rights of access, inspection and audit for the entity and the authorities, and cooperation during on-site inspections | DORA 30(3)(e) | ||
| FD-07 | An exit strategy with a mandatory adequate transition period | DORA 30(3)(f); DORA 28(8) | ||
| FD-08 | Subcontracting conditions: responsibility for subcontracted services, monitoring and reporting, the same access and audit rights, and notice of material changes with time for the entity to approve or object | RTS 532 4; RTS 532 5 | ||
| FD-09 | The information the entity must enter in its register: the provider's legal name, a valid LEI or EUID, its ultimate parent, the country of its headquarters, and the same identifiers for the subcontractors behind a critical or important service | ITS 2956 3; ITS 2956 B_05 | ||
| FD-10 | Where the ESAs designate the provider as critical: oversight by a Lead Overseer, a yearly list, and, for a provider established in a third country, a subsidiary in the Union within 12 months | DORA 31(1); DORA 31(9); DORA 31(12) |
Summary
Library summary
Calculated from the Requirement Library, Applies To, Supporting Documents and Supplier Flow-Down. The counts say which cells are filled in. They do not say whether a requirement is in place: rate that in the DORA Readiness Self-Assessment.
EXAMPLE: Lantern Pay Services (EXAMPLE) answers and records, as at 2026-09-30. Clear the EXAMPLE entries to use your own.
| Pillar | Requirements | Duties | Options | Published documents | Applies to us: Yes | Applies, no record named | Owner named | Your ISO/IEC 27001 entry | Your NIST CSF entry |
|---|---|---|---|---|---|---|---|---|---|
| Scope and proportionality | 3 | 3 | 0 | 1 | 2 | 0 | 2 | 0 | 0 |
| ICT risk management | 23 | 23 | 0 | 172 | 19 | 0 | 19 | 0 | 0 |
| ICT-related incident management, classification and reporting | 5 | 4 | 1 | 28 | 5 | 0 | 5 | 0 | 0 |
| Digital operational resilience testing | 9 | 9 | 0 | 36 | 3 | 0 | 3 | 0 | 0 |
| Management of ICT third-party risk | 11 | 11 | 0 | 63 | 11 | 0 | 11 | 0 | 0 |
| Information sharing | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 0 |
| All pillars | 52 | 50 | 2 | 300 | 41 | 0 | 41 | 0 | 0 |
41 of 52 requirements are marked as applying to you; 0 are not yet assessed.
A requirement with no published document is not a gap in your controls. It means CISO Times has no template that cites it yet. The "Published documents" count is per pillar, and a document is counted once for each requirement it helps with.
Requirements that apply, by kind of entity
| Kind of entity | Requirements that apply | Of them, duties | Of them, options |
|---|---|---|---|
| Full framework | 40 | 38 | 2 |
| Full framework, microenterprise | 34 | 32 | 2 |
| Simplified framework (Article 16) | 25 | 23 | 2 |
| Full framework, identified for threat-led testing | 43 | 41 | 2 |
| Payment institution, full framework | 41 | 39 | 2 |
0 of 10 supplier flow-down items have a contract or record named.
A duty is a requirement the text imposes. An option is one the text leaves to the entity. Neither count is a score.
Lists
| Applies | Why |
|---|---|
| Yes | Cites the provision |
| No | Helps with the pillar |
| Not yet assessed | No published CISO Times document yet |
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| Requirement (RQ-nn) | One provision of DORA, or of a technical standard under it, that this pack relies on. RQ-01 to RQ-52 are the pack's stable IDs for them. The text asked for is ours, from the texts read on 8 October 2026. |
| Duty and option | A duty is a requirement the text imposes on the entities it names. An option is one the text lets the entity choose, such as sharing cyber threat information. |
| What to be able to show | The documents and records a supervisor would expect to see for the requirement, in our words. They are what a competent authority may ask for. |
| CISO Times documents that help | A CISO Times document is listed against a requirement when its own framework references cite that article or technical standard. Where fewer than three documents do, those that belong to the work the requirement's pillar describes are added (PILLAR_SUPPORT). Only published documents are listed. The list says a document helps. It says nothing about compliance. |
| Your own entry | The last two columns of the library: the ISO/IEC 27001 controls and NIST CSF outcomes you use for the requirement, if you run either. The workbook leaves them blank. What you enter is your judgement. |
| Financial entity | An entity of the kinds listed in Article 2(1), points (a) to (t), of DORA, such as a credit institution, a payment institution, an investment firm or an insurance undertaking. ICT third-party service providers are not financial entities. DORA binds financial entities, except those Article 2(3) excludes and those a Member State excludes under Article 2(4). |
| Microenterprise | A financial entity, other than a trading venue, a central counterparty, a trade repository or a central securities depository, that employs fewer than 10 persons and has an annual turnover or an annual balance sheet total that does not exceed EUR 2 million (DORA Art 3(60)). Several duties do not apply to a microenterprise, and the Regulation says where. |
| Full framework | The ICT risk management framework of DORA Articles 5 to 15, which applies to every financial entity that is not one of the Article 16 entities. Title II of Delegated Regulation (EU) 2024/1774 details it. |
| Simplified framework | The lighter ICT risk management framework of DORA Article 16 for small and non-interconnected investment firms, exempted payment institutions, exempted electronic money institutions, certain institutions exempted under Directive 2013/36/EU, and small institutions for occupational retirement provision. Articles 5 to 15 do not apply to them. Title III of Delegated Regulation (EU) 2024/1774 details it. |
| Management body | The body that effectively runs the entity or has key functions under the law that governs it, such as the board (DORA Art 3(30)). It defines, approves and oversees the ICT risk management arrangements and is ultimately responsible for ICT risk (Art 5). |
| 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 whose discontinued, defective or failed performance would materially impair its continuing compliance with the conditions of its authorisation or its other duties under financial services law (DORA Art 3(22)). The entity decides which of its functions are critical or important, records why, and reviews the decision. |
| ICT third-party service provider | An undertaking providing ICT services (DORA Art 3(19)). ICT services are digital and data services provided through ICT systems to one or more users on an ongoing basis, including hardware as a service, and excluding traditional analogue telephone services (Art 3(21)). |
| Supplier | In this pack, an organisation that provides ICT services to a financial entity. DORA reaches a supplier that is not itself a financial entity through the contract the financial entity must write (Article 30) and the information the financial entity must collect, and, if the ESAs designate it as critical, through oversight. A financial entity that sells ICT services to another financial entity follows this pack for its own duties and is a supplier to that customer, which writes the Article 30 terms into the contract with it. |
| Threat-led penetration testing (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). |
| Readiness item and evidence item | A readiness item (such as RM-02) is a group of requirements that the readiness self-assessment rates. An evidence item (EV-nn) is a record the documentation checklist lists. The library names the ones that relate to each requirement. |
| DR-nn | The pack's rules, DR-01 to DR-23, set out in the pack guide and quoted in each document. |
| EXAMPLE | A worked example: Lantern Pay Services (EXAMPLE), a small authorised payment institution in an EU Member State, with 64 staff, as at 2026-09-30. Clear the EXAMPLE entries 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.31 — Legal, statutory, regulatory and contractual requirements | The whole library: the legal and regulatory requirements that apply to the entity identified and recorded, each with an owner |
| NIST CSF 2.0 | GV.OC-03 — “Legal, regulatory, and contractual requirements regarding cybersecurity - including privacy and civil liberties obligations - are understood and managed” | The whole library: what DORA requires understood, and each requirement managed by a named owner |
| 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) | Requirement Library: RQ-02 |
| DORA — Regulation (EU) 2022/2554 | Article 5(2) — the management body defines, approves, oversees and is responsible for the ICT risk management framework, bears ultimate responsibility for ICT risk and sets the risk tolerance | Requirement Library: RQ-04 |
| DORA — Regulation (EU) 2022/2554 | Article 5(3) — financial entities, other than microenterprises, “shall establish a role in order to monitor the arrangements concluded with ICT third-party service providers on the use of ICT services, or shall designate a member of senior management as responsible for overseeing the related risk exposure and relevant documentation” | Requirement Library: RQ-45 |
| DORA — Regulation (EU) 2022/2554 | Article 5(4) — members of the management body keep up to date with sufficient knowledge and skills to understand and assess ICT risk, including through regular training | Requirement Library: RQ-06 |
| DORA — Regulation (EU) 2022/2554 | Article 6(1) — a sound, comprehensive and well-documented ICT risk management framework as part of the overall risk management system | Requirement Library: RQ-07 |
| DORA — Regulation (EU) 2022/2554 | Article 6(5) — the ICT risk management framework is documented and reviewed at least once a year (periodically for microenterprises), upon major ICT-related incidents, and following supervisory instructions or conclusions from digital operational resilience testing or audit processes; “It shall be continuously improved on the basis of lessons derived from implementation and monitoring.” A report on the review is submitted to the competent authority on request | Requirement Library: RQ-09 |
| DORA — Regulation (EU) 2022/2554 | Article 6(8) — the framework includes a digital operational resilience strategy that explains how the framework supports the business strategy, sets the risk tolerance level for ICT risk and analyses impact tolerance for ICT disruptions, sets information security objectives with key performance indicators and key risk metrics, explains the ICT reference architecture, outlines the mechanisms that detect incidents and protect against them, evidences the current position on the basis of the major ICT-related incidents reported and the effectiveness of preventive measures, implements resilience testing under Chapter IV, and outlines a communication strategy for incidents that Article 14 requires to be disclosed | Requirement Library: RQ-10 |
| DORA — Regulation (EU) 2022/2554 | Article 7 — financial entities use and maintain updated ICT systems, protocols and tools that are appropriate to the magnitude of their operations, reliable, equipped with sufficient capacity to process data accurately and deal with peak orders, message or transaction volumes, and technologically resilient under stressed conditions | Requirement Library: RQ-11 |
| DORA — Regulation (EU) 2022/2554 | Article 8(1) — identify, classify and document ICT-supported business functions, information assets and ICT assets, reviewed at least yearly | Requirement Library: RQ-12 |
| DORA — Regulation (EU) 2022/2554 | Article 9(2) — financial entities design, procure and implement ICT security policies, procedures, protocols and tools that aim “to maintain high standards of availability, authenticity, integrity and confidentiality of data, whether at rest, in use or in transit” | Requirement Library: RQ-14 |
| DORA — Regulation (EU) 2022/2554 | Article 10(1) to (3) — mechanisms to “promptly detect anomalous activities”, including ICT network performance issues and ICT-related incidents, and to identify potential material single points of failure; the mechanisms are regularly tested under Article 25, enable multiple layers of control, define alert thresholds and criteria that trigger incident response and include automatic alerts for the staff in charge; sufficient resources and capabilities monitor user activity, ICT anomalies and incidents | Requirement Library: RQ-15 |
| DORA — Regulation (EU) 2022/2554 | Article 11(1) — as part of the ICT risk management framework and based on the identification requirements of Article 8, “financial entities shall put in place a comprehensive ICT business continuity policy, which may be adopted as a dedicated specific policy, forming an integral part of the overall business continuity policy of the financial entity” | Requirement Library: RQ-16 |
| 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 | Requirement Library: RQ-17 |
| DORA — Regulation (EU) 2022/2554 | Article 12(1) — “For the purpose of ensuring the restoration of ICT systems and data with minimum downtime, limited disruption and loss”, financial entities develop and document backup policies and procedures specifying “the scope of the data that is subject to the backup and the minimum frequency of the backup, based on the criticality of information or the confidentiality level of the data”, and restoration and recovery procedures and methods | Requirement Library: RQ-19 |
| DORA — Regulation (EU) 2022/2554 | Article 13(2) — post ICT-related incident reviews after a major ICT-related incident disrupts core activities, analysing the causes and identifying improvements; financial entities other than microenterprises tell the competent authorities on request what changed as a result; the reviews determine whether procedures were followed and actions effective, including the promptness of response, the quality and speed of any forensic analysis, the effectiveness of escalation, and internal and external communication | Requirement Library: RQ-20 |
| DORA — Regulation (EU) 2022/2554 | Article 14(1) — “financial entities shall have in place crisis communication plans enabling a responsible disclosure of, at least, major ICT-related incidents or vulnerabilities to clients and counterparts as well as to the public, as appropriate” | Requirement Library: RQ-22 |
| DORA — Regulation (EU) 2022/2554 | Article 16(1) — “Articles 5 to 15 of this Regulation shall not apply to” small and non-interconnected investment firms, exempted payment institutions, institutions exempted under Directive 2013/36/EU where the Member State has not applied the Article 2(4) option, exempted electronic money institutions, and small institutions for occupational retirement provision; those entities instead apply the simplified ICT risk management framework | Requirement Library: RQ-03, RQ-26 |
| DORA — Regulation (EU) 2022/2554 | Article 17(1) — define, establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents | Requirement Library: RQ-27 |
| DORA — Regulation (EU) 2022/2554 | Article 18(1) — classify ICT-related incidents by clients and transactions affected, reputational impact, duration and downtime, geographical spread, data losses, criticality of services affected and economic impact | Requirement Library: RQ-28 |
| DORA — Regulation (EU) 2022/2554 | Article 19(1) — report major ICT-related incidents to the relevant competent authority | Requirement Library: RQ-29 |
| 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 | Requirement Library: RQ-32 |
| DORA — Regulation (EU) 2022/2554 | Article 24(6) — at least yearly, appropriate tests on all ICT systems and applications supporting critical or important functions | Requirement Library: RQ-33 |
| DORA — Regulation (EU) 2022/2554 | Article 25(1) — the testing programme provides for appropriate tests, among them “scenario-based tests” | Requirement Library: RQ-34 |
| 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 | Requirement Library: RQ-37 |
| 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 | Requirement Library: RQ-39 |
| DORA — Regulation (EU) 2022/2554 | Article 28(2) — a strategy on ICT third-party risk, including a policy on ICT services supporting critical or important functions | Requirement Library: RQ-44 |
| DORA — Regulation (EU) 2022/2554 | Article 28(3) — a register of information on all contractual arrangements for ICT services, distinguishing those supporting critical or important functions | Requirement Library: RQ-42 |
| DORA — Regulation (EU) 2022/2554 | Article 28(8) — for ICT services supporting critical or important functions, financial entities put in place exit strategies that take account of provider failure, deteriorating quality, business disruption and termination; they must be able to exit without disruption to business activities, without limiting regulatory compliance and without detriment to the continuity and quality of services to clients; exit plans are comprehensive, documented and “sufficiently tested and reviewed periodically”, with alternative solutions, transition plans and contingency measures | Requirement Library: RQ-49 |
| DORA — Regulation (EU) 2022/2554 | Article 29(1) — assessing concentration risk: providers not easily substitutable, or several arrangements with the same provider | Requirement Library: RQ-46 |
| DORA — Regulation (EU) 2022/2554 | Article 30(2) — minimum contract content: services, locations, data protection, data return, service levels, incident assistance, cooperation with authorities, termination rights, training | Requirement Library: RQ-47 |
| DORA — Regulation (EU) 2022/2554 | Article 30(3) — additional contract content for critical or important functions: full service levels, notice duties, contingency plans and security, testing participation, audit and access rights, exit strategies | Requirement Library: RQ-48 |
| DORA — Regulation (EU) 2022/2554 | Article 45 — financial entities may exchange cyber threat information and intelligence among themselves, within trusted communities and under arrangements that protect sensitive information and set conditions for participation; they notify the competent authorities of their participation, once membership is validated, and of the end of it | Requirement Library: RQ-52 |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 3 — ICT risk management policies and procedures contain, among other elements, the approved risk tolerance level for ICT risk; a risk assessment procedure and methodology that identifies vulnerabilities and threats and uses quantitative or qualitative indicators of impact and likelihood; the procedure to identify, implement and document risk treatment measures; and, for residual risk, the roles that accept risk above the tolerance level, an inventory of accepted residual risks with justification and a review of them at least once a year | Requirement Library: RQ-07 |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 27(2) — the report on the review of the ICT risk management framework (DORA Article 6(5)), in a searchable electronic format, contains an introduction and executive summary, the date of the management body’s approval, the reason for the review, the review period, the function responsible, major changes since the previous review, a summary of findings with the severity of weaknesses, deficiencies and gaps, the measures to address them with dates, resources and the function responsible, planned developments, conclusions, information on past reviews and the sources used, including internal audit results (other than for microenterprises), compliance assessments, resilience testing results and external sources | Requirement Library: RQ-09 |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 28(2) — for the entities of DORA Article 16(1), the management body bears overall responsibility for the simplified framework in line with the risk appetite; sets roles and responsibilities for ICT tasks and information security objectives; approves, oversees and periodically reviews the classification of information assets, the main risks, the business impact analysis, the business continuity plans and the response and recovery measures; allocates and reviews the budget at least once a year; and sets reporting arrangements to itself | Requirement Library: RQ-26 |
| 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” | Requirement Library: RQ-24 |
| DORA — Delegated Regulation (EU) 2024/1772 | Article 8 — an incident is major where it affects critical services and either meets the data-loss threshold in Article 9(5)(b) or meets two or more of the other materiality thresholds | Requirement Library: RQ-28 |
| DORA — Delegated Regulation (EU) 2024/1773 | Article 3 — the management body reviews the policy at least once a year; the policy sets a methodology to decide which ICT services support critical or important functions, assigns internal responsibilities for approving, managing, controlling and documenting the arrangements, identifies the role or senior manager that monitors them and the reporting lines to the management body, requires independent review of these services and their inclusion in the audit plan, and states that the arrangements do not relieve the entity and its management body of their responsibilities | Requirement Library: RQ-44 |
| 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 | Requirement Library: RQ-38 |
| DORA — Delegated Regulation (EU) 2025/532 | Article 4 — the contract identifies which services supporting critical or important functions may be subcontracted and on what conditions, and states that the provider is responsible for subcontracted services and monitors them, its monitoring and reporting duties towards the entity, the locations of data processed by subcontractors, continuity throughout the chain, contingency plan and security requirements passed down, the same access, inspection and audit rights, and notice of material changes to subcontracting | Requirement Library: RQ-50 |
| DORA — Implementing Regulation (EU) 2024/2956 | Article 5 — the register holds templates B_01.01 (entity maintaining the register), B_01.02 (entities in the consolidation), B_01.03 (branches), B_02.01 and B_02.02 (contractual arrangements, general and specific), B_02.03 (intra-group arrangements), B_03.01 to B_03.03 (signing entities and providers), B_04.01 (entities using the services), B_05.01 (providers and subcontractors), B_05.02 (supply chain), B_06.01 (functions), B_07.01 (assessment of the ICT services) and B_99.01 (the entity’s own definitions of the closed lists); entities may add information for their own risk or contract management | Requirement Library: RQ-42 |
| DORA — Delegated Regulation (EU) 2025/301 | Article 5 — initial notification within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it; intermediate report within 72 hours of the initial notification; final report no later than one month after the latest intermediate report | Requirement Library: RQ-29 |
| DORA — Implementing Regulation (EU) 2025/302 | Article 1 — the Annex I template is used for the initial notification, the intermediate report and the final report | Requirement Library: RQ-29 |
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.