EU’s DORA Isn’t the Villain — Sloppy Resilience Is

Viewing DORA through the Data Management Lens.

If you’ve been watching your systems coast along on good intentions, duct tape, and the occasional “we’ll fix that later” it’s time to meet DORA.

The Digital Operational Resilience Act (DORA) is the EU’s answer to the question:

“What happens when everything breaks?”

DORA doesn’t care how shiny your cloud architecture looks or how many buzzwords you can fit into a slide deck. It cares about two things: resilience and proof that your systems can recover quickly, securely, and consistently from disruptions.

Unlike GDPR, which made you scramble to find your cookie settings, DORA is here to stress-test your digital backbone and your databases are front and center. Why? Because they hold the operational crown jewels: transactions, customer records, logs, compliance data, and more.

When databases go down, everything else follows.

DORA applies to a broad range of organizations — from banks to payment platforms, fintechs, and the tech providers that support them. This includes cloud services, managed database offerings, and third-party vendors. But — and here’s the twist — even if you’re using best-in-class cloud platforms, you don’t get to outsource your accountability.

This is where the shared responsibility model enters the scene. Yes, your cloud provider secures the underlying infrastructure. But everything above that — access control, backup strategies, recovery testing, monitoring, and response plans — still belongs to you. In the eyes of DORA, your third-party stack is an extension of your own system, not an excuse.

So, if your current disaster recovery plan is “hope we never need it” this article is for you.

We’ll walk through what DORA compliance really means for your databases — whether on-prem, in the cloud, or managed by someone else. From high availability and backup testing to observability and third-party accountability, you’ll learn how to bring your data layer up to standard — with fewer surprises when the auditors (or outages) come knocking.

High Availability Is No Longer Optional

[…] all financial entities need to make sure they can withstand, respond to, and recover from all types of ICT-related disruptions and threats.
[]

Downtime is no longer just a nuisance — under DORA, it’s a compliance risk. The regulation mandates that financial entities ensure their critical systems, including databases, can continue operating even in the face of disruptions. That means high availability (HA) is not just a best practice anymore — it’s a baseline requirement.

In technical terms, DORA expects organizations to plan for the worst and prove they can still function. This includes building infrastructure that supports:

• Automated failover mechanisms: If your primary database node goes offline, a standby instance in another zone or region must take over without manual intervention or data loss.
• Geographic redundancy: Databases supporting critical services must span failure domains — ideally across multiple availability zones or regions.
• Recovery Time Objective (RTO) and Recovery Point Objective (RPO): You need clear metrics for how quickly systems recover and how much data you can afford to lose — and you must be able to meet those targets consistently.
• Resilience testing and documentation
  It’s not enough to claim HA — you need to test it under real-world conditions and maintain records that demonstrate those tests were successful.

In practice, this means that having a single-region database with a standby server in the same data center might be challenged by DORA — especially if you’ve never tested switching over under real pressure.

[…] partial or total failure of premises, including office and business premises, and data centres […]
[DORA Reference: Article 26]

Note that DORA doesn’t explicitly prohibit standby servers in the same data center, it requires financial entities to assess and mitigate risks to their ICT systems comprehensively. Implementing a standby server within the same data center may not provide adequate protection against certain risks, such as power outages, natural disasters, or other localized incidents that could compromise the entire facility. Therefore, to align with DORA’s requirements for operational resilience, it’s advisable to deploy system resources across geographically separate locations.

If you’re relying on a managed service or cloud platform, be sure to validate that:

• Multi-zone or multi-region replication is enabled and tested
• Automated backup and restore mechanisms are functional
• SLAs from your provider align with your compliance needs
• Monitoring tools are in place to detect outages and track recovery times

Even with cloud-native HA features you must be able to explain — and prove — how your database architecture supports continuity of operations, even in extreme scenarios.

“[…] financial entities shall remain fully responsible for the verification of compliance with the ICT risk management requirements”
[DORA Reference: Article 28]

In short, DORA asks a simple question: Can your systems still serve customers if your primary infrastructure fails?

If the answer isn’t a confident — a tested “yes” — you have work to do.

Logging and Observability Are Mandatory

Under DORA, it’s no longer acceptable to find out your systems were down after customers start calling.

[…] establish, implement, and operate technical, […] incident management process, including mechanisms to enable a prompt detection of anomalous activities […]
[DORA Reference: Article 22]

