GDPR and erasure#

An audit log that can be quietly edited is worthless as evidence; a data-protection regime that includes a right to erasure (GDPR Article 17 being the canonical example) sometimes requires content to be destroyed. Sigilbase resolves that collision with one rule, stated here exactly as it is enforced in the product:

No silent deletion exists. Content erasure exists: tenant-initiated only, hash-preserving, itself recorded in the ledger, structurally impossible to hide, and incapable of touching sequence, metadata, hashes, checkpoints, or anchors.

This page explains the three tools in the order you should reach for them. One honesty note before that: Sigilbase produces evidence; it does not make you GDPR-compliant, and nothing on this page is legal advice. What personal data you record, on what lawful basis, and how you answer a data subject are decisions between you and your advisers.

Rule one: record references, not personal data#

The best erasure story is having nothing to erase. Design payloads to carry references and hashes: an event that says actor user:42 acted on patient:9f31 with a content_hash of the document proves what happened without storing who - the personal data stays in your own systems, where it is mutable and erasable. When an erasure request arrives, it falls on your systems; the immutable ledger holds nothing about the subject beyond opaque references you control the meaning of.

This remains the strongly recommended default for every stream. See Sending events for the payload guidance.

Redaction: for personal data that got in by mistake#

Minimisation fails in practice in one specific way: someone pastes real personal data into a payload - a support engineer includes a patient name, an integration ships an email address it should have hashed. Mistakes do not wait for roadmaps, so every plan includes hash-preserving redaction.

A stream owner (only an owner - not admins, not auditors, and never Sigilbase operators, who have no such capability) can destroy the stored payload of specific, named events, one event or a sequence range at a time. What redaction does, exactly:

• Destroys: the stored payload content in the live system, and any stored evidence exports that contained it, recording the removal in your ledger. Database backups taken before the redaction still contain it until they expire: up to 35 days in-region and up to 365 days for the offsite copy. Our restore procedure reapplies every erasure before a restored system serves requests. Bundles you have already downloaded are your own copies.
• Preserves: the event's sequence, actor, action, resource, timestamps, its payload hash, its entry hash, every chain link, its checkpoint membership, and any anchor tokens. The chain verifies identically afterwards because entry hashes commit to the payload hash, not the payload bytes.
• Declares: the act itself appends a payload.redacted event - actor, the sequences destroyed, your stated reason - to the same ledger. The erasure lives in the audit trail it edited.

A redacted event renders as a tombstone ("payload redacted {date} · hash preserved") everywhere the event appears: your stream browser, the auditor portal, API reads, and evidence bundles. The preserved payload hash keeps evidential value - if a purported copy of the destroyed content ever resurfaces, anyone can hash it and check the claim against the ledger.

Evidence bundles (format 1.2) carry a redactions.json manifest declaring every redacted event in the exported range, and the standalone verifier fails any bundle where a payload is absent without a declaration. Absence is declared, never implied - which is precisely what makes a redacted log stronger evidence than a silently "clean" one. Evidence bundles has the format detail; the auditor guide explains what your auditor sees.

Redaction is a ceremony, not an API: it requires the owner role, a stated reason (recorded in the ledger), and a typed confirmation, in the UI only. It works on paused and archived streams - erasure obligations do not expire with a stream's status.

Organisations that want four-eyes control can require it: with the dual-control setting on (tenant settings, owner-only, needs at least two owners), every redaction, subject erasure and signer identity erasure queues for approval by a different owner before anything is destroyed. The request, its approval or withdrawal, and the destruction's declaration - naming both owners - are all recorded in the ledger; unapproved requests lapse after 72 hours.

The PII vault: for personal data you must record#

Some workloads genuinely need personal data in payloads - a clinical audit trail, say, where the record is about the person. For those, Business and Enterprise plans include the PII vault: flag an event with pii: true at ingestion and its payload is envelope-encrypted at rest under a per-event data key before storage, while hashing runs over the plaintext exactly as normal - nothing about the chain, checkpoints, proofs, or the verifier changes. A stream whose payloads are personal throughout can be set to vault by default on the Streams page: events arriving without the flag are then vaulted as if they had sent it, an explicit pii value always wins, and events already stored are unchanged.

