DORA Compliance in 2026: What Article 9 Requires at the Database Layer

Originally published January 8, 2025. Updated August 3, 2026 to reflect DORA's active enforcement phase and expanded database change governance guidance.

The grace period is over. The Digital Operational Resilience Act has applied across the EU since January 17, 2025, and 2026 is the year supervisors stop checking readiness and start checking compliance.

Where enforcement stands right now:

• National competent authorities are running active supervisory reviews, not readiness checks.
• The European Supervisory Authorities have designated the first 19 critical ICT third-party providers for direct oversight.
• First formal fines are expected in the second half of the year.
• Deloitte's research found only half of institutions expected to reach full DORA compliance by the end of 2025, with another 38 percent pushing their target into 2026.

That last point is worth sitting with. Nearly half the regulated market is entering enforcement having already admitted it isn't ready.

Most of what's been written about DORA compliance covers the same ground: the five pillars, the incident reporting clock, the third-party oversight regime. That's useful, and there's good material out there on it. What's missing from almost all of it is the question that matters most to the teams who actually have to pass an examination: what does “controlled” mean when the change in question is a database schema update, and how do you prove it?

Our take: DORA didn't invent this gap. It just gave examiners a specific article to point to when they find it. Organizations that treat Article 9 as an application-layer checkbox are going to discover what SOX and PCI audits have already surfaced elsewhere in financial services: the riskiest ungoverned change in the environment was never in the app tier. It's in the database, and it always has been.

‍

Article 9 is a change management mandate, and it reaches your database

Buried inside DORA's ICT risk management framework is a requirement that gets a lot less airtime than incident reporting deadlines or penetration testing, but has more daily relevance to platform, DBA, and data engineering teams than almost anything else in the regulation.

What Article 9 actually requires:

• Documented policies and procedures for ICT change management, covering changes to software, hardware, firmware, and system components.
• Regulatory backing from Commission Delegated Regulation (EU) 2024/1774, which treats change management as its own defined control domain, alongside ICT project management and operations security, not a footnote.
• Every change recorded, tested, assessed for risk, approved, implemented, and verified in a controlled manner.
• No carve-out for the data layer, and no exception for changes that are “just DDL” or “just a quick fix.”

Read that list again. A database schema change is an ICT change. If it touches an ICT system that supports a critical or important function, Article 9 applies to it the same way it applies to an application deployment.

The gap between the regulation and the ticket queue

Here's where the compliance requirement runs into how database change actually happens at most financial institutions. A developer or DBA writes a script. It goes into a ticket. It sits in a queue. Someone picks it up during a maintenance window and runs it against production. There's often no automated policy check, no consistent risk assessment, no rollback plan beyond improvisation, and no tamper-evident record of who approved what and when.

That process might satisfy an internal sign-off culture. It does not produce the evidence Article 9 asks for. When an examiner asks for proof that a specific schema change was recorded, tested, risk-assessed, approved, and verified as a controlled, repeatable process rather than an ad hoc one, “the ticket shows it was approved” is a partial answer at best. And partial answers are what generate findings.

This is not a hypothetical. The UK's TSB migration failure predates DORA and wasn't examined under it, but it's the exact failure mode Article 9 exists to prevent: a poorly controlled technical change, executed without adequate testing and rollback planning, that took every branch offline for months and ultimately cost the bank more than £330 million and a joint FCA/PRA fine. Regulators do not need a new law to know what an ungoverned change looks like. DORA just gives them a specific article to cite when they find one.

AI changes the volume of database change. It doesn't change the accountability.

Developers at financial institutions are already using AI tools to generate schema changes and SQL. That's not a future risk to plan around, it's a current one to govern.

What changes, and what doesn't:

• Article 9 doesn't distinguish between a change a person wrote and a change an AI agent proposed. A change is a change.
• The same standard applies regardless of what authored the first draft: recorded, tested, risk-assessed, approved, implemented, verified.
• The industry has already seen what happens when that governance is missing. AI coding agents given unchecked database access have issued destructive commands in live environments, including a widely reported incident where an AI tool wiped a production database during an active change freeze.
• These are not model problems. They're change management problems, and they land squarely inside Article 9's scope.

