Five common DORA compliance mistakes

Introduction

The Digital Operational Resilience Act (DORA) is top of mind for financial firms these days, not just the banks. As of early 2025, this EU regulation is in effect, and it's causing more than a few headaches. DORA affects virtually every aspect of how financial entities manage technology and operational risk. It's broad, complex, and new, so even senior teams are feeling the pressure. A survey by Deloitte shows that only about a quarter of financial entities consider themselves fully compliant with DORA's ICT risk requirements, and a whopping 92% admit their digital operational resilience isn't yet up to DORA's standard.

If you feel like your team is navigating DORA compliance in real time, you're not alone. Many organisations are essentially “trying to build the plane while flying it”. Which makes sense, since DORA is still relatively new. The good news is that common missteps are becoming apparent, and once you identify them, you can take corrective action. This blog will walk you through five common DORA compliance mistakes and how you can fix them before they become bigger, costly problems.

Mistake 1: Thinking DORA is just for the IT department

Why this happens

DORA's focus on ICT risk can make it seem like a purely IT issue. It's easy to assume your CIO and IT security teams should "handle DORA" since it involves cybersecurity and data recovery. After all, if it's digital resilience, isn't it the tech team's job? Many organisations went ahead and made DORA compliance the responsibility of the IT team. After all, it’s “digital resilience”, so why wouldn’t it be the tech team’s job?

Why it's a problem

Limiting DORA to IT is like trying to win a football match with only your goalkeeper. DORA compliance spans legal, procurement, risk management, and operations. Without legal's input, important contract provisions get overlooked. Without procurement involvement, you could onboard third-party providers, missing critical DORA requirements. This results in gaps in your DORA compliance that regulators will definitely spot, but you don’t. Plus, 41% of financial firms reported increased stress on their IT and security teams under DORA. Too often, those teams are carrying the load alone, which in a worst-case scenario may lead to burnout.

How to fix it

Treat DORA compliance like a team sport. Establish a DORA working group with representatives from IT, risk management, compliance, legal, procurement, and business continuity. This group can map out who owns which requirements. IT drives technical controls, compliance owns incident reporting processes, and legal reviews supplier contracts for DORA clauses. Make sure senior management and the board are involved too, since DORA explicitly holds management accountable for ICT risks. Build a shared responsibility model for DORA. You can use something like a RACI matrix in order to organise responsibilities per team.

Mistake 2: Buying tools without knowing what you need

Why this happens

When faced with DORA's urgency, the instinct is to act fast. Buying a shiny new

"DORA compliance" tool feels like taking action. Vendors are happy to pitch their solutions, and it's tempting to believe the right tool will make DORA compliance fall into place. Tools are tangible, and buying them is quick; unlike the painstaking work of scoping requirements.

Why it's a problem

Purchasing solutions without a clear plan leads to expensive guesswork. You might end up with software that addresses the wrong priorities or becomes "shelfware", bought but barely used. For example, if you buy a third-party risk system but haven't classified your vendors first, the tool won't deliver value. DORA compliance can’t be bought; it's achieved through a set of practices and processes. Jumping to solutions gives false progress while underlying requirements remain unmet.

How to fix it

Pause and start with a DORA compliance assessment. Before spending your hard-earned budget on new technology, take some time to map out what DORA requires and where your gaps are. Review the regulation's key areas: ICT risk management, incident response, operational resilience testing, third-party risk management, and assess how you currently stack up. You might find out that you lack a proper incident notification process, or that your vendor inventory is incomplete and messy.

Once you have this picture, prioritise what needs fixing first. Then look for some tooling that aligns with those pain points. Don't put the cart before the horse. Find out what your requirements are, then choose tools that meet them. To start with an initial assessment, check our guide on how to conduct a DORA compliance assessment for a step-by-step approach.

Mistake 3: Treating all vendors the same

Why this happens

Most financial firms have hundreds or thousands of third-party vendors. DORA's scrutiny of ICT third-party relationships can be overwhelming. With limited resources, many teams end up with a one-size-fits-all approach for vendor risk management. The mindset is often, "If we treat everyone as critical, we'll cover all bases." Creating a nuanced vendor oversight program takes effort, and in a rush to comply and avoid fines, uniformity seems easier.

Why it's a problem

Your ICT vendors will rarely be equal in risk. This approach usually leads to under-scrutinising your high-risk suppliers while also overloading low-risk vendors with unnecessary work. By overworking low-risk third parties, you waste time and may even strain key relationships without any benefit. After all, it doesn’t make you “more compliant”, you either are, or aren’t. And in doing so, your team might be so busy with paperwork from all vendors that they fail to properly analyse the few that matter. One survey found that third-party risk oversight is the single most challenging DORA requirement for 34% of organisations. DORA expects proportionality,  which means focusing your effort where impact is greatest, so uniform approaches conflict with the regulation's intent.

How to fix it

