Commission Delegated Regulation (EU) 2024/1774 and Related DORA Secondary Legislation: An Advanced Deep Dive

Proportionality

Requirements regarding ICT security policies, procedures, protocols and tools, and the simplified framework, should be proportionate to the entity's size, structure, internal organisation, nature and complexity, and corresponding risks.

Documentation flexibility

Financial entities should be allowed to use documentation they already have to comply with documentation requirements flowing from the requirements.

Segregation of duties

Financial entities should ensure segregation of duties when assigning ICT roles and responsibilities, to limit conflicts of interest.

Two-pronged encryption process

Data classification plus a comprehensive ICT risk assessment informs encryption at rest, in transit, or, where necessary, in use.

Production separation

The recital identifies strict separation of production from development, testing, and other non-production environments; production testing is described only for exceptional, justified, approved circumstances.

Incident detection and personal data

Entities should use different information sources and, where information is personal data, it should be limited to what is necessary for incident detection.

Article 1 proportionality principle

When developing and implementing the stated controls, the entity's size, overall risk profile, and the nature, scale, and increased or reduced complexity of its services, activities, and operations shall be taken into account.

Accepted residual-risk inventory

Article 3 requires the development of an inventory of accepted residual ICT risks, including a justification for their acceptance.

Residual-risk review frequency

Accepted residual ICT risks shall be reviewed at least once a year, including changed risks, available mitigations, and whether acceptance reasons remain valid and applicable.

Asset lifecycle

The asset-management policy shall prescribe monitoring and management of the lifecycle of ICT assets identified and classified in accordance with Article 8(1) of Regulation (EU) 2022/2554.

Encryption fallback for data in use

Where encryption of data in use is not possible, data shall be processed in a separated and protected environment, or equivalent measures shall be taken.

Cryptographic key lifecycle

It includes generating, renewing, storing, backing up, archiving, retrieving, transmitting, retiring, revoking, and destroying cryptographic keys.

Network segmentation

Article 13 requires "the segregation and segmentation of ICT systems and networks" taking account of supported-function criticality or importance, Article 8(1) classification, and the ICT assets' overall risk profile.

Firewall review for critical systems

For ICT systems supporting critical or important functions, adequacy of existing firewall rules and connection filters shall be verified at least every 6 months.

Network architecture review

Article 13 requires reviews of network architecture and network-security design once a year, and periodically for microenterprises, to identify potential vulnerabilities.

Testing proportionality

"The level of testing shall be commensurate to the criticality of the business procedures and ICT assets concerned."

Non-production data default

"non-production environments only store anonymised, pseudonymised, or randomised production data". Production data are permitted only under the Article 16(6) derogation and its conditions.

Change-function independence

Article 17 requires mechanisms ensuring independence between functions approving changes and functions requesting and implementing them.

Article 22 evidence retention

Financial entities shall "retain all evidence relating to ICT-related incidents for a period that shall be no longer than necessary for the purposes for which the data are collected" and retain that evidence securely.

Article 23 automated alerts

Tools shall contain tools that provide automated alerts based on pre-defined rules to identify anomalies affecting completeness and integrity of data sources or log collection.

Article 23 escalation

Consider malicious activity or compromise indications, data loss, adverse transaction or operational impact, and ICT system or network unavailability. Also consider the criticality of affected services.

Article 24 recovery objectives

The policy must specify that critical or important functions can be recovered after disruption within a recovery time objective and a recovery point objective.

Article 25 scenario standard

Testing shall be performed using scenarios that simulate potential disruptions, including an adequate set of severe but plausible scenarios.

Article 26 alternatives

Where primary recovery measures may not be feasible in the short term because of costs, risks, logistics, or unforeseen circumstances, plans shall consider alternative options.

Article 28 governance objective

"an internal governance and control framework that ensures an effective and prudent management of ICT risk to achieve a high level of digital operational resilience."

Annual budget obligation

"allocates and reviews at least once a year the budget necessary to fulfil the financial entity’s digital operational resilience needs"

Access-control basis

"access rights to information assets, ICT assets, and their supported functions, and to critical locations of operation of the financial entity, are managed on a need-to-know, need-to-use and least privileges basis"

Operational vulnerability control

"perform automated vulnerability scanning and assessments of ICT assets commensurate to their classification"

Data-protection states

"the identification and implementation of measures to protect data in use, in transit, and at rest"

Controlled change requirement

"all changes to ICT systems are recorded, tested, assessed, approved, implemented, and verified in a controlled manner"

Affected clients under Article 1(1)