Optionally tag flagged events with a subject reference ("subject": "patient:9f31"). Erasing that subject is then one operation: destroy the subject's data keys. The live system can no longer decrypt the content, and any stored evidence exports that contained it are removed, with the removal recorded in your ledger. Backups taken before the erasure hold the key material until they expire, on the same schedule as redaction above, and our restore procedure reapplies every erasure before a restored system serves requests. Bundles you have already downloaded are your own copies. Every hash survives, and the act appends a pii.subject_erased event naming the subject reference, the event count, and your reason. Erased events carry the same tombstone semantics as redaction ("content erased {date} · hashes preserved"): one concept for the verifier, bundles, and UI.

Day to day the vault is invisible: your team reads flagged events normally (decryption is automatic for tenant users), exports decrypt flagged payloads at export time (they are your evidence), and Sigilbase operators can read none of it - the operator boundary is unchanged by encryption, before and after. Nightly verification additionally checks each stored ciphertext's authenticated-encryption integrity.

The vault is proactive machinery for data you know is personal in advance. Redaction - the lawful-erasure necessity - is available on every plan regardless.

Signers, recipients and generated documents#

Signature requests and attestation campaigns record people by name and email, so this section states exactly what erasure reaches there and what it does not.

The events. Every signing and attestation event acts under an opaque, stable actor (signer:<id> or recipient:<id>); the name and email travel only in the payload. Redaction therefore removes the identity from a named event completely: API reads, exports and evidence bundles show the opaque actor and a tombstone where the payload was. Events recorded before 7 September 2026 named the signer's or recipient's email in the actor field itself. The actor is an input to the entry hash and is preserved by redaction by design, so that email cannot be removed from those events by anyone; their payloads can still be redacted.

The working rows. Beside the ledger, Sigilbase keeps a row per signer and per recipient (name, email, the typed name, a stored image of the drawn signature mark, the personal link) so dashboards, certificates and countersigned copies can render without reading the ledger. Signer identity erasure is an owner-only, declared operation over those rows, run from the Streams page through the same ceremony as subject erasure: a stated reason, a typed confirmation of the email address, and, when the dual-control setting is on, a different owner's approval before anything is scrubbed. For one email address across the workspace, name, email and typed name become markers, the mark image is deleted from storage, the personal link and any email-confirmation code die, and the act is recorded as signer.identity_erased in the workspace's system stream, naming the row references and the reason, never the email. What stays on the row: the time of the act, the hash of the mark, the hash of the version viewed and signed, and the intent statement, which are the facts the ledger already states.

Generated documents. A document generated from a template keeps its rendered text (and, if you opted in, the values you entered) beside the published PDF, so a countersigned copy can reproduce the full text. An owner can clear that text and those values from the document's page (Clear rendered text, beside the version in its history), with a stated reason and a typed confirmation of the version number; the act is recorded as document.draft_text_cleared. Dual control does not apply here, because nothing in the ledger is destroyed: the published PDF, its sha256, and the hashes proving which template and inputs produced it are unchanged, and a countersigned copy generated afterwards identifies the original by hash instead of reproducing it.

What none of this removes. A countersigned copy or a certificate already rendered is a published, hashed artefact of record and is never altered or deleted: the names on it are the signature record as it was made, and keeping that record is the reason a signature was collected. Whether your lawful basis for retaining it outlasts an erasure request is a question for you and your advisers, not for the tooling. Evidence bundles exported after an identity erasure carry the marker in place of the identity in signatures.json.

Which tool, when#

What this never does#

There is no retention-based expiry (retention is forever on every plan; erasure is always a deliberate, recorded act), no platform-initiated erasure of any kind, no bulk cross-stream tooling, and no way - for anyone - to remove an event, a sequence number, a hash, or the record that an erasure happened.