GDPR audit trail with n8n and Supabase: logging your automations to prove compliance

A CNIL inspection, an ISO 27001 audit, a Qualiopi surveillance audit for a French training provider, or simply a client asking "can you prove that reminder actually went out on March 12th?" — the underlying question is always the same: do you have a reliable record of what your automations did? GDPR Article 5(2), the accountability principle, is explicit: it's not enough to follow the rules, you must be able to demonstrate it at any time. With n8n and a well-designed Postgres table on Supabase, you build that proof in one afternoon, with no third-party service and no application code.

What an audit trail actually needs to contain

A usable audit trail always answers the same questions: who (or which system) did what, when, on which object, with what result. Concretely, for a compliance case or an automated reminder, that's an event like: case #482, answer to question 3 recorded, 2026-03-12 14:32, by the AI agent, status validated.

Two properties separate a real audit trail from a plain application log file:

• Immutability: once written, a row must never be editable or deletable — otherwise it proves nothing.
• Completeness: every sensitive action must be logged, including failures. A trail that only records successes hides exactly what an auditor is looking for.

The architecture: one logging sub-workflow, not a duplicated node everywhere

The most common mistake is bolting a Supabase "insert" node onto the end of every workflow, copy-pasted from one automation to the next. The day you add a field or switch storage provider, you're editing twenty workflows.

The correct n8n pattern isolates logging into a dedicated sub-workflow, triggered by an Execute Sub-workflow Trigger node, and called from any other workflow via an Execute Sub-workflow node. One place to maintain, a guaranteed-consistent event format, and the freedom to change the storage layer without touching business workflows. That's exactly the pattern behind the "Audit record in Supabase" workflow in our Compliance & Audit Pack: a webhook (or sub-workflow) that validates fields, timestamps, and inserts — callable from a conversational bot just as easily as from your own forms.

Step 1: a Supabase schema designed to stay immutable

In the Supabase SQL editor:

create table if not exists audit_log (
  id bigserial primary key,
  event_type text not null,        -- e.g. 'case.answer_validated'
  entity_id text not null,         -- e.g. the case identifier
  actor text not null,             -- user, AI agent, or workflow name
  payload jsonb,                   -- event detail
  status text not null default 'success', -- 'success' or 'failure'
  recorded_at timestamptz not null default now()
);
create index if not exists audit_log_entity_idx on audit_log (entity_id);
create index if not exists audit_log_event_idx on audit_log (event_type, recorded_at);

-- Forbid any modification or deletion, even by accident
revoke update, delete on audit_log from authenticated, anon;

That revoke line matters most: it turns an ordinary Postgres table into a genuinely append-only log, even against an application bug that attempts an accidental update. Use n8n's service_role key for inserts only — never for updates on this table.

Step 2: the "Log an event" sub-workflow

Minimal structure, three nodes:

1. Execute Sub-workflow Trigger, with an input mode (Define using JSON Schema or Define below) expecting eventType, entityId, actor, payload, and status.
2. Edit Fields (Set), to normalize missing fields (status defaults to success if absent) and add recorded_at on the n8n side in addition to Postgres's default now() — useful if you ever need to replay events after the fact with a different original date.
3. Supabase, Insert operation, table audit_log.

Once this workflow is saved, every business workflow calls it in one step: an Execute Sub-workflow node pointing at it, with the four fields mapped from the calling workflow's data. Adding logging to a new workflow becomes a copy-paste of that single node — never a re-implementation of the write logic itself.

Step 3: don't skip the failures

An audit trail that only records successes has a blind spot exactly where an audit tends to look hardest: what happened when it failed? n8n has a dedicated mechanism for this, decoupled from business logic: under Settings → Workflow Settings for each sensitive workflow, the Error Workflow field designates a workflow triggered automatically on every failed execution, with the error details as input.

Configure that Error Workflow to call the same logging sub-workflow with status: 'failure' and the error message in payload. You get an audit trail covering both success and failure without duplicating error handling in every individual workflow.

Step 4: an AI-generated audit report, not a hand-compiled one

