# EBA Guidelines on ICT and Security Risk Management After DORA

Source: https://www.cyadviso.com/ebas-guidelines-on-ict-and-security-risk-management
Last reviewed: 2026-04-29
Tags: DORA, ICT Risk

How EBA/GL/2019/04 fits with DORA in 2026: narrowed scope, audit use, ICT risk evidence, governance, outsourcing and payment-services security obligations.

---

**Last reviewed: 29 April 2026**

**Key takeaways**

- The EBA ICT and security risk guidelines remain useful context, but DORA is now the primary operational-resilience framework for in-scope entities.
- The practical task is to preserve useful controls while updating legal basis, evidence and review cadence.
- Supervisors and partners ask whether old ICT-risk material reflects current DORA obligations.
- Fastest path: inventory old controls -> map to DORA -> remove stale wording -> keep evidence current.

The EBA Guidelines on ICT and security risk management were an important pre-DORA baseline for banks, payment institutions and other EBA-supervised financial institutions. In 2026 they should no longer be read as if DORA did not exist.

DORA has applied since 17 January 2025 and now provides the harmonised ICT risk management framework for financial entities in scope. The European Banking Authority amended its Guidelines on ICT and security risk management through EBA/GL/2025/02, applicable from 20 May 2025, to narrow their scope in the context of DORA.

That does not make the EBA Guidelines irrelevant. It changes how they should be used.

For an EU fintech, bank, payment institution or EMI, the practical question is:

> Are the EBA Guidelines still a live obligation for this entity or activity, or are they better used as historical supervisory context and audit mapping for a DORA control framework?

## Short answer for 2026

| Question | Practical answer |
| --- | --- |
| Are the EBA Guidelines still important? | Yes, but their role changed after DORA. They remain relevant for residual scope and as supervisory context. |
| Did DORA replace all ICT expectations? | No. DORA harmonises ICT risk management for in-scope financial entities, while PSD2, CRD, outsourcing and national supervisory expectations may still matter. |
| Should a DORA programme copy EBA/GL/2019/04 line by line? | No. Use DORA and its technical standards as the primary framework, then map EBA guidance where it remains relevant. |
| Are the Guidelines useful in audits? | Yes. They help explain the lineage of governance, ICT operations, security, outsourcing and payment security controls. |
| What changed in 2025? | EBA/GL/2025/02 amended EBA/GL/2019/04 and narrowed the scope in the context of DORA application. |
| What should firms do now? | Maintain a DORA-led evidence model and keep an EBA-to-DORA mapping for legacy policies and audit questions. |

## What the EBA Guidelines are

The EBA Guidelines on ICT and security risk management (EBA/GL/2019/04) were published in 2019 and applied from 30 June 2020. They were built on the EBA's mandates under CRD and PSD2 and were intended to create a consistent supervisory approach to ICT and security risk management.

They covered areas that are now familiar to anyone working on DORA:

- governance and management body responsibilities;
- ICT risk identification, assessment and mitigation;
- information security;
- ICT operations management;
- ICT project and change management;
- business continuity management;
- payment services user relationship management;
- outsourcing and third-party dependency controls;
- internal control, audit and assurance.

Before DORA, many EU financial institutions used the EBA Guidelines as the main supervisory baseline for ICT risk and security controls. DORA then created a directly applicable EU regulation with a wider and more harmonised operational resilience framework.

## What changed after DORA

DORA changed the legal hierarchy for ICT risk in the financial sector. It moved many ICT risk expectations from guideline-based supervisory practice into a regulation that applies directly to in-scope financial entities.

The EBA narrowed the scope of its existing Guidelines because DORA introduced harmonised ICT risk management requirements from 17 January 2025. EBA/GL/2025/02 amends EBA/GL/2019/04 and is applicable from 20 May 2025.

That point matters for content accuracy. A 2026 article should not imply that EBA/GL/2019/04 is the primary ICT risk framework for every financial entity in the same way it was before DORA.

