Most DORA programmes can recite Articles 5 to 16 of the regulation, but supervisors test against the detail in Commission Delegated Regulation (EU) 2024/1774, and that is where the specific numbers, records and review cycles sit. The RTS was adopted on 13 March 2024 and entered into force on 15 July 2024; it applies alongside DORA, which has applied since 17 January 2025. This guide walks through the RTS article by article: the policies it requires, the frequencies it fixes, the records an examiner will ask for, and the separate simplified framework for smaller entities. It is for ICT risk, information security, compliance and internal audit teams in EU financial entities. The DORA Guide covers the whole regulation and the DORA Readiness Checklist gives a short checklist; this page goes deeper on the RTS itself.
Key takeaways
- Two frameworks, one regulation: Title II (Articles 2 to 27) applies to most financial entities; Title III (Articles 28 to 41) sets a simplified framework for the entities listed in DORA Article 16(1).
- Fixed numbers exist and are tested: weekly vulnerability scans for assets supporting critical or important functions, firewall rule reviews at least every 6 months, access rights reviews at least yearly for all systems and every 6 months for critical ones, and a yearly review of accepted residual risks.
- Every policy needs the same skeleton: Article 2 requires a management body approval date, indicators to monitor implementation, exception recording, named responsibilities and segregation of duties for each ICT security policy.
- Identity is explicit, not implied: Article 20 requires a unique identity for every staff member and third-party user, and Article 21 covers generic administrator accounts and strong authentication for remote and privileged access.
- Proportionality is built in, not a waiver: Article 1 lets you scale controls to size, risk profile and complexity, but you still need to record why a lighter measure is appropriate.
Where the RTS sits in DORA
DORA Article 15 mandated the European Supervisory Authorities (EBA, EIOPA and ESMA) to draft technical standards that harmonise ICT risk management tools, methods, processes and policies. The ESAs published the final draft on 17 January 2024 after a consultation that ran from 19 June to 11 September 2023, and the Commission adopted it as Delegated Regulation (EU) 2024/1774. As a regulation it is directly applicable in every Member State, so there is no national transposition to wait for. It supplements DORA Articles 5 to 14 (the ICT risk management framework) and Article 16 (the simplified framework).
| RTS part | Articles | What it covers | DORA article it supplements |
|---|---|---|---|
| Title I | 1 | Overall risk profile and complexity (proportionality) | Art. 4 |
| Title II, Chapter I | 2 to 18 | ICT security policies: risk management, assets, cryptography, operations, network, projects and change, physical security | Art. 9 and 15 |
| Title II, Chapter II | 19 to 21 | Human resources, identity management, access control | Art. 9(4) |
| Title II, Chapter III | 22 and 23 | ICT-related incident management policy, anomaly detection and response criteria | Art. 10 and 17 |
| Title II, Chapter IV | 24 to 26 | ICT business continuity policy, testing, response and recovery plans | Art. 11 and 12 |
| Title II, Chapter V | 27 | Report on the review of the ICT risk management framework | Art. 6(5) |
| Title III | 28 to 41 | Simplified ICT risk management framework | Art. 16 |
DORA itself requires the framework to be documented and reviewed at least once a year (periodically for microenterprises) and after major ICT-related incidents, with a report to the competent authority on request (Article 6(5)). Non-microenterprises must assign ICT risk to a control function with appropriate independence (Article 6(4)) and have the framework internally audited on a regular basis (Article 6(6)).
Policy architecture: Articles 1 to 3
Article 2 is the one teams most often skip, because it reads as boilerplate. It is not: it sets the minimum content for every ICT security policy, procedure, protocol and tool in Title II. Each policy must:
- Align with objectives: follow the information security objectives in the digital operational resilience strategy.
- Record approval: show the date the management body approved it.
- Be measurable: include indicators and measures to monitor implementation and record exceptions.
- Assign people: define responsibilities of staff at all levels and segregate duties, including in line with the three lines of defence or an equivalent internal risk management and control model.
- Be reviewed: on the DORA Article 6(5) cycle.
Article 3 then fixes the risk process: an approved risk tolerance level, a documented risk assessment methodology, risk treatment, an inventory of accepted residual risks with the reasons for accepting them, and a review of those accepted residual risks at least once a year. It also asks you to monitor changes in the threat landscape and in the business strategy. See the Risk Register Template and the ISO 31000 Risk Management Guide for methodology.
The Title II controls, article by article
| Article | Requirement in brief | Evidence an examiner will ask for |
|---|---|---|
| 4 and 5: ICT asset management | Lifecycle policy; records of identifier, location, classification, owner, supported business functions, recovery requirements, internet exposure, interdependencies and end of vendor support; criticality assessment procedure. Non-microenterprises also keep records for legacy systems. | Asset register with these fields; criticality method; legacy system list |
| 6: Encryption and cryptographic controls | Policy based on data classification and risk assessment, covering data at rest, in transit and, where necessary, in use; where in-use encryption is not possible, processing in a separated and protected environment; update cryptography as cryptanalysis develops and record mitigations | Cryptography policy; algorithm inventory; exception records |
| 7: Cryptographic key management | Full key lifecycle; protection against loss and unauthorised access; replacement of compromised keys; a register of certificates for assets supporting critical or important functions; renewal in advance of expiry | Key management procedure; certificate register with expiry dates |
| 8 and 9: ICT operations, capacity | Secure installation, configuration and deinstallation, backup and restore, scheduling, audit trails, error handling; separation of production and non-production; testing in production only where identified, reasoned, time-limited and approved; capacity and performance management | Operations procedures; production test approvals; capacity reports |
| 10: Vulnerability and patch management | Automated vulnerability scanning, at least weekly for assets supporting critical or important functions; checking that ICT third-party providers handle vulnerabilities; tracking third-party and open-source libraries; responsible disclosure; prioritised patching with emergency procedures and deadlines | Scan schedules and results; library inventory; patch SLAs and exceptions |
| 11: Data and system security | Access restrictions, secure configuration baselines, authorised software only, malware protection, removable media and endpoint controls, secure deletion and disposal, data leakage prevention, teleworking and private devices, assets operated by third parties | Baselines; allow lists; disposal records |
| 12: Logging | Define events to log (including access control, identity management, capacity, change, ICT operations and network activity); retention set by reference to business and information security objectives and the risk assessment; log protection; detection of logging failures; clock synchronisation to a reliable reference | Logging standard; retention rationale; log failure alerts |
| 13 and 14: Network security, data in transit | Segregation and segmentation; documented data flows; a separate administration network; encryption of network connections; architecture and security design reviewed once a year; firewall and connection filter rules reviewed at least every 6 months for systems supporting critical or important functions; session lock or termination after inactivity; secure transfer and confidentiality arrangements | Network diagrams; firewall review records; data flow maps |
| 15 to 17: Projects, acquisition and development, change | Project risk assessment and security testing before production; reporting projects affecting critical or important functions to the management body; testing and approval before use; static and dynamic source code review; non-production use of production data only when anonymised, pseudonymised or randomised, with narrow exceptions; independence between change approval and implementation; fall-back procedures; emergency change handling | Project reports; code review results; change records with separate approver |
| 18: Physical and environmental security | Premises and data centres, assets inside and outside premises, maintenance, clear desk and clear screen, unattended equipment | Physical security policy; access logs |
The numbers in this table are the minimums the RTS states. Where your own risk assessment points to a shorter cycle, use it; the RTS does not cap frequency.
Identity and access: Articles 19 to 21
Chapter II is the most concrete identity text in EU financial regulation. Read it with non-human identities in mind, because "users" and "accounts" are not limited to people.
- Article 19, human resources: assign ICT security responsibilities, require staff and ICT third-party provider staff to follow the policies, make reporting channels known, and recover assets when employment ends.
- Article 20, identity management: a unique identity for each staff member and each ICT third-party user, with a corresponding user account; a lifecycle process for identities and accounts; records of identity assignments; and automation where appropriate.
- Article 21, access control: access rights on need-to-know, need-to-use and least privilege, including for remote and emergency access; account management covering granting, changing and revoking access, including generic administrator accounts; prompt withdrawal when employment ends or access is no longer needed; access rights reviews at least once a year for all ICT systems and at least every 6 months for systems supporting critical or important functions; strong authentication for remote access, privileged access and critical or publicly accessible assets; and logged, monitored physical access.
Three practical consequences. First, shared and generic administrator accounts are not banned, but they must be under account management with a named owner, which in practice means vaulting and session attribution. See the Privileged Access Management Guide. Second, service accounts, API keys and integration credentials used by systems supporting critical or important functions fall inside the 6-month review if you treat them as accounts, and most examiners do. See How to Run an Access Review for Service Accounts and the NHI Policy Template. Third, emergency access is in scope of least privilege, so break-glass accounts need a documented procedure and post-use review. See the Break Glass Access Procedure Template.
Detection, continuity and the review report: Articles 22 to 27
- Article 22, incident management policy: document the process, keep contact lists for detection and vulnerability management, set mechanisms for prompt anomaly detection, analyse significant or recurring incidents, and retain evidence securely for no longer than necessary.
- Article 23, anomalous activity detection and response criteria: clear roles; collection and analysis of internal and external factors, including incidents reported by ICT third-party providers; alerts for anomalies at least for assets supporting critical or important functions; tamper-protected detection records showing the date of occurrence, date of detection and type; and criteria that trigger response, such as suspected malicious activity, data loss, adverse impact on operations and unavailability. Link these criteria to the classification in the DORA Major ICT Incident Reporting Guide.
- Articles 24 to 26, ICT business continuity: a policy with objectives, scope, timeframes, activation criteria and governance; tests based on the business impact analysis using severe but plausible scenarios, including third-party services and, for non-microenterprises, switchover to redundant capacity; and response and recovery plans covering scenarios such as cyber-attacks, third-party failure, loss of premises or data centre, staff unavailability, insider attacks, natural events and power outages. Central counterparties and central securities depositories have a recovery time objective of no longer than 2 hours for critical functions, and trading venues must resume trading within or close to 2 hours. See the Business Continuity and Disaster Recovery Guide.
- Article 27, review report: submitted in a searchable electronic format, with the approval date, reason and period of the review, the function responsible, findings, remediation measures with deadlines, resource impact, future plans and conclusions. Where the review followed incidents, list them with root-cause analysis.
The simplified framework: Title III
DORA Article 16(1) removes Articles 5 to 15 for small and non-interconnected investment firms, exempted payment institutions, exempted electronic money institutions, certain institutions exempted under the Capital Requirements Directive, and small institutions for occupational retirement provision. These entities follow Title III instead.
| Area | Title III article | Key point |
|---|---|---|
| Governance | 28 | Management body approves policies, sets roles and allocates budget at least once a year; control and audit functions independent |
| Policy and classification | 29, 30 | Information security policy; identify critical or important functions, supporting assets and interdependencies |
| Risk and physical security | 31, 32 | Risk tolerance, periodic assessment, alert thresholds; physical and environmental protection |
| Access control | 33 | Need-to-know and least privilege, account management, strong authentication for remote and privileged access, periodic review |
| Operations, data and network, testing | 34 to 36 | Asset lifecycle, vulnerability scanning, logging; protection of data at rest and in transit; an ICT security testing plan |
| Development and change | 37, 38 | Requirements, testing before use, recorded and approved changes |
| Continuity and review | 39 to 41 | Continuity plan; backup and restore tested at least once every year; review report in searchable electronic format |
How to implement: a phased approach
The sequence below is NHI Mgmt Group's recommended order, not a regulatory requirement.
- Confirm the framework: decide whether Title II or Title III applies, record the Article 1 proportionality reasoning, and map every RTS article to a policy owner.
- Build the Article 2 policy skeleton: one template with approval date, indicators, exception log and responsibilities, then retrofit every existing ICT security policy to it.
- Fix the inventory first: close the Article 4 asset record fields, including identities and credentials attached to each asset, because Articles 10, 12, 13 and 21 all key off "assets supporting critical or important functions".
- Put the fixed cycles in a calendar: weekly scans, 6-monthly firewall and access reviews, yearly residual-risk review, architecture review and framework review. See the Compliance Calendar Template.
- Test the evidence, not the policy: pick one critical function and walk it end to end, from asset record to access review to restore test, as an examiner would.
- Write the first Article 27 report: produce it even if not yet requested, so the format and sources are proven before a supervisor asks.
To roll back a control change that disrupts operations (for example a stricter session timeout under Article 13), record it as a time-limited exception under the Article 2 exception process rather than silently reverting.
Decision guidance
- Title II or Title III: follow DORA Article 16(1) only. Being small is not enough; the entity must be one of the listed types.
- EBA Guidelines or RTS: credit institutions that built controls on the EBA ICT and security risk guidelines will find much reuse, but the RTS numbers prevail where they are stricter. See the EBA ICT and Security Risk Guidelines Guide.
- Proportionality: a smaller entity may justify fewer tools, but not skipping a fixed review cycle. Record the reason when you choose a lighter measure.
Detection and measurement
| Metric | RTS anchor | Target to evidence |
|---|---|---|
| Assets supporting critical or important functions scanned in the last 7 days | Art. 10 | 100 percent |
| Access reviews completed on time (6 months critical, 12 months other) | Art. 21 | 100 percent, with revocations recorded |
| Privileged and remote access covered by strong authentication | Art. 21 | 100 percent, exceptions logged |
| Firewall rule sets reviewed within 6 months | Art. 13 | 100 percent for critical systems |
| Certificates for critical assets renewed before expiry | Art. 7 | No expiries in production |
| Policies with a current approval date and open exceptions tracked | Art. 2 | All policies |
Framework mapping
| RTS area | NIST CSF 2.0 | NIST SP 800-53 Rev 5 |
|---|---|---|
| Risk tolerance and methodology (Art. 3) | GV.RM | PM-9, RA-3 |
| Asset management (Art. 4, 5) | ID.AM | CM-8 |
| Cryptography and keys (Art. 6, 7) | PR.DS | SC-12, SC-13 |
| Vulnerabilities and patching (Art. 10) | ID.RA, PR.PS | RA-5, SI-2 |
| Logging (Art. 12) | DE.CM | AU-2, AU-11 |
| Network security (Art. 13) | PR.IR | SC-7 |
| Change and development (Art. 16, 17) | PR.PS | CM-3, SA-11 |
| Identity and access (Art. 20, 21) | PR.AA | AC-2, AC-6, IA-2 |
| Incident detection and response (Art. 22, 23) | DE.AE, RS.MA | IR-4 |
| Continuity and recovery (Art. 24 to 26) | RC.RP | CP-2, CP-4 |
Common failure patterns
- Policies without the Article 2 elements: well written documents with no approval date, no indicators and no exception log.
- Human-only access reviews: the 6-month review covers staff but not the service accounts and API keys that run critical functions.
- Asset register missing the RTS fields: no internet exposure, end-of-support date or recovery requirement, so criticality cannot be shown.
- Residual risks accepted once and forgotten: no evidence of the yearly review Article 3 requires.
- Logging retention with no rationale: a fixed number chosen by the tool default rather than tied to objectives and risk assessment as Article 12 asks.
- Continuity tests that skip third parties: Article 25 expects tests to include ICT third-party services.
Practitioner checklist
- Record whether Title II or Title III applies and why.
- Retrofit every ICT security policy with approval date, indicators, exceptions and responsibilities.
- Complete the Article 4 asset record fields for every asset supporting critical or important functions.
- Keep a certificate register and renew before expiry.
- Scan assets supporting critical or important functions at least weekly.
- Review firewall rules for critical systems at least every 6 months.
- Review access rights at least every 6 months for critical systems and yearly for all others, including non-human accounts.
- Enforce strong authentication for remote, privileged and publicly accessible access.
- Review accepted residual risks at least once a year.
- Produce a test Article 27 review report in searchable electronic format.
Standards and references
- EUR-Lex: Commission Delegated Regulation (EU) 2024/1774 on ICT risk management tools, methods, processes and policies and the simplified ICT risk management framework
- EUR-Lex: Delegated Regulation (EU) 2024/1774, Official Journal record
- EUR-Lex: Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)
- EBA: ESAs publish first set of rules under DORA for ICT and third-party risk management and incident classification
- EBA: Regulatory Technical Standards on ICT risk management framework and simplified ICT risk management framework
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: DORA Guide · DORA Readiness Checklist · DORA ICT Third-Party Risk and Register of Information Guide · EBA ICT and Security Risk Guidelines Guide · Compliance Obligations Register Template. This guide summarises Delegated Regulation (EU) 2024/1774 and is not legal advice.