This article examines DORA's requirements for database change management and explains how Redgate Flyway Enterprise addresses them.

The EU's Digital Operational Resilience Act (DORA) came into full effect in January 2025. It is designed to strengthen the ability of financial institutions to withstand operational disruption, whether caused by technology failures, data corruption, human error, or a cyberattack. For every financial entity operating in the EU, from banks and insurers to investment firms and critical third-party providers, it sets a new baseline for how Information and Communication Technology (ICT) risk must be managed, monitored, and evidenced.

Much of the existing guidance and discussion focusses on network security, managing cybersecurity threats, incident response, and third-party risk. What gets far less attention is the database, the system of record that sits beneath almost every critical business process.

Poorly controlled database change is a well-documented source of operational disruption, and so a major compliance risk under DORA. It also makes it very hard for an organization to demonstrate that changes to a critical ICT system are "recorded, tested, assessed, approved, implemented and verified in a controlled manner", which is precisely what Article 9 of DORA requires.

Redgate Flyway Enterprise provides the governance framework for database change that DORA demands, by embedding the required checks, controls, and traceability directly into an automated deployment process.

What DORA Requires (From a Database Perspective)

DORA is built around five broad areas:

• Governance and ICT Risk Management (Arts. 5–9)
  Establish a framework of governance, accountability, and controls ensuring all changes to ICT systems are traceable, tested, and auditable.
• Incident Response, Recovery and Reporting (Arts. 11–14, 17–23).
  Detect and report major ICT-related incidents promptly, and maintain plans for business continuity, recovery, and communication
• Operational Resilience Testing (Arts. 24–27)
  Regularly test critical business services under realistic conditions, which may include advanced threat-led penetration testing (TLPT)
• ICT Third-Party Risk (Arts. 28–44)
  Ensure oversight, contract controls, and monitoring of any external ICT providers supporting critical functions
• Information Sharing (Art. 45)
  Voluntarily exchange cyber-threat intelligence to strengthen sector-wide resilience

Database schema changes are ICT changes and fall squarely under DORA's ICT governance and risk management obligations. Article 9 sets out the protection and prevention measures required to ensure ICT systems, including databases, maintain resilience, continuity, and availability, and are protected against data corruption, loss, and integrity issues [9(3)b and d]. It requires that any changes to these systems are "recorded, tested, assessed, approved, implemented and verified in a controlled manner" [9(4)e].

In the context of database changes, this means that a DORA auditor may expect organizations to be able to demonstrate policies and processes to ensure:

• A complete and accurate record of what changed, when, by whom, and why.
• All changes, including hotfixes, are checked and tested to minimize risk
• Changes are reviewed and approved by the appropriate 'lines of management' before deployment.
• Any uncontrolled change is detected and investigated

They will expect documented evidence that these policies and processes don't just exist on paper but are continuously enforced and maintained.

For many organizations, this is where gaps exist. Application code may already be version-controlled and deployed through automated pipelines. Database changes, by contrast, are often handled through manual scripts, ad-hoc DBA interventions, or undocumented hotfixes. These processes are poorly controlled and leave little or no reliable evidence that DORA requirements are consistently met.

The Compliance Risk Hidden in Your Database Pipeline

The database is frequently the last part of the technology stack to be brought under proper change control. There are understandable reasons for this: database changes are often handled by specialist DBAs working outside normal development workflows, the consequences of failed deployments in mission-critical environments can be severe, and legacy systems carry accumulated complexity that makes automation feel risky.

But this caution creates its own risk. For organizations still relying on ad hoc scripts, manual DBA access, or undocumented hotfixes, it is extremely difficult to prove that changes to their ICT systems are recorded, tested, assessed, approved, implemented, and verified in a controlled manner, as article 9(4)(e) requires.

No reliable 'audit trail' of change

DORA requires changes to be recorded. Where database changes are applied informally, via ad-hoc scripts, manual DBA access, or undocumented emergency fixes, there is no consistent record of what changed, when, by whom, or why. Reconstructing the history of a production database for a regulatory audit becomes an exercise in detective work, and the answers are rarely complete.

No way to detect out-of-process change (a.k.a. 'environment drift')

An automated, version-controlled database change process only demonstrates compliance if all changes use this process. Without drift detection, changes made outside the formal process can be missed, and so will be deployed without being recorded, tested, assessed or approved.

When development, test, staging, and production environments drift out of sync, it is difficult to validate changes before they go live, which increases the risk of deployment failures, with direct relevance to DORA's operational resilience requirements.

No guarantee that changes are tested and approved before deployment

