Erasure & retention
05 · Erasure & retention
Two obligations sit in genuine tension here: GDPR Art. 17 gives a data subject a right to erasure, and German tax law (§147 AO — the GoBD framework) can obligate a business to retain certain records unaltered for years. This page explains exactly how each is handled, and is deliberately precise about the limits of both.
How erasure works
An anchored Merkle proof is, by construction, a commitment to specific bytes — so "deleting" a record without breaking every other proof in its batch requires deleting only the thing that lets someone reconstruct those bytes, while leaving the commitment itself untouched. Concretely, erasing an event:
- sets its stored
canonicalpayload tonull, - sets its stored
salttonull, - leaves its
leafhash, and every proof and root built from it, exactly as they were.
The Merkle tree and the anchored root don't change — they can't, and don't need to; the leaf hash was always just a hash, revealing nothing on its own. Every other event in the same batch still verifies normally. The erased record's receipt still proves that something was anchored at that position; it no longer reveals, or lets anyone recompute, what.
Why the salt has to go too, not just the payload
Audit events are low-entropy structured JSON — the schema is public (it's on the verification algorithm page), field names are known, and the part that varies is often one guessable value. Deleting the payload but leaving an unsalted hash would still let someone enumerate plausible events — "was it Bob deleting record 4470? 4471? 4472?" — and check each guess against the public leaf until one matches. That's a working dictionary attack against data you supposedly erased. A random 32-byte salt in the preimage defeats it: without the salt, brute-forcing the leaf back to a payload is infeasible even though the payload itself was guessable. Destroying the salt is the step that actually achieves erasure; destroying the payload alone would not.
Erasing an already-erased record is a no-op, not an error — exercising the same right twice shouldn't produce a failure. There is currently no self-serve erasure endpoint in the public API — see the API reference, which lists only the two routes that exist. Erasure requests are handled on request today; contact us to initiate one.
retention_class
Every event carries a retention classification, set by you at ingest time
(it defaults to ordinary if omitted):
| value | meaning |
|---|---|
ordinary | No statutory retention floor. Erasable on request, subject to the mechanism above. |
gobd-relevant | A Buchungsbeleg or similar record falling under §147 AO. Erasure is refused for these until the statutory retention period lapses. |
We do not infer this classification. You are the data controller; we are the processor. Guessing which of your records are tax-relevant would be us making your compliance determination on your behalf, and getting it wrong in either direction has real consequences — wrongly erasing a record you were legally required to keep, or wrongly refusing to erase one you weren't. You classify; we enforce what you declared.
Why GoBD retention can override a GDPR erasure request
GDPR Art. 17(3)(b) exempts erasure specifically where a legal obligation requires
continued retention. §147 AO is such an obligation for records classified
gobd-relevant — so for those, and only those, an erasure request is refused
until the retention period lapses rather than honoured immediately. This is not a loophole
Backrun invented; it's the GDPR text's own carve-out, applied narrowly to the specific
category of record it was written for.
For everything classified ordinary — the default, and the overwhelming
majority of events most customers log — this exemption does not apply, and
erasure proceeds as described above with no override.
What "GoBD" honestly means here — read this before quoting it to an auditor
Backrun helps you demonstrate Unveränderbarkeit (immutability) for the specific records you anchor — that a given record hasn't been altered since a provable point in time. That is one requirement among several GoBD actually imposes, and Backrun does not provide the others: a Verfahrensdokumentation (procedural documentation describing your whole record-keeping process), correctly applied retention periods across your full record set, or Z1/Z2/Z3 data export for a tax audit. We do not make you, or anyone, "GoBD-compliant." Anyone on your team telling a customer or auditor otherwise is overclaiming what this product does — say "helps demonstrate immutability of anchored records," not "GoBD-compliant," every time.
What survives an erasure request, and what a customer's own systems still know
On our side, after erasure of an ordinary record:
- Gone: the event payload, the salt, and therefore any way to recompute the leaf from a guessed payload.
- Kept: the leaf hash itself (an opaque 32 bytes, revealing nothing), every Merkle proof built from it, the anchored root, and the on-chain transaction — none of which can be un-anchored, and none of which need to be for erasure to be meaningful.
This is erasure to the extent technically possible on our side — not anonymisation, and the distinction matters. Your own systems — the application that generated the event, your logs, your database, your support tickets — almost always still hold the correlating knowledge ("user X was the actor in event Y"), and GDPR's identifiability test considers any party reasonably likely to have access, not just us. Erasing our copy does not erase yours; you remain responsible for erasure across your own systems the same way you would be without Backrun in the picture at all.