EBA ICT and Security Risk Guidelines and DORA

The EBA Guidelines on ICT and security risk management (EBA/GL/2019/04) were for five years the main ICT security rulebook for EU banks and payment firms, and since DORA most of them no longer apply, yet many control frameworks, audit plans and supplier contracts still cite them. The EBA amended the guidelines in 2025 (EBA/GL/2025/02) to remove everything DORA now covers, leaving only the section on payment service user relationship management. This guide explains what the original guidelines required, what remains in force and for whom, where each original requirement now lives in DORA and its technical standards, and how to migrate a control framework without losing evidence. It is for ICT risk, information security, identity, compliance and internal audit teams at credit institutions, payment and e-money institutions, and the suppliers that support them.

Key takeaways

Most of the guidelines are deleted: the consolidated version of 19 May 2026 marks sections 3.1 to 3.7 (governance, risk framework, information security, operations, change and continuity) as deleted, together with the definitions.
One section survives: section 3.8, payment service user relationship management (paragraphs 92 to 98), still applies to payment service providers under PSD2 Article 95(3), alongside DORA.
DORA is now the ICT rulebook: Regulation (EU) 2022/2554 has applied since 17 January 2025, and Delegated Regulation (EU) 2024/1774 sets the detailed ICT risk management controls, including identity management and access control.
The control content carried over and got stricter: the 2019 access principles (least privilege, accountability, privileged access, recertification) reappear in the RTS with firmer rules, such as access reviews at least every six months for systems supporting critical or important functions.
Update your references, keep your evidence: re-map policies and audit programmes from GL paragraphs to DORA and RTS articles, but keep the history of tests, reviews and risk assessments that show continuity.

What it is and who it applies to

The EBA published the Guidelines on ICT and security risk management in November 2019. They applied from 30 June 2020 and replaced the earlier Guidelines on security measures for operational and security risks of payment services (EBA/GL/2017/17). Their legal bases were the EBA's general mandate for credit institutions and investment firms and PSD2 Article 95(3), which asks the EBA to issue guidelines on the security measures payment service providers must take to manage operational and security risks.

DORA, the Digital Operational Resilience Act, applies from 17 January 2025 and sets harmonised ICT risk management rules for most EU financial entities. To avoid duplication, the EBA amended the guidelines on 11 February 2025, and the amending guidelines apply from 20 May 2025.

Aspect	Original EBA/GL/2019/04	As amended by EBA/GL/2025/02
Addressees	Credit institutions, investment firms and payment service providers	Payment service providers under PSD2 Art. 1(1)(a), (b) and (d), including entities exempted under PSD2 Arts. 32 or 33 and electronic money institutions exempted under Art. 9 of Directive 2009/110/EC
Subject matter	Full ICT and security risk management: governance, framework, information security, operations, change, continuity, customer relationship	Payment service user relationship management only (section 3.8)
Relationship to DORA	Pre-dated DORA	Complements DORA and its technical standards
Removed from scope	Not applicable	Investment firms; entities outside DORA such as post office giro institutions and credit unions (PSD2 security requirements and national rules still apply to them)
Application	30 June 2020	20 May 2025

Firms should check their national competent authority's compliance notification: the EBA's compliance table for the amended guidelines was last updated on 18 September 2026.

Structure and key requirements

The original guidelines had eight sections and 98 paragraphs. Knowing the original structure matters because many policies, supplier questionnaires and audit reports still reference paragraph numbers.

Section (paragraphs)	Original requirement	Status after 2025 amendment
3.1 Proportionality (1)	Apply in a manner proportionate to size, complexity and risk	Deleted
3.2 Governance and strategy (2 to 9)	Management body accountability, ICT strategy aligned with business strategy, security objectives in third-party contracts and SLAs	Deleted
3.3 Risk management framework (10 to 27)	Independent control function, asset and function inventory, annual risk assessment, mitigation, reporting, independent audit	Deleted
3.4 Information security (28 to 49)	Security policy, logical and physical security, operations security, monitoring, testing, training	Deleted
3.5 ICT operations management (50 to 60)	Operations procedures, incident and problem management	Deleted
3.6 Project and change management (61 to 76)	Project governance, secure acquisition and development, controlled change	Deleted
3.7 Business continuity (77 to 91)	Business impact analysis, plans, annual testing, crisis communication	Deleted
3.8 Payment service user relationship management (92 to 98)	Customer security guidance, ability to disable functions, spending limits, alerts, support	Kept

What section 3.8 still requires