All affected natural or legal-person clients who were unable to use the service during the incident or were adversely impacted, plus explicitly covered contractual beneficiaries.

Affected transactions under Article 1(4)

All affected transactions involving a monetary amount where at least one part of the transaction is carried out in the Union.

Unknown affected figures under Article 1(5)

The financial entity shall estimate numbers or amounts based on available data from comparable reference periods.

Reputational impact under Article 2(1)

It has occurred where at least one listed criterion is met: media reflection, repetitive complaints, actual or likely regulatory non-compliance, or actual or likely material loss of clients or counterparts.

Incident duration under Article 3(1)

From when the incident occurs until it is resolved, subject to the specified detection, log-record, and estimation rules.

Service downtime under Article 3(2)

From full or partial unavailability until restoration to the pre-incident level of service; where a delay remains, until the delayed service is fully provided.

Article 8 major-incident rule

Critical services under Article 6 must be affected, and either Article 9(5)(b) is met or two or more other Article 9 thresholds are met.

Recurring incidents

They must occur at least twice within 6 months, have the same apparent root cause, and collectively meet Article 8(1). Assessment is monthly, subject to the stated exclusions.

Article 9 client percentage

The threshold is met where affected clients are higher than 10% of all clients using the affected service.

Duration and downtime

Duration longer than 24 hours, or downtime longer than 2 hours for ICT services supporting critical or important functions.

Economic impact

Included incident costs and losses are summed without accounting for financial recoveries. The threshold is exceeded or likely exceeded at EUR 100,000.

Significant cyber threat

All Article 10 conditions are required: potential impact, high probability of materialisation, and potential to meet the specified criticality or materiality consequence.

Annual review

Article 3(1): The management body shall review the policy at least once a year and update it where necessary.

Classification methodology

Article 3(2): The policy shall establish or refer to a methodology for determining which ICT services support critical or important functions, and specify when assessment and review occur.

Internal responsibilities

Article 3(3): The policy shall clearly assign responsibilities for approval, management, control, and documentation of relevant contractual arrangements.

Reporting lines

Article 3(5): The policy shall identify the responsible role or senior-management member and set out reporting lines, information, documents, and frequency.

Independent review

Article 3(7): ICT services supporting critical or important functions provided by ICT third party service providers shall be subject to independent review and included in the audit plan.

Article 5 timing

Business needs must be defined, and the required risk assessment must be conducted, before a contractual arrangement is concluded.

Article 6 assurance

Financial entities shall ensure an appropriate level of assurance on the provider's performance. Where appropriate, more than one assurance element shall be used.

Article 7 intragroup rule

For ICT intra-group service providers, decisions on conditions, including financial conditions, are to be taken objectively.

Article 8 long-term reliance rule

The financial entity shall not over time rely solely on specified third-party certifications or provider-made-available audit reports.

Article 9 remediation

Measures addressing shortcomings must be monitored so that they are effectively complied with within a defined timeframe, taking account of materiality.

Article 10 exit-plan standard

The exit plan shall be realistic, feasible, based on plausible scenarios and reasonable assumptions, with a schedule compatible with contractual exit and termination terms.

Article 1

Applies general information to initial notifications, intermediate reports, and final reports, including entity identity, LEI code, submitter, contacts, and conditional aggregation, group, and currency details.

Initial notification deadline

As early as possible and, in any event, within four hours from classification as major and no later than 24 hours from awareness of the ICT-related incident.

Intermediate report deadline

At the latest within 72 hours from submission of the initial notification, even if the status or handling of the incident has not changed.

Updated intermediate report

Submit without undue delay and, in any case, when regular activities have been recovered.

Final report deadline

No later than one month after the intermediate report or, where applicable, the latest updated intermediate report.

Delay notice

Inform the competent authority without undue delay, no later than the relevant reporting deadline, and explain the reasons for the delay.

When must the financial entity decide whether subcontracting is permitted?

Before entering into the contractual arrangement with the ICT third-party service provider, under Article 3(1).

Who must identify all relevant subcontractors and notify the financial entity?

The ICT third-party service provider, under Article 3(1)(b).

What rights must the subcontractor grant under Article 3(1)(d)?

The same contractual rights of access and inspection as those granted by the ICT third-party service provider to the financial entity and competent and resolution authorities.

Which Article 3 risks are periodically reassessed?

The risk assessment in Article 3(1)(f) to (j), against possible changes in the business environment.

Can a financial entity transfer its final DORA responsibility by relying on its provider's assessment?

No. Article 3(3) states that reliance on the provider's risk assessment shall not limit the financial entity's final responsibility.