Setting the file. One moment.
Subchapter 179.1
references/data-rights.mdMarkdown6 KBView on GitHub
Load this file when you need implementation detail on: user rights endpoints, Data Subject Request (DSR) workflow, Record of Processing Activities (RoPA), consent management.
Every right MUST have a tested API endpoint or documented back-office process before the system goes live. Respond to verified requests within 30 calendar days.
| Right | Article | Engineering implementation |
|---|---|---|
| Right of access | 15 | GET /api/v1/me/data-export — all personal data, JSON or CSV |
| Right to rectification | 16 | PUT /api/v1/me/profile — propagate to all downstream stores |
| Right to erasure | 17 | DELETE /api/v1/me — scrub all stores per erasure checklist |
| Right to restriction | 18 | ProcessingRestricted flag on user record; gate non-essential processing |
| Right to portability | 20 | Same as access endpoint; structured, machine-readable (JSON) |
| Right to object | 21 | Opt-out endpoint for legitimate-interest processing; honor immediately |
| Automated decision-making | 22 | Expose a human review path + explanation of the logic |
When DELETE /api/v1/me is called, the erasure pipeline MUST scrub:
{
"exportedAt": "2025-03-30T10:00:00Z",
"subject": {
"id": "uuid",
"email": "user@example.com",
"createdAt": "2024-01-15T08:30:00Z"
},
"profile": { ... },
"orders": [ ... ],
"consents": [ ... ],
"auditEvents": [ ... ]
}Implement a Data Subject Request tracker with:
Automate the primary store scrubbing; document manual steps for third-party stores.
Maintain as a living document (Markdown, YAML, or JSON) version-controlled in the repo. Update with every new feature that introduces a processing activity.
- name: "User account management"
purpose: "Create and manage user accounts for service access"
legalBasis: "Contract (Art. 6(1)(b))"
dataSubjects: ["Registered users"]
personalDataCategories: ["Name", "Email", "Password hash", "IP address"]
recipients: ["Internal engineering team", "Brevo (email delivery)"]
retentionPeriod: "Account lifetime + 12 months"
transfers:
outside_eea: true
safeguard: "Brevo — Standard Contractual Clauses (SCCs)"
securityMeasures: ["TLS 1.3", "AES-256 at rest", "bcrypt password hashing"]
dpia_required: false| Basis | When to use |
|---|---|
Contract (6(1)(b)) | Processing necessary to fulfill the service contract |
Legitimate interest (6(1)(f)) | Fraud prevention, security, analytics (requires balancing test) |
Consent (6(1)(a)) | Marketing, non-essential cookies, optional profiling |
Legal obligation (6(1)(c)) | Tax records, anti-money-laundering |
Vital interest (6(1)(d)) | Emergency situations only |
Public task (6(1)(e)) | Public authorities |
CREATE TABLE ConsentRecords (
Id UUID PRIMARY KEY,
UserId UUID NOT NULL,
Purpose VARCHAR(100) NOT NULL, -- e.g. "marketing_emails", "analytics"
Granted BOOLEAN NOT NULL,
PolicyVersion VARCHAR(20) NOT NULL,
ConsentedAt TIMESTAMPTZ NOT NULL,
IpAddressHash VARCHAR(64), -- HMAC-SHA256 of anonymized IP
UserAgent VARCHAR(500)
);Maintain a sub-processor list updated with every new SaaS tool or cloud service that touches personal data.
Minimum fields per sub-processor:
| Field | Example |
|---|---|
| Name | Brevo |
| Service | Transactional email |
| Data categories transferred | Email address, name, email content |
| Processing location | EU (Paris) |
| DPA signed | 2024-01-10 |
| DPA URL / reference | [link] |
| SCCs applicable | N/A (EU-based) |
MUST review the sub-processor list annually and upon any change. MUST NOT allow data to flow to a new sub-processor before a DPA is signed.
A DPIA is mandatory before processing that is likely to result in a high risk. Triggers include:
When in doubt: conduct the DPIA anyway. Document the outcome.