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.

What is Residual ICT risk?

The related ICT risk that Article 27 requires the report to evaluate, and for which it requires explanation of acceptance criteria when identified weaknesses, deficiencies, or gaps are not subject to corrective measures.

What is Anomalous activity?

An activity or behaviour detected through the Article 23 mechanism and recorded with its occurrence time, detection time, and type.

What is Recovery time objective?

The recovery-time target within which Article 24 requires the financial entity to be able to recover operations of critical or important functions after disruption.

Regulation 2024/1774: Incident Response, Business Continuity, and Framework Review Reports — Commission Delegated Regulation (EU) 2024/1774 and Related DORA Secondary Legislation: An Advanced Deep Dive

1. The Response Arc: From Anomaly to Governance Evidence

One connected operating cycle

Chapters III to V connect detection, incident response, business continuity, recovery, and framework review reporting. The same disruption can therefore create operational, continuity, and governance evidence.

Read the provisions in sequence

Article 22 addresses policy and evidence; Article 23 addresses anomaly detection and escalation criteria; Articles 24 to 26 address continuity and recovery; Article 27 addresses the searchable review report.

Why this matters

Think of a monitoring alert becoming an incident, a continuity-plan activation, a recovery exercise, and later a report finding. The Regulation requires controls across that full chain rather than only at one point.

2. Article 22: Build the Incident Management Policy

Policy is mandatory

Article 22 says financial entities shall develop, document, and implement an ICT-related incident policy. It must document the incident-management process referred to in Article 17 of Regulation (EU) 2022/2554.

Contacts and operational support

The policy shall identify relevant internal and external contacts involved in ICT operations security, including cyber-threat monitoring, anomalous-activity detection, and vulnerability management.

Evidence and patterns

Evidence must be retained securely and no longer than necessary for the collection purpose, with criticality considered. The policy must also analyse significant or recurring incidents and patterns in their number and occurrence.

Current cross-reference

External currency note: the May 15, 2025 in-force corrigendum changed Article 22(d)'s reference from Article 15 to Article 8(2) of Commission Delegated Regulation (EU) 2024/1772.

3. Article 23(1)-(4): Detect, Alert, Protect, and Log

Clear ownership

Article 23(1) requires clear roles and responsibilities for effective detection and response. A monitoring team, business function, security function, and incident decision-maker need defined responsibilities rather than informal assumptions.

Inputs to detection

The mechanism must draw on logs, business and ICT information, user reports, threat intelligence, threat-actor scenarios, and relevant incident notifications from ICT third-party service providers.

Alerts must be usable

At least for assets supporting critical or important functions, tools must identify anomalies and generate alerts. Alerts must be prioritised for management within entity-specified resolution time, including outside working hours.

Integrity of records

Anomaly records require protection against tampering and unauthorised access at rest, in transit, and where relevant in use. Each detected anomaly needs occurrence time, detection time, and anomaly type.

4. Article 23(5)-(6): When Does an Anomaly Trigger Response?

Criteria are an escalation assessment

Article 23(5) requires consideration of four triggers: malicious activity or compromise indications, data loss, adverse operational or transaction impact, and ICT system or network unavailability.

Criticality changes the assessment

The financial entity must also consider the criticality of affected services. The Regulation therefore connects the technical anomaly to the business significance of the service it supports.

Worked example

Missing payment-system logs plus unusual privileged-account attempts may indicate compromise. The entity records and protects the anomaly, considers every Article 23(5) criterion, and considers the payment service's criticality.

5. Quiz: Anomaly Records and Escalation

Choose the answer that accurately reflects Article 23.

Which statement is required for every detected anomalous activity under Article 23(4)?

Log the occurrence date and time, detection date and time, and type of anomalous activity.
Log only the identity of the employee who first saw the alert.
Delete records after the anomaly is determined not to be malicious.
Escalate every anomaly automatically as a major ICT-related incident.

Show Answer

Answer: A) Log the occurrence date and time, detection date and time, and type of anomalous activity.

Article 23(4) requires logging information enabling identification of the occurrence date and time, detection date and time, and type of anomalous activity. It does not require automatic major-incident classification.

6. Article 24: What the ICT Business Continuity Policy Must Contain

Describe boundaries and activation

The policy must describe objectives, ICT's interrelation with overall continuity, scope, limitations, exclusions, timeframe, and criteria to activate or deactivate continuity, response and recovery, and crisis-communication plans.

Governance and alignment

It must set governance, roles, responsibilities, escalation procedures, and resources. ICT continuity plans must align with overall plans on failure scenarios and recovery objectives.

Two recovery objectives

The policy must specify the entity's ability to recover critical or important functions after disruptions within both a recovery time objective and a recovery point objective.

Plan, test, review, communicate

Article 24 also requires severe-disruption planning, risk-based action prioritisation, development and testing of response and recovery plans, effectiveness review, and alignment with required communication arrangements.

7. Article 24(2)-(4): Sector-Specific Continuity Outcomes

Central counterparties

