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. It is gone; there is no undo and no recovery, by you or by Sigilbase.
• 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 and subject 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 ciphertext becomes permanently undecipherable — cryptographic shredding — 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.

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.