Implement a tiered vendor risk management model. This means segmenting vendors by their importance and risk and then adjusting oversight accordingly. Define what makes a vendor "critical". Typically, this means their failure could severely disrupt critical services. Your core banking software provider would be Tier 1; office catering would be a lower tier. High-risk vendors receive rigorous treatment: detailed due diligence, frequent assessments, robust contractual clauses, and resilience testing. Mid-tier vendors get a moderate assessment. Lowest-tier vendors receive lightweight checks. This ensures you understand your ICT supply chain and apply energy where it matters most. For practical steps, see our article on segmenting vendors for DORA.

Mistake 4: Overlooking what needs to be in contracts

Why this happens

DORA's requirements often get discussed in terms of technology and risk, but there's a distinctly legal component that can fly under the radar. Article 30 introduces specific contractual provisions for ICT service provider agreements. This happens when teams handling DORA assume existing contracts are "good enough" or that legal will handle it later. On top of that, vendors might not be happy about changes to terms, and a busy team won’t be excited about renegotiating contracts either. The path of least resistance is focusing on operations and assuming paperwork is fine.

Why it's a problem

Skipping contract details leaves compliance gaps and operational risks. DORA spells out certain clauses that must be in your contracts. Common missing clauses include:

• Audit and access rights: You need contractual rights to audit vendor security and risk measures, and access to relevant information or premises.
• Incident reporting obligations: Vendors must promptly notify you of incidents that could impact your services.
• Subcontracting controls: Requiring approval before subcontracting critical functions
• Termination rights and exit strategy: Clear conditions for termination and data recovery
• Other provisions: Depending on the service, you may need clauses on data location, minimum security requirements, business community support, and cooperation with regulators.

Without these, your resilience is weaker and you're out of step with DORA's Article 28/30 obligations. Regulators will check contracts, especially for critical ICT services.

How to fix it

Involve your legal team early in your DORA program. Develop a DORA contract checklist based on Articles 28 and 30. For each key vendor, check: do we have audit rights? Incident notification? Exit provisions? If not, add them as soon as possible for critical vendors. Many large vendors know DORA and are updating templates, so they might be receptive. Make it standard practice that new ICT supplier agreements undergo DORA compliance review. If you’re looking for extra guidance on this specific topic, read our blog about DORA-compliant contracts.

Mistake 5: Skipping testing and simulation exercises

Why this happens‍

Testing operational resilience plans is something everyone agrees is important, but many postpone. Under DORA, it's not optional, yet teams hesitate. It can be unclear how to test, testing seems resource-intensive, or there's analysis paralysis with so many other tasks. If your organisation hasn't done disaster drills before, you might initially feel reluctant. It can feel uncomfortable to imagine worst-case scenarios, and you don’t want to bother other departments or critical vendors with simulation exercises. In the end, testing can feel vague, time-consuming, or intimidating, so teams skip it, hoping plans on paper are sufficient.

Why it's a problem

‍Not testing is like never doing fire drills; you won't know if anything works until a real crisis. DORA explicitly requires regular testing. Plans that look good on paper can fail spectacularly in practice. Regulators will ask for evidence of testing. Recent findings show that about 24% of organisations haven't implemented continuity testing, and 24% haven't formalised incident reporting processes or appointed a DORA lead. That's a quarter of companies flying blind.

How to fix it

‍Start testing, but start small. For example, you can begin with a tabletop exercise. Gather key people and walk through a scenario like "Our primary trading platform went offline, what do we do now?" Have stakeholders talk through their steps. These exercises are low-cost, don’t require you to directly involve your vendors yet, and reveal hidden assumptions.

Once comfortable, advance to technical testing: maybe a partial disaster recovery test or simulated ransomware scenario. DORA expects a range of testing. Every test should end with a report on what went well and what didn't, feeding back into refined procedures. Consider involving critical third-party providers in exercises. Remember, resilience testing is about learning, not passing or failing. When regulators see you conduct simulations and act on lessons learned, it demonstrates maturity.

Conclusion

If you've recognised your organisation in these mistakes, don’t worry, you are far from alone, and each mistake is fixable. By widening effort beyond IT, doing homework before buying tools (and buying the right ones), calibrating vendor oversight, tightening contracts, and practising response plans, you can dramatically improve your DORA posture.

Remember "progress over perfection." DORA is an ongoing effort to build digital operational resilience. Regulators don't expect perfection on day one, but they expect continuous improvement. Focus on steady progress rather than being paralysed by the task's enormity. Each mistake addressed is a step toward a stronger organisation.

You don't have to go alone. If you're curious how the right tools can help you achieve compliance without costing you all your time and energy, feel free to book a demo of our solution. If a demo feels like a bit too much for you at this stage, you can also check out our DORA framework page to see the platform in action and learn more about how 3rdRisk's solution helps you achieve compliance while saving you time and energy.

By tackling these common mistakes now, you'll satisfy regulators and build a safer organisation ready to thrive in the digital age.

‍