{"id":110437,"date":"2026-06-11T12:00:00","date_gmt":"2026-06-11T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=110437"},"modified":"2026-06-03T09:36:58","modified_gmt":"2026-06-03T09:36:58","slug":"its-2026-why-are-databases-still-failing-gdpr-compliance-audits","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/its-2026-why-are-databases-still-failing-gdpr-compliance-audits\/","title":{"rendered":"It’s 2026. Why are databases still failing GDPR compliance audits?"},"content":{"rendered":"\n

Seven years after GDPR came into force, European regulators have issued over 2,245 fines totalling nearly 5.65 billion euros \u2014 and enforcement shows no sign of slowing down. Yet most compliance conversations focus on legal and governance failures, while the deeper technical root causes go unaddressed. <\/strong><\/p>\n\n\n\n

This article examines three recurring database-layer failures documented in the EDPB’s 2026 enforcement findings: the complexity of executing erasure across relational schemas, the backup paradox that can silently undo compliant deletions, and the audit log contradiction that traps organizations between two competing obligations. <\/strong><\/p>\n\n\n\n

We then look at how SQL Server, PostgreSQL, Oracle, and MySQL each handle these requirements \u2014 and where the gaps remain.<\/strong><\/p>\n\n\n\n

The General Data Protection Regulation (GDPR)<\/a> came into force in May 2018. By March 2025 – seven years later -European regulators had issued more than 2,245 recorded fines, totaling approximately 5.65 billion euros.<\/p>\n\n\n\n

That’s according to the CMS GDPR Enforcement Tracker<\/a>, but it’s not the only source we have to work with. DLA Piper’s 2025 GDPR fines and data breach survey reported 1.2 billion euros in fines issued in a single twelve-month period, across financial services, healthcare, retail, energy, and the public sector. <\/p>\n\n\n\n

Yes – 1.2 billion euros in fines in just one year.<\/em><\/p>\n\n\n\n

Why, exactly, is this happening?<\/h2>\n\n\n\n

The standard explanation for persistent GDPR compliance failures is that organizations have legal and governance problems. Insufficient consent mechanisms, inadequate privacy policies, and missing data protection officers – to name a few.<\/strong><\/p>\n\n\n\n

None of these, however, explain where a large share of the actual failures originate. Many of the recurring compliance gaps the GDPR enforcement record documents are technical database problems that no legal team can solve, and no policy document can paper over.<\/p>\n\n\n\n

On February 18, 2026, the European Data Protection Board published the findings<\/a> from its 2025 Coordinated Enforcement Framework<\/a> action on the right to erasure under Article 17 of the GDPR<\/a>. This was the fourth CEF action in four years, and 32 Data Protection Authorities across the European Economic Area (EEA) participated. <\/p>\n\n\n\n

Nine launched formal investigations and, all in all, 23 fact-finding exercises were conducted across 764 controllers – spanning SMEs, multinationals, and public sector organizations.<\/p>\n\n\n\n

ReedSmith’s analysis of the report<\/a> summarized its central finding plainly, identifying seven systemic weaknesses, with the two most persistent and consequential being the absence of systematic internal data classification and the lack of automated deletion mechanisms. Both of these are database engineering problems.<\/strong><\/p>\n\n\n\n

This article works through three specific database-layer failures that the EDPB report and enforcement record document consistently. We’ll then examine how SQL Server<\/a>, PostgreSQL<\/a>, Oracle<\/a>, and MySQL<\/a> each approach the technical requirements – and where the gaps are on each platform.<\/p>\n\n\n\n

The GDPR erasure problem is a database architecture problem – here’s why<\/h2>\n\n\n\n

Article 17 of the GDPR grants individuals the right to have their personal data erased when it’s no longer needed for the purpose for which it was collected.<\/strong> <\/p>\n\n\n\n

The regulation calls for erasure without undue delay. In a simple flat database, this is manageable. In any production relational database of meaningful complexity, however, it’s one of the hardest technical requirements in the regulation.<\/p>\n\n\n\n

Consider a normalized e-commerce schema. A table of customers, for example, holds a ton of personal data: name, email, address, date of birth. However, deleting the customer row in the customers table does not delete the data<\/strong>. It breaks referential integrity on every table that references it, unless you have decided in advance what to do with each dependency.<\/p>\n\n\n\n

In this instance, the options available to you are:<\/h4>\n\n\n\n

Cascade the deletion through all dependent tables<\/strong> (which may violate financial record-keeping obligations for transaction data under accounting law).<\/p>\n\n\n\n

Null the foreign keys and orphan the dependent records<\/strong> (which corrupts data integrity).<\/p>\n\n\n\n

Pseudonymize the personal identifiers<\/strong> – replacing them with anonymous tokens that preserve structural relationships without identifying information.<\/p>\n\n\n\n

The EDPB’s February 2026 report was explicit about two recurring failures here. First, many controllers relied on anonymization techniques<\/a> that were weak or amounted to mere pseudonymization, leaving re-identification risks. <\/p>\n\n\n\n

\n
\n\n

Important note<\/strong><\/p>\n\n\n\n

The EDPB is currently developing updated anonymization guidelines following the CJEU ruling in EDPS v SRB (Case C-413\/23P). Controllers using pseudonymization as an erasure substitute are on uncertain legal ground until that guidance is issued.<\/p>\n\n<\/div>\n<\/div> \n\n\n

Second, some controllers treated account deactivation as equivalent to erasure<\/strong>. A user deletes their account. The application removes the login credentials. The underlying personal data remains intact in the database. The EDPB was explicit<\/a> that this does not satisfy Article 17. Deactivating an account is only a service-layer operation. Erasure means deleting or sufficiently anonymizing the personal data itself.<\/strong><\/p>\n\n\n\n

The backup paradox<\/h2>\n\n\n\n

Once the erasure is correctly executed in the live database, the compliance obligation does not end. It extends to every backup taken before the deletion occurred.<\/p>\n\n\n\n

An organization taking daily database backups has a retention schedule. Backups from the last 30 days are stored online, while older backups are archived to cheaper storage. When a customer submits an erasure request, the database team correctly deletes all of that customer’s personal data from the live tables. The application then confirms the erasure.<\/p>\n\n\n\n

Every backup taken before<\/em> that deletion still contains the customer’s personal data in fully recoverable form. If any of those backups is restored during a disaster recovery<\/a> event, a data investigation, or a development environment refresh, the deleted data reappears in the live system. The right to erasure has been satisfied in the live database, yet simultaneously undermined by the backup infrastructure.<\/p>\n\n\n\n

The GDPR does not prescribe a specific technical approach to backup erasure, and supervisory authorities have taken varying positions.<\/strong> <\/p>\n\n\n\n

The EDPB’s 2026 report<\/a> found that half of the responding DPAs raised concerns that many controllers had no specific procedures for erasure in the backup context. Some controllers had no procedures at all, relying exclusively on automatic overwrite cycles. The report calls for the EDPB to issue guidance on what ‘without undue delay’ means specifically in the context of backups.<\/p>\n\n\n\n

The practical compliance position, based on severalnines.com’s analysis of GDPR and database backups<\/a> and enforcement practice,\u00a0involves three things: <\/p>\n\n\n

\n
    \n
  1. Documenting your backup retention schedule clearly in your privacy notice;

    <\/li>\n\n\n\n
  2. Ensuring that backup restoration does not re-introduce data that has been legitimately erased from live systems;

    <\/li>\n\n\n\n
  3. Reducing backup retention periods for data categories that carry high erasure request volume.<\/li>\n<\/ol>\n<\/div>\n\n\n
    \n
    \n
    \n
    \n

    Protect your data. Demonstrate compliance.<\/h3>\n
    \n With Redgate, stay ahead of threats with real-time monitoring and alerts, protect sensitive data with automated discovery & masking, and demonstrate compliance with traceability across every environment. <\/div>\n <\/div>\n Learn more<\/a>\n <\/div>\n <\/div>\n<\/section>\n\n\n

    The audit log contradiction<\/h2>\n\n\n\n

    Here’s a scenario that regularly catches well-intentioned organizations out in GDPR audits:<\/p>\n\n\n\n

    A data subject requests erasure. The database team executes the deletion correctly. Six months later, a supervisory authority requests evidence that the deletion was carried out.<\/strong><\/p>\n\n\n\n

    The evidence for this should be in your audit logs<\/a>. But audit logs, if they capture the content of operations, contain the personal data that was deleted. To produce the audit trail proving that you deleted the data, you must produce logs that contain the data you deleted.<\/p>\n\n\n\n

    This is a genuine regulatory tension between two legitimate obligations: the obligation to maintain audit trails for accountability and security, and the obligation to erase personal data on request. The resolution is to design audit logging so that it captures what happened, without<\/em> capturing the content of what changed.<\/p>\n\n\n\n

    \n
    \n\n

    What does a GDPR-compliant audit entry look like? <\/strong><\/p>\n\n\n\n

    A GDPR-compliant audit entry looks like: ‘Customer record with internal ID 847392 was deleted at 14:23 UTC on 2025-03-15 by process data-erasure-job.’<\/em> It does not<\/strong> contain the customer’s name, email, or any other personal data. Most default audit logging configurations for all four major database platforms do not produce entries in this format without deliberate configuration.<\/p>\n\n<\/div>\n<\/div> \n\n\n

    Building this kind of audit logging requires the following:<\/strong><\/p>\n\n\n

    \n
      \n
    1. Deciding in advance what the log entry should capture;

      <\/li>\n\n\n\n
    2. Configuring the database audit tooling to capture at the right level of detail;

      <\/li>\n\n\n\n
    3. Testing that the resulting logs contain what a regulator would need to see, without<\/em> containing what the regulation prohibits being retained.<\/li>\n<\/ol>\n<\/div>\n\n\n

      Data retention: why policy is not<\/em> a technical control<\/h2>\n\n\n\n

      Nearly every organization subject to the GDPR has a data retention policy<\/a>. Most of them say something like: ‘personal data will be deleted after two years following the end of the customer relationship, unless legal obligations require longer retention.’<\/em> <\/strong><\/p>\n\n\n\n

      The EDPB’s 2026 report<\/a> identified this explicitly: many organizations have policies but no automated deletion mechanisms to enforce them.<\/strong> <\/p>\n\n\n\n

      Data accumulates for five, seven, or ten years because the policy says two years, but nothing in the database actually enforces<\/em> it.<\/p>\n\n\n\n

      Building automated retention enforcement in a relational database is not trivial. It requires a complete inventory of which tables contain personal data subject to retention obligations. It also requires documented mapping of legal retention periods to specific database objects, because different data categories have different requirements.<\/p>\n\n\n\n

      Financial transaction data<\/strong>, for example, may have a legal obligation to be retained for seven to ten years under accounting law – even after the customer relationship has ended. Marketing profile data<\/strong>, meanwhile, may need to be deleted within months<\/em>.<\/p>\n\n\n\n

      It requires cascade logic that handles dependent tables correctly without breaking referential integrity or downstream applications. And it requires testing that the automated deletion processes run on schedule, handle edge cases, and do not produce errors that cause the deletion jobs<\/a> to fail silently.<\/p>\n\n\n\n

      Ultimately, this is a database engineering project<\/a>. It requires schema knowledge, a data inventory, and coordination between the database team and the legal team.<\/strong> The latter defines the retention requirements, while the former has to actually build<\/em> the implementation. <\/p>\n\n\n\n

      In most organizations failing GDPR audits on retention, these two teams have never had that conversation in sufficient technical detail.<\/strong><\/p>\n\n\n\n

      Platform by platform: where does each database sit when it comes to GDPR?<\/h2>\n\n\n\n

      SQL Server and GDPR<\/h3>\n\n\n\n

      SQL Server<\/a> has mature capabilities for most<\/em> of what GDPR’s technical requirements demand.<\/strong> <\/p>\n\n\n\n

      First, SQL Server Audit<\/a> provides comprehensive event logging at both the server and database level. Then there’s Always Encrypted<\/a>, which allows column-level encryption where even database administrators cannot read the encrypted values without the column encryption keys. And finally, Row-Level Security<\/a> enables fine-grained access control, and Transparent Data Encryption<\/a> protects data at rest.<\/p>\n\n\n\n

      The challenge is configuration, not capability. SQL Server Audit is powerful but requires deliberate policy design to capture what GDPR audits need without capturing the personal data content of every operation.<\/strong> <\/p>\n\n\n\n

      Organizations that deployed SQL Server Audit years ago for a different compliance purpose, PCI<\/a>, SOX<\/a>, or internal auditing, often have audit policies that do not satisfy the Article 17 accountability requirements regulators now look for. Revisiting that configuration is work that most teams defer until an audit forces the issue.<\/p>\n\n\n\n

      \n
      \n
      \n
      \n

      Fast, reliable and consistent SQL Server development…<\/h3>\n
      \n …with SQL Toolbelt Essentials. 10 ingeniously simple tools for accelerating development, reducing risk, and standardizing workflows. <\/div>\n <\/div>\n Learn more & try for free<\/a>\n <\/div>\n <\/div>\n<\/section>\n\n\n

      PostgreSQL and GDPR<\/h3>\n\n\n\n

      PostgreSQL’s<\/a> native audit capabilities are limited for GDPR compliance purposes.<\/strong> <\/p>\n\n\n\n

      The core postgresql.conf logging settings can<\/em> capture connections, queries, and errors. However, they’re not<\/em> designed for fine-grained data access auditing, and don’t<\/em> produce the structured logs that GDPR audits require without significant configuration. <\/p>\n\n\n\n

      The standard solution for production PostgreSQL environments handling regulated data is pgaudit<\/a>. <\/strong>This is an open-source extension that provides session-level and object-level audit logging equivalent to what enterprise database products offer natively.<\/p>\n\n\n\n

      pgaudit can log who accessed which tables and when (at the row level if needed), without<\/em> capturing the content of the data accessed. Organizations running PostgreSQL for GDPR-regulated workloads without pgaudit (or a commercial equivalent) frequently discover that they have no adequate audit trail for the period preceding the audit.<\/em> Building the trail after the fact is not an option.<\/p>\n\n\n\n

      Oracle and GDPR<\/h3>\n\n\n\n

      Oracle’s Unified Auditing<\/a>, introduced in Oracle 12c and the default audit architecture from Oracle 21c onward, provides the most comprehensive out-of-box audit capabilities of the four platforms covered here. <\/strong><\/p>\n\n\n\n

      Fine-grained auditing allows audit policies to capture specific columns in specific tables under specific conditions. Oracle Label Security provides row-level classification. And, finally, Oracle Data Masking and Subsetting enables pseudonymization at the column level.<\/p>\n\n\n\n

      Oracle’s compliance tooling is mature enough for GDPR requirements. The challenge is that complex Oracle environments often have audit configurations that were established during initial deployment and then forgotten about as the data processing activities of the business evolved.<\/strong> <\/p>\n\n\n\n

      An audit policy that captured what was required for a 2017 PCI audit, for example, may not capture what’s needed for an Article 17 compliance review in 2026.<\/p>\n\n\n\n

      MySQL and GDPR<\/h3>\n\n\n\n

      MySQL’s<\/a> audit story depends on which edition you’re running. MySQL Enterprise Edition<\/a> includes the MySQL Enterprise Audit plugin, which provides comprehensive session and query-level audit logging suitable for compliance use. However, MySQL Community Edition – which a substantial number of organizations run for cost reasons – does not<\/em> include a native audit plugin.<\/strong><\/p>\n\n\n\n

      Third-party and open-source audit solutions exist for MySQL Community, but many organizations running MySQL Community for GDPR-regulated workloads haven’t implemented any of them. The result is a compliance gap that is not immediately obvious from looking at the database configuration. <\/p>\n\n\n\n

      An organization can have MySQL running correctly, handling data reliably, with no error logs or signs of trouble – yet not<\/em> have an audit trail that could satisfy a regulatory request for evidence of erasure execution.<\/strong><\/p>\n\n\n\n

      Why a data inventory is so important in 2026<\/h2>\n\n\n\n

      The EDPB’s report identified the absence of systematic internal data classification as one of the two most consequential weaknesses it found. This is the root problem that makes everything else harder. Every other technical control depends on knowing what data you have, where it lives, and what applies to it.<\/strong><\/p>\n\n\n\n

      Without a data inventory, you have the following issues:<\/h4>\n\n\n
      \n
        \n
      1. You can’t implement automated retention enforcement, because you don’t know which tables to apply it to!

        <\/li>\n\n\n\n
      2. You can’t respond completely to erasure requests…because you can’t identify all the places where the requested data exists.

        <\/li>\n\n\n\n
      3. You cannot configure meaningful audit logging, because you don’t know which tables require it.

        <\/li>\n\n\n\n
      4. You cannot assess your backup exposure, because you don’t know which backup archives contain regulated data.<\/li>\n<\/ol>\n<\/div>\n\n\n

        What a data inventory must<\/em> include to satisfy GDPR compliance<\/h2>\n\n\n\n

        A data inventory for GDPR purposes is a documented record of: <\/p>\n\n\n

        \n
          \n
        1. Which tables in which databases contain personal data subject to the GDPR;

          <\/li>\n\n\n\n
        2. What categories of personal data each table contains (contact information, financial data, health data, behavioral data);

          <\/li>\n\n\n\n
        3. The legal basis for processing;

          <\/li>\n\n\n\n
        4. The applicable retention period;

          <\/li>\n\n\n\n
        5. The dependent tables that reference the personal data.

          AWS’s GDPR compliance guidance for Redshift<\/a> describes a similar inventory-first approach as the prerequisite for implementing the right to erasure technically, and the same logic applies across platforms.<\/li>\n<\/ol>\n<\/div>\n\n\n

          In summary<\/h2>\n\n\n\n

          For legacy systems with years of accumulated schema changes and undocumented tables, building this inventory is genuinely difficult work. Starting with the tables that receive the highest volume of erasure requests, and building outward from there, produces the most compliance value for the most effort in the shortest time.<\/p>\n\n\n\n

          The EDPB’s 2026 coordinated enforcement action on erasure is the fourth in four years. The 2026 action will focus on transparency and information obligations<\/a>. The scrutiny is not ending with erasure. Organizations that built a data inventory to address erasure compliance are positioned to respond to the next wave. Organizations that did not<\/em>, are likely to be unprepared for both.<\/p>\n\n\n\n

          \n

          FAQs: Why databases are still failing GDPR compliance audits in 2026<\/h2>\n\n

          1. What is Article 17 of the GDPR?<\/h3>\n
          \n

          Article 17 grants individuals the right to request deletion of their personal data when it is no longer needed for the purpose it was collected. Organizations must act without undue delay, which applies not just to live databases but to all systems where that data exists.<\/p>\n <\/div>\n

          2. Does deleting a user account satisfy a GDPR erasure request?<\/h3>\n
          \n

          No. Deactivating or deleting an account is a service-layer operation. The EDPB has been explicit that unless the underlying personal data is deleted or sufficiently anonymized in the database itself, the erasure obligation under Article 17 is not met.<\/p>\n <\/div>\n

          3. Do GDPR erasure obligations apply to database backups?<\/h3>\n
          \n

          Yes, and this is one of the most practically difficult aspects of compliance. Backups taken before a deletion still contain the erased data in recoverable form. While the EDPB has yet to issue definitive guidance on timelines for backup erasure, organizations are expected to have documented procedures and reduced retention periods for high-risk data categories.<\/p>\n <\/div>\n

          4. What is the difference between anonymization and pseudonymization under GDPR?<\/h3>\n
          \n

          Pseudonymization replaces personal identifiers with tokens but the original data can still be re-identified with a key. True anonymization makes re-identification impossible. GDPR obligations, including the right to erasure, do not apply to genuinely anonymized data \u2014 but the EDPB has found that many organizations are using pseudonymization and incorrectly treating it as anonymization.<\/p>\n <\/div>\n

          5. Which database platform has the strongest native GDPR compliance capabilities?<\/h3>\n
          \n
          \n
          \n
          \n
          \n
          \n
          \n
          \n

          Oracle’s Unified Auditing and fine-grained audit policies provide the most comprehensive out-of-box tooling. SQL Server is also well-equipped but requires deliberate configuration. PostgreSQL requires the pgaudit extension for adequate audit logging. MySQL Community Edition has no native audit plugin, making it the most challenging platform for regulated workloads without additional tooling.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n <\/div>\n

          6. What is a data inventory and why does GDPR require one?<\/h3>\n
          \n

          A data inventory is a documented record of which tables contain personal data, what categories they hold, the legal basis for processing, applicable retention periods, and dependent table relationships. Without one, organizations cannot implement automated deletion, respond completely to erasure requests, configure meaningful audit logging, or assess backup exposure.<\/p>\n <\/div>\n <\/section>\n","protected":false},"excerpt":{"rendered":"

          GDPR erasure failures are often database engineering problems, not legal ones. Learn how relational schema design, backup retention, and audit logging create compliance gaps \u2014 and how SQL Server, PostgreSQL, Oracle, and MySQL compare.
          \n…<\/p>\n","protected":false},"author":342096,"featured_media":106674,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143514,46,143523,53,145792,143533,143534,143530,143524],"tags":[4168,4170,57573,5854,4459,158978,4619,5765,4151],"coauthors":[159002],"class_list":["post-110437","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-privacy-and-protection","category-security-and-compliance","category-databases","category-featured","category-mysql","category-oracle-databases","category-postgresql","category-security","category-sql-server","tag-database","tag-database-administration","tag-gdpr","tag-mysql","tag-oracle","tag-postgresql","tag-security","tag-security-and-compliance","tag-sql-server"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/110437","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/342096"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=110437"}],"version-history":[{"count":15,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/110437\/revisions"}],"predecessor-version":[{"id":110590,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/110437\/revisions\/110590"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media\/106674"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=110437"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=110437"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=110437"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=110437"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}