GDPR Article 17: how to prove erasure.

GDPR Article 17 requires a controller to erase personal data on request, but says nothing about proof. The duty to demonstrate compliance comes from Article 5(2), and it is the part most teams are least prepared for: a closed ticket shows a decision, not the state of the database. This guide is for the DPO or engineer who has to answer "show me" after the deletion job has run.

What does Article 17 actually require?

When one of the grounds in Article 17(1) applies — the data is no longer necessary, consent is withdrawn, the person objects, the processing was unlawful, and so on — the controller must erase the personal data "without undue delay". Article 12(3) puts a clock on it: respond within one month, extendable by two further months for complex or numerous requests, with the person told why.

Two further duties travel with the request. Article 19 requires the controller to tell every recipient of the data about the erasure, unless that is impossible or disproportionate. Article 17(2) adds that if the controller itself made the data public, it must take reasonable steps, given available technology and cost, to inform other controllers processing it that erasure of links and copies has been requested. So an erasure is rarely one delete statement; it is a fan-out across systems, processors, and sometimes third parties.

Where does the duty to prove it come from?

Article 5(2), the accountability principle: the controller "shall be responsible for, and be able to demonstrate compliance with" the data-protection principles. Article 24(1) repeats it for technical and organisational measures. Article 30 requires most controllers to keep a record of processing activities, including the envisaged time limits for erasure. None of these say "keep a deletion log", but together they mean that when a supervisory authority or an auditor asks how a specific request was handled, "we deleted it" is an assertion and the controller is expected to have something behind it.

The stakes are the ones in Article 83(5): infringements of the data-subject rights in Articles 12 to 22 sit in the higher fine band, up to €20 million or 4% of worldwide annual turnover, whichever is higher.

What evidence do teams usually have?

In practice, one of these:

• A ticket in the request-handling system, marked done, with a timestamp.
• An application log line: deleted user 48213.
• A screenshot of a query returning zero rows.
• A completion record exported from a privacy-workflow platform.

Each records that someone believed the deletion happened. None lets a reviewer confirm it independently. The log can be edited; the screenshot can be of any query; the ticket records a decision, not an observation of the database. This is not an accusation of dishonesty. It is the structural problem with self-attestation: the same party produces the claim and the evidence for it. That is the gap a verification record is built to close. It carries the measurement rather than an assertion about it: the systems that were queried, the hash of each query, the counts before and after, and two signatures over canonical bytes that a reviewer can check without asking the controller for anything. An inclusion proof in a public append-only log fixes when the record was made, so evidence cannot be produced later and dated earlier. None of that decides whether your erasure obligation was discharged — that is a legal judgement — but it gives whoever makes it something verifiable rather than something to be believed.

What would a regulator or auditor be able to check?

Evidence a third party can check has three properties.

It records observations, not intentions. What was in the system before, what was in it after, with timestamps — rather than "deletion executed".

It is signed by a party that did not perform the deletion. Independence is what separates evidence from testimony. If the signer had no way to make the data disappear and no stake in the answer, the signature carries weight.

It can be verified without trusting the signer's infrastructure. A published public key, standard signature algorithms, and a public log the reviewer can query themselves. If the check requires logging in to the vendor's dashboard, the reviewer is back to trusting a dashboard.

A verification record built this way is the artifact you hand over. BurnLedger's version is described in What is a deletion certificate?; the fields are in Verification Record anatomy.

A practical erasure evidence process

1. Know your systems. An erasure you cannot enumerate, you cannot prove. Keep the Article 30 record current, down to the datastore.
2. Snapshot before you delete. Record, per system, that records for this subject exist. In BurnLedger this is the attest call: a read-only query, hashed in memory, nothing retained but the hash.
3. Delete with your own tools. Nothing about proof requires giving a third party write access. Keep the deletion logic where it already lives.
4. Re-query after. The same query, the same systems. If any comes back non-empty, the deletion is incomplete and no verification record is issued.
5. Get the observations signed and logged. A verification record that binds subject, systems, both snapshots and both timestamps under a signature, entered in a public transparency log so it cannot be backdated or quietly withdrawn.
6. File it with the request. Store the verification record next to the ticket, along with the issuer's public keys, so the pair can be verified years later without anyone's cooperation.
7. Extend it to processors. Article 28(3)(g) requires processors, at the controller's choice, to delete or return all personal data at the end of the service and to delete existing copies unless law requires their retention. Ask them for the same standard of evidence. Free, CC0 contract language for this is in the Verifiable Deletion Addendum.