| Before DORA | After DORA |
| --- | --- |
| EBA Guidelines were a central ICT risk baseline for many EBA-regulated firms | DORA is the primary harmonised ICT resilience framework for in-scope financial entities |
| Outsourcing and ICT controls were often mapped through EBA Guidelines and local supervisory expectations | ICT third-party risk is directly addressed by DORA Articles 28-30 and related technical standards |
| Incident and security requirements were split across PSD2, EBA guidance and national rules | Major ICT-related incident reporting is handled under DORA technical standards for in-scope entities |
| Audit evidence often referenced the EBA Guidelines directly | Audit evidence should reference DORA first, then EBA Guidelines where relevant |
| Payment security controls relied heavily on PSD2 / EBA security-risk guidance | Payment security remains relevant, but ICT resilience evidence should be DORA-led where the entity is in scope |

## What remains live and what becomes context

The safest implementation stance is not “EBA Guidelines are gone”. It is to classify each control area.

| Area | 2026 role of EBA Guidelines | Primary operating framework |
|---|---|---|
| ICT risk governance for DORA in-scope entity | Supervisory context and legacy mapping | DORA Article 5-6 and ICT risk RTS |
| Information security controls | Useful control language and audit lineage | DORA ICT risk management framework |
| ICT operations and change management | Useful operating baseline | DORA framework, testing and control evidence |
| Major ICT incident reporting | Historical context only for in-scope entities | DORA Article 19 and reporting technical standards |
| Payment security under PSD2 | Still relevant where PSD2 Article 95 security-risk logic applies | PSD2 / payment-services law plus DORA for ICT resilience |
| Outsourcing arrangements outside DORA ICT third-party scope | Still useful with EBA outsourcing guidance | Outsourcing guidance / local law, plus DORA where ICT services are in scope |
| Internal audit and assurance | Useful for audit design and control lineage | DORA evidence model and internal control framework |

For payment institutions and EMIs, this classification matters because payment security and DORA ICT resilience overlap but are not identical.

## How EBA Guidelines and DORA fit together

DORA did not appear in a vacuum. It builds on a supervisory tradition that included the EBA Guidelines, the EBA Guidelines on outsourcing arrangements, PSD2 operational and security risk expectations, SREP ICT risk assessment work and national supervisory practice.

For implementation teams, the EBA Guidelines are useful in four ways:

1. They provide historical context for why supervisors expect board-level ICT risk ownership.
2. They help interpret control areas that also appear in DORA.
3. They support gap analysis where existing policies were written before DORA and need remapping.
4. They help internal audit understand which legacy controls were absorbed into a DORA-led operating model.

| Control area | EBA Guidelines baseline | DORA 2026 framing |
| --- | --- | --- |
| Governance | Management body oversight, internal control and clear responsibilities | Article 5 governance and control framework for ICT risk |
| ICT risk management | Identify, assess, monitor and mitigate ICT and security risk | Chapter II ICT risk management framework |
| Information security | Logical security, access control, data protection and monitoring | Protection and prevention controls under DORA and ICT risk RTS |
| ICT operations | Operations management, capacity, logging and monitoring | Resilient ICT systems, continuous monitoring and control evidence |
| Change management | Project, acquisition and change controls | Change controls as part of ICT risk management and testing evidence |
| Business continuity | Continuity plans, disaster recovery and testing | DORA Articles 11-12 and operational resilience testing |
| Third-party risk | Outsourcing due diligence, contracts and monitoring | DORA ICT third-party risk management and Register of Information |
| Internal audit | Independent review of ICT and security risk management | Board assurance and audit evidence for DORA operating model |

## What should be primary in 2026

For a DORA in-scope financial entity, the primary reference should be DORA and the relevant regulatory and implementing technical standards. The EBA Guidelines can remain in the legal and control mapping, but they should not override DORA terminology, reporting channels or required artefacts.

| Topic | Use as primary source | Use EBA Guidelines for |
| --- | --- | --- |
| ICT risk management framework | DORA Article 6 and ICT risk management RTS | Control lineage and legacy policy mapping |
| Management body responsibility | DORA Article 5 | Governance language and supervisory context |
| Major ICT incident reporting | DORA Article 19 and reporting technical standards | Historical PSD2/security-risk context only |
| Digital operational resilience testing | DORA Articles 24-27 | Existing assurance and testing practices |
| ICT third-party risk | DORA Articles 28-30, Register of Information ITS | Outsourcing baseline and contract governance history |
| Payment security | PSD2 / PSD3-PSR context plus DORA for ICT resilience | PSD2-related operational and security-risk context |
| Internal audit | DORA operating evidence and board assurance | Audit universe and control-history mapping |

## What a fintech should do with old EBA-based policies

