DORA Is Not an IT Problem

Category: Operational Resilience Author: Cody Swidler Tags: DORA, operational resilience, financial services, ICT risk, third-party risk, operating model

The Digital Operational Resilience Act went into effect in January 2025. Financial services firms across the EU — and a significant number of US-based firms with EU operations or customers — spent the better part of two years preparing for it.

A lot of them prepared wrong.

The most common mistake wasn't technical. It was organizational. DORA got handed to IT, treated as an ICT risk management exercise, and implemented as a technology compliance project. That's a misread of what the regulation actually requires — and it's setting up a lot of organizations for gaps that will surface the moment a regulator looks closely.

What DORA Actually Requires

DORA has five pillars: ICT risk management, incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. Each one has technical dimensions. None of them is purely a technology problem.

ICT risk management under DORA requires a governance framework — board oversight, clearly defined roles and responsibilities, an information security policy that reflects actual risk appetite. That's a governance question as much as a technology one.

Resilience testing — particularly the Threat-Led Penetration Testing (TLPT) requirements for significant firms — requires coordinating across security, technology, compliance, legal, and business operations. It can't be run by the IT team alone.

Third-party risk management requires a complete register of ICT service providers, tiering by criticality, contractual requirements, exit strategies, and concentration risk analysis. The contractual and exit strategy requirements aren't IT work — they're legal and procurement work, informed by operational risk analysis.

Incident reporting requires defined thresholds, classification criteria, and escalation paths that connect operational teams to compliance and regulatory functions. Getting a major incident report to your regulator within the DORA-specified timeframes requires a process that runs across functions — and it needs to be tested before the incident happens.

The Ownership Gap

In organizations where DORA landed with IT, the common pattern I've seen is that the ICT-specific requirements got addressed — risk registers were updated, testing plans were developed, vendor lists were compiled — but the governance layer that DORA actually requires is thin or missing.

Board reporting on ICT risk is a box-check rather than a substantive discussion. Roles and responsibilities for resilience decisions are documented in a policy but not operationalized. The incident response process works for a purely technical incident but hasn't been tested against a scenario that requires coordinated regulatory notification.

These gaps are hard to see from inside the program because the documentation looks complete. They become visible when something goes wrong, or when a regulator asks the questions that the documentation was designed to deflect.

What Good Looks Like

Organizations that have implemented DORA effectively — not just compliantly, but actually — tend to have a few things in common.

Resilience has an executive owner. Someone at the senior level is accountable for DORA compliance as a whole, with authority to direct work across IT, Legal, Compliance, Operations, and Procurement. Not a steering committee. A person.

The testing program is treated as a business program. TLPT and other resilience tests are not IT projects. They're business-critical exercises that require executive sponsorship, coordinated participation, and serious post-test remediation processes. Organizations that run them as technical tests get technical results. Organizations that run them as business resilience exercises get organizational learning.

Third-party risk management is integrated with procurement. The DORA requirement for contractual provisions, exit strategies, and concentration risk analysis only works if it's built into the vendor onboarding and contract renewal process. If it's a separate compliance review that happens after contracts are signed, you're always going to be chasing gaps.

Incident response has been rehearsed end-to-end. That means a tabletop or live exercise that runs from initial detection through regulatory notification, including the decision-making, escalation, and communication steps that don't happen in a purely technical response drill.

For US Firms

If you're a US-based financial services firm without direct EU regulatory exposure, DORA still matters. The FFIEC's operational resilience guidance, the SEC's cybersecurity disclosure rules, and the Federal Reserve and OCC's expectations around third-party risk management are converging toward the same place DORA has landed. What the EU has codified, US regulators are signaling through examination findings and guidance updates.

The organizations that treat resilience as a governance problem — who owns it, how decisions get made, how the program is tested and improved — are better positioned for any regulatory framework. The ones that treat it as a technology problem are going to keep patching the same gaps in different regulatory flavors.

Cody Swidler is the founder of PivotRisk. He has built operational resilience and GRC programs at organizations operating under FFIEC, SEC, FCA, and DORA-aligned frameworks across fintech, asset management, and network infrastructure.