A GDPR audit checklist for engineering teams

Published on September 16, 2026

When a real audit lands, the questions aren't legal ones. They're data questions. Here's what an engineer needs to be able to show, and where each piece lives if you run on Tripticonsent.

A GDPR audit almost never opens with a legal question. It opens with a data question: "show me the exact consent this user gave, on this date, and prove it hasn't changed since." If that question sends you off to write an ad-hoc query against production, you're already behind.

Here's what a serious audit actually asks for, laid out as a checklist. Each item links to where that piece lives if you run on Tripticonsent, but the standard itself applies equally to any stack, including a hand-built one.

A boolean on a users table only tells you the current state. A regulator asks about a moment in the past: which version of the clause was published, and what that person decided about that exact version. That requires storing every change as a new row, never overwriting the previous one. In the vault this is the full per-subject timeline: consent, preferences, and merges, each timestamped.

2. Can you prove exactly what the person saw, word for word?

Knowing they accepted "marketing" isn't enough. You need the exact text in front of them at that moment, with its version. The signed receipt includes a hash of the exact clause text alongside the decision, so any dispute over what the banner said gets resolved by comparing hashes, not memories.

3. Can anyone verify that proof without taking your word for it?

This is the question almost no homegrown stack asks itself until it's too late. A receipt signed with Ed25519 verifies against the public keys at /.well-known/jwks.json, without calling your API. We wrote about this in detail in what a signed receipt actually proves.

4. Can you deliver a complete export for one person on request?

An export DSAR isn't "search their email in the database." It's complete history, receipts included, delivered in a verifiable way. The data request flow generates a signed, expiring URL for exactly this.

5. When you delete someone, are they actually gone, and can you prove it?

"Delete" in most homegrown systems means an update that sets a deleted-at date. The identifier is still sitting in plaintext in some backup somewhere. Real crypto-shredding destroys the identifier's encryption material immediately: the subject becomes unlocatable from that instant, and the anonymized record left behind serves as defensive proof, not a liability.

6. Can your own change log be altered without anyone noticing?

An audit log an admin can quietly edit isn't proof, it's an opinion. Every entry in a hash-chained log includes the hash of the entry before it. Altering or deleting a row in the middle breaks the chain from that point forward, visibly, without depending on anyone manually reviewing the logs.

7. Do you know, and can you show, who else touches that data?

An auditor asks about sub-processors: who handles the data besides you. Stripe for payments, Groq for AI cookie classification when enabled, your hosting provider. The full list, with what each one does, needs to be published ahead of time, not discovered during the audit itself.

None of these seven items is unique to Tripticonsent. They're the list a serious auditor checks against any stack. The difference is whether the answer to each one is "yes, look here" or "give me a week to rebuild it."