FlowKit

Keeping Your GDPR Records of Processing Activities (Article 30) Up to Date with n8n

Published 2 August 2026 · 6 min read

A GDPR records of processing activities register kept in a shared spreadsheet always meets the same fate: accurate the day it's created, stale six months later. A new SaaS tool gets connected to the CRM, an intern wires up a Zapier integration to test an idea, a recruitment form collects CVs for three months and then vanishes from view — and no one thinks to open the spreadsheet and add a row. A study by Freitas and Mira da Silva, based on interviews with ten industrial SMEs and published in 2018 in the Journal of Information Systems Engineering & Management, already documented this pattern: none of the companies interviewed regularly assessed their compliance with the regulation, and the difficulty wasn't a lack of understanding of the law but the absence of a process repeated over time (study on Google Scholar). This guide shows how n8n can turn the register from a document everyone forgets into a process that keeps itself current.

What the register covers — and what it doesn't

Three related but distinct GDPR obligations are often mixed up by mistake:

  • The records of processing activities (Article 30): the inventory of every personal-data processing activity the company runs — the subject of this article.
  • The audit trail (Article 5(2), accountability): a record of what your automations actually did, covered in our guide on building a GDPR audit trail with n8n and Supabase.
  • Handling GDPR requests (Articles 15, 17, 20): responding to someone exercising their access, erasure, or portability rights, detailed in our guide on handling GDPR requests with n8n.

The register sits furthest upstream of the three: without an up-to-date inventory of existing processing activities, there's no way to know which sources to search when an access request comes in, nor which actions to log in an audit trail.

Who's actually on the hook

Article 30(5) of the GDPR theoretically exempts organizations with fewer than 250 employees from keeping a register. In practice, this exemption is far narrower than it looks: it only applies if every processing activity is occasional, carries no particular risk to individuals, and involves no sensitive data (health, origin, opinions…) or criminal-record data. A CRM, a monthly newsletter, or standard HR tracking — the situation for nearly every SME and small business — is enough to void the exemption. Supervisory authorities then expect a register, at least in simplified form.

The eight fields every record needs

A record compliant with Article 30 consistently answers the same questions:

  1. Purpose — why this processing exists ("managing the marketing newsletter").
  2. Legal basis — consent, contract, legitimate interest, legal obligation…
  3. Categories of data subjects — customers, prospects, employees, applicants…
  4. Categories of data — identity, contact details, connection data, sensitive data where relevant.
  5. Recipients — internal departments, processors (the SaaS tool itself counts).
  6. Transfers outside the EU — where applicable, with the safeguard used (standard contractual clauses, adequacy decision).
  7. Retention period — how long the data is kept, and what triggers its deletion.
  8. Security measures — encryption, access control, backups.

These eight fields are exactly the columns of the Supabase table this workflow will fill in.

Why a static spreadsheet can't keep pace with n8n

An active n8n instance accumulates integrations faster than a manually kept register can track: every new credential (a CRM, an email tool, a lead-scoring API) is potentially a new personal-data processing activity under GDPR. This is precisely where an automation instance changes the equation compared to a company that only runs a handful of standard SaaS tools — new processing activities appear at the pace of new workflows, not at the pace of quarterly compliance reviews.

The fix: instead of hoping someone remembers to update the register every time a new workflow ships, have it automatically flag candidates to document, via the n8n REST API.

Step 1 — Detect new candidate processing activities

A scheduled workflow (once a week is plenty) queries GET /api/v1/workflows?active=true with a dedicated Header Auth credential, as described in our guide to the n8n REST API. For each active workflow, it checks its ID against the registre_traitements table: any active workflow missing from the register becomes a row with a to_document status.

A simple filter keeps the noise down: only surface workflows whose nodes use credential types relevant to personal data (email, CRM, forms, customer databases) rather than purely technical workflows (API uptime checks, image generation). This coarse sort clears out most false positives without pretending to be a perfect classifier.

Step 2 — An AI-drafted record, never published without review