A central counterparty needs a maximum recovery time for critical functions of no longer than 2 hours, continuity arrangements for disaster scenarios, and processing and business-site arrangements specified by Article 24(2).

Distinct geography matters

For a central counterparty, the secondary processing site must have a geographical risk profile distinct from the primary site's. The arrangements also address people, maximum downtime, failover, and recovery.

Depositories and trading venues

A central securities depository has a recovery time objective no longer than 2 hours. A trading venue must enable trading to resume within or close to 2 hours and keep possible IT-service data loss close to zero.

8. Article 25: Test Continuity Plans Against Severe but Plausible Disruption

Test the ability to continue

Testing assesses whether continuity of critical or important functions can be ensured. It must account for the BIA and ICT risk assessment, and it must always include scenarios used to develop continuity plans.

Severe but plausible

Tests must simulate potential disruption using an adequate set of severe but plausible scenarios. They must challenge plan assumptions, including governance arrangements and crisis communication plans.

Third parties and switchover

Where applicable, test ICT third-party services. Other than microenterprises must test switchover to redundant capacity, backups, and redundant facilities, verifying sustained operation and restoration.

Deficiencies reach the management body

Financial entities shall document test results. Any identified deficiencies shall be analysed, addressed, and reported to the management body.

9. Quiz: Continuity Testing

Select the most accurate description of the testing requirement.

Under Article 25, which item must be included in continuity-plan testing for financial entities other than microenterprises?

Only a tabletop exercise involving senior management.
Scenarios of switchover from primary ICT infrastructure to redundant capacity, backups, and redundant facilities.
A guarantee that no data can ever be lost.
Testing only after a real ICT-related incident has occurred.

Show Answer

Answer: B) Scenarios of switchover from primary ICT infrastructure to redundant capacity, backups, and redundant facilities.

Article 25(2)(c) requires, for financial entities other than microenterprises, scenarios of switchover from primary ICT infrastructure to redundant capacity, backups, and redundant facilities. The testing must also verify appropriate operation for a sufficient period and restoration of normal functioning.

10. Article 26: Response and Recovery Plans Need Realistic Alternatives

Plans must be executable

Response and recovery plans require activation and deactivation conditions, actions for availability, integrity, continuity, and recovery, emergency accessibility, short- and long-term options, and criteria for successful execution.

Scenarios use current learning

Plans must identify relevant severe-disruption and increased-likelihood scenarios. They must be based on current threat information and lessons learned from previous business disruptions.

The scenario set is broad

Required consideration covers cyber-attacks, third-party failure, premises and data-centre failure, communications failure, critical staff unavailability, insider attacks, instability, and power outages.

Alternatives and third-party continuity

If primary recovery is not feasible in the short term because of costs, risks, logistics, or unforeseen circumstances, alternatives shall be considered. Continuity measures for relevant ICT third-party failures shall be considered and implemented.

11. Article 27: The Searchable Framework-Review Report

Format and context

Article 27 requires submission in a searchable electronic format. The report must identify the entity and provide operational context, including critical functions, dependencies, projects, and loss or degradation implications.

Executive-level view

The report must summarize the current and near-term ICT risk profile, threat landscape, assessed control effectiveness, and security posture. It also identifies the review reason, period, and responsible function.

Findings and corrective measures

Findings need severity analysis of weaknesses, deficiencies, and gaps. Remediation reporting includes progress, expected implementation dates, internal-control dates, responsible functions, tools, and resource impact.

Residual risk and incident-triggered reviews

If no corrective measure is planned, the report needs criteria for impact analysis, residual-risk evaluation, and residual-risk acceptance. If incidents triggered review, list all ICT-related incidents with root-cause analysis.

12. Flashcards: Key Obligations Across Articles 22-27

Flip each card, then explain the obligation aloud in your own words without weakening its qualifiers.

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 27 uncorrected weaknesses: The report needs detailed criteria to analyse impact, evaluate related residual ICT risk, and accept that residual risk where weaknesses, deficiencies, or gaps are not subject to corrective measures.

Key Terms

Residual ICT risk: The related ICT risk that Article 27 requires the report to evaluate, and for which it requires explanation of acceptance criteria when identified weaknesses, deficiencies, or gaps are not subject to corrective measures.
Anomalous activity: An activity or behaviour detected through the Article 23 mechanism and recorded with its occurrence time, detection time, and type.
Recovery time objective: The recovery-time target within which Article 24 requires the financial entity to be able to recover operations of critical or important functions after disruption.
Recovery point objective: The recovery-point target that Article 24 requires alongside the recovery time objective.
Searchable electronic format: The mandatory Article 27(1) format for submitting the report on the review of the ICT risk management framework.
Business impact analysis (BIA): The analysis whose results Article 24, Article 25, and Article 26 require financial entities to take into account in the specified continuity, testing, and recovery contexts.
Critical or important function: A function whose supporting ICT systems, services, information assets, and recovery needs receive specified attention throughout Articles 23 to 26.
Severe but plausible scenarios: The adequate set of disruption scenarios that Article 25(2)(a) requires continuity-plan testing to include.