Many fintechs still have ICT risk, outsourcing or security policies written around the EBA Guidelines. That is not automatically a problem. The problem is leaving those policies unmapped after DORA.

The clean approach is to keep useful content, but update the legal basis and evidence model.

| Legacy policy section | 2026 action |
| --- | --- |
| "EBA ICT Guidelines" as the main authority | Replace with DORA as the primary authority where the entity is in DORA scope |
| Generic ICT risk assessment | Map to DORA ICT risk framework, asset inventory, classification and control monitoring |
| Outsourcing due diligence | Expand to DORA ICT third-party risk, critical or important functions and Register of Information fields |
| Incident escalation | Replace generic security incident language with DORA major ICT-related incident classification and reporting logic |
| Business continuity | Map to DORA BCP, disaster recovery, backup and restoration evidence |
| Audit and testing | Connect to DORA resilience testing and management body reporting |
| Payment security controls | Keep PSD2/payment-service logic, but connect ICT systems to DORA evidence |
| Internal audit references | Add a DORA-led control map and note where EBA guidance remains contextual |

## EBA-to-DORA migration checklist

Use this checklist when reviewing old policies, audit files or control libraries.

| Step | Question | Output |
|---|---|---|
| 1. Confirm scope | Is the entity in DORA scope? Is any activity outside DORA but still under CRD/PSD2/EBA expectations? | Scope note |
| 2. Identify legacy references | Which policies cite EBA/GL/2019/04 as the main ICT authority? | Legacy reference list |
| 3. Map control areas | Which EBA control areas map to DORA governance, ICT risk, incidents, testing, BCDR and third-party risk? | EBA-to-DORA control map |
| 4. Update terminology | Are incident, supplier and testing terms aligned with DORA? | Updated policy language |
| 5. Replace weak evidence | Are controls supported by logs, registers, tests and board records? | Evidence gap tracker |
| 6. Preserve residual use | Where do PSD2, outsourcing or non-DORA contexts still require EBA references? | Residual EBA relevance note |
| 7. Approve and review | Has the management body or accountable owner approved the DORA-led model? | Decision record and review date |

This prevents two errors: deleting useful legacy controls or leaving outdated legal references in place.

## Evidence checklist for audit teams

If a reviewer asks how the EBA Guidelines are reflected after DORA, do not answer with a long policy list. Show a mapping.

| Evidence | What it should show |
| --- | --- |
| DORA-to-EBA control map | Which EBA control areas were absorbed into DORA controls and which remain separately relevant |
| Updated ICT risk policy | DORA is the primary framework for in-scope entities; EBA references are contextual or residual |
| Management body minutes | ICT risk ownership, risk appetite and resilience reporting are active, not only written |
| ICT risk register | Risks are classified, owned, treated and reviewed |
| Incident classification procedure | DORA reporting triggers are separated from general security event triage |
| Supplier due diligence file | EBA outsourcing history is mapped to DORA ICT third-party risk requirements |
| Register of Information | ICT service dependencies are recorded in the required DORA format |
| Internal audit plan | ICT risk and DORA operating controls are independently reviewed |
| Payment security evidence | PSD2 security-risk controls remain connected to payment services and ICT dependencies |
| Board reporting pack | Management body sees ICT risk, incidents, suppliers, tests and remediation decisions |

## Where the old article often becomes misleading

Older summaries of the EBA Guidelines usually say that the Guidelines apply to all EU financial institutions and provide the comprehensive ICT risk framework. That was closer to the practical picture before DORA. In 2026, the statement needs qualification.

A safer statement is:

> The EBA Guidelines on ICT and security risk management remain relevant supervisory material, but for DORA in-scope financial entities the primary ICT operational resilience framework is now DORA and its technical standards. The EBA amended and narrowed the scope of EBA/GL/2019/04 because of DORA application from 17 January 2025.

That wording avoids two mistakes: pretending the EBA Guidelines disappeared, and pretending DORA did not change their role.

## Practical operating model for fintech SMBs

For a fintech SMB, the operating model can stay simple:

1. Maintain DORA as the top-level ICT resilience framework.
2. Keep an evidence map showing how legacy EBA-based controls were migrated.
3. Use EBA Guidelines language where it supports governance, internal control, audit and PSD2/payment security context.
4. Avoid using EBA-based incident or outsourcing wording where DORA requires a specific artefact, template or classification.
5. Review local competent authority expectations, because supervisors may still reference EBA material in national guidance or audits.

