By 
The Digital Operational Resilience Act (DORA) will apply as of 17 January 2025, marking another checkpoint in EU’s regulatory landscape. While organizations still struggle to adapt to NIS2, CRA and GDPR requirements, DORA brings a new set of technical demands for the financial sector.
DORA is like that task we keep postponing, thinking it will go away. It won’t. It will officially start in January, and the implications run deeper than most realize.
Whether you’re a developer securing financial applications or a business leader planning a compliance strategy, DORA’s requirements will reshape how we approach digital security going forward.
What companies are affected?
The mandate is specific for EU’s financial sector: Credit & Payment institutions, Account information service providers, investments firms, electronic money institutions including crypto-asset service providers.
KPMC Malta summarized it perfectly:
Entities impacted by DORA
Real-Time Monitoring: Beyond Traditional Approaches
Proactivity is the recurrent factor in this resilience act.
DORA requires specific ICT (Information and Communication Technology) risk management implementations, demanding practical solutions instead of the theoretical security of older standards. For this aspect, financial institutions need to map their entire digital infrastructure, from customer-facing applications to backend processing systems.
This means continuous asset discovery, real-time monitoring, and automated validation of security controls.
Aspects that are executed by any serious company that want to ensure good security posture are now a requirement in the financial sector.
For payment processors, for example, monitoring needs to be more thorough, evaluating not only transaction success or failure, but the entire chain of dependencies. This means every connected API call, database transaction, and third-party integration requires continuous verification. Because systems must detect and respond to anomalies before they cascade into systemic failures.
What Are Financial System Anomalies?
In financial systems, anomalies manifest in various forms.
Continuing with the payment processing system example, anomalies might appear as unusual transaction patterns, unexpected API response times, or deviations in database performance.
It’s still a bit too confusing because we can’t easily detect or define anomalies. Deviations or unexpected API responses can be caused by a hosting or a spike in the ISP. Unusual transaction patterns again seem hard to categorize and label.
Therefore, DORA brings uncertainty in requirements, but that doesn’t mean we can’t prepare for it.
Anomalies usually mean deviations from their usual pattern in the closed system.
In the payment processor example, if we expand it further:
On a typical Thursday morning at a payment processor. Transaction volumes follow their usual pattern, API response times stay within normal ranges, and everything seems business as usual. But beneath the surface, small deviations accumulate. A database query that usually takes 100ms now takes 150ms. The authentication service shows a 2% increase in token refresh requests. Individually, these changes appear insignificant.
That slight increase in query times might show an emerging replication lag. Or just a hosting, anti-DDoS software responding to a threat, ISP as discussed. But this combined with extra token refreshes? They could signal a failing cache layer.
This is where the anomalies are starting to make sense, where each small deviation potentially tells a story about the system’s health. Of course, this example is rudimentary, and patterns or group of them are more refined and usually complex.
However, the real challenge remains in understanding what’s normal within the project. Next, understand the ecosystem. Financial systems naturally experience fluctuations: end-of-month payment spikes, trading hour peaks, batch processing windows.
A monitoring system must understand these patterns. A 50% increase in transaction volume might be perfectly normal at month-end but could signal an attack on a quiet Sunday morning. Or not. Or even attackers can take advantage of these as well and they might be a step ahead.
This is exactly what DORA targets – the ability to detect and understand these subtle changes before they cascade into system-wide issues. How and what are to be implemented are decisions that usually depend on the project’s requirements.
Technical Implementation Requirements
Testing requirements move beyond traditional vulnerability scanning. For these requirements, organizations must implement threat-led penetration testing and scenario-based assessments.
For larger institutions, this extends to full red team exercises that simulate sophisticated cyber attacks.
The topic requires its own overview. However, the main point is to ensure that the system is tested, not just prepared, in the SLDC. This is an important part of improving AppSec. In summary, DORA enables both the Red Team and Blue Team to conduct testing.
Overall, the technical components of the resilience act include:
- Continuous security monitoring with automated alerts
- Real-time configuration validation against security baselines
- Automated compliance checks integrated into CI/CD pipelines
- Comprehensive logging and audit trail mechanisms
Automated Incident Response
We explored real time monitoring, and the need to test the application in a simulation of sophisticated cyber attack.
Another main point of DORA’s requirements is the automated incidence response.
Incident response undergoes a fundamental transformation. Financial organizations will need automated detection systems feeding into response procedures.
For developers and security teams, DORA means setting up and building resilience into every layer of the technology stack. Applications must include security monitoring hooks, automated testing capabilities, and robust logging mechanisms. Infrastructure requires continuous configuration validation, automated compliance checks, and real-time security metrics.
The path toward DORA compliance requires fundamental changes in how we approach security architecture as well.
Conclusions
DORA helps the financial sector become more resilient. At least in theory, until further details.
It makes security an operational advantage instead of a compliance burden. However, there is a cost. Currently, organizations feel the burden of compliance more than the advantage of secure applications. As security experts, we cannot force them to comply by threatening them with consequences.
Bilbiography