Paragraph 92: help payment service users understand security risks with assistance and guidance.
Paragraph 93: update guidance as threats change and communicate the changes.
Paragraph 94: where the product allows, let users disable specific payment functionalities.
Paragraph 95: let payers adjust spending limits up to the agreed maximum.
Paragraph 96: offer alerts on initiated and failed payment attempts.
Paragraph 97: inform users about updates to security procedures.
Paragraph 98: provide assistance for questions, support requests and reports of anomalies.

These are customer-facing controls, and they connect directly to strong customer authentication and fraud prevention. See the PSD2/PSD3 Strong Customer Authentication Guide.

Requirements worth remembering from the deleted sections

Supervisors and auditors will still compare current practice with the 2019 baseline. The original text set clear expectations:

Testing (paragraphs 41 to 48): independent testers, vulnerability scans and penetration tests, threat-led penetration testing where appropriate, critical systems tested at least annually and other systems at least every three years, and testing after relevant changes or incidents.
Risk assessment (paragraph 20): documented annually or more often, and updated after major changes.
Business continuity (paragraphs 87 to 90): plans for critical functions tested at least annually under severe but plausible scenarios, including switch-over to the disaster recovery environment, with deficiencies reported to the management body.
Change (paragraphs 75 and 76): every change recorded, tested, assessed, approved, implemented and verified, with safeguards for emergency changes.

Identity and NHI requirements

Paragraph 31 of the original guidelines set seven logical access principles. Delegated Regulation 2024/1774 carries every one of them into DORA, mostly in Article 20 (identity management) and Article 21 (access control), and adds detail.

EBA/GL/2019/04 para. 31	DORA RTS (Delegated Regulation 2024/1774)	What changed
(a) Need to know, least privilege, segregation of duties	Art. 21: need-to-know and need-to-use, least privilege including remote and emergency access, segregation of duties	Explicit coverage of remote and emergency access and of combinations of rights that bypass controls
(b) User accountability, limit generic and shared accounts	Art. 20: unique identification for every person and system; unique account for each staff member, including ICT third-party provider staff. Art. 21: users identifiable for actions at all times	Identity uniqueness extended to systems and supplier staff
(c) Privileged access rights, strong authentication for remote admin access	Art. 21: privileged, emergency and administrator access granted on a need-to-use or ad hoc basis; dedicated admin accounts; automated privileged access management where feasible	PAM tooling expected where feasible
(d) Logging of user activities, especially privileged users	Art. 12: log access control and identity management events, protect logs from tampering, synchronise clocks to a reliable time source	Log integrity and time synchronisation made explicit
(e) Timely access management	Art. 20: lifecycle covering creation, change, review, temporary deactivation and termination, automated where feasible. Art. 21: withdraw access without undue delay on leaving or role change	Records of identity assignments kept after reorganisation or contract end
(f) Periodic access recertification	Art. 21: review at least once a year, and at least every six months for systems supporting critical or important functions	Fixed review frequencies
(g) Authentication commensurate with criticality (at least complex passwords or 2FA)	Art. 21: methods based on classification and risk; strong authentication for remote network access, privileged access, systems supporting critical or important functions and publicly accessible assets	Strong authentication mandatory in four defined cases

Article 20's requirement that every system accessing the entity's information has a unique identification is the clearest DORA hook for non-human identities: service accounts, API clients, robotic process automation bots and workload identities need an owner, a lifecycle and a review, just like staff accounts. Smaller entities eligible for the simplified ICT risk management framework (DORA Article 16) follow Title III of the RTS, where Article 33 covers the same access themes in five points. See the Privileged Access Management Guide and the RPA and Bot Identity Security Guide.

Implementation steps

For an institution that built its framework on EBA/GL/2019/04, the move to DORA is mainly a re-mapping and gap-closing exercise.

Confirm your status. Establish whether you are a DORA financial entity, whether you qualify for the simplified framework, and which parts of section 3.8 apply to your payment products. Record the conclusion and its legal basis.
Build a crosswalk. Map every policy statement and control that cites a GL paragraph to the DORA or RTS article that now governs it. Keep the old reference in a secondary column so audit history stays traceable.
Close the gaps that tightened. Typical gaps: six-monthly access reviews for systems supporting critical or important functions, unique identities for supplier staff and systems, strong authentication for publicly accessible assets, log protection and clock synchronisation, and the ICT asset inventory under RTS Articles 4 and 5.
Bring machine identities into the lifecycle. Inventory service accounts, API keys, certificates and bot accounts, assign owners, and apply the same review frequency as for human access. Start with accounts that touch critical or important functions.
Keep section 3.8 controls live. Check that customers can still disable functions, set spending limits and receive payment alerts in every channel, including new apps.
Pilot, then switch. Run the new review and logging controls in parallel with the old ones for one cycle, compare results, and retire old procedures only when the new evidence is complete. Keep the previous procedures documented so you can revert if a control fails in audit.
Update third-party contracts. Replace GL paragraph references in contracts and questionnaires with DORA Articles 28 to 30 and the register of information. See the Third-Party Risk Management Guide.

