# 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**.

This process involves the following steps:

1. **Create a backup using the API** – see **[Backup and Restore](/docs/eventsourcingdb/v1.1/backup-and-restore)**.
2. **Filter or transform the backup to remove or pseudonymize sensitive information**.
3. **Restore the transformed backup into a clean instance of EventSourcingDB** – see **[Migrating Between Instances](/docs/eventsourcingdb/v1.1/migrating-between-instances)**.

This strategy is known as **rehydration or migration-based redaction**. While it is technically feasible, it requires **careful planning, validation, and operational discipline**. It is not a substitute for **data minimization or privacy-aware modeling**.

## 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.