Gdpr-Compliant

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