For each new candidate, an LLM node receives the workflow's name, description, and node list, and drafts a first version of the purpose, likely data categories, and recipients fields — on the same principle as the audit summary report in the Compliance & Audit Pack. This draft speeds up the writing, but it must never move to a "validated" status automatically: the legal basis and retention period are choices that legally bind the company, not statistical inferences. The workflow posts the draft to a dedicated Slack channel for human validation, on the same model as human approval with Wait and Slack.

Step 3 — The Supabase schema

create table registre_traitements (
  id uuid primary key default gen_random_uuid(),
  workflow_id text unique,
  nom_traitement text not null,
  finalite text,
  base_legale text,
  personnes_concernees text,
  categories_donnees text,
  destinataires text,
  transfert_hors_ue text,
  duree_conservation text,
  mesures_securite text,
  statut text default 'a_documenter',
  derniere_revue date,
  created_at timestamptz default now()
);

The unique workflow_id column links each record to its source n8n workflow — that's what lets the detection step know what's already covered without duplicating rows.

Step 4 — Nudging periodic reviews

A register accurate on the day it was created goes stale too: a purpose changes, a processor gets swapped out, a retention period stops being honored. A second workflow, triggered by a monthly Schedule Trigger, selects records where derniere_revue is more than twelve months old and sends a batched reminder — the same pattern used for tracking contract deadlines. The human review stays deliberately manual: only the nudge is automated.

Step 5 — Exporting for an inspection

If a regulator comes knocking, you need to produce the register in a readable form within minutes. A Supabase node followed by a CSV export — on the same principle as our guide on generating Excel and CSV files with n8n — covers most requests. For a more formal output, the same data can feed an HTML template converted to PDF, as detailed in our guide on generating PDFs with n8n.

Securing access

By construction, the register maps out exactly which personal data the company handles — a prime target in the event of a breach. The n8n API key used for detection and the Supabase credential behind the register need the same hygiene as any admin-level secret: stored as an environment variable, access restricted, rotated at the first sign of doubt, as detailed in our guide on securing n8n credentials.

What this automation doesn't replace

This workflow detects candidates to document and speeds up drafting; it replaces neither a Data Protection Officer, nor a Data Protection Impact Assessment for high-risk processing, nor human judgment on which legal basis applies. Its role is more modest and more useful day to day: making sure the register reflects the actual state of the n8n instance rather than a snapshot from whenever someone last had time to fill it in.

In summary

A records of processing activities register isn't a document you write once and file away — it's meant to track the real pace of activity, and on a growing n8n instance, that pace quickly outstrips a manual quarterly update. Detecting new processing activities through the n8n API, drafting a first record with AI that's always subject to human review, and nudging periodic reviews: these three automations are enough to keep a register that holds up under inspection. The workflows in the Compliance & Audit Pack (€149) apply the same timestamped traceability principle to your questionnaires and audits — the audit trail and the register complement each other to cover your accountability obligations end to end.

FAQ

Frequently asked questions

Is a records of processing activities register mandatory for a small business?

Article 30(5) of the GDPR theoretically exempts organizations with fewer than 250 employees, but only if all their processing is occasional, carries no particular risk, and involves no sensitive data. As soon as there's a CRM, a recurring newsletter, or standard HR tracking — the situation for nearly every SME — supervisory authorities like France's CNIL expect a register, at least in simplified form.

Can an LLM write the register's records directly without review?

No, and it shouldn't. The AI-generated draft based on a workflow's name and nodes is a starting-point aid, not a source of truth: the exact purpose, legal basis, and retention period are legal choices that bind the company and must be validated by a person before publication.

Does this register replace a Data Protection Impact Assessment (DPIA)?

No. The register inventories existing processing activities; a DPIA is an in-depth study required only for high-risk processing (large-scale profiling, video surveillance, sensitive data at volume). The register can, however, serve as a starting point for spotting which processing activities might warrant a DPIA.

Bundle FlowKit Complet

€269