Personal Data Map: find every column a GDPR subject access request has to reach

Five columns in this thirty-line Postgres migration will break your next subject access request - backend engineers in the EU, one month on the clock.

db/migrations/014_patients.sql
   8  error  password - credential under a plain name; Art. 32, and an Art. 15 export must never return it.
  11  warn   is_deleted - a flag is not erasure under Art. 17; the row still holds the person.
  17  warn   user_id REFERENCES users(id) - no ON DELETE rule; the row outlives the person you erased.
  18  error  diagnosis - Art. 9 special-category data; needs an Art. 9(2) condition on top of your Art. 6 basis.
  24  error  CREATE TABLE users_audit - copy table; Art. 17 erasure and Art. 15 access have to reach it too.

That is the finished answer. Here is the file it came from - thirty lines, none of them unusual.

-- 014_patients.sql  (Postgres, EU health app)
CREATE TABLE users (
  id                 BIGSERIAL PRIMARY KEY,
  email              VARCHAR(255) NOT NULL UNIQUE,
  full_name          VARCHAR(120),
  date_of_birth      DATE,
  national_id        VARCHAR(20),
  password           VARCHAR(72) NOT NULL,
  ip_address         INET,
  stripe_customer_id VARCHAR(40),
  is_deleted         BOOLEAN DEFAULT false,
  created_at         TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE health_records (
  id        BIGSERIAL PRIMARY KEY,
  user_id   BIGINT REFERENCES users(id),
  diagnosis TEXT,
  notes     TEXT,
  latitude  NUMERIC(9,6),
  longitude NUMERIC(9,6)
);

CREATE TABLE users_audit (
  id         BIGSERIAL PRIMARY KEY,
  user_id    BIGINT,
  email      VARCHAR(255),
  iban       VARCHAR(34),
  changed_at TIMESTAMPTZ
);

Under Art. 12(3) you have one month from the request, extendable by two more only if you tell the person why inside that first month. Here is what that month runs into.

password is stored under a plain name. Art. 32 asks for state-of-the-art protection, and an Art. 15 export must never return it. Rename it to password_hash.

diagnosis is Art. 9 special-category data. An Art. 6 legal basis is not enough on its own here: it needs an Art. 9(2) condition sitting on top of it, and you have to name which one.

CREATE TABLE users_audit is the expensive one. Erasure under Art. 17 and access under Art. 15 reach the copies too, and incomplete erasure is almost always found here, not in the main table.

REFERENCES users(id) with no ON DELETE rule means the health record survives the user you just deleted. The erasure was not an erasure.

is_deleted BOOLEAN is the same failure wearing a different hat. A flag is not erasure. The row still holds the person, and read replicas still serve it. Name the hard-delete or anonymise job that follows the flag.

Two more the same file hides. ip_address is personal data once you can identify the user (Recital 30, and the CJEU in Breyer, C-582/14). stripe_customer_id is proof that this person's data left for a processor who must be named in your Art. 30(1) record.

The obvious move is to paste the file into a chatbot. It reads the one table you gave it. It cannot see the other migrations in the repository, and it cannot see the missing ON DELETE three files away. On the law it is worse than blind: ask it about the Art. 30 record today and it will hand you the Digital Omnibus 750-employee exemption, which as of September 2026 is a proposal still under negotiation, not law you can rely on.

A manual subject access request averages about $1,524 in staff time, eight to twelve hours of it, and an independent EU privacy consultant bills EUR 100-200 an hour. The map of which columns you actually hold is the cheap part.

Personal Data Map is a VS Code extension and a free web page that run the same thirteen rules over a schema and return line numbers with the article each finding hangs on. The free side finishes the file you have open; paste a migration into the page and the answer is on screen before you type.