The Digital Operational Resilience Act (DORA) has applied to financial organizations across the EU since January 2025 and is designed to strengthen their ability to withstand operational disruption.

What the roundtables revealed was that although these financial organizations had completed extensive DORA planning exercises, this groundwork was not reliably translating into auditable operational control. They were still struggling to prove that their controls work and are applied consistently everywhere, especially across complex database estates, inherited infrastructure, and third-party systems. As one leader put it:

"It's hard to keep track of the gaps between what a documented process says should happen, and what happens in practice."

Participants reported audit failures linked to inadequate visibility and control over database management, and third-party acquisitions whose compliance claims didn't withstand scrutiny. They also raised an increasingly urgent concern around AI projects gaining access to business data without proper governance and making changes to ICT systems without clear accountability.

A common theme in many cases was the absence of a senior DORA owner with cross-functional authority to coordinate activities and push through any required investment in tools and processes, allowing compliance risks to accumulate over time.

Here's a breakdown of the main problems discussed, and what technical leaders can act on right now.

1. The database is a common DORA blind spot

Almost every organization represented at the roundtables had been through a substantial DORA planning exercise, including gap analyses, creating compliance workstreams and establishing reporting ownership. However, many acknowledged that the database layer rarely received the same scrutiny as application software, networks, or cloud infrastructure.

One participant described how a bank failed an audit not because of a breach or outage, but because it could not demonstrate visibility into how its databases were managed. The bank was forced into an unplanned, disruptive and expensive remediation program, pulling people and budget away from planned work.

It's a stark illustration of how easily compliance planning can break down at the operational level. Participants described inconsistent deployment processes between teams, undocumented schema changes, and incomplete oversight of who changed what, in which environment and when.

All of this will be difficult to defend in a DORA audit, given that Article 9 explicitly requires changes to ICT systems to be "recorded, tested, assessed, approved, implemented and verified in a controlled manner."

How technical leaders can respond

Identify where database change processes still vary between teams, platforms or environments, and bring production and non-production changes under consistent controls. Every change should be recorded, attributed, tested and approved. You need readily available evidence of what changed and when, who approved it, where it was deployed and which checks were completed.

The practical test is whether the organization can quickly produce a clear account of significant recent database changes: what changed, who approved it, where it was deployed and which checks were completed. If that evidence must be reconstructed manually, the control is not yet reliable.

Version-controlled database change management and automated deployment processes provide a practical way to apply those controls consistently and close visibility gaps before an audit exposes them.

2. AI governance and DORA compliance are two sides of the same problem

AI governance and DORA compliance converge on shared challenges: how is the change controlled, how is data protected, and who is accountable for the outcome?

A leader at a global reinsurer described the growing issue of ungoverned AI change very clearly. Financial risk frameworks assume that a human accepts and owns the risk. But if a two-person team drives through millions of lines of AI-generated code, who accepts that risk? How do they verify what the code does? How do they respond to an incident caused by a system nobody fully understands? Who is accountable if it causes a major failure?

Many leaders fear this is building into an industry-wide problem. AI-generated technical debt is accumulating faster than most organizations can understand or govern it, while the experienced people needed to control it are becoming scarcer.

One participant picked up the theme, describing developers, data teams and AI agents all making changes to data pipelines, with governance and accountability for the AI-generated portion effectively absent. Another described the frustration of teams submitting "vibe-coded proofs of concept" for security assessment, only to rebuild the codebase before launch, forcing the entire assessment to be repeated from scratch.

DORA provides no exemption for AI-generated change. Article 9 requires changes to ICT systems to be recorded, tested, assessed, approved, implemented, and verified in a controlled manner. Its incident-management and resilience-testing requirements apply regardless of how the change was produced.

How technical leaders can respond

Identify every AI service or agent that can access sensitive data, modify databases or change data pipelines in any environment. Remove direct, ungoverned access and ensure all AI-generated changes are subject to the same governance, change-control and data-protection policies as changes made by people.

This should include automated, deterministic checks for adherence to code policies, as well as assigning a named human owner to every AI-generated change. That owner is responsible for confirming it has passed the required governance and change-control checks before approving its release.

3. Third-party risk management is where many organizations are furthest behind

Participants saw third-party risk as the least mature area of DORA compliance. One leader at a global payments network described the accumulated exposure as “staring down the barrel of one big industry shock”.