Small payment and e-money institutions usually have few systems but rely heavily on outsourced platforms, so the crosswalk is short and the work is in supplier evidence. Large banking groups usually already ran an integrated control library; their task is mostly reference updates and the stricter review and logging rules.

Evidence and assessment

Crosswalk document: GL paragraph, DORA or RTS article, control owner, control test, and evidence location.
Access review records: review dates by system, with the critical or important function flag showing the six-month cycle is met, and revocations completed.
Identity inventory: human and non-human accounts with unique identifiers, owners, lifecycle state and last review.
Testing and continuity records: carried forward from the GL regime and continued under DORA's testing chapter, including threat-led testing where required.
Customer controls (section 3.8): screenshots or configuration evidence of disable functions, spending limits and alerts per channel, plus customer security communications.

Metrics that show the transition is working: percentage of controls mapped to a DORA or RTS article; percentage of systems supporting critical or important functions reviewed within six months; time to revoke access after a leaver event; share of non-human identities with a named owner; percentage of privileged sessions under privileged access management; share of customers with alerts enabled.

Mapping to other frameworks

Control area	DORA and RTS 2024/1774	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Identity and account lifecycle	RTS Art. 20	PR.AA-01	AC-2, IA-2
Least privilege and segregation of duties	RTS Art. 21	PR.AA-05	AC-5, AC-6
Privileged access	RTS Art. 21	PR.AA-05	AC-6(5), IA-2(1)
Logging	RTS Art. 12	DE.CM-03	AU-2, AU-6
Risk assessment	DORA ICT risk management framework; RTS Art. 3	ID.RA-05	RA-3
Testing	DORA testing chapter	ID.RA-05	CA-8
Continuity	RTS Arts. 24 to 26	GV.OC-03	CP-4
Third parties	DORA third-party risk chapter	GV.SC-07	SR-6

In ISO/IEC 27001:2022 Annex A, the access rows correspond to 5.15 Access control, 5.16 Identity management, 5.18 Access rights and 8.2 Privileged access rights. Entities that also fall under NIS2 should read the DORA and NIS2 Overlap Mapping Guide; for DORA as a whole see the DORA Guide.

Common pitfalls

Treating the guidelines as fully repealed: section 3.8 still applies to payment service providers, and supervisors can ask for evidence of customer security controls.
Keeping GL references as the source of truth: policies that still cite paragraph 31 miss DORA's fixed review frequencies and the four mandatory strong authentication cases.
Human-only access reviews: RTS Article 20 covers systems as well as people. Service accounts and API keys left out of reviews are a standing finding and a common breach route, as the Salesloft Drift breach showed when stolen OAuth tokens from one integration reached hundreds of Salesforce tenants.
Supplier staff on shared accounts: Article 20 requires a unique account for each ICT third-party provider staff member who accesses the entity's assets.
Losing the audit trail: deleting old procedures and evidence during the switch makes it impossible to show that controls ran without interruption.
Assuming out-of-scope means unregulated: entities removed from the guidelines and outside DORA still have PSD2 security obligations and national requirements.

Practitioner checklist

Confirm whether you are a DORA financial entity, eligible for the simplified framework, or outside DORA.
Verify section 3.8 customer controls (disable functions, spending limits, alerts, guidance, support) in every payment channel.
Produce a crosswalk from every GL/2019/04 reference in policies and contracts to DORA and RTS 2024/1774 articles.
Set access review cycles to at least annual, and six-monthly for systems supporting critical or important functions.
Give every person, supplier staff member and system a unique identity with an owner and lifecycle.
Require strong authentication for remote network access, privileged access, critical-function systems and public-facing assets.
Protect identity and access logs from tampering and synchronise clocks to a reliable source.
Retain historical test, review and risk assessment evidence from the GL regime.

Standards and references

Related NHI Mgmt Group resources: DORA Guide · NIS2 Directive Guide · Financial Services Identity Security Guide · MAS Technology Risk Management Guide · Phishing-Resistant MFA Guide. This guide summarises the EBA Guidelines on ICT and security risk management and their relationship to DORA and is not legal advice.

EBA ICT and Security Risk Guidelines Guide: Requirements and the Move to DORA