The regulation expects financial entities to have real-time visibility into their critical systems — including databases — with the ability to detect, investigate, and respond to incidents as they happen.

This means that logging and observability are not optional add-ons. They are foundational controls, and your database systems are fully within scope.

What That Means in Practice:

• Access Logging: You must record who accessed the database, when, from where, and what they did — especially in systems that store or process sensitive financial data. Every authentication attempt, query, or schema change must be traceable.
• Query and Activity Monitoring: It’s not enough to know someone connected — you must monitor how they’re using the database. That includes slow queries, spikes in access frequency, or unusual patterns that could indicate misuse or attack.
• Error and Anomaly Detection: Your systems must detect and alert on anomalies — whether it’s an unexpected spike in failed logins, replication lag, or a sudden drop in query performance.
• Centralized Logging Integration: Logs should not live exclusively on the database host. DORA expects integration with a central observability system. That ensures data is retained, aggregated, analyzed, and protected against tampering.
• Log Retention and Integrity: Retention policies must be clearly defined — and logs must be stored securely, with protections to prevent deletion or alteration.

This includes identifying events in real time, classifying them appropriately, and ensuring they are escalated, documented, and resolved efficiently.

In essence, DORA requires that your database systems can speak clearly, consistently, and immediately when something’s wrong — and that someone is always listening.

While many modern databases support native logging and monitoring, the compliance challenge lies in how well those tools are configured, integrated, and maintained. For example, enabling query logging without log rotation or encryption introduces more risk than it solves. Likewise, keeping logs only locally on disk without backups or off-host aggregation won’t meet DORA standards.

If you’re using a cloud database, ensure that:

• Audit logging is enabled and properly configured
• Logs are exported to centralized monitoring tools (e.g. GCP Cloud Monitoring, Elastic, Datadog, …)
• Sensitive data is not inadvertently written to logs
• Monitoring systems are subject to the same access controls and alerting rules as production systems

DORA doesn’t just want to know that your database is working. It wants to know that you know — and that you’re ready to act the moment something goes wrong.

Backup and Recovery Plans Are Essential

Backups are only useful if they work when you need them. DORA takes this to its logical conclusion: you must not only back up your data — you must be able to restore it quickly, reliably, and under pressure.

For database systems, this is a cornerstone of operational resilience.

The regulation is clear: it’s not enough to schedule nightly backups and call it a day. Financial entities must develop, test, and document comprehensive recovery strategies — and prove that they meet their business continuity objectives.

What That Means in Practice:

• Reliable, Encrypted Backups: Backups must be created regularly and stored securely — ideally in geographically separate locations. They should be encrypted both in transit and at rest, using robust key management practices.
• Documented Recovery Workflows: There should be written, version-controlled procedures that clearly explain how to restore each database — step-by-step. These workflows must include prerequisites, timing expectations, and validation steps.
• Regular, Auditable Recovery Tests: DORA requires that you actually test your ability to restore from backups — not just once, but on a recurring basis. These tests should simulate realistic disaster scenarios (e.g. region outage, data corruption, ransomware) and be auditable.
• Validation of RTO and RPO Objectives
  You must define your Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for each database, and demonstrate that you can meet them. If you’re not measuring this during your restore drills, you’re not truly testing.

These plans must include procedures for ensuring the availability, continuity and recovery of critical or important functions, including backup policies and restoration testing, and the identification of alternative systems and manual workarounds.

In other words, a backup you’ve never tried to restore is a compliance risk — not a safety net.

Additional Considerations for Databases:

• Version compatibility: Can you restore a backup to a newer or patched version of your database engine? Have you tested that?
• Point-in-time recovery: Can you restore the database to a specific point — such as 30 minutes before a data corruption incident?
• Backups of system-level metadata: Are you backing up user roles, permissions, functions, stored procedures, and configuration settings — not just the raw data?
• Isolation and tamper-resistance: Backups should be stored in environments that are inaccessible from production to prevent for example ransomware attacks or accidental deletion.

If you’re using managed databases, ensure that:

• Automated backups are enabled (daily, hourly, or continuous depending on data criticality)
• You have access to initiate restores or export backups if needed
• Restore performance and success rates are measured and logged
• Documentation reflects both provider capabilities and your internal procedures