Without a structured deployment process that enforces code review, test and approval gates, with automated checks that catch problematic changes before they reach production, there is no reliable mechanism to meet or demonstrate compliance with DORA 9(3)(b), 9(3)(d) or 9(4)(e).

Slow recovery from database-related incidents

Article 11 requires financial entities to maintain business continuity plans and recover from ICT incidents quickly and with minimal disruption. Documented and tested plans for recovery from database deployment failures, including rollback or fail-forward strategies, are a necessary component of proving to auditors that services will be restored within stated recovery time and recovery point objectives.

Inability to demonstrate control

Regulators and auditors will want more than an assertion that controls exist. Article 9(4)(e) requires evidence: change logs, approval records, deployment histories, test results. Each of the problems above doesn't just create operational risk; it creates an evidential gap that is very difficult to close retrospectively.

How Redgate Flyway Enterprise Addresses DORA's Requirements

DORA does not prescribe a specific database deployment tool. It does, however, require controlled, documented, risk-based ICT change management. Articles 9(3)(b) and (d) emphasize the need to minimize disruption caused by technical flaws, poor administration, and human error. Article 9(4)(e) requires that changes are traceable, tested, and controlled.

For databases that support critical or important functions, Redgate Flyway Enterprise can help implement and enforce these controls as part of a wider ICT change management process. It is built on the principle that database schema changes must be managed with the same discipline as application code, bringing to the database the version control, automation, and CI/CD practices that are standard in application development.

DORA Objective	Official DORA anchor	How Flyway Enterprise can support it
Recorded and traceable ICT changes	Article 9(4)(e).	Every migration script has a version number and is stored and tracked in version control, with a direct record of which database objects were affected by each versioned migration (schema model tracking). Flyway Enterprise records exactly what was deployed, to which environment, at what time, by whom, and whether it succeeded or failed.
Pre-deployment testing, review and approval	Article 9(4)(e); Art. 9(3)(b) and (d).	Flyway migrations are reviewed and verified through the standard CI/CD pipeline, including automated code policy checks that catch security issues, performance risks, and error-prone patterns before deployment. Approval gates can be enforced before any script reaches production.
Detect out-of-process change (drift) and ensure environmental consistency.	Primary: Article 9(4)(e) Secondary: Article 24(1).	Flyway Enterprise's drift detection identifies when a database has diverged from its expected state, flagging unauthorized or undocumented changes. Use of versioned migrations, state-based approaches, and drift checks ensures pre-production environments remain consistent, so what you test accurately reflects what will be deployed. By detecting database drift, this also closes a control gap that can impact operational resilience (24(1))
Faster recovery from database-related incidents	Art. 11	Planned and tested database rollback and fail-forward strategies, combined with a complete deployment history, support business continuity plans and help prove that services can be restored within stated recovery time and recovery point objectives.
Centralized, auditable history of database deployments	Article 9(4)(e).	Flyway Enterprise embedded in CI/CD pipelines provides a centralized, history of all database deployments with change logs and deployment histories, without requiring direct environment access.

Database as Code: The Foundation of Auditable Change

Under DORA 9(4)(e), any database deployments characterised by running untracked database scripts and performing undocumented production fixes are difficult to defend. The core principle underpinning Flyway Enterprise’s approach, by contrast, is "database as code".

Just as Infrastructure as Code turns manual server configuration into a versioned, automated, repeatable, and auditable process, so Flyway Enterprise does the same for database change management. It replaces ad hoc scripts and manual fixes with a controlled, traceable deployment process that can be reviewed, tested, and proved to regulators.

Planned database changes are defined as versioned migration scripts in the version control system and are tracked through the Flyway schema history table. As database changes are applied, Flyway's schema model records changes to the database state (the structure of each individual database object), providing a single place to track how the database structure has changed across versions.

Every change made through the Flyway-controlled process can be linked to this source control history and to deployment logs, and so provides direct, compliance-critical evidence of controlled change management that is difficult or impossible to achieve through manual processes:

• Every deployed change has an author, a timestamp, and a version number – automatically.
• The complete structure or 'state' of the database is visible – from version control history, for any given database version
• Every version-controlled change can be linked to deployment trail – giving direct evidence of what changes were intended, what was deployed, where it was deployed, when it ran, and whether it succeeded or failed
• Database change is traceable from 'commit' to deployment outcome – this evidence can be included in wider ICT change-management, audit, and supervisory review processes.

This 'database as code' approach gives teams a much stronger basis for auditable database change management, but it also relies on automatic detection of any out-of-process schema changes.

Drift Detection: Catching out-of-process changes before they become Incidents

Every change made through Flyway is traceable and controlled, but Article 9(4)(e) is only satisfied if uncontrolled changes are detected too.

