GDPR checklist.
For SaaS engineering teams.

1. 01
   Day 1–3 · Inventory the data

   List every service that touches personal data, where it stores, who has access. The map is the artifact — most teams skip this and pay for it later.
2. 02
   Day 4–8 · Encryption + access

   Encryption at rest and in transit (Article 32(1)(a)), RBAC + MFA + audit log on personal data stores (Articles 28(3)(b), 32(4)). These two are non-negotiable.
3. 03
   Day 9–14 · DSR plumbing

   Export and delete endpoints. Test that delete propagates to replicas, backups, search indexes, and analytics warehouses. Articles 15, 17, 20.
4. 04
   Day 15–21 · Retention + audit log

   Per-purpose retention rules in code, scheduled deletion jobs, audit log demonstrating accountability. Articles 5(1)(e), 5(2).
5. 05
   Day 22–26 · Processor commitments

   Sub-processor list (public page), DPA template ready to send, processing instructions documented. Article 28.
6. 06
   Day 27–30 · Breach plumbing

   Detection in place + 72-hour escalation runbook. Most teams have detection, few have the runbook. Articles 33, 34.

The structure below maps onto RuleMesh bundles, but works whether or not you use the Jira app. Five epics, each carrying its own IT requirements, cloud control mappings, and evidence schema.

• check_circle
  EPIC: access-control-security

  Bundles encryption, RBAC, audit logging. 19 sub-tasks if you map every IT requirement; ~6 if you collapse them.
• check_circle
  EPIC: data-subject-rights

  Export endpoint + delete pipeline + restriction handling. Test against your search index and analytics warehouse.
• check_circle
  EPIC: retention-and-deletion

  Per-purpose retention schedule, scheduled jobs, hard-delete (not soft).
• check_circle
  EPIC: processor-governance

  Sub-processor inventory, DPA template, instruction-bound processing controls.
• check_circle
  EPIC: breach-notification-pipeline

  Detection → escalation → 72-hour notification runbook.

One install, one prompt. The MCP server returns the bundle's IT requirements, cloud control mappings, and evidence schema. The agent does the rest.

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

Run an audit of this repo against GDPR Article 32 controls.
Use rulemesh.pull_rules("access-control-security") and tell me what's
already in place vs what's missing. Submit findings via submit_signals.

Implement the data-subject-rights bundle. Pull the rules from
rulemesh, write the export and delete endpoints, test that delete
propagates to replicas and search indexes, and submit evidence for
each requirement.

Pull the access-control-security bundle from rulemesh and produce a
markdown checklist I can paste into our Jira epic. One line per
requirement, with the cloud control IDs and evidence type.

This checklist is engineering work — the layer where compliance is demonstrable. It does not replace:

• The Records of Processing Activities document (Article 30) — paperwork, owned by the DPO.
• The Data Protection Impact Assessment for high-risk processing (Article 35) — paperwork, owned by the DPO.
• The lawful basis decision for each processing purpose — legal call, owned by counsel.
• The DPA you sign with customers and sub-processors — legal artifact.

Engineering owns the execution layer. That's a feature, not a bug.

• GDPR for developers — full guide →
• GDPR for SaaS startups — what enterprise procurement checks →
• Run a GDPR audit with Claude Code, Cursor, or Codex →
• The RuleMesh Jira app →