DORA does not expect perfection — but it does expect preparedness. When an outage hits, the question isn’t “Did we back up our data?” It’s “Can we restore it — fast, securely, and under stress?”

If your answer is anything less than a confident “yes, and we tested it last quarter” now’s the time to act.

Third-Party Database Providers Are Your Responsibility

Using cloud or managed database services doesn’t absolve you of responsibility. In fact, it adds another layer of accountability.

While providers handle the infrastructure, patching, and sometimes even replication and backups, you are still responsible for ensuring that your use of these services meets all applicable requirements.

In simple terms: your cloud database provider might keep the lights on, but you still own the compliance.

What You Need to Do

• Perform Due Diligence on Providers: Evaluate the operational resilience, security controls, and compliance posture of your third-party providers — whether it’s a hyperscaler or a specialized database vendor. Review certifications, incident response capabilities, and documented SLAs.
• Map the Shared Responsibility Model Clearly: Understand which controls are handled by the provider and which remain your responsibility. For example: a) They may encrypt the data at rest — but you must manage who has access. b) They may take backups — but you must test and validate them against your recovery objectives.
• Include Providers in Your Resilience Planning: Third-party services should not be “black boxes” Ensure they are included in: Business impact assessments, Continuity and recovery testing, Risk evaluations, Third-party risk registers
• Set and Monitor SLAs: Service Level Agreements must align with your defined RTO and RPO targets — and be backed by real operational transparency (uptime reporting, audit logs, support escalation paths).
• Plan for Exit and Substitution: DORA also emphasizes the need for exit strategies. You should have a realistic, documented plan to migrate away from a provider if needed — whether due to vendor failure, breach of contract, or strategic shifts.

DORA doesn’t prohibit the use of cloud or third-party database platforms. It simply says: if your systems fail because of them, you’re still accountable. That’s a mindset shift — not just for compliance teams, but for architects and engineers.

In a DORA world, resilience is your responsibility — regardless of where the database physically runs.

Documentation, Testing, and Drills Are Required

DORA is not just about having resilient systems — it’s about proving they are resilient. That proof comes in the form of up-to-date documentation, regular testing, and real-world operational drills.

If you can’t show how your database systems behave under stress — and how your teams respond — you’re not compliant.

In short: resilience is not theoretical. DORA expects operational readiness to be validated, not assumed.

This includes not only penetration testing and vulnerability assessments but also continuity and recovery testing, tailored to each critical system — including databases.

What This Means for Your Databases

• Document Everything (and keep it current): Architectural diagrams, replication setups, backup procedures, failover paths, access control lists, versioning policies — all of these must be clearly documented, version-controlled, and reviewed regularly. If your documentation lives in a dusty Confluence page last touched in 2021, it won’t satisfy DORA.
• Simulate Real Failures, Not Just Ideal Restores: It’s easy to test restoring a database from backup on a sunny Tuesday afternoon. DORA wants you to test under real-world conditions: What happens if a region goes down? Can you fail over in under 5 minutes? What if your primary backup is corrupted?
• These aren’t just technical drills: They are business continuity exercises, and they must involve IT, security, risk, and operations teams.
• Test Roles, Not Just Systems: Who initiates the recovery? Who authorizes it? Who verifies data integrity? DORA wants you to test people and processes, not just buttons and scripts.
• Keep Evidence of Testing Activities: You must maintain records of (for internal reviews and if requested for regulators): What was tested? When and how it was tested? The results and lessons learned? Action items and follow-up progress?
• Drills Must Be Regular, Not One-Off: DORA requires that your testing program is recurring and part of your ongoing resilience strategy. For critical systems this means regular drills and not just annual check-the-box exercises.

Tips for Database Resilience Testing

• Create a playbook for intentional failure injection (e.g. shutting down a primary node)
• Track RTO/RPO results for each test and compare against compliance targets
• Align your test scope with criticality — high-impact databases require deeper scenarios

DORA doesn’t expect perfection, but it expects preparation. If your recovery plan is a theoretical document that’s never been practiced, you’re at risk — both operationally and from a compliance perspective.

The most resilient teams are those that train like they’ll need it. DORA simply codifies that expectation.

Conclusion

DORA raises the bar for operational resilience — and your databases are squarely in scope. From high availability and tested backups to logging, documentation, and vendor accountability, compliance isn’t optional and assumptions won’t cut it.