Get early access
For regulated teams/Records of processing
GDPR Art. 30 · records of processing

Your Record of Processing Activities, built from the contract.

Article 30 requires a record of what personal data you process, why, and how. Because a Blueprint form declares every field it collects, the contract is the machine-readable source of truth for your register — and because it is the app, it can’t drift from it.

GDPR Art. 30Drift-proof by designSemantic layer · after v1

The obligation: Article 30 GDPR — controllers and processors must maintain records of their processing activities. GDPR Art. 30 ↗

The requirement

What Article 30 asks you to keep.

A written record of your processing — and health or other special-category data keeps you in scope even at a small size.

Art. 30(1)–(2)
Maintain a record of processing activities
  • The record covers the purposes, the categories of data subjects and personal data, the recipients, any third-country transfers, the retention periods, and a general description of security measures.
  • It applies to controllers (30(1)) and, for their own processing, to processors (30(2)) — and must be available to the supervisory authority on request.
Source: GDPR Art. 30 ↗
Art. 30(5) + Art. 9
Special-category data keeps you in scope
  • The under-250-employee exemption is narrow: it falls away if processing is risky, is not occasional, or includes special-category data (Art. 9) — any one is enough.
  • Art. 9 special categories include health, genetic, and biometric data — so a form collecting a diagnosis is in scope regardless of company size.
Source: GDPR Art. 9 ↗
The problem

Why a hand-kept register goes stale.

1

A hand-maintained ROPA drifts from the real app: forms change, fields get added, the spreadsheet doesn’t. At audit, the register doesn’t match the software.

2

When UI lives in a builder, there’s no machine-readable description of what each field collects — the register is reconstructed by interviewing people.

3

Spotting special-category (Art. 9) fields by hand is error-prone — a “diagnosis” field is health data whether or not anyone labelled it.

The answer

What the contract gives you — and what the semantic layer adds.

Requirement
What it needs
How Blueprint answers it
Art. 30(1) · contents
Purposes, data categories, recipients, retention.
The contract already declares every field the form collects — the machine-readable inventory of your data. With the semantic layer (after v1) it emits the full register: each field with its meaning, classification and retention.
Art. 30(4) · keep it current
The record must match the processing.
The source is the same contract that renders the screen, so it can’t drift from the app — and the semantic layer regenerates the register on every change.
Art. 9 · special categories
Identify health, biometric, and other Art. 9 data.
Coming with the semantic layer: a classifier that auto-flags special-category fields (e.g. health), so a “diagnosis” field is caught whether or not anyone labelled it.
Standards-out · interop
Portable, machine-readable records.
Coming with the semantic layer: the canonical entity maps to schema.org and FHIR R4 — data born structured at the point of entry.
The semantic layer · after v1

What it will produce: a register that matches the app.

The register the semantic layer emits from the contract — every field classified, the special-category ones flagged.

register/patient-intake.ropa.json · emitted by the semantic layer (after v1)
{ "record": "patient-intake", "fields": [
  { "name": "email",     "class": "personal" },
  { "name": "diagnosis", "class": "health", "art9": true },
  { "name": "allergies", "class": "health", "art9": true },
  { "name": "consent",   "class": "none", "basis": "explicit" }
] }

Special-category fields flagged

2Art. 9 fields, auto-detected

The register

  • Built from the design yes
  • Regenerates on change yes
  • Export PDF / CSV

The honest part

Article 30 is your obligation as controller or processor — Blueprint doesn’t file it for you, and it doesn’t decide your legal basis. Today, the contract is the drift-proof, machine-readable inventory of what you collect — the source of truth your register is built from, that can’t diverge from the app. The classifier, the Art. 9 auto-flagging, and the generated register above are the semantic layer — shipping after v1. Your DPO reviews and owns the record either way.

For your privacy review

The questions your DPO will ask.

Does Blueprint file our ROPA for us?

No. Article 30 is your obligation as controller or processor. Blueprint gives you the machine-readable source of truth — and, with the semantic layer, generates the register from it — so it’s accurate and current; your DPO reviews and owns it.

Aren’t small companies exempt?

Rarely. The under-250-employee exemption falls away if your processing is risky, is not occasional, or includes special-category data (Art. 9) — health data alone keeps you in scope. Treat the exemption as the exception, not the rule.

How will it flag health data?

The semantic layer — shipping after v1 — classifies fields from their declared meaning and auto-flags special-category (Art. 9) data, so a “diagnosis” field is caught whether or not someone remembered to.

Where do purposes, legal basis and retention come from?

You declare them once in the contract’s metadata (with the semantic layer); the register carries them per field. They’re your decisions, captured in one place — not invented by the tool.

Sources

Verify it yourself.

The Article 30 and Article 9 obligations this page relies on.

The other obligations

Continue across the regulation map.

PCI DSS Payment-page scripts Residency Data residency & sovereignty HIPAA Protected health data Audit Change control Self-host Self-host & air-gap
Bring us your hardest audit

Your contract is the drift-proof source of truth. Your DPO builds from it, not from interviews.

Talk to us about your audit Back to the regulation map