GDPR for developers.
What to actually build.

When the GDPR pressure lands on engineering, it almost always lands as a request to "implement GDPR" — handed down as a 261-page document. It is not 261 pages of engineering work. The articles that touch your code, your config, and your data stores collapse into a handful of recurring patterns.

Roughly: encryption, access control, audit logging, data subject rights (export / delete / restrict), retention enforcement, processor commitments, and breach notification plumbing. The rest is governance — written work for the DPO, not your sprint.

• check_circle
  Encryption (Article 32(1)(a))

  TLS 1.2+ in transit, AES-256 at rest, KMS with key rotation. Cloud-side: AWS KMS, Azure Key Vault, GCP CMEK.
• check_circle
  Access control (Articles 28(3)(b), 29, 32(4))

  Role-based access tied to documented confidentiality commitments. Periodic reviews. Audit logs of provisioning + processing.
• check_circle
  Audit logging (Article 5(2))

  Comprehensive logs that demonstrate accountability — purpose, lawful basis, retention. CloudTrail, Azure Monitor, Cloud Audit Logs.
• check_circle
  Data subject rights (Articles 15–22)

  Export, rectification, erasure, restriction. Deletion that actually deletes from backups, replicas, and search indexes — not just the primary table.
• check_circle
  Retention (Article 5(1)(e))

  Per-purpose retention rules enforced in code. Hard delete, not soft-delete. Schedule jobs, not policy docs.
• check_circle
  Processor commitments (Article 28)

  Documented purposes, instructions, sub-processor flow-down. Processing technically restricted to controller-defined purposes.
• check_circle
  Breach notification (Articles 33–34)

  Detection plumbing + a 72-hour escalation path. Most teams have detection. Few have the escalation runbook.

The fastest path through GDPR engineering work is the same path you already use for everything else: prompt your coding agent. The constraint is that the agent doesn't know GDPR — it can guess at "implement encryption" but it doesn't know which article requires what, what evidence proves it, or which cloud control satisfies it.

That's what RuleMesh's MCP server provides. The agent calls pull_rules(bundle_id), gets back the requirement, the cloud control mappings, and the evidence schema, then writes the code. Your source never leaves the machine.

~/your-repo $ claude mcp add rulemesh
→ opens browser to authenticate
→ tool registered: pull_rules
→ tool registered: submit_signals
✓ connected · workspace="acme"

From that point, any prompt of the shape "implement bundle X" works. The agent pulls the requirements, implements them, scans the codebase locally, and submits evidence signals. Verification still happens in Jira (or your tool of choice).

1. 01
   Week 1 — Map the data

   Run an inventory: which services touch personal data, where it lives, who has access. Don't trust the wiki — read the schema. The map is more important than any policy doc.
2. 02
   Week 2 — Lock the perimeter

   Encryption (in transit + at rest) and access control. These two close the most exposure for the least work and are required by Article 32 explicitly.
3. 03
   Week 3 — DSR plumbing

   Build the export and delete pipelines. Test that delete actually removes from replicas, backups, and search indexes. Most teams discover their search index leaks PII at this stage.
4. 04
   Week 4 — Retention + audit log

   Per-purpose retention rules in code, scheduled deletion jobs, and an audit log that demonstrates accountability. Article 5(2) is the article that gets companies fined when nothing else does.

Some GDPR obligations are not engineering problems and won't be solved by writing better software. Records of Processing Activities (Article 30) is paperwork. Data Protection Impact Assessments (Article 35) are paperwork. The lawful basis for each processing purpose is a legal call, not a code change.

Engineering's job is the execution layer — the place where the policy gets enforced and the evidence gets generated. The policy itself still has to exist somewhere, and it's not your job to write it. Insist on that boundary.

• GDPR Article 32 checklist for engineering teams →
• GDPR checklist for SaaS engineering teams →
• Run a GDPR audit with Claude Code, Cursor, or Codex →
• Cloud control mappings (AWS, Azure, GCP) →