EBA Guidelines on ICT and Security Risk Management After…

In this article ↓

Short answer for 2026
What the EBA Guidelines are
What changed after DORA
What remains live and what becomes context
How EBA Guidelines and DORA fit together
What should be primary in 2026
What a fintech should do with old EBA-based policies
EBA-to-DORA migration checklist
Evidence checklist for audit teams
Where the old article often becomes misleading
Practical operating model for fintech SMBs
Common questions
Are the EBA Guidelines repealed by DORA?
What is EBA/GL/2025/02?
Can we use our old EBA ICT policy for DORA?
Are the EBA Guidelines still useful for payment institutions?
Should auditors ask for an EBA-to-DORA mapping?
What is the main risk in 2026?
Bottom line
Related reading
Primary sources

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.

Still running on pre-DORA ICT risk material?

A 15-minute call can show what to preserve, what to remap and what evidence is now missing.

Book a free 15-min call →

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:

They provide historical context for why supervisors expect board-level ICT risk ownership.
They help interpret control areas that also appear in DORA.
They support gap analysis where existing policies were written before DORA and need remapping.
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:

Maintain DORA as the top-level ICT resilience framework.
Keep an evidence map showing how legacy EBA-based controls were migrated.
Use EBA Guidelines language where it supports governance, internal control, audit and PSD2/payment security context.
Avoid using EBA-based incident or outsourcing wording where DORA requires a specific artefact, template or classification.
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.

EBA Guidelines on ICT and Security Risk Management After DORA