Handling GDPR requests (access, erasure, portability) with n8n

A customer emails asking for access to their data, or worse, for it to be deleted entirely. The usual reflex: open a ticket, search manually through the CRM, the production database, the logs, the shared inbox, then reply by hand before the legal deadline runs out. That works for the first request. It breaks down by the tenth, especially when no one has a full picture of where personal data actually lives. A 2022 study by Rupp, Syrmoudis, and Grossklags, published in Proceedings on Privacy Enhancing Technologies, tested erasure requests against 90 online services: 27% remained non-compliant, with supposedly deleted data still reachable elsewhere on the service (study on Google Scholar). The problem isn't bad faith — it's the lack of a repeatable process. That's exactly what an n8n workflow can provide.

What GDPR actually requires

Three rights come up most often in requests a small business receives:

• Article 15 — right of access: provide a copy of all personal data held on the person, within one month.
• Article 17 — right to erasure ("the right to be forgotten"): delete the data, unless a legal retention obligation applies (invoicing records, for instance).
• Article 20 — right to data portability: provide the data in a structured, commonly used, machine-readable format (typically JSON or CSV).

The legal deadline is one month from receipt, extendable by two further months for complex requests — provided the person is informed within the initial month. Miss that window without a response or justification, and the company is at fault regardless of how good the eventual answer turns out to be.

Why manual handling doesn't scale

This isn't a large-company-only problem. A 2020 study by Mangini, Tal, and Moldovan, presented at the ACM ARES conference, found that organizations struggle specifically with running system and process audits and with the practical application of the right to erasure — not with understanding the law itself, but with its repeated operational execution (study on Google Scholar). Manually searching across five different tools, without missing one, while racing a deadline, is exactly the kind of repetitive, rigid task a workflow automates better than a rushed human does.

Step 1 — Intake and identity verification

A Form Trigger hosted directly on your n8n instance captures the request with the essential fields: which right is being exercised (access, erasure, portability), the email tied to the account, and a confirmation checkbox. The workflow then sends a confirmation link to that address — the minimum identity check required before any processing, so a bad actor can't trigger the deletion of someone else's account. For anything atypical (an unrecognized address, sensitive data), route it to a human-approval step with the Wait node and Slack instead of automating blindly.

Step 2 — Aggregate personal data across every source

This is the technical core of the problem: a customer's data rarely lives in one place. It's spread across the production database (often Supabase or Postgres), the CRM, the shared inbox, the billing tool. Rather than one monolithic workflow, split the collection into sub-workflows — one per data source — called in parallel by an orchestrator workflow that receives the verified request. Each sub-workflow queries its source, normalizes the result (a consistent output shape: source, records, timestamp), then returns it to the parent workflow. This architecture pays off directly for compliance: adding a new data source later (a new SaaS tool, say) just means adding a sub-workflow, without touching the rest of the pipeline — so no source gets forgotten on the next request.

Step 3 — Fulfilling access and portability

Once aggregation is done, a Code node assembles the sub-workflows' results into a single JSON object, machine-readable by design — which satisfies the Article 20 portability requirement outright. For human reading, the same content can be converted to CSV or a structured Excel file using the techniques in our guide to extracting and generating Excel/CSV files with n8n. The file is then sent by email or via a time-limited download link — never as an unprotected attachment if the data volume is sensitive.

Step 4 — Handling erasure without breaking production

Erasure is the riskiest step in the pipeline: deleting too much, or in the wrong order, breaks database relationships (foreign keys, order history that legally must be kept for invoicing). Two principles cut that risk:

• Anonymize instead of delete where the law requires it: an invoice has to stay in the accounting records, but the customer's name can be replaced with an anonymous identifier. The erasure sub-workflow must explicitly separate fields to delete from fields to anonymize, table by table.
• Order deletions by dependency: delete data with no foreign-key constraints first, then work up toward referenced tables — the same sequencing discipline as a well-built Error Workflow, with the same concern for failing cleanly rather than leaving a partial deletion undetected.

An erasure run that fails halfway through needs to be visible immediately, not discovered three months later during an audit.

Step 5 — Meeting the deadline and logging the request

A daily cron trigger, on the same pattern used to follow up on incomplete files, checks every morning for GDPR requests still open and alerts the team (Slack, email) once a deadline is five days out. Every request — received, processed, or pending — should be logged in an append-only table, following the exact model in our GDPR audit trail with Supabase guide: who asked for what, when, what was found, what was deleted or anonymized, and by which workflow execution. In the event of an audit, that trail proves compliance far better than an approximate memory of events.

Common pitfalls

• Missing a data source: without a sub-workflow architecture, a new SaaS integration is easily forgotten on the next access or erasure request.
• Deleting without distinguishing legal retention obligations: erasing a required invoice instead of anonymizing it trades one kind of non-compliance for another, this time an accounting one.
• No identity verification: processing an erasure request received by email with no confirmation opens the door to malicious abuse of the service.
• Silence past the one-month deadline: even a partial reply with a justified delay beats no response at all.

Going further

This pipeline — intake, verification, multi-source aggregation, cascading erasure, logging — is exactly what the Compliance & Audit Pack (€149) assembles, alongside workflows for following up on incomplete files and generating audit summary reports. If your GDPR compliance today runs on a spreadsheet and good intentions, this is the most direct starting point to replace it with a process that holds up, request after request.