DORA: Why Cybersecurity Alone Won’t Make You Compliant

The Digital Operational Resilience Act (DORA) came into force in January 2025 with a simple objective: ensure that financial institutions can continue operating when technology fails.

Whether the disruption comes from a cyberattack, system outage, or third-party provider failure, the consequences can quickly spread beyond a single institution and impact customers, businesses, and the wider financial system.

The objective is straightforward. What resilience actually looks like is less so.

The Blind Spot in DORA’s Cyber Focus

More than a year after DORA went live, many organizations still approach resilience primarily through a cybersecurity lens and focusing on firewalls, encryption, incident response, and system availability.

These capabilities are, of course, essential. But DORA is ultimately concerned with the broader continuity and integrity of critical business services. That means looking beyond traditional cyber controls and accounting for fraud risks that don’t rely on breaking systems, but on exploiting weakened defenses.

Within this broader scope, a clear blind spot emerges. Fraud detection and prevention systems are critical to protecting customers, transactions, and financial assets but are not always treated as resilience controls in the same way as cybersecurity infrastructure.

The distinction matters. A bank may be well prepared to recover from a cyber incident, but what happens if fraud monitoring becomes unavailable or degraded during a disruption? We know all too well that attackers don’t stop operating simply because the institution is focused on recovery.

As financial institutions continue maturing their DORA programs, an important question remains: Is an institution truly resilient if its fraud defenses cannot withstand disruption?

Fraud in Times of Cyber Disruption: Hidden Resilience Gaps

Cyber incidents don’t just test your security controls. They stress everything around them. The issue is, fraud doesn’t need systems to go fully down. It just needs things to be slightly degraded, slightly delayed, or slightly inconsistent. That’s exactly what disruption creates.

Reduced Visibility During Incident Response

One of the most common patterns shows up during incident response. Systems are isolated and connections are restricted. Fraud prevention controls rely on the same infrastructure so when those inputs are disrupted, the system keeps running, but with less context. Models fall back to simpler logic, decisions rely more on static rules, and some signals disappear entirely. Payments still go through, but detection is now running on partial visibility. And that’s enough for higher-risk activity to start blending in.

Operational Trade-Offs Under Pressure

Pressure to maintain service continuity often forces trade-offs. When payments are at risk of disruption, the priority is to keep customers transacting. In practice, that often means simplifying authentication or increasing manual approvals. These are rational decisions made under time pressure, but they change the risk profile of the system. Controls become less consistent, more reliant on human judgment, and—crucially—more permissive. That’s exactly the kind of environment attackers are waiting for.

Detection Lag During Recovery

Even when core systems recover, detection doesn’t always catch up at the same speed. Failover plans typically prioritize getting payments back online, which makes sense from the banking perspective. But fraud visibility lags behind. Alert pipelines slow down, integrations with case management break or degrade, and queues start to build. And in today’s real-time fraud environment, delayed detection has a very real impact: by the time alerts are reviewed, multiple transactions may have already cleared, spread across accounts, or moved further down the chain.

None of this requires a sophisticated new attack. It’s the same fraud patterns you already deal with, just operating in a moment where controls are weaker or slower.

Three Steps Cyber Teams Need to Own

Seeing fraud as part of resilience is only the starting point. The real work is making sure fraud controls actually hold up across planning, testing, and recovery. While cyber teams may not own fraud operations, they often own the infrastructure, integrations, and data flows that decide whether fraud controls hold during disruption.

In practice, that makes cyber teams directly responsible for the conditions under which fraud controls succeed or fail.

That matters because the window between weakness and exploitation is shrinking. Advances in AI are already accelerating how quickly vulnerabilities get turned into real attacks. What once took months can now happen in days or even hours.

As attack timelines shrink, the real question is whether your controls still work when systems are degraded.

Inventory Fraud Tools

Most institutions maintain detailed inventories of critical infrastructure, applications, and third-party services. Yet fraud controls are rarely mapped with the same rigor, even though they sit directly on the path of financial loss.

Fraud detection often depends on a complex ecosystem of monitoring platforms, authentication systems, case management tools, and external data providers. For cyber teams, the first step is identifying those fraud controls and understanding:

• What feeds them? (transaction data, device intelligence, third-party risk scoring)
• What do they depend on? (APIs, identity systems, data pipelines)
• What happens if those dependencies become unavailable, delayed, or degraded?
• Which fraud signals or detection capabilities would be lost as a result?

The goal is to make sure that fraud controls are part of operational resilience, not something that gets handled downstream.

Test Fraud Resilience

Many resilience exercises focus on two states: everything works vs. everything is down. But fraud detection rarely fails so cleanly. More often, controls continue operating with reduced visibility, delayed inputs, degraded scoring, or fallback logic.

That’s why resilience testing should go beyond system availability and explore how fraud controls perform when critical dependencies are only partially available. Consider questions such as:

• What happens if device intelligence becomes unavailable?
• What happens if risk scoring is delayed?
• What happens if fraud models switch to fallback rules?

Fraud detection should be treated like any other critical continuity capability. Testing how controls perform under degraded conditions separates real resilience from checkbox compliance.

Coordinate with Fraud Operations

Fraud resilience isn’t something cyber can solve alone. It requires coordination with the teams monitoring fraud, investigating alerts, and managing risk day to day. That coordination shows up in practice: institutions that integrate cyber and fraud functions report faster implementation of defenses and more effective incident containment.

Shared incident playbooks, pre-agreed thresholds, and clear escalation paths help make sure fraud stays part of the response, not an afterthought. To make that happen, key questions include:

• Who is responsible for assessing fraud impact during an incident?
• Which controls can be relaxed—and which should never be?
• What fallback procedures exist if critical fraud capabilities become unavailable?
• What are the escalation paths when fraud risk increases during an incident?

The goal is having clear, practical answers for what happens when fraud controls weaken or detection starts to slip.

Regulatory Expectations: What Supervisors Will Ask For

DORA changes the discussion from design to proof. By the time supervisors start asking questions, the focus is no longer on how your controls are supposed to work, but on whether you can demonstrate that they actually do under stress.

In practice, that evidence needs to show three things: that fraud controls are in scope, that they’ve been tested under realistic conditions, and that decisions are clearly owned.

That includes:

• Results of resilience and scenario testing
• Documented dependencies and failure modes
• Incident learnings and post-mortems
• Metrics showing how detection performs under stress

If fraud controls degrade during disruption, supervisors will expect to see that you’ve observed it, tested it, and built around it.

Strategic Takeaway: Cybersecurity Success Depends on Fraud Resilience

DORA forces a shift many organizations haven’t fully made yet. Cybersecurity is no longer judged only by whether systems are protected or quickly restored, but by whether critical services remain trustworthy under pressure.

That distinction matters. From a customer and financial perspective, a service that is available but exposed to fraud is still failing.

What this highlights is a structural gap. Cyber and fraud functions often operate with different priorities, different tooling, and different definitions of success. Under normal conditions, that separation holds. Under disruption, it doesn’t. This is where resilience either works—or breaks.

For cyber leaders, the takeaway is not to take on fraud operations, but to recognize that fraud outcomes are now part of resilience outcomes. If controls weaken when systems are degraded, that risk sits within the same boundary as availability, integrity, and recovery.

DORA brings that into focus by making those dependencies visible and assessable. And once they’re visible, they’re owned.

Close the DORA blind spot before it’s exposed under disruption.