# GDPR Compliance

This guide explains what EventSourcingDB offers – and does not offer – for GDPR compliance, and how to remove personal data from the event log if this becomes legally required. For the principles of designing privacy-aware event-sourced systems, see **[GDPR Compliance](/concepts/gdpr-compliance)** in Concepts.

EventSourcingDB does not include any built-in features for **anonymization, redaction, or deletion of data**. Instead, it relies on **architectural discipline** and **design-time decisions** to ensure that systems built on top of it can meet legal and regulatory requirements.

## Events Are Immutable

By design, EventSourcingDB stores events in an **append-only log**. Once an event has been written, it **cannot be changed or deleted**. Since EventSourcingDB does not allow updates or deletions, rights such as the **right to rectification** or the **right to erasure** **cannot be fulfilled at the level of the database itself**. Instead, they must be addressed through **application design, data modeling, and operational processes**.

## No Built-In Deletion

EventSourcingDB does not support **deletion of individual events or fields**. There is no API for **removing data from the event log**. If you need to eliminate certain events or anonymize their content, the only option is to **perform a controlled migration to a new instance**.

*(Removed in 1.3)* This process involves the following steps:

1. **Create a backup using the API** – see **[Backup and Restore](/docs/eventsourcingdb/v1.2/backup-and-restore)**.
2. **Filter or transform the backup to remove or pseudonymize sensitive information**.
3. **Rebuild the chain of the backup** from the first event you changed or removed on, since a restore checks every event against its hash and the one before it, and refuses a backup at the first event that does not fit: number the events again from `0` without gaps, compute the hash of every event again, and set the predecessor hash of every event to the hash of the one before it. Work on a full backup, and keep the time of every event as it is.
4. **Restore the transformed backup into a clean instance of EventSourcingDB** – see **[Migrating Between Instances](/docs/eventsourcingdb/v1.2/migrating-between-instances)**.

*(Added in 1.1; Changed in 1.3)* How to compute the hash of an event is described in **[Verifying Event Signatures](/docs/eventsourcingdb/v1.2/verifying-event-signatures#verifying-events)**.

This strategy is known as **rehydration or migration-based redaction**. It is technically feasible, but **a last resort**: rebuilding the chain **changes the IDs and hashes** of the events from the first change on, so read models, the positions of observers, and anything else that stored them have to be rebuilt as well. It is not a substitute for **data minimization or privacy-aware modeling**, such as **crypto-shredding**, described next.

## Crypto-Shredding

Crypto-shredding is not part of EventSourcingDB itself, but it can be **implemented at the application level**: encrypt sensitive fields using a **per-user encryption key**, and **destroy the key** when the user requests deletion. This renders the encrypted data unreadable without physically deleting it.