Files
awesome-copilot/skills/gdpr-compliant/references/data-rights.md
Mikael 7454bbdb7c feat: add GDPR-compliant engineering practices skill documentation (#1230)
* feat: add GDPR-compliant engineering practices skill documentation

* Add GDPR compliance references for Security and Data Rights

- Introduced a comprehensive Security.md file detailing encryption, password hashing, secrets management, anonymization, cloud practices, CI/CD controls, and incident response protocols.
- Created a Data Rights.md file outlining user rights implementation, Record of Processing Activities (RoPA), consent management, sub-processor management, and DPIA triggers.

* Refine GDPR compliance documentation by removing unnecessary symbols and ensuring clarity in security and data rights references

* refactor: streamline description formatting in GDPR compliance skill documentation

---------

Co-authored-by: Aaron Powell <me@aaron-powell.com>
2026-03-31 10:53:25 +11:00

6.4 KiB
Raw Blame History

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

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

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

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.
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:

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.


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.