The Verifiable Deletion Addendum.

Contract language a controller can drop into a Data Processing Agreement to require evidence of deletion they can check for themselves — instead of a letter saying it happened. Version 1.0. Public domain under CC0. No attribution required.

This is a template, not legal advice. It has not been reviewed by counsel on your behalf, makes no accommodation for your jurisdiction, and the bracketed values are decisions only you can make. Have your own lawyer review it before it goes near an executed agreement.

Why this exists

Virtually every enterprise DPA already requires a processor to “certify” deletion at the end of the engagement. The EU Standard Contractual Clauses say so outright — Clause 8.5 and Clause 16(d) both oblige the data importer to certify deletion to the exporter.

In practice that certification is a signed letter. The party with the strongest incentive to say deletion happened is the only party attesting that it did, and the receiving party has no way to check. When the EDPB ran its coordinated enforcement action on the right to erasure in February 2026 — 32 authorities, 764 controllers — it reported that controllers routinely fail to confirm erasure was actually carried out. The addendum below replaces that letter with a property a counterparty can check: evidence that named systems were queried, that matching records existed, and that they no longer do — signed, and placed in a log whose contents cannot be rewritten without leaving a trace. It names no supplier, because a clause naming a vendor is one no lawyer will insert into a client’s agreement. It specifies properties instead, and anything meeting them qualifies.

This addendum replaces trust the letter with check the evidence.

Written by BurnLedger, which sells a product that satisfies it. We are not disinterested and it would be silly to pretend otherwise. But the clause below names no supplier, and that is deliberate rather than modest: a clause naming a vendor is one no lawyer will insert into their client’s agreement, so a vendor-locked clause would be worth nothing to you and nothing to us. It specifies properties. Anything meeting them qualifies — including things that don’t exist yet.

No warranty, and no reliance. This text is provided as-is, without warranty of any kind, express or implied. Adopting it does not achieve compliance with the GDPR, the UK GDPR, the CCPA, or any other law, and nothing here should be read as saying it does — a clause is a requirement placed on a counterparty, not a state of affairs. Whether your processing complies is a question about what your processors actually do, which no contract language can settle on its own. Neither ProChatFlow LLC nor any contributor accepts liability arising from use of this text.

The clause

Copy from here. It is written to be pasted into an existing agreement as a named addendum.

Verifiable Deletion Addendum

1. Definition. “Verifiable Deletion Evidence” means a record which:

(a) is cryptographically signed such that any recipient may verify its integrity and origin offline, without contacting the Processor or any third party, and without holding an account or credential with either;

(b) states, for each data store within scope, a stable identifier for that store, the number of records matching a defined query at a first point in time, and that no records matched the same query at a later point in time;

(c) commits to the query used, such that a different query cannot be substituted after issuance without invalidating the signature;

(d) is recorded in an append-only public log and carries proof of its inclusion in that log, such that the record cannot be withdrawn or altered after the Controller has received it; and

(e) may be checked for revocation by the recipient without the Processor’s cooperation.

2. Obligation. Where this Agreement requires the Processor to delete or return Personal Data, the Processor shall, at the Controller’s request, provide Verifiable Deletion Evidence covering the data stores identified in Schedule [X] within [30] days of completing the deletion.

3. No Personal Data in evidence. Verifiable Deletion Evidence shall not itself contain Personal Data. Where a data subject must be identified, the evidence shall reference a salted hash of the identifier rather than the identifier.

4. Scope of the assertion. Verifiable Deletion Evidence attests to the state of the named data stores at the two times stated, and to nothing further. It does not attest that the query used captured every copy of a data subject’s Personal Data, that data stores not named are unaffected, that backups, replicas or snapshots are affected unless named as data stores in their own right, or that any legal obligation has been discharged. Nothing in this Addendum limits the Processor’s other obligations under this Agreement or under applicable law.

5. No supplier requirement. The Processor may satisfy this Addendum by any means meeting Section 1. Nothing here requires the use of a particular supplier, product or service.

Download as Markdown

What each part is doing

1(a) — “offline… without an account or credential.” The load-bearing sentence. Evidence you can only check by logging into the processor’s dashboard is not evidence; it is the processor’s word with extra steps. Offline verification means the check survives the processor losing interest, going out of business, or disputing the matter later.

1(b) — a count before and zero after, per named store. A single global “we deleted it” hides partial coverage. Per-store figures make an incomplete deletion visible on the face of the document rather than discoverable in litigation.

1(c) — commitment to the query. Without it, a processor can run a narrow query, produce a truthful “zero records” and imply a broad one. Binding the query into the signature lets the Controller compare it against the query they were shown.

1(d) — append-only public log. Stops a record being quietly withdrawn after the fact, and gives both parties a shared timeline neither controls.

1(e) — revocation checkable by the recipient. Evidence whose revocation only the issuer can see is not a durable record. Note the asymmetry: absence of a revocation statement is not proof of validity, and a careful verifier reports unknown rather than valid.

3 — no Personal Data in the evidence. Counsel will ask, correctly, whether “deletion evidence” means the processor mails personal data back. It must not. Hashing the subject identifier keeps the record safe to store, forward and file.

4 — the limits, stated by the requesting party. A clause that overclaims gets negotiated out. This one says exactly what the evidence is worth, which makes it harder to resist and stops the Controller relying on it for something it cannot support.

What it deliberately does not require

Adoptability comes from restraint. The clause does not require:

  • Coverage of backups by default. Backup retention is often contractually or legally mandated. Naming backups in Schedule [X] is available where it makes sense; requiring it universally makes the clause unsignable.
  • Proof of legal compliance. Whether a deletion satisfies GDPR Article 17 is a legal conclusion about the Controller’s obligations. Evidence supports that conclusion; it is not that conclusion.
  • Proof that the deletion was complete. Only that the named stores no longer return records for the defined query. Nobody can prove a negative about systems nobody named.
  • Real-time or continuous attestation. Point-in-time is what is achievable today. Recurring re-verification is reasonable to negotiate for separately.

How the receiving party checks

A record meeting Section 1 is verifiable by arithmetic rather than by trust. The Controller — or their counsel, or their auditor — should be able to:

  1. Verify the signature against a published key obtained independently of the document.
  2. Confirm the record’s inclusion in the public log named in it.
  3. Query revocation status without authenticating.
  4. Read the per-store counts and the committed query, and compare that query against what was represented to them.

Implementations that do this in a browser, offline, exist — including a free one at burnledger.io/verify, which runs entirely in the page and sends nothing anywhere. Any implementation meeting Section 1 will do.

Licence

Dedicated to the public domain under CC0 1.0 Universal. Copy it, change it, sell services around it, ship it in your own template library, remove the notice. No attribution required and none expected — a clause with strings attached does not travel, and travelling is the entire point.