A worked example: one request, end to end

The clock below is one erasure request handled with the process above. The three timestamps on day 3 are the ones a BurnLedger verification record carries — the attestation, the verification, and the issue time — taken from the verification record in What is a deletion certificate?. Everything else is the controller's own record.

Day 0   2025-06-12  Request received by email.            Art. 12(3): one-month clock starts.
                    Identity confirmed; ticket opened.    Art. 12(6): only if there is reasonable doubt.
Day 1   2025-06-13  Ground identified: consent withdrawn. Art. 17(1)(b).
                    Systems enumerated from the           Art. 30 record of processing:
                    processing record: prod-users (postgresql), logs-s3 (s3).
                    Recipients listed: 1 processor.       Art. 19.
Day 3   2025-06-15  12:00:00Z  ATTEST   prod-users: 42 records   logs-s3: 7 objects
                                        (read-only query, hashed; signed by BurnLedger)
                    12:00–12:05 DELETE  controller runs its own deletion job
                    12:05:00Z  VERIFY   prod-users: 0            logs-s3: 0
                    12:05:01Z  ISSUE    certificate dc_111111 signed, log entry #1
                    Processor asked to delete its copy    Art. 19 / Art. 28(3)(g).
Day 5   2025-06-17  Reply to the data subject:            Art. 12(3): "without undue delay".
                    erasure done, recipients informed,    Art. 19: recipients on request.
                    backups out of scope until overwrite. (ICO guidance on backups)
Day 8   2025-06-20  Processor's own deletion certificate  Art. 28(3)(h): evidence for the controller.
                    received and filed with the ticket.
Day 30  2025-07-12  Statutory deadline. Not needed.       Art. 12(3).
        later       Auditor asks "show me": ticket +      Art. 5(2): the certificate verifies offline
                    certificate + issuer's public keys.   against published keys; no one's word required.

The point of the layout is the five-minute window on day 3. Everything before it is intention and process; everything after it is paperwork. The two observations either side of the deletion, and the signature over them, are the only lines a reviewer can check without trusting the controller.

What about backups?

The UK ICO's guidance on the right to erasure accepts that data may remain in a backup until it is overwritten on an established schedule, provided it is put "beyond use", not used for any other purpose, and the individual is told clearly what will happen to their data — while still expecting the controller to take steps toward erasure from backups. EU supervisory authorities have not published an equivalent general position. Honest evidence therefore states its scope: which live systems were checked, and that backups were out of scope. A verification record should claim only what was observed. BurnLedger's verification records name exactly the systems and query hashes they cover, and the verification record documentation states what falls outside that.

Common questions

Does GDPR require a deletion certificate?

No. GDPR requires that you erase the data (Article 17) and that you can demonstrate compliance with the principles that erasure serves (Article 5(2)). A verification record is a way of meeting the second duty with evidence a supervisory authority can check independently, rather than a record it has to take on trust.

How long do I have to erase data under Article 17?

Without undue delay, and in any case you must respond within one month of receiving the request (Article 12(3)). That period may be extended by two further months where necessary, taking into account the complexity and number of requests, provided you tell the person within the first month and explain why.

Do I have to tell third parties about an erasure?

Usually. Article 19 requires you to communicate the erasure to each recipient the data was disclosed to, unless that proves impossible or involves disproportionate effort, and to tell the data subject about those recipients if asked. If you made the data public, Article 17(2) adds a duty to take reasonable steps to inform other controllers.

Is a screenshot of an empty query enough evidence?

It shows that some query returned nothing at some moment on someone's screen. It does not show which query, against which system, or that the same query returned rows before. A reviewer who wants to be rigorous has no way to distinguish it from a screenshot of the wrong query. Before-and-after observations, signed by an independent party, are checkable; a screenshot is not.