He had seen organizations acquire smaller firms that claimed DORA compliance, only to discover that these claims did not withstand scrutiny. Backups had not been tested, critical data had no clear authoritative source, and the High Availability (HA) architecture did not match what the buyer thought it was acquiring.

A trade credit insurer described working with over 150 data providers, ranging from global firms to small local credit bureaus, and the "impossibility" of applying consistent governance standards across all of them. A commercial bank acknowledged data quality issues flowing directly from the manual data entry processes of a third-party tool.

Article 28 of DORA requires financial entities to maintain an up-to-date register of ICT service contracts and to risk-assess any providers supporting critical business functions. Many participants commented on the scale and complexity of establishing this oversight, with some discovering the gaps only when DORA forced a systematic assessment.

How technical leaders can respond

The immediate priority is to complete and validate the register, making sure it correctly identifies which providers support critical business functions. The harder task is verifying whether those providers' resilience commitments hold up in practice: do backup, recovery and data management arrangements work as claimed? That takes monitoring and auditing capable of producing ongoing evidence that the commitments continue to be met.

4. DORA needs a clear owner with cross-functional authority

DORA Article 5 places strict accountability on the 'management body' for ICT risk but does not dictate how that accountability should be organized day-to-day. Participants repeatedly raised the lack of a single senior DORA owner as the resulting problem.

In practice, responsibility for DORA often spans risk, compliance, security, data and infrastructure teams, and nobody has the authority to coordinate activities. Risks were identified but not acted on, delaying investment in the monitoring, change management and audit processes needed to address known gaps.

A global insurer gave a concrete example of how they established a Risk and Compliance Directorate sitting under the COO, with clear accountability for collecting, coordinating, and reporting DORA obligations. This created a clear route for bringing together technical evidence, compliance reporting, and the work and investment required to address identified risks.

Without that cross-functional authority, compliance teams struggle to understand the technical environment, and technical teams often don't engage with the regulatory requirements. The result is that nobody has a complete view of whether risks have been addressed across the organization, allowing compliance risks to increase over time.

How technical leaders can respond

It is not enough to establish formal ownership of DORA reporting, unless it comes with the authority to make teams act. Organizations need a named senior owner who can coordinate DORA obligations across functions, establish clear responsibility for each area and escalate unresolved gaps. Organizations already subject to ISO 27001 or SOX compliance may simply extend the authority of an existing control or security owner to DORA.

The organization should be able to quickly show which significant ICT risks have been identified, who owns each one, what action has been taken and what remains unresolved. If that picture is fragmented across teams, the ownership model is not working.

5. Build the compliance business case around operational value

One participant from a global payments network said institutions were finding it easier to secure support for investment in DORA compliance when they linked it to wider priorities. These included PSD3 obligations, cyber threat visibility and AI data readiness.

This changes the conversation at board level. Presented purely as additional compliance spending, the board often treats DORA investment as a new cost center. One payments-network leader acknowledged that some firms may even "make a bottom-line decision to absorb penalties rather than invest".

This is a dangerous calculation though, given the operational disruption, reputational damage and accumulated risk that weak controls create.

The safer approach is to strengthen the business case by showing how the same investment will also deliver operational improvements the organization already needs. Database monitoring introduced to support incident detection and investigation will also improve visibility of security and performance risks. A controlled database change process that provides DORA evidence that changes are properly managed will also support safer, more frequent delivery of those changes. Similarly, investment in better test data management to support realistic resilience testing will also enable safer AI development.

As control and automation become standard practice across teams and environments, the cost of change falls too, as does the cost of proving compliance.

How technical leaders can respond

Frame DORA investment around both the regulatory requirement and the operational problem it will solve. Define the expected improvement, whether that is faster incident response, stronger change control, lower audit effort or safer access to data, and explain how it will be measured.

From compliance planning to operational control

DORA auditors judge organizations on the controls they can demonstrate day-to-day, not on what they've documented. Perhaps above all else, these roundtables revealed the gap between the two: solid planning on paper, but only patchy evidence of control in practice.

The results included untraceable database changes, third-party systems that seemed almost impervious to consistent standards of control, and failed audits that caused real expense and disruption. An urgent problem common to both discussions was AI increasingly gaining access to sensitive systems and data, without clear processes for checks, oversight and accountability.

The priority for technical leaders looking to close the gaps between DORA planning and practice is to find where practice diverges between teams and environments. The next task is to impose consistent, automated and traceable processes, and make sure evidence is created as work happens, rather than needing to be reconstructed after an auditor asks for it.