DORA implementation

Scope: one financial entity, end to end · Who: the officer who owns ICT risk · Prerequisites: the official texts and a contract inventory · First result: a function map

1. Why this exists (the failure mode it prevents)#

DORA gets run as a filing exercise: a register assembled from procurement data, submitted, and left alone.

The shape is recognisable. The register lists arrangements, but no function map sits behind it, so criticality is a guess. Classification exists as a policy and has never been rehearsed. Testing covers what is convenient.

Each surfaces predictably. A supervisor reads the register first, and may ask for all of it or specified sections ¹. An incident is reported late because nobody had run the criteria; the initial notification is due within four hours of classification ². Testing is scoped without the function map, though a threat-led scope is validated by the authority ³.

The framework is reviewed at least yearly (periodically for microenterprises), on every major incident, and after supervisory instructions ⁴. That cadence is the tell.

2. Definitions (only the ones that cause disputes)#

Term	Working definition	Source
ICT risk	A reasonably identifiable circumstance in the use of network and information systems which, materialising, may compromise their security.	5
ICT-related incident	A single event, or linked events unplanned by the entity, compromising system security and harming data or services.	6
Major ICT-related incident	An incident with a high adverse impact on the systems behind the entity's critical or important functions.	7
Critical or important function	A function whose disruption would materially impair financial performance, the soundness or continuity of services, or continued compliance with its authorisation.	8
ICT third-party service provider	An undertaking providing ICT services: digital and data services delivered through ICT systems on an ongoing basis.	9
ICT intra-group service provider	An undertaking in a financial group providing predominantly ICT services within it.	10
ICT concentration risk	A dependency on individual or related critical providers whose failure may endanger critical functions.	11
Threat-led penetration testing	A framework mimicking real threat actors: a controlled, intelligence-led red team test of live production systems.	12
Register of information	The record of all arrangements on the use of ICT services from third-party providers.	1
Proportionality, and the simplified framework	Chapter II applies in proportion to size, risk profile and complexity. Articles 5 to 15 do not apply to the Article 16(1) entities.	13

3. The method — numbered steps, each with input, activity, output and owner#

Ten steps in dependency order.

3.1 Fix scope and proportionality first#

Article 2(1) lists the entity types reached, at points (a) to (u). Points (a) to (t) are collectively the financial entities; point (u) is ICT third-party providers. Article 2(3) carves out six categories, and a Member State may exclude more ¹⁴.

Proportionality is two rules: Chapter II in proportion to size, risk profile and complexity, and Chapters III, IV and V Section I as their own rules provide ¹⁵. Article 16 is a closed list, not a self-assessment. Articles 5 to 15 miss five categories: small and non-interconnected investment firms, exempted payment and electronic money institutions, small occupational retirement institutions, and institutions exempted under Directive 2013/36/EU. Those entities carry eight duties instead ¹⁶.

• Input: the authorisation register; legal form; group structure.
• Activity: work each Article 2 test in order, recording answer and citation.
• Output: scope and proportionality memo, the Article 16 answer stated either way.
• Owner: the ICT risk owner; legal counsel confirms the entity type.

3.2 Put the governance in place before the documents#

The management body defines, approves, oversees and is responsible for implementing every arrangement in the framework. Nine duties sit under that, at points (a) to (i). They include approving the resilience strategy and risk tolerance, the ICT audit plans, the budget and the third-party policy ¹⁷.

Two duties are easy to miss. An entity other than a microenterprise names a role, or a senior manager, to monitor third-party arrangements. Management body members keep their knowledge current, following specific training regularly ¹⁸. Staff training is separate: awareness and resilience training are compulsory modules for all employees and senior management staff ¹⁹.

• Input: the board calendar; the delegation of authority; training records.
• Activity: map each Article 5(2) duty to an agenda item; name the monitoring role; schedule board training separately.
• Output: governance map, and a dated approval record per duty.
• Owner: the management body; the ICT risk owner prepares the papers.

3.3 Build the ICT risk management framework#

