GDPR Article 32 checklist.
For engineering teams.

Article 32 is the article supervisors reach for when something has gone wrong technically. Encryption gaps, broken access control, missing audit logs — these are the failures that show up in fine notices. It is also the article most cleanly mapped to cloud controls you can actually verify in code.

The text says: "appropriate technical and organisational measures." The four named measures are pseudonymisation, encryption, ongoing CIA (confidentiality / integrity / availability), and the ability to restore. The rest of this page is what those four mean in practice.

• check_circle
  TLS 1.2 or higher in transit

  All personal data flows are TLS-terminated at 1.2 minimum. Test from outside the VPC.
• check_circle
  AES-256 at rest

  Production databases, object storage, and backups encrypted with AES-256 or equivalent.
• check_circle
  KMS with key rotation

  Customer-managed key option enabled where required. Rotation enforced ≤ 365 days.
• check_circle
  Pseudonymisation where feasible

  Identifiers separated from sensitive attributes. Re-identification keys stored separately.
• check_circle
  Documented and reviewed

  Encryption configuration captured in code/config, reviewed periodically. Article 32 requires evidence, not a one-time setting.

• check_circle
  Role-based access control

  IAM roles tied to documented confidentiality commitments. No broad "production-admin" roles.
• check_circle
  Need-to-know enforcement

  Personal data access scoped to the engineers who actually need it. Reviewed quarterly.
• check_circle
  Audit logs of access

  Every access to personal data store logged. Logs retained per Article 5(2) accountability.
• check_circle
  Instruction-bound processing

  Article 32(4): no processing outside controller instructions. Technical enforcement, not just a policy doc.

The trap most teams hit on Article 32(4): "natural persons acting under the authority of the controller... process personal data only on instructions from the controller." Translation: your engineers can't run ad-hoc queries on production personal data without an audit trail tying the query to a documented purpose. Most teams have audit logs; few have the join from "audit log" to "documented purpose."

• check_circle
  Backups + tested restore

  Backups exist and have been restored from in the last 90 days. Untested backups don't count.
• check_circle
  Availability monitoring

  Uptime SLO defined and monitored. Personal data systems have a runbook for outages.
• check_circle
  Periodic security testing

  Pen-test, scanner runs, dependency audit on a real cadence — annually minimum.

The "ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident" requires that you have actually tested restore. A backup that has never been restored is not an Article 32 control; it's a hope.

The full Article 32 surface is bundled in RuleMesh as access-control-security — 19 IT requirements, 89 evidence checks, 17 high-risk items, mapped to all three major clouds.

~/your-repo $ claude mcp add rulemesh
~/your-repo $ # then, in your agent:
implement bundle access-control-security

The agent pulls the rules, implements the controls (or stubs them where it needs your sign-off), runs scans against the repo locally, and submits evidence signals — file paths and check results, never source. You verify in your tracker.

• Article 32 deep dive: controls, evidence, and agent prompts →
• Cloud control mappings (AWS, Azure, GCP) →
• Security control mappings (NIST CSF, OWASP, ISO) →
• GDPR for developers — full guide →