In recent months, I’ve had some lively debates on whether technological upgrades should take priority over new products and features. Honestly, I’ve enjoyed these discussions—I think they’re essential and should happen more often, with the Tech Lead stepping up to defend such initiatives! But then I discovered why these debates have become so pressing—the mythical DORA (Digital Operational Resilience Act) is here to stay. And with less than 5 months left until the deadline, it seems like some parts of the financial sector are in a rush to eliminate all technical debt. We’re talking about things like outdated versions of Java or PHP with security vulnerabilities, unpatched operating systems, outdated middleware and APIs, and more—all things I would have hoped were priorities long before now. Well, better late than never, right?
Not quite. With the deadline of January 17, 2025, looming, this rush is leaving some product development teams stretched thin for the foreseeable future, as they have to focus on these updates instead of new customer-facing improvements. Tech leads are simply stating that they can’t focus on anything new until the complicated requirements of DORA are dealt with. This got me thinking—is DORA really to blame for this rush, or is it the result of poor planning?
What is DORA?
DORA, adopted by the European Union in 2022 (so it shouldn’t be a surprise to anyone, though I’ll admit I’ve been out of FinTech for a while), is a regulation designed to ensure that financial institutions—and their Information and Communication Technology (ICT) Service Providers and Software Development partners—can handle and recover from digital disruptions. It focuses on several key areas that push companies to maintain up-to-date, secure technology systems with requirements going beyond ISO 27001/IEC in a few key areas, meaning that even compliant companies will need to take additional steps. The possible sanctions for non-compliance stretch from administrative fines to revocation of licenses and sanctions on senior management.
DORA is supposedly better than existing legislation because it replaces the previously fragmented and inconsistent regulations with a unified and comprehensive framework, ensuring standardized digital operational resilience across the EU financial sector. So, what does DORA demand?
ICT Risk Management: Before DORA, companies had general guidelines for managing technology risks but no strict requirements. DORA now mandates that companies actively find and fix weak points in their systems, pushing them to upgrade outdated software like old versions of Java or PHP. This means companies can no longer ignore ageing tech that puts them at risk.
Digital Operational Resilience Testing: Previously, regular resilience testing wasn’t consistently mandated by regulations. Companies were left to decide how often to test their systems, which led to many skipping this crucial step to save time or resources. DORA changes this by requiring frequent and thorough testing, ensuring that companies identify and address weaknesses before they cause problems. Now, companies must upgrade to newer, more secure systems that can pass these rigorous tests.
Third-party Risk Management: Earlier regulations were vague about the responsibility financial institutions had for their third-party providers. DORA fixes this by clearly stating that companies must ensure their providers meet the same resilience standards. If a provider uses outdated software, companies are now required to upgrade or switch providers to stay compliant.
ICT-related Incident Reporting: Right now incident reporting is inconsistent, with many companies downplaying or delaying reports of tech-related issues. DORA enforces immediate and detailed reporting of significant incidents, which means companies must keep their systems up to date to avoid frequent, costly incidents and the scrutiny that follows.
Information Sharing Arrangements: So far information about cyber threats has often been kept siloed, reducing overall industry security. DORA promotes active sharing of threat information, encouraging companies to fix vulnerabilities faster. This change pushes institutions to be more proactive in securing their systems, protecting both their reputation and customer trust.
Is the Real Issue Strategic Planning?
As a Product Lead, I’ve often found myself asking for a better strategic plan for technology. Why? Because I often feel that the product side of the roadmap gets too much weight, while there should be a healthy balance between the two. This imbalance makes me uneasy because I know there’s a fine line between product innovation and technological excellence. If technology is left behind, sooner or later, product development will slow down as a consequence.
I used to think this imbalance was just a one-off every now and then, but seeing how some institutions are reacting to DORA has made me reconsider. It seems that technology needs to be prioritized much more in strategic discussions than it currently is.
When tech teams say that product management doesn’t prioritize technical improvements and that these improvements have been pushed aside in favour of new customer features, it suggests there’s a disconnect between technology and the overall business strategy. I truly and wholeheartedly do not believe that such decisions should be left for product teams to decide upon. This isn’t a failure of product management; it’s a gap in leadership. Critical improvements should be prioritized at a higher level, and the company should treat the technology roadmap as just as important as the product roadmap. A CTO, CISO or similar leader should be driving these necessary upgrades, ensuring they’re part of the long-term plan and not just an afterthought. I wonder why this wasn’t possible in these companies.
On an interesting note, Urmo Keskel pointed out that under the influence of DORA, looking at job portals it has been noticeable how banks and other fintechs have started recruiting more people for additional IT security-related roles. I hope this is an indication that things are truly about to change.
A Catalyst, Not the Cause
DORA isn’t the bad guy here—it’s just exposing the weaknesses in the system. The regulation is pushing financial institutions to do what they should have done long ago—modernize their technology. Usually, when this happens (think GDPR), I get the feeling things have been pretty bad for a while. With the January 17, 2025, deadline fast approaching, companies are under pressure to act quickly. DORA isn’t introducing anything new, and the deadline wasn’t unreasonable—it’s simply enforcing best practices and forcing companies to deal with the technical debt that has accumulated over the years because it has been ignored.
For me, the key takeaway is this: Strategic technology planning should be more of a priority. If it’s not, companies end up rushing to meet compliance deadlines or, even worse, reacting to serious incidents and taking resources away from customer-focused innovations. Moving forward, leadership needs to ensure that technology and product roadmaps are aligned and given equal importance. This will not only help meet regulatory requirements but also build a stronger foundation for future growth and innovation.
I hope DORA achieves what it’s meant to achieve. But even more so, I hope we start paying more attention to the state of our technology, even without DORA.
"I often feel that the product side of the roadmap gets too much weight, while there should be a healthy balance between the two."
I very much agree with this. The most positive experience I had with this situation was when we were using a system to layer roadmaps into different categories: tech debt, maintenance, growth, regulatory work, etc. We set up a goal at the leadership level of what to focus on depending on the business goal of the period, but teams did not have to abide to that rule or goal by the book, since some teams where naturally more tech related and others where newly set up to address a newly discovered market problem so they were, naturally, more growth focused. The data tracked allowed to understand the tendency and inform future planning cycles.
Thanks to my ex-colleagues at Pipedrive for helping me rescue some of the memories of the above approach.