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, four Prompts. The MCP server exposes a workflow of compliance tools — plan, pull rules, scan, submit evidence, verify — plus high-level Prompts (plan_compliance, scan_and_report_bundle, implement_bundle, review_bundle) that thread those tools together for you. Claude Code supports Prompts; for clients that don't, fall back to calling the tools directly.

~/your-repo $ claude mcp add rulemesh https://api.rulemesh.com/mcp
→ browser opens · log in with your RuleMesh email + password
✓ connected

/scan_and_report_bundle bundle_id="access-control-security"

/implement_bundle bundle_id="data-subject-rights"

Call pull_rules(bundle_id="access-control-security")
and produce a markdown checklist for our Jira epic. One line
per requirement, with the cloud control IDs and evidence type.
No code changes, no submit_signals — just the list.

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 →