The framework is well documented and part of the overall risk management system, holding at least the strategies, policies, procedures, ICT protocols and tools protecting all information and ICT assets. An entity other than a microenterprise assigns ICT risk to an independent control function under a three lines of defence model. It is reviewed at least yearly, on major incidents, and after supervisory instructions, with a report to the authority on request. Internal audit reviews it regularly, critical findings get a formal follow-up, and a resilience strategy with eight elements sits inside it ²⁰.

The policy set is not left to judgement. Delegated Regulation (EU) 2024/1774 names each policy by its own article title, at Articles 4 to 22. Seven cover operations: ICT asset management policy, ICT asset management procedure, Encryption and cryptographic controls, Cryptographic key management, Policies and procedures for ICT operations, Capacity and performance management, and Vulnerability and patch management. Six cover systems and data: Data and system security, Logging, Network security management, Securing information in transit, ICT project management, and ICT systems acquisition, development, and maintenance. Six cover people and change: ICT change management, Physical and environmental security, Human resources policy, Identity management, Access control, and ICT-related incident management policy. Each policy records the date of its approval by the management body, and Article 27 fixes the review report's format ²¹. Articles 28 to 41 carry the parallel set for the simplified framework ²².

• Input: the scope memo; existing policies; the audit plan.
• Activity: map each policy to an article title above; open a gap where nothing maps; date each approval.
• Output: framework document set, with a policy index and approval dates.
• Owner: the ICT risk control function; each policy has an owning role.

3.4 Identify, protect, detect#

Identification comes first, because everything downstream is scoped from it. The entity identifies, classifies and documents all ICT-supported business functions, roles and responsibilities, and the assets behind them, reviewing that yearly. It maps critical assets and their interdependencies, identifies processes dependent on a third-party provider, and assesses legacy systems yearly ²³.

Protection is an outcome: policies, procedures, protocols and tools preserving availability, authenticity, integrity and confidentiality of data at rest, in use and in transit ²⁴. Detection has three testable properties. Mechanisms find anomalous activity promptly and identify material single points of failure, are themselves tested, and carry alert thresholds that start the response process ²⁵.

• Input: the asset and contract inventories.
• Activity: build one function map, attach assets and providers to it, and set alert thresholds against it.
• Output: function map and asset and dependency inventories, reviewed yearly.
• Owner: the ICT risk control function; business owners confirm their functions.

3.5 Response, recovery, backup, learning, communication#

The ICT business continuity policy is implemented through documented arrangements, plans, procedures and mechanisms, with five aims at points (a) to (e). Response and recovery plans face independent internal audit review, except in microenterprises. Plans are tested at least yearly, and on substantive changes to systems behind critical or important functions ²⁶.

Backup carries its own rules. Policies specify the scope of data backed up and the minimum frequency. Restoration from own systems uses systems physically and logically segregated from the source, and recovery objectives are set per function ²⁷. A post-incident review follows any major incident disrupting core activities, feeds the risk assessment process, and reaches the management body yearly through senior ICT staff ²⁸.

• Input: the function map; agreed recovery objectives.
• Activity: test on the calendar and on change; run one timed restore from segregated systems; hold the review even after a quick fix.
• Output: tested continuity and recovery plans, a restore-test record, and a post-incident review.
• Owner: the continuity owner; the control function owns the lessons.

3.6 Incidents: process, classification, reporting#

The process comes before the classification. The entity records all ICT-related incidents and significant cyber threats, ensuring root causes are identified and addressed. Six elements sit at points (a) to (f), among them early warning indicators, procedures to classify by priority and severity, and escalation to the management body ²⁹.

Classification runs on six criteria: clients, counterparts and transactions affected including reputational impact; duration and downtime; geographical spread; data losses; criticality of the services; and economic impact ³⁰. Delegated Regulation (EU) 2024/1772 turns those into measurable tests at Articles 1 to 7, then sets thresholds.

An incident is major where it affected critical services and either the data-loss threshold at Article 9(5), point (b) is met, or two or more other thresholds are. Recurring incidents aggregate where they occur at least twice in six months with the same apparent root cause ³¹. The thresholds are printed figures. More than ten per cent of clients using the affected service, or more than 100 000 affected clients. More than thirty per cent of financial counterparts, or more than ten per cent of the daily average number or value of transactions. Duration over twenty-four hours, or downtime over two hours for services behind critical or important functions. Impact in two or more Member States. Costs and losses over 100 000 euro ³².

