GDPR vs DORA: What Database Teams Need to Know About Both

Two Regulations, One Database

If you work in financial services in the EU, your database must satisfy two separate regulatory frameworks simultaneously. Understanding where they overlap — and where they diverge — determines how efficiently you can implement both.

The Fundamental Difference

GDPR asks: "Are you protecting people's personal data?"

DORA asks: "Can your financial services keep running when things go wrong?"

GDPR is about data protection rights. DORA is about operational resilience. They come from different legislative traditions, have different enforcement bodies, and have different primary concerns. But at the database level, many of the technical controls are the same.

Where They Overlap

Access Control

Both regulations require that only authorized personnel access sensitive data:

• GDPR Article 32: "appropriate technical measures" including access control
• DORA Article 9(4)(c): "strong authentication mechanisms" and access rights policies

In practice: role-based access, Row-Level Security, least privilege, and regular access reviews satisfy both.

Encryption

• GDPR Article 32(1)(a): "encryption of personal data"
• DORA Article 9(4)(d): "encryption and cryptographic controls"

In practice: SSL/TLS for connections, encryption at rest, SCRAM-SHA-256 for authentication.

Audit Trails

• GDPR Article 5(2): accountability principle — you must demonstrate compliance
• DORA Article 12: logging and monitoring of ICT operations

In practice: immutable audit logs, DDL/DML change tracking, access logging.

Incident Reporting

Both require you to report incidents, but the requirements differ significantly:

| Aspect | GDPR (Article 33/34) | DORA (Articles 17-19) | |--------|----------------------|----------------------| | Report to | Supervisory authority (DPA) | Competent authority (e.g., BaFin) | | Timeline | 72 hours | 4 hours (initial), 72 hours (intermediate), 1 month (final) | | Threshold | Risk to data subjects | Major ICT-related incident | | Content | Nature of breach, data types, subjects affected | Impact assessment, root cause, recovery actions | | Data subject notification | Required if high risk | Not directly required |

A single incident — say, unauthorized database access at a bank — can trigger reporting obligations under both regulations simultaneously, to different authorities, with different timelines and content requirements.

Where They Diverge

GDPR-Only Requirements

These have no DORA equivalent:

• Right to erasure (Article 17): Individuals can request deletion of their data. DORA has no such concept.
• Data portability (Article 20): Export personal data in a machine-readable format.
• Consent management (Articles 6-7): Legal basis tracking, consent withdrawal.
• Data minimization (Article 5(1)(c)): Only collect what you need.
• DPIA (Article 35): Data Protection Impact Assessments for high-risk processing.
• DPO requirement (Article 37): Designated Data Protection Officer.

DORA-Only Requirements

These have no direct GDPR equivalent:

• ICT risk management framework (Articles 5-16): Formal ICT risk governance with board-level oversight.
• Digital operational resilience testing (Articles 24-25): Regular testing including threat-led penetration testing for significant entities.
• Third-party ICT risk management (Articles 28-30): Register of all ICT third-party arrangements, concentration risk assessment, exit strategies.
• Information sharing (Article 45): Voluntary sharing of cyber threat intelligence between financial entities.
• Business continuity (Article 11): ICT business continuity policies with tested recovery procedures.

Different Enforcement Bodies

| Country | GDPR Authority | DORA Authority | |---------|---------------|----------------| | Germany | State DPAs (LfDI) | BaFin | | France | CNIL | ACPR / AMF | | Netherlands | Autoriteit Persoonsgegevens | DNB / AFM | | Ireland | DPC | Central Bank of Ireland |

You may be audited by both authorities independently, and they do not necessarily coordinate.

The Proportionality Question

Both regulations include proportionality principles, but they apply differently:

GDPR scales by: type and volume of personal data processed, risk to data subjects, nature of processing.

DORA scales by: entity size, nature and complexity of ICT systems, overall risk profile, scope and complexity of financial services.

A small fintech processing payment data faces full GDPR obligations (payment data is sensitive PII) but lighter DORA requirements (proportional to size). A large bank faces maximum requirements under both.

Implementation Strategy for Database Teams

The most efficient approach: implement database controls that satisfy both regulations simultaneously, then add the GDPR-specific and DORA-specific layers.

Shared Foundation (Satisfies Both)

1. SSL/TLS encryption on all database connections
2. SCRAM-SHA-256 authentication (not MD5)
3. Role-based access control with least privilege
4. Row-Level Security on tables with financial or personal data
5. Immutable audit trail with integrity verification
6. DDL change tracking for configuration management
7. Regular access reviews (quarterly recommended)
8. Connection security monitoring and timeout enforcement

GDPR Layer (Add On Top)

9. PII inventory — classify which columns contain personal data
10. Erasure capability — delete a user's data across all tables
11. Data portability — export user data in structured format
12. Consent tracking — record legal basis per processing purpose
13. Retention policies — auto-delete data past its purpose
14. Data minimization — identify and eliminate unnecessary PII

DORA Layer (Add On Top)

15. Health check automation — regular configuration assessment
16. Resilience testing — backup validation, failover drills
17. Third-party register — document database provider dependencies
18. Incident classification — structured severity-based reporting
19. Recovery testing — monthly backup restoration verification

The Bottom Line

GDPR and DORA are complementary, not competing. Database teams that build a strong shared foundation of access control, encryption, and audit logging are 70% of the way to satisfying both. The remaining 30% is regulation-specific: GDPR demands data subject rights (erasure, portability, consent), while DORA demands operational resilience (testing, recovery, third-party management).

Neither regulation is optional. Both carry penalties that can threaten a financial entity's ability to operate. The good news: the technical implementations overlap substantially, and a well-architected PostgreSQL database can satisfy both with the same infrastructure.