Database Change Governance Under DORA

The Digital Operational Resilience Act (DORA) never uses the word database. It does not need to. Article 9(4)(d) requires policies and procedures for ICT change management, and Article 17 of the Regulatory Technical Standards (RTS) that complete it, Commission Delegated Regulation (EU) 2024/1774, sets out what those procedures must contain. A schema migration on a production system is an ICT change. An engineer running a single UPDATE statement against a live table is an ICT change too, whether or not anyone recorded it. This guide sets out what the two texts require, why database work slips out of the controls that already cover application releases, and the evidence that answers a competent authority.

Where the obligation sits

Article 9 of DORA carries the protection and prevention duties. Point (d) of Article 9(4) requires financial entities to implement policies and procedures for ICT change management, including changes to software, hardware, firmware components, systems or security parameters. Three qualifiers in that sentence do most of the work:

• the procedures are based on a risk assessment approach, so the depth of control follows the risk the change carries, not a uniform ceremony applied to everything;
• they are an integral part of the overall change management process of the financial entity, which rules out an ICT process running beside the corporate one and answering to nobody;
• every change is recorded, tested, assessed, approved, implemented and verified in a controlled manner. Six verbs, each of which a reviewer can ask you to evidence separately.

Article 9(4)(c) sits one point earlier and matters just as much at the database layer: access to ICT assets and data is limited to what is required for legitimate and approved functions and activities. A standing administrator connection to production fails that test on its own terms, before any change process is even discussed.

Sources: Regulation (EU) 2022/2554, Article 9, and Commission Delegated Regulation (EU) 2024/1774, Articles 16, 17, 20 and 21. The full standards map is on our RTS and ITS reference page.

What Article 17 of the RTS adds

DORA states the outcome; the RTS states the mechanics. Article 17 sits in the ICT operations chapter and turns change management into a list of things your procedure has to contain. Read at the database layer, it looks like this.

Why database changes escape the controls you already have

Most entities running a mature delivery process already satisfy Article 17 for application code: a pull request, an automated pipeline, a second reviewer, an audit trail generated as a by-product. Database work is where that evidence chain usually breaks, in four recognisable ways.

• The out-of-band fix. A data correction is not a release, so it never enters the release process. It is still a change to an ICT system supporting a business service.
• The shared account. Several people connect through one technical account, so the audit trail records the account rather than the person. Article 20 of the RTS asks for identity management that attributes actions to individuals.
• The unversioned schema. Application code has a history; the schema has whatever state the last person left it in. Without a version, there is nothing to compare a production database against and no way to prove which changes were applied.
• The copy of production in test. A restore into a lower environment is fast, convenient, and puts live customer data where the access controls are weaker.

The four have one thing in common: none of them is deliberate non-compliance. They are the residue of processes designed around applications, on systems where the data itself is the asset. If your Article 8 asset mapping lists a database as supporting a critical or important function, the controls above are the ones a reviewer will test.

Production data access is a separate duty

Reading customer records changes nothing, so it produces no change record, and it is exactly the activity that most often has no control attached to it. DORA and the RTS govern it anyway.

• Article 9(4)(c) of DORA limits access to ICT assets and data to what legitimate and approved functions require.
• Article 20 of the RTS covers identity management: accounts attributable to an identified person, with the life cycle that follows.
• Article 21 of the RTS covers access control. Privileged access is granted on a need-to-use or ad hoc basis, granting, review and revocation are assigned to named roles, and rights are reviewed periodically, at least annually, with a higher frequency where the account reaches a critical or important function.
• Article 16(5) of the RTS is the one teams forget: non-production environments hold only anonymised, pseudonymised or randomised production data. Restoring a live backup into a test environment is the single most common breach of it.

General Data Protection Regulation obligations run alongside, not instead: a query against a customer table is a processing operation with its own lawful basis and its own logging expectations.

Emergency changes: the gap reviewers open first

Article 17 explicitly allows emergency changes, and attaches two conditions: adequate safeguards at the time, and documentation, re-evaluation, assessment and approval after implementation. That second half is what tends to be missing. A defensible emergency route needs four things written down before you need it: who may declare an emergency, what the safeguards are while it runs, the deadline for retrospective documentation, and who performs the retrospective approval. Add a fifth in practice: a count. If a third of your changes are emergencies, the emergency route has quietly become the normal route, and that is a finding on its own.

Segregation of duties when the team is three people

Article 17 asks for independence between the approving function and the implementing function. It does not ask for a large team. Where headcount makes strict separation impossible, the recognised answer is compensating controls, documented as such:

• approval by someone outside the requesting function, even where that person is not a database specialist, provided the change record is legible enough for them to challenge;
• an automated gate that blocks a class of statements outright, so the control does not depend on a human being available;
• review by a second person within a fixed window after execution, where prior approval is genuinely impossible;
• full session capture on privileged connections, so what was actually executed is reconstructible rather than asserted.

What does not work is leaving the gap undocumented. A recorded compensating control is a supervisory conversation; a silent one is a finding.

The evidence a competent authority can ask for

• The change management policy, showing that database changes are in scope and how their risk classification is set.
• A change register covering a period, from which any single production change can be traced to its request, approval, test result and verification.
• The list of accounts holding privileged access to production databases, with the last review date and the person accountable for each.
• Evidence that non-production environments hold no identifiable production data, or the masking process that makes that true.
• Emergency changes over the period, each with its retrospective approval, and the count as a proportion of all changes.
• One rollback that was actually exercised, in a test or in production. A rollback procedure nobody has run is a document, not a control.

Our free gap analysis tool scores the Pillar 1 controls this sits inside, and the ICT Risk Management Playbook carries the policy language and the RACI that go with it.

Build, buy, or extend what you have

Three routes satisfy Article 17 at the database layer. Extending the pipeline you already run is the cheapest: version the schema, put migrations through the same review as application code, and remove interactive production access so the pipeline becomes the only path. Buying a database governance platform buys the approval workflow, the policy engine and the audit trail as a product. Building is rarely worth it, though a scripted approval gate plus session capture is a legitimate starting point.

One consequence of buying deserves to be priced in before the demo. A tool that sits in the path of your production data becomes an ICT third-party service provider, and if the database supports a critical or important function, the full Article 28 to 30 regime follows: an entry in the Register of Information, the contractual provisions of Article 30, a view on data location and sub-outsourcing, and a documented exit strategy. Ask for the provider legal entity, the deployment model, the hosting location, an information security certification and a data processing agreement before the pilot, not after it. Where the provider is established outside the European Union, transfer safeguards belong in the same file. Our third-party risk page and the Third-Party Risk Playbook cover the assessment that has to happen first. An on-premise deployment inside your own perimeter changes that calculation substantially, and is worth asking about early.

Five gestures

1. Declare database changes in scope. One sentence in the change management policy stating that schema and data changes on production systems follow the same process. Most policies are silent, and silence is what creates the out-of-band habit.
2. Version the schema. Until schema state has a history, nothing else in Article 17 is verifiable.
3. Remove standing production access. Move to time-bound, approved, attributable access. This satisfies Article 9(4)(c) and Article 21 of the RTS at the same time, and it is the change that most reduces risk per unit of effort.
4. Write the emergency route, then count how often it is used. Both halves are the control.
5. Mask what leaves production. Article 16(5) is unambiguous and easier to satisfy before a lower environment exists than after.

Delivery teams carrying this work will find the same ground covered, with exercises, in the DORA for DevOps and Platform Teams course.