Learn
After reading this, you’ll know exactly what belongs in your ICT risk management framework, what the ESA’s technical standards changed from the Level 1 text, and where most firms are falling short.
Let me tell you about a moment I keep reliving. I was in a meeting with a bank’s CISO - experienced, sharp, somebody who’d been managing ICT risk since before it was called “ICT risk” - and she told me, with complete sincerity, “We already have an ICT risk management framework. We wrote it in 2019. It’s comprehensive.”
She wasn’t wrong that it was comprehensive. It covered everything you’d expect from a pre-DORA framework: asset inventories, access controls, change management, incident response. Good stuff. Solid work.
She was wrong that it was sufficient. Because DORA’s Chapter II, combined with the ESA’s Regulatory Technical Standards on ICT risk management (RTS 2024/1774, if you want to look it up), raised the bar in ways that most existing frameworks simply don’t address.
This article walks through the key requirements - not by quoting regulation at you (you can read that yourself), but by explaining what each requirement actually means in practice and where the common mistakes live.
Understanding the Hierarchy: Level 1 vs. Level 2
Before we dive in, a quick orientation. DORA works at two levels:
Level 1 is the regulation itself - the text published in the Official Journal. Chapter II (Articles 5-16) covers ICT risk management. These articles set out the principles and high-level requirements. They tell you what you need.
Level 2 is the Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) developed by the ESAs (EBA, EIOPA, ESMA). These are the detailed specifications. They tell you how, with considerably more granularity than the Level 1 text.
The mistake I see constantly: firms read Chapter II of DORA, build their framework to match those articles, and think they’re done. They haven’t read the RTS. The RTS adds substantial detail - specific requirements for documentation, governance structures, review cycles, and technical measures that aren’t obvious from the Level 1 text alone.
You need to build your framework against both levels. The Level 1 text gives you the architecture. The RTS gives you the building code.
The Core Components the RTS Requires
Nine areas you can’t skip, explained in human terms
1. ICT Asset Management
You can’t manage risk on assets you don’t know about. The RTS requires a comprehensive inventory of all ICT assets - hardware, software, network components, data repositories - including their interdependencies and their criticality to business functions.
This sounds obvious. It’s not. Most firms I’ve worked with discover 20-30% more ICT assets during this exercise than they thought they had. Shadow IT is real. That analytics tool the marketing team signed up for? The productivity app someone bought with a corporate card? The legacy system in the corner that nobody dares turn off because it still processes settlement files from 2014? All ICT assets. All in scope.
The RTS also requires classification by criticality. Not everything is equally important. But you need to explicitly decide what’s critical, document that decision, and review it at least annually.
2. Risk Identification and Assessment
The RTS expects a systematic process for identifying ICT risks - not a workshop where people brainstorm threats onto sticky notes once a year. I’ve seen that pass as a “risk assessment” too many times.
Specifically, the RTS requires risk assessments to cover: threats to ICT assets and data, vulnerabilities in ICT systems, the effectiveness of existing controls, and the potential impact on business functions. The assessment must consider both internal risks (misconfiguration, insider threat, technical debt) and external risks (cyber attacks, provider failure, regulatory changes).
Assessments must be performed at defined intervals and after any significant change to the ICT landscape. New system deployment? Re-assess. Major provider change? Re-assess. Acquisition of another entity? Definitely re-assess. The “we do risk assessments annually” approach doesn’t satisfy the RTS if your ICT environment changed materially in month three and you waited until month twelve to notice.
3. ICT Security Policies and Procedures
DORA and the RTS require documented policies covering (at minimum): information security, network security, access control, cryptographic controls, ICT project management, ICT change management, physical security, and data protection. These aren’t suggestions. They’re requirements.
But here’s what the RTS adds that catches people off guard: these policies must be reviewed and updated at least annually, or whenever a material change occurs. They must be approved by the management body. And they must be communicated to all relevant staff with appropriate training.
A policy that sits in a document management system untouched for two years, reviewed by nobody, communicated to nobody, is not a policy. It’s a liability in PDF form.
4. ICT Incident Management
The RTS requires an incident management process aligned with DORA’s classification criteria. This means the process must include: detection mechanisms, classification against DORA’s specific thresholds (not just your internal severity scale), escalation procedures, communication protocols (internal and regulatory), root cause analysis, and post-incident review.
The 4-hour initial notification window for major ICT-related incidents makes this time-critical. Your process needs to work at 3am on a Sunday as reliably as it does at 2pm on a Tuesday. If your incident classification depends on a single person who might be on holiday, your process isn’t resilient. Which is ironic, given what the regulation is called.
5. Business Continuity and Disaster Recovery
DORA goes beyond traditional BCP/DRP. The RTS requires: defined recovery time objectives (RTOs) and recovery point objectives (RPOs) for all critical business functions, regular testing of recovery procedures (not just documentation), crisis communication plans, and the ability to recover from “severe business disruptions” including scenarios where primary ICT systems and their backups are simultaneously unavailable.
That last point is significant. DORA is explicitly asking: what happens when your disaster recovery also fails? Do you have a third option? Most firms haven’t thought that far, because traditional DRP assumes the backup works. DORA doesn’t make that assumption.
6. ICT Change Management
Changes to ICT systems must follow a controlled process with risk assessment, testing, approval, and rollback capability. The RTS specifies that change management must cover: development, acquisition, maintenance, and decommissioning of ICT systems.
The part that firms overlook: change management must include a risk assessment for each significant change. Not a rubber stamp. An actual evaluation of whether this change could affect the availability, integrity, or security of critical services. If a deployment goes wrong, can you roll back? How fast? Has that been tested?
7. Access Control and Authentication
The RTS requires access control based on the principles of least privilege and need-to-know. Strong authentication (multi-factor) is expected for access to critical systems. Access rights must be reviewed at least annually, and there must be a process for promptly revoking access when no longer needed.
The gap I see most: firms have MFA for production systems but not for the tools used to manage those systems. Your deployment pipeline, your cloud console, your CI/CD system - if those aren’t protected with the same rigor as the systems they deploy to, your access control has a hole.
8. Learning and Evolving
DORA Article 13 and the RTS require that your framework isn’t static. It must incorporate lessons from: incidents (both yours and industry-wide), resilience testing results, threat intelligence, and regulatory developments. There must be a documented process for how these inputs lead to framework updates.
This is the “learning loop” that separates compliance theater from actual risk management. A framework that hasn’t changed since it was written isn’t learning. And if your regulator can see that the same vulnerability finding from your 2024 pen test is still unresolved in 2026, they’ll draw the obvious conclusion.
9. Communication and Reporting
The management body must be informed about ICT risk on a regular basis. The RTS specifies that reporting to the board should include: the current risk profile, significant incidents, status of risk treatment actions, and results of resilience testing. This isn’t annual reporting. It’s ongoing.
A compliance officer told me recently that their board receives an ICT risk report once a year, buried in a 200-page pack that also covers credit risk, market risk, and operational risk. The ICT section is four slides. Nobody has ever asked a question about it. That’s not “informing the management body.” That’s hiding information in plain sight.
The Governance Piece Nobody Gets Right
DORA Article 5 places ultimate responsibility for ICT risk management on the “management body.” That’s your board or equivalent. Not the CISO. Not the CTO. Not the compliance team. The board.
The RTS elaborates on what this means practically:
The board must approve the ICT risk management framework - not delegate approval to a committee. The full board. This means board members need to actually understand what they’re approving, which in turn means someone needs to explain it in business terms, not technical jargon.
The board must allocate adequate resources - budget and people - for ICT risk management. “We don’t have the budget” is not a defense when the board is personally responsible for ensuring adequate resources.
Board members must undergo training on ICT risk - sufficient to understand the risks and their potential impact on the entity. The days of board members saying “I’m not technical” as a way to opt out of ICT oversight are over. DORA doesn’t care if you’re technical. It requires you to be informed.
The board must define risk appetite for ICT risk - explicitly, in writing. Not as a general statement about “low tolerance for technology risk,” but with enough specificity to guide operational decisions. What level of service unavailability is acceptable? What data loss threshold triggers escalation? These need board-level answers.
Structuring Your Framework: A Practical Approach
I’ve seen firms produce 150-page framework documents that are technically complete but practically useless. Nobody reads them. Nobody follows them. They exist to satisfy an audit finding.
Here’s what works better:
A concise framework document (30-40 pages) that covers the nine core components above, defines governance responsibilities, and references more detailed procedures. This is the document the board approves.
Detailed procedures underneath, owned by the teams that execute them. Your incident management procedure is owned by the SOC team. Your change management procedure is owned by IT operations. Your access control procedure is owned by IAM. These procedures implement the framework. They can be updated operationally without requiring full board re-approval every time.
A risk register that captures identified risks, their assessment, and the treatment decisions. This is a living document - updated continuously, reviewed quarterly, reported to the board regularly.
An evidence repository that demonstrates the framework is operational: completed risk assessments, testing reports, incident records, policy review logs, training records, board minutes showing ICT risk discussion. If your regulator asks “show me the evidence,” you should be able to pull it up in minutes, not weeks. Tools like Venvera centralize this evidence trail across frameworks - risk assessments, policies, testing records - with full audit logging, which makes regulatory requests considerably less painful.
Five Pitfalls That Sink Otherwise Good Frameworks
Writing to impress, not to implement
Frameworks filled with aspirational language (“world-class,” “best-in-class,” “cutting-edge”) that don’t translate into specific, measurable requirements. Write what you’re actually going to do, not what sounds good in a board paper.
Ignoring the proportionality principle
Small firms copying enterprise frameworks end up with requirements they can’t realistically implement. A 50-person payment institution doesn’t need a three-line-of-defense model with separate risk and audit functions. Scale the framework to your reality. DORA explicitly allows this.
No connection to the Register of Information
Your risk management framework should reference and integrate with your RoI. Third-party risks identified in the framework should map to providers in the register. Concentration risks should be assessed using RoI data. If these two pieces exist in separate silos, neither is working properly.
Treating review as a formality
The RTS requires at least annual review and update. I’ve seen “reviews” where someone opens the document, changes the date in the header, and calls it reviewed. That’s not a review. A review asks: did any risks materialize? Did any testing reveal gaps? Did the threat landscape change? Does this framework still reflect how we actually operate? If the answer to any of those is yes, the framework needs updating, not just re-dating.
No testing of the framework itself
You test your systems. You test your backups. You test your incident response. But have you tested whether your risk management framework actually works under stress? A scenario exercise that walks through a major ICT incident, following your framework step by step, will reveal gaps that no document review ever will.
The Framework Is the Foundation
Everything else in DORA - the Register of Information, incident reporting, resilience testing, third-party risk management - connects back to the ICT risk management framework. It’s the foundation on which every other obligation rests.
Get the framework right, and the rest becomes structurally sound. Get it wrong - or worse, build it as a document exercise with no connection to operational reality - and everything built on top of it is unstable.
The ESA’s technical standards didn’t make this easy. They made it specific, detailed, and demanding. But they also made it clear: a well-built ICT risk management framework isn’t just regulatory compliance. It’s genuinely good risk management. The firms that treat it that way - as useful intelligence rather than regulatory burden - are the ones that come out ahead.
Build Your Framework on Solid Ground
Venvera’s DORA module includes risk assessment workflows, policy management, incident classification aligned with ESA RTS criteria, and full audit trails - across 13 frameworks, starting at €399/month.
Get Started →Last updated: March 2026. References to ESA RTS based on published delegated regulations.