Raw Supabase data is enough to answer a demanding inspector, but a readable summary report convinces a client or external auditor faster. A weekly scheduled workflow does the job:

1. Schedule Trigger, every Monday morning.
2. Supabase, Get Many operation on audit_log, filtered on the past week.
3. AI Agent (or a simple Chain — see our guide to n8n's AI nodes), with a system prompt that structures the output: event counts by type, anomalies (failure spikes, cases stuck past X days), and a plain-language summary.
4. Send Email or Slack, to deliver the report to whoever owns compliance.

That's exactly the logic behind the "AI audit summary report" workflow in the Compliance & Audit Pack, applied here across all your automations instead of a single case file.

Going further: hash chaining for demonstrable integrity

revoke update, delete protects against accidental edits and against an attacker limited to application-level privileges. For a stronger level of proof — useful in regulated environments — each row can carry the hash of the previous one:

alter table audit_log add column prev_hash text;
alter table audit_log add column row_hash text;

Computed in n8n with a Code node (crypto.createHash('sha256') over the concatenated fields plus prev_hash), this chaining makes retroactive tampering detectable: editing an old row breaks the hash chain of every row after it. It's the same principle as double-entry bookkeeping, applied to an event log.

Mistakes that void an audit trail

• A table that can be modified: without revoke, any bug or direct database access can alter history — the trail loses all evidentiary value.
• Logging duplicated across workflows: formats inevitably drift over time; always route through the single sub-workflow.
• Untracked failures: a workflow silently fails and nobody knows until the client complains — always configure the Error Workflow.
• Thin payloads: event_type and entity_id alone can't reconstruct an incident; always include enough context in payload to understand the event without cross-referencing other systems.
• No defined retention: pick a retention period aligned with your obligations (often 3–5 years for GDPR or accounting audit trails) and document it — an audit trail kept forever becomes its own GDPR risk under data minimization.

The same audit trail for other obligations: CRA and KYC / AML

The append-only table and the logging sub-workflow described above are not only for GDPR. Two other regulatory obligations rest on exactly the same backbone.

Cyber Resilience Act: timing the reports

Since 11 September 2026, the CRA requires manufacturers (software publishers included) selling a product with digital elements in the EU to report an actively exploited vulnerability to ENISA and the national CSIRT within 24 hours, then follow up within 72 hours. CE marking and conformity assessment only apply from December 2027: these are two separate deadlines. The CRA comes on top of NIS2 (which targets sectors, not products). In n8n: a Schedule Trigger polls the CVE/NVD feeds of your dependencies, every entry qualified as "actively exploited" opens a timestamped row in the audit table, a Slack alert goes out immediately and the final qualification goes through human approval with a Wait node. The resulting register (deadlines met or missed, time to first notification) is your proof of diligence.

KYC and AML due diligence: logging every screening decision

At onboarding, AML rules require identifying the customer and their beneficial owner, screening sanctions and PEP lists, then classifying the risk. n8n orchestrates this around a screening API (OpenSanctions or equivalent); every match, its qualification (true or false positive) and the decision to onboard are logged in the same table. Three rules: never let a score threshold decide an ambiguous case on its own (human review is mandatory), periodically rescreen the whole customer base with a Schedule Trigger (lists and PEP statuses change), and keep n8n for reasonable volumes — beyond several thousand customers a month, a dedicated KYC tool is warranted and n8n only orchestrates alerts and reporting around it.

Save yourself the afternoon it takes

Designing the schema, writing the sub-workflow, wiring the Error Workflow and the AI report — it's very doable solo, but it's a solid afternoon of work the first time. The Compliance & Audit Pack ships these four workflows ready to import — guided questionnaire bot, Supabase audit logging, automatic reminders for incomplete cases, and an AI summary report — with the SQL script and a full setup guide: paste your credentials and it's running the same day.

If your automations also handle documents (contracts, procedures, questionnaire answers you need to find semantically), our Supabase pgvector + n8n guide shows how to pair this audit trail with an assistant that can retrieve and cite the right records. And for especially sensitive data, our n8n self-hosted vs cloud comparison helps you decide whether your audit trail should stay on infrastructure you fully control.