Reporting is three submissions: an initial notification, an intermediate report, and a final report once root cause analysis is complete ³³. Delegated Regulation (EU) 2025/301 holds the clocks. The initial notification goes as early as possible, in any case within four hours of the classification as major, and no later than twenty-four hours from becoming aware. The intermediate report follows at the latest within seventy-two hours of the initial notification, even where nothing has changed. The final report is due no later than one month after the intermediate report, or after the latest updated one ².

The forms are fixed. Implementing Regulation (EU) 2025/302 sets Annex I, Templates for the reporting of major incidents, and Annex III, Templates for notification of significant cyber threats. All three submissions use Annex I, with different fields mandatory at each stage ³⁴.

• Input: the function map; the incident record.
• Activity: classify every incident against the six criteria; rehearse the four-hour path twice a year.
• Output: classification procedure, a worksheet per incident, and a report pack on the Annex I fields.
• Owner: the incident manager classifies; the ICT risk owner countersigns.

3.7 Testing tied to the functions it protects#

An entity other than a microenterprise establishes, maintains and reviews a resilience testing programme inside the framework. Tests are undertaken by independent parties, internal or external, and every issue is prioritised, classified and remedied under an internal validation method. The floor is explicit: at least yearly, appropriate tests on all systems and applications behind critical or important functions ³⁵. Article 25 names the test types, from vulnerability assessments and scans to source code reviews and penetration testing ³⁶.

Threat-led penetration testing is separate and rarer. Identified entities carry it out at least every three years, and a competent authority may change that frequency. Each test covers several or all critical or important functions on live production systems, and its scope is authority-validated ³⁷. Testers meet five conditions; an internal tester needs prior approval and an external threat intelligence provider ³⁸.

• Input: the function map; the testing calendar.
• Activity: derive coverage from the function map, not the asset list; record the rationale; queue findings with audit findings.
• Output: testing programme with per-function coverage, and a findings record.
• Owner: the testing owner; the control function validates independence.

3.8 Third-party risk, from strategy to contract#

The entity stays fully responsible for compliance whatever it contracts out. Above the Article 16(1) entities and microenterprises, it adopts and reviews a strategy on ICT third-party risk, including a policy on ICT services behind critical or important functions. The management body reviews the risks in those arrangements ³⁹.

Delegated Regulation (EU) 2024/1773 sets what the policy contains, by article title. Five come first: Group application, Governance arrangements, Main phases of the life cycle for the adoption and use of contractual arrangements, Ex-ante risk assessment, and Due diligence. Four follow: Conflicts of interest, Contractual clauses, Monitoring of the contractual arrangements, and Exit from and termination of the contractual arrangements. Its lifecycle article names record-keeping as a phase, pointing at Article 28(3) ⁴⁰.

Before signing, five things are assessed. Whether the arrangement covers a critical or important function, whether supervisory conditions are met, all relevant risks including concentration, provider due diligence, and conflicts of interest ⁴¹. For services behind critical or important functions, concentration risk has two pre-contract tests. One is a provider that is not easily substitutable; the other is multiple critical arrangements with the same or closely connected providers ⁴².

Article 30 sets the contract. Paragraph 2 lists nine elements every arrangement carries, at points (a) to (i). They run from the service description and the service and data locations through data protection, access and return of data, service levels and incident assistance to termination rights. Paragraph 3 adds six for critical or important functions, at points (a) to (f). They cover quantitative service targets, notice and reporting duties, contingency and security requirements, participation in threat-led testing, and unrestricted access, inspection and audit rights. Exit strategies with a transition period close the list ⁴³. Article 28(8) requires them separately, tested and periodically reviewed ⁴⁴.

Subcontracting has its own instrument. The entity decides before signing whether subcontracting of a critical or important function is permitted, and may proceed only where ten conditions hold, at points (a) to (j). The contract then names which services are eligible, and on what terms, in twelve specified points ⁴⁵.

