/gdpr-compliant

name: gdpr-compliant
description: 'Apply GDPR-compliant engineering practices across your codebase. Use this skill whenever you are designing APIs, writing data models, building authentication flows, implementing logging, handling user data, writing retention/deletion jobs, designing cloud infrastructure, or reviewing pull requests for privacy compliance. Trigger this skill for any task involving personal data, user accounts, cookies, analytics, emails, audit logs, encryption, pseudonymization, anonymization, data exports, breach response, CI/CD pipelines that process real data, or any question framed as "is this GDPR-compliant?". Inspired by CNIL developer guidance and GDPR Articles 5, 25, 32, 33, 35.'

GDPR Engineering Skill

Actionable GDPR reference for engineers, architects, DevOps, and tech leads. Inspired by CNIL developer guidance and GDPR Articles 5, 25, 32, 33, 35.

> **Golden Rule:** Collect less. Store less. Expose less. Retain less.

For deep dives, read the reference files in `references/`:

• `references/data-rights.md` — user rights endpoints, DSR workflow, RoPA
• `references/security.md` — encryption, hashing, secrets, anonymization
• `references/operations.md` — cloud, CI/CD, incident response, architecture patterns

---

1. Core GDPR Principles (Article 5)

| Principle | Engineering obligation | |---|---| | Lawfulness, fairness, transparency | Document legal basis for every processing activity in the RoPA | | Purpose limitation | Data collected for purpose A **MUST NOT** be reused for purpose B without a new legal basis | | Data minimization | Collect only fields with a documented business need today | | Accuracy | Provide update endpoints; propagate corrections to downstream stores | | Storage limitation | Define TTL at schema design time — never after | | Integrity & confidentiality | Encrypt at rest and in transit; restrict and audit access | | Accountability | Maintain evidence of compliance; RoPA ready for DPA inspection at any time |

---

2. Privacy by Design & by Default

**MUST**

• Add `CreatedAt`, `RetentionExpiresAt` to every table holding personal data at creation time.
• Default all optional data collection to **off**. Users opt in; they never opt out of a default-on setting.
• Conduct a **DPIA** before building high-risk processing (biometrics, health data, large-scale profiling, systematic monitoring).
• Update the **RoPA** with every new feature that introduces a processing activity.
• Sign a **DPA** with every sub-processor before data flows to them.

**MUST NOT**

• Ship a new data collection feature without a documented legal basis.
• Enable analytics, tracking, or telemetry by default without explicit consent.
• Store personal data in a system not listed in the RoPA.

---

3. Data Minimization

**MUST**

• Map every DTO/model field to a concrete business need. Remove undocumented fields.
• Use **separate DTOs** for create, read, and update — never reuse the same object.
• Return only what the caller is authorized to see — use response projections.
• Mask sensitive values at the edge: return `****1234` for card numbers, never the full value.
• Exclude sensitive fields (DOB, national ID, health) from default list/search projections.

**MUST NOT**

• Log full request/response bodies if they may contain personal data.
• Include personal data in URL path segments or query parameters (CDN logs, browser history).
• Collect `dateOfBirth`, national ID, or health data without an explicit legal basis.

---

4. Purpose Limitation

**MUST**

• Document the purpose of every processing activity in code comments and in the RoPA.
• Obtain a new legal basis or perform a compatibility analysis before reusing data for a secondary purpose.

**MUST NOT**

• Share personal data collected for service delivery with advertising networks without explicit consent.
• Use support ticket content to train ML models without a separate legal basis and user notice.

---

5. Storage Limitation & Retention

**MUST**

• Every table holding personal data **MUST** have a defined retention period.
• Enforce retention automatically via a scheduled job (Hangfire, cron) — never a manual process.
• Anonymize or delete data when retention expires — never leave expired data silently in production.

**Recommended defaults**

| Data type | Max retention | |---|---| | Auth / audit logs | 12–24 months | | Session / refresh tokens | 30–90 days | | Email / notification logs | 6 months | | Inactive user accounts | 12 months after last login → notify → delete | | Payment records | As required by tax law (7–10 years), minimized | | Analytics events | 13 months |

**SHOULD**

• Add `RetentionExpiresAt` column — compute at insert time.
• Use soft-delete (`DeletedAt`) with a scheduled hard-delete after the erasure request window (30 days).

**MUST NOT**

• Retain personal data indefinitely "in case it becomes useful later."

---

6. API Design Rules

**MUST**

• MUST NOT include personal data in URL paths or query parameters.
• `GET /users/{userId}`
• Authenticate all endpoints that return or accept personal data.
• Extract the acting user's identity from the JWT — never from the request body.
• Validate ownership on every resource: `if (resource.OwnerId != currentUserId) return 403`.
• Use UUIDs or opaque identifiers — never sequential integers as public resource IDs.

**SHOULD**

• Rate-limit sensitive endpoints (login, data export, password reset).
• Set `Referrer-Policy: no-referrer` and an explicit `CORS` allowlist.

**MUST NOT**

• Return stack traces, internal paths, or database errors in API responses.
• Use `Access-Control-Allow-Origin: *` on authenticated APIs.

---

7. Logging Rules

**MUST**

• Anonymize IPs in application logs — mask last octet (IPv4) or last 80 bits (IPv6).
• `192.168.1.xxx`
• MUST NOT log: passwords, tokens, session IDs, credentials, card numbers, national IDs, health data.
• MUST NOT log full request/response bodies where PII may be present.
• Enforce l