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 the data it collects, the contract already holds that information — so your ROPA is generated from the design, and it can’t drift from the app.
The obligation: Article 30 GDPR — controllers and processors must maintain records of their processing activities. GDPR Art. 30 ↗
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.
- 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.
- 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.
Why a hand-kept register goes stale.
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.
When UI lives in a builder, there’s no machine-readable description of what each field collects — the register is reconstructed by interviewing people.
Spotting special-category (Art. 9) fields by hand is error-prone — a “diagnosis” field is health data whether or not anyone labelled it.
The register is emitted from the design, point by point.
What a DPO sees: a register that matches the app.
Generated from the contract — every field classified, the special-category ones flagged.
{ "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
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. What it does: because the form declares what it collects, the register is generated from the design — classification and Art. 9 flags derived automatically, purposes, legal basis and retention carried from the metadata you declare once — so it matches the app and stays current. Your DPO reviews and owns it.
The questions your DPO will ask.
Does Blueprint file our ROPA for us?
No. Article 30 is your obligation as controller or processor. Blueprint generates the register from your contract 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 does it flag health data?
The semantic layer classifies fields from their declared meaning and auto-flags special-category (Art. 9) data — so a “diagnosis” field is flagged whether or not someone remembered to.
Where do purposes, legal basis and retention come from?
You declare them once in the contract’s metadata; the register carries them per field. They’re your decisions, captured in one place — not invented by the tool.
Verify it yourself.
The Article 30 and Article 9 obligations this page relies on.
- PrimaryEUR-Lex — Regulation (EU) 2016/679 (GDPR) — the authoritative consolidated text (Articles 30 and 9).
- Art. 30GDPR Article 30 — Records of processing activities — record contents (30(1)–(2)) and the narrow under-250 exemption (30(5)).
- Art. 9GDPR Article 9 — Special categories of personal data — health, genetic, biometric, and the other special categories.