• Input: the contract inventory; the due-diligence file.
• Activity: run the Article 28(4) assessment before signature; check each contract against the Article 30(2) and 30(3) lists; settle subcontracting in writing.
• Output: third-party policy, a pre-contract assessment per arrangement, exit plans, and a contract compliance matrix.
• Owner: the third-party monitoring role; procurement and legal execute.

3.9 Build and maintain the register of information#

The register is maintained and updated at entity, sub-consolidated and consolidated levels, for all arrangements on the use of ICT services from third-party providers, with those covering critical or important functions distinguished. Three duties attach. The entity reports at least yearly to its competent authority on new arrangements, provider categories, arrangement types, and the services and functions provided. It makes the full register, or specified sections, available on request. It gives advance notice of any planned arrangement covering a critical or important function, and of a function becoming one ¹.

Implementing Regulation (EU) 2024/2956 sets the shape: Annex I holds fifteen templates, codes and titles printed ⁴⁶.

Template	Title as printed	Holds
B_01.01	Entity maintaining the register of information	Register keeper
B_01.02	List of entities within the scope of consolidation	Group entities
B_01.03	List of branches	Their branches
B_02.01	Contractual arrangements – general information	One row per arrangement
B_02.02	Contractual arrangements – specific information	Services and terms
B_02.03	List of intra-group contractual arrangements	Intra-group links
B_03.01	Entities signing the contractual arrangements for receiving ICT service(s) or on behalf of the entities making use of the ICT service(s)	Receiving signatory
B_03.02	ICT third-party service providers signing the contractual arrangements for providing ICT service(s)	Providing signatory
B_03.03	Entities signing the contractual arrangements for providing ICT service(s) to other entities within the scope of consolidation	Internal providers
B_04.01	Entities making use of the ICT services	Service consumers
B_05.01	ICT third-party service providers	Providers, parents
B_05.02	ICT service supply chain	Chain members, ranked
B_06.01	Functions identification	Functions, criticality
B_07.01	Assessments of the ICT services	Substitutability, exit
B_99.01	Definitions from entities making use of the ICT Services	Option meanings

Four rules separate a register from a spreadsheet. Every provider that is a legal person is identified by a valid and active LEI or EUID, and by both where available; an individual acting in a business capacity is the exception. The register covers all services from direct providers, plus all subcontractors that effectively underpin critical or important functions. The data meets six quality principles: accuracy, completeness, consistency, integrity, uniformity and validity. Each template has fixed columns and one value per data element, so a second valid value needs a second row ⁴⁷. Many columns are closed sets. Service types use a closed list, S01 to S19, and B_99.01 records what each option means inside the organisation ⁴⁸.

• Input: the function map; the assessments from 3.8; an LEI or EUID per provider.
• Activity: fill the function template first, then arrangements, providers and the supply chain, resolving closed-option values first. The Register of information starter mirrors this structure.
• Output: register of information per level, plus the yearly report.
• Owner: the third-party monitoring role; owners confirm their rows.

3.10 Keep it alive#

Five triggers cover most movement, each naming the artefact it reopens.

• The yearly framework review, plus any major incident or supervisory instruction ⁴. Reopens the framework set.

• The yearly classification review ⁴⁹. Reopens the function map and B_06.01.

• The testing calendar: yearly tests, threat-led testing every three years ⁵⁰. Reopens the testing programme.

• A new or changed arrangement, notified in advance where a critical or important function is covered ¹. Reopens the register.

• A subcontracting change, material ones having their own regime ⁵¹; and register maintenance, reviewed regularly with errors corrected promptly ⁵². Reopens the supply chain and register.

• Input: the triggers, each with a date or event.

• Activity: hold the review even when nothing moved, and record it.

• Output: change-trigger register, with a dated record per trigger.

• Owner: the ICT risk control function.

4. Deliverables#

Seven artefacts carry the method; one template ships.

Deliverable	Format	Template	Retention
Scope and proportionality memo	document	template pending	current, plus superseded
Framework set, with policy index	document set	template pending	life of the framework
Function map, with criticality	register	template pending	current, plus history
Classification procedure and report pack	procedure, forms	template pending	per the record-keeping rule
Testing programme, per-function coverage	plan, results	template pending	one three-year cycle
Third-party policy, exit strategies, assessments	document set	template pending	life of the arrangement
Register of information	spreadsheet	/templates/register-of-information	every reported version

