-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Web application for managing a GDPR/RGPD processing activities register.
GDPR Article 30 requires every organisation that processes personal data at non-trivial scale to maintain a written register of processing activities, the "who, what, why, where, how long, and how secured" of every data-handling operation, and produce it on demand for the supervisory authority (CNIL in France, equivalent DPAs elsewhere).
Most organisations end up maintaining this register in a spreadsheet that drifts out of sync with reality the moment the spreadsheet is closed: no review cadence, no validation workflow, no audit trail, no link to the DSRs / vendors / violations that actually exercise the processing it describes.
This app exists to make that register a first-class, living artefact: a typed schema instead of free-form cells, a DPO validation workflow instead of undated edits, a tamper-evident audit log instead of "last modified by" metadata, and structured links to the operational surfaces (DSR intake, vendor DPAs, breach log, DPIA screening) that the register is supposed to describe. The name isn't a hedge, the entire data model is Article 30 turned into code.
For new organisations migrating from an existing register, the Import button on the Treatment register opens a three-step modal: download the XLSX template, fill it (one row per treatment, ; separator for multi-value cells), then upload. The server returns a preview showing which rows are ready, conflicting (name already in use), or invalid (missing required fields, unknown legal basis, or unknown assignee email). The commit step is all-or-nothing: any error blocks the entire import until the file is fixed.
The template covers a flat subset of the Treatment fields (name, purpose, legalBasis, personCategories, subPurposes, retentionPeriod, assignedToEmail). Nested fields (data categories, recipients, transfers, security measures, sensitive categories, risk criteria) are filled per-treatment in the wizard after the bootstrap import. Cap: 500 rows / 5 MB per upload.
The Treatment model maps point-for-point against GDPR Article 30(1). The schema is the regulatory checklist turned into a data model, not a branding choice.
| Art. 30(1) paragraph | Field(s) on Treatment / Organization
|
|---|---|
| (a) controller / representative / DPO contact |
Organization: companyName, address, representativeName/Role, dpoName/Email/Phone
|
| (b) purposes of processing |
purpose, subPurposes
|
| (c) categories of data subjects + personal data |
personCategories, dataCategories (+ hasSensitiveData / sensitiveCategories for Art. 9) |
| (d) categories of recipients (incl. third-country) |
recipientTypes, recipients
|
| (e) third-country transfers + safeguards |
transfers (JSON) |
| (f) retention periods | retentionPeriod |
| (g) technical / organizational security measures |
securityMeasures, securityMeasuresDetailed
|
On top of Article 30 strictly, the model also captures:
- Art. 6(1) lawful basis
- Art. 35 DPIA triggers
- DPO validation workflow
- Register reference number
- Art. 30(4) "make available to the supervisory authority"
- Storage - how document and attachment downloads flow through the backend, with the per-entity authorization model.