| Operating layer | Lightweight implementation |
|---|---|
| Governance | One owner matrix, management-body review cadence and decision log |
| ICT risk | Risk register mapped to critical functions, systems and suppliers |
| Incidents | One DORA classification workflow with payment/security decision points where relevant |
| BCDR and testing | Annual service-chain test plus remediation tracker |
| Suppliers | Register of Information, criticality, contract gap tracker and exit assumptions |
| Audit mapping | EBA-to-DORA control map and evidence index |

This is enough for many smaller fintechs if evidence is current and ownership is clear.

## Common questions

### Are the EBA Guidelines repealed by DORA?

No simple universal answer should be used without checking the exact entity and activity. The EBA has amended and narrowed the scope of EBA/GL/2019/04 due to DORA. For in-scope DORA entities, DORA should be treated as the primary ICT operational resilience framework.

### What is EBA/GL/2025/02?

EBA/GL/2025/02 is the amendment to the EBA Guidelines on ICT and security risk management. It narrows the scope of EBA/GL/2019/04 in the context of DORA and is applicable from 20 May 2025.

### Can we use our old EBA ICT policy for DORA?

Only as a starting point. The policy should be remapped to DORA Articles, technical standards, Register of Information requirements, incident reporting logic and resilience testing expectations.

### Are the EBA Guidelines still useful for payment institutions?

Yes, especially as PSD2 and supervisory context for operational and security risks related to payment services. But if the payment institution is in DORA scope, the DORA framework should drive current ICT resilience evidence.

### Should auditors ask for an EBA-to-DORA mapping?

Yes. A mapping is often more useful than a rewritten policy because it shows what changed, what stayed and which control owners maintain the evidence.

### What is the main risk in 2026?

The main risk is regulatory layering without ownership: old EBA policy language, new DORA obligations, legacy outsourcing files and no clear evidence model. Supervisors and auditors will look for an operating control framework, not just citations.

## Bottom line

The EBA Guidelines on ICT and security risk management still matter, but their 2026 role is different.

For DORA in-scope financial entities, they are not the lead framework. DORA is. The Guidelines are best used as supervisory context, legacy-control mapping and audit support, especially for governance, ICT operations, security controls, outsourcing and payment-security history.

The practical work is to convert old EBA-based policies into a DORA-led evidence model: management body ownership, ICT risk register, incident classification, supplier oversight, Register of Information, testing records and audit trail.

## Related reading

- [DORA Compliance Checklist 2026: Practical Implementation Guide](/dora-compliance-guide)
- [DORA Requirements in 2026: Operating Controls and Evidence Checklist](/dora-requirements-2025)
- [DORA ICT Risk Register Template](/dora-compliant-ict-risk-register)
- [DORA Incident Reporting 2026](/dora-incident-reporting)
- [DORA Register of Information](/dora-register-of-information)
- [DORA vs PSD2/PSD3](/dora-vs-psd2-psd3)
- [DORA Board Responsibilities 2026](/dora-board-responsibilities-2025-eu-financial-checklist)

## Primary sources

- [EBA — Guidelines on ICT and security risk management](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-ict-and-security-risk-management)
- [EBA — amendment of ICT and security risk management Guidelines in the context of DORA](https://www.eba.europa.eu/publications-and-media/press-releases/eba-amends-its-guidelines-ict-and-security-risk-management-measures-context-dora-application)
- [EBA — Final report on amending Guidelines EBA/GL/2019/04, EBA/GL/2025/02](https://www.eba.europa.eu/sites/default/files/2025-02/23684f95-f669-4852-94a0-dac6c2ae67ad/Final%20report%20on%20amending%20GLs%20on%20ICT%20risk%20and%20security.pdf)
- [EBA — Guidelines on outsourcing arrangements](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-outsourcing-arrangements)
- [Regulation (EU) 2022/2554 — DORA, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554)
- [EBA — Regulatory Technical Standards on the ICT risk management framework](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/regulatory-technical-0?version=2024)

---

Authored by Andrey Gubarev — CISO for EU fintechs (CISM, CDPSE, SABSA).
CyAdviso · DORA / ICT risk / vCISO programmes for EU-licensed fintechs.
Canonical HTML: https://www.cyadviso.com/ebas-guidelines-on-ict-and-security-risk-management