The training record sits alongside them, kept per member ⁵³.

5. What the supervisor will ask#

Each question is answered by a named artefact.

6. Failure modes and how they surface as findings#

Four patterns account for most avoidable damage.

7. Mapping to the technical standards#

Each row carries its citation. The technical-standard column was read at the EU Publications Office ⁵⁴. Clause titles come from the ISO Online Browsing Platform listing ⁵⁵. Rows with no logged title say "at clause level".

DORA article	Technical standard	ISO/IEC 27001:2022	Evidence	Verified
Art. 5(2), 5(4) and 13(6), governance and training	2024/1774 Art. 2(2)(b)	Clause 5.1 Leadership and commitment; 7.2 Competence	Approval, training records	56
Art. 6(2), 6(5) and 6(6), framework, review, audit	2024/1774 Articles 4 to 22 and Art. 27	Clause 6.1.3 Information security risk treatment; 9.3.3 Management review results	Policy index, review record	57
Art. 8(1) and 11(6), identification and continuity	2024/1774 Articles 4, 5 and 24 to 26	Clause 6.1.2 Information security risk assessment	Function map, test records	58
Art. 17(3) and 18(1), incidents	2024/1774 Art. 22; 2024/1772 Art. 8 and Art. 9	Clause 10.2 Nonconformity and corrective action	Worksheet, incident record	59
Art. 19(4) and 24(6), reporting and testing	2025/301 Art. 5; 2025/302 Annex I	Clause 9.1 Monitoring, measurement, analysis and evaluation	Submissions, coverage	60
Art. 28(2), 28(4) and 28(8), third-party risk	2024/1773 Articles 2 to 10	At clause level	Policy, assessment, exit plan	61
Art. 28(3), the register	2024/2956 Annex I	Clause 7.5.3 Control of documented information	Register, yearly report	1
Art. 30(2)(a), subcontracting terms	2025/532 Art. 3 and Art. 4, made under Art. 30(5)	At clause level	Compliance matrix	62

8. Checklist#

Each item is observable, as a dated record.

• The scope memo answers the Article 16 question either way, cited.
• Every Article 5(2) duty maps to an agenda item with a dated approval.
• Management-body training is recorded per member.
• The framework review record carries a date, even where nothing moved.
• The function map predates the register, and each function carries a criticality decision.
• Every incident carries a classification worksheet, and the four-hour path was rehearsed.
• Test coverage derives from the function map, with a written rationale.
• Every arrangement has a pre-contract assessment dated before signature.
• Each critical arrangement has an exit plan exercised in the last year.
• Every provider that is a legal person carries a valid LEI or EUID, subcontractors included.

Dates#

The Regulation entered into force on the twentieth day after its publication in the Official Journal, and applies from 17 January 2025 ⁶³. The radar entry records the same date ⁶⁴. Each technical standard cited states the same twentieth-day rule in its own final article ⁶⁵. No other date appears in the texts read.

References#

Primary sources, read at the EU Publications Office.

1. Regulation (EU) 2022/2554 (DORA). https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng ⁶⁶
2. Commission Delegated Regulation (EU) 2024/1772. https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng ⁶⁷
3. Commission Delegated Regulation (EU) 2024/1773. https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng ⁶⁸
4. Commission Delegated Regulation (EU) 2024/1774. https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng ⁶⁹
5. Commission Implementing Regulation (EU) 2024/2956. https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj/eng ⁷⁰
6. Commission Delegated Regulation (EU) 2025/301. https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng ⁷¹
7. Commission Implementing Regulation (EU) 2025/302. https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng ⁷²
8. Commission Delegated Regulation (EU) 2025/532. https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng ⁷³
9. ISO/IEC. Information security management systems — Requirements. ISO/IEC 27001:2022. https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-3:v1:en ⁵⁵

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication and is not affiliated with, authorized, sponsored or endorsed by ISO, IEC or any other standards body.