Because Flyway tracks the expected database state for each deployed version, it can alert when a target database has drifted and no longer matches the expected, version-controlled state. Emergency hotfixes or undocumented manual changes made outside the formal process can be captured and brought back into version control. Any unexpected changes can be reported and investigated.

Drift detection also ensures that differences between database environments, such as development, testing, QA, and staging, are caught and reconciled before they undermine the validity of testing, deployment and rollback strategies.

Beyond Article 9(4)(e), drift detection supports Article 24(1)'s requirement to identify weaknesses and gaps in digital operational resilience; uncontrolled database change is precisely that. It also addresses Article 9(3)'s requirement to prevent technical flaws and data corruption and aligns with Article 10's broader expectation that anomalous activity in ICT systems is detected and investigated.

Code Policy and Pre-Deployment Checks in an automated DevOps pipeline

Embedded in an automated CI/CD pipeline, Flyway Enterprise's built-in code policy checks and testing ensure that no migration reaches production without having been reviewed, validated, and approved. This transforms the approval and assessment requirements of Article 9(4)(e) from a manual, easily bypassed gate into an enforced, documented step in every deployment.

Recovering quickly from database incidents

Article 11 requires financial entities to maintain tested plans for recovering from ICT incidents quickly and with minimal disruption. Within the context of recovery from database deployment issues, Flyway supports this in three ways:

• Migrations execute within a transaction – so any deployment error automatically rolls back the entire migration rather than leaving the database in a partial state
• Versioned undo migrations – provide a tested, reviewed rollback path to the previous database version and state
• Flyway Schema comparison can generate roll forward scripts – Where a deployment has resulted in an unexpected state, Flyway can generate a script to roll forward to the intended, version-controlled state.

Third-Party Risk: extending secured, governed database across Your Supply Chain

DORA’s third-party risk requirements are much broader than database deployment. They cover governance, contractual obligations, oversight, concentration risk, exit strategies, and the financial entity’s continuing responsibility for ICT services delivered by third parties.

However, where external suppliers, outsourced development teams, or managed service providers contribute database changes, DORA 28(1)(a) is clear that the financial entity will remain fully responsible for DORA compliance.

Flyway Enterprise can provide evidence that helps demonstrate that outsourced or supplier-authored database changes are subject to the same auditable database change management process as internal contributors. Regardless of who authors the database change it passes through the same version-controlled, policy-checked, pipeline-enforced process, and so will be recorded and traceable.

Flyway Enterprise's role-based access controls and secrets management via secure vault also ensure that regardless of who is involved in the deployment process, access to the database change process is controlled, with credentials centrally and securely managed, and the principle of least privilege is maintained. This directly supports the access control requirements of Article 9(4)(c).

Building the Business Case: Compliance as a Byproduct of Good Practice

The capabilities that DORA requires are not compliance-specific overhead. They are the same capabilities that make development teams faster, more confident, and less likely to cause production incidents.

A version-controlled database change process gives teams a clearer view of what is changing, why it is changing, who approved it, where it has been deployed, and whether it succeeded. That reduces reliance on manual handovers, undocumented scripts, and post-incident reconstruction. It also gives DBAs, developers, operations teams, and compliance stakeholders a shared record of database change activity.

This matters for the business case because it reframes the investment. The question is not 'how much will DORA compliance cost?' It is 'how much is the current lack of database change control already costing us in incidents, slow deployments, and audit preparation time?' For most organisations, the answer to the second question more than justifies the investment implied by the first.

"With all the tests in place, they make big changes and forget the database migration complexity. Every database change is tracked with complete traceability: what was developed, by whom, when it was approved, and when it was deployed." — Credit union customer using Flyway Enterprise

Conclusion: Informal Database Change Management is not DORA compliant

DORA has raised the bar for how financial entities must manage, monitor, and document their technology operations. For database teams, this is a moment of clarity: the informal, manual, undocumented approaches that have been tolerated for years are no longer adequate.

The good news is that the solution is not just a compliance project, but a modernisation of how database changes are managed. Redgate Flyway Enterprise places proper governance at the heart of database change management, modernising how changes are managed, controlled, and proved.

Database teams get the version control, automated deployments, drift detection, and centralised change tracking they need to move faster safely, deploying more frequently and with greater confidence and less operational risk. These same governance controls give financial institutions what they need to meet DORA's requirements and build the kind of robust, resilient database operations that withstand regulatory scrutiny.

For financial services organisations evaluating their DORA readiness, the database is the place to start.

Find out more

Explore Redgate Flyway Enterprise and auditable database change management, or speak to our team about your specific compliance requirements.