/gdpr-compliant

GDPR Reference — Data Rights, Accountability & Governance

Load this file when you need implementation detail on: user rights endpoints, Data Subject Request (DSR) workflow, Record of Processing Activities (RoPA), consent management.

User Rights Implementation (Articles 15–22)

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.

Erasure Checklist — MUST cover all stores

When DELETE /api/v1/me is called, the erasure pipeline MUST scrub:

• Primary relational database (anonymize or delete rows)
• Read replicas
• Search index (Elasticsearch, Azure Cognitive Search, etc.)
• In-memory cache (Redis, IMemoryCache)
• Object storage (S3, Azure Blob — profile pictures, documents)
• Email service logs (Brevo, SendGrid — delivery logs)
• Analytics platform (Mixpanel, Amplitude, GA4 — user deletion API)
• Audit logs (anonymize identifying fields — do not delete the event)
• Backups (document the backup TTL; accept that backups expire naturally)
• CDN edge cache (purge if personal data may be cached)
• Third-party sub-processors (trigger their deletion API or document the manual step)

Data Export Format (GET /api/v1/me/data-export)

{
  "exportedAt": "2025-03-30T10:00:00Z",
  "subject": {
    "id": "uuid",
    "email": "user@example.com",
    "createdAt": "2024-01-15T08:30:00Z"
  },
  "profile": { ... },
  "orders": [ ... ],
  "consents": [ ... ],
  "auditEvents": [ ... ]
}

• MUST be machine-readable (JSON preferred, CSV acceptable).
• MUST NOT be a PDF screenshot or HTML page.
• MUST include all stores listed in the RoPA for this user.

DSR Tracker (back-office)

Implement a Data Subject Request tracker with:

• Incoming request date
• Request type (access / rectification / erasure / portability / restriction / objection)
• Verification status (identity confirmed y/n)
• Deadline (received date + 30 days)
• Assigned handler
• Completion date and outcome
• Notes

Automate the primary store scrubbing; document manual steps for third-party stores.

Record of Processing Activities (RoPA)

Maintain as a living document (Markdown, YAML, or JSON) version-controlled in the repo. Update with every new feature that introduces a processing activity.

Minimum fields per 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

Legal basis options (Art. 6)

Consent Management

MUST

• Store consent as an immutable event log, not a mutable boolean flag.
• Record: what was consented to, when, which version of the privacy policy, the mechanism.
• Load analytics / marketing SDKs conditionally — only after consent is granted.
• Provide a consent withdrawal mechanism as easy to use as the consent grant.

Consent store schema (minimum)

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)
);

MUST NOT

• MUST NOT pre-tick consent checkboxes.
• MUST NOT bundle consent for marketing with consent for service delivery.
• MUST NOT make service access conditional on marketing consent.
• MUST NOT use dark patterns (e.g., "Accept all" prominent, "Reject" buried).

Sub-processor Management

Maintain a sub-processor list updated with every new SaaS tool or cloud service that touches personal data.

Minimum fields per sub-processor:

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.

DPIA Triggers (Article 35)

A DPIA is mandatory before processing that is likely to result in a high risk. Triggers include:

• Systematic and extensive profiling with significant effects on individuals
• Large-scale processing of special category data (health, biometric, racial origin, sexual orientation, religion)
• Systematic monitoring of publicly accessible areas (CCTV, location tracking)
• Processing of children's data at scale
• Innovative technology with unknown privacy implications
• Matching or combining datasets from multiple sources

When in doubt: conduct the DPIA anyway. Document the outcome.