An organization that can't govern a human-authored schema change consistently is not going to be in a stronger position when the author is a copilot.

Governing AI-generated database change isn't about slowing AI adoption down. It's about making sure every change, no matter who or what proposed it, moves through the same recorded, tested, risk-assessed, approved, and verified path before it reaches production. That consistency is what keeps AI-ready databases accurate and auditable, and it's what an examiner is actually looking for.

How Liquibase Secure produces that evidence

Article 9 describes an outcome. It doesn't prescribe a tool. But the outcome maps cleanly to the controls Liquibase Secure is built to produce, at the specific layer, the database, where most DORA programs haven't looked closely yet.

‍

Each row in that table is doing a specific job, not a marketing label stretched to fit a regulation:

• Policy checks make “tested” and “risk-assessed” real. Every changeset is validated against naming standards, permission rules, and destructive-operation checks (DROP, TRUNCATE, unreviewed ALTER) before it ever reaches an environment, not after something breaks in production.
• RBAC and ITSM integration make “approved” enforceable, without an approval engine built into Liquibase. Liquibase Secure doesn't run the approval workflow itself. It enforces role-based access so only authorized identities can promote a change, and it integrates with existing systems like ServiceNow or CI/CD approval gates so a deployment holds until that external sign-off is granted.
• Flows make “implemented in a controlled manner” repeatable. The same guardrails run the same way every time, regardless of who triggers the deployment or which environment it's headed to, so “controlled” doesn't depend on who's on call that week.
• Drift detection makes “verified” continuous instead of a one-time approval. Production is compared against the last approved baseline on an ongoing basis, and anything that got there another way gets flagged before it compounds.
• The audit trail makes “recorded” exportable. Author, approver, timestamp, and outcome are captured for every change automatically, so producing evidence for an examiner is a query, not a reconstruction project.

This isn't theoretical for financial institutions specifically. Zions Bank used Liquibase to achieve 120x deployment efficiency, a 95 percent reduction in errors, and a 90 percent reduction in the DBA intervention routine database changes required. That's not a compliance case study. It's a controls story that happens to satisfy a compliance requirement, which is exactly the pattern DORA rewards: governance that also makes delivery faster, not slower.

It also has to work everywhere the data actually lives. A typical enterprise bank runs Oracle, SQL Server, PostgreSQL, Snowflake, Databricks, and DynamoDB at the same time, often as a result of M&A, cloud migration, or ordinary organic growth. Article 9 doesn't stop applying at the edge of whatever platform a governance tool happens to support. Liquibase Secure governs change consistently across 65+ database platforms, so the gap doesn't just relocate from Oracle to whatever the next migration target is.

None of this requires ripping out an existing GRC or business continuity program. DORA compliance work at most institutions is already anchored in business impact analysis, incident response, and third-party risk platforms, and it should stay that way. Liquibase Secure doesn't replace that work. It closes the one piece most DORA programs have left ungoverned: the database changes feeding everything else.

Why this is worth fixing now, not after an examination

Compliance is rarely what gets budget approved on its own merits, but it's consistently what triggers the conversation. An audit finding or a supervisory letter creates urgency that a roadmap slide never will. Once the pipeline exists, the same governance that satisfies an examiner also cuts deployment cycles from days to minutes, catches errors before they reach production, and gives DBA teams their time back from routine script execution.

DORA enforcement in 2026 isn't a reason to build a compliance program from scratch. It's a reason to make sure the one you have actually reaches the database, where a large share of your riskiest, least-governed ICT change has been happening in plain sight.

Govern database change the way DORA expects.

See how Liquibase Secure gives financial institutions a recorded, tested, approved, and verified path for every database change, human-authored or AI-generated.

Request a custom demo →

‍