# GDPR Compliance

This guide explains how to assess and achieve GDPR compliance in event-sourced systems. It addresses the challenges of storing personal data in immutable event streams, outlines the implications for the right to erasure and other GDPR provisions, and offers practical recommendations for designing compliant systems.

When the event store does not include built-in features for **anonymization, redaction, or deletion of data**, compliance relies on **architectural discipline** and **design-time decisions** to ensure that systems built on top of it can meet legal and regulatory requirements. Understanding these implications is essential when handling personal or sensitive data in a production context.

## Events Are Immutable

By design, an event store keeps events in an **append-only log**. Once an event has been written, it **cannot be changed or deleted**. This immutability guarantees **consistency, auditability, and replayability** – but it also has implications for privacy regulations like the General Data Protection Regulation (GDPR), which includes rights such as:

- **The right to access stored data**
- **The right to rectification of inaccurate data**
- **The right to restriction of processing**
- **The right to erasure ("right to be forgotten")**

If the event store does not allow updates or deletions, these rights **cannot be fulfilled at the level of the event store itself**. Instead, they must be addressed through **application design, data modeling, and operational processes**.

## Think Before You Write

The most effective way to build GDPR-compliant event-sourced systems is to **avoid storing personal data in events unless strictly necessary**. In many cases, you can store **references (such as user IDs) instead of actual names or contact information**. The referenced data can then reside in a traditional database, where it can be **updated or removed independently**.

Another option is to use **pseudonymization**: replace direct identifiers with pseudonyms or tokens that can only be resolved externally. For example, instead of storing `"email": "alice@example.com"`, store `"userId": "a3f2b1"` and keep the mapping in a separate system.

If personal data must be included in events, make sure to **document which fields contain such data, why it is necessary, and how long it should be retained**. Align this with your organization's data protection policies and risk assessments.

## No Built-In Deletion

If the event store does not support **deletion of individual events or fields**, and 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 of the event store**.
2. **Filter or transform the backup to remove or pseudonymize sensitive information**.
3. **Restore the transformed backup into a clean instance**.

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

> **Try it with EventSourcingDB**
>
> EventSourcingDB has no API for removing data from the event log. How to perform such a migration is described in **[GDPR Compliance](/docs/eventsourcingdb/gdpr-compliance)** in the EventSourcingDB documentation.

## Anonymization and Crypto-Shredding

One possible strategy for eventual erasure is **crypto-shredding**: 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. Crypto-shredding does not need to be part of the event store itself – it can be **implemented at the application level**.

This approach allows the system to maintain its **immutable event history** while rendering personal data inaccessible – a compromise that may be acceptable under certain interpretations of GDPR, especially when combined with **documentation and appropriate legal review**.

## Operational Isolation

When working with personal data, it is also important to **isolate environments (e.g. development, staging, production)** and to **avoid replicating personal data into systems that don't require it**. Always treat event logs as **production-grade data** – even when they are used for debugging or analytics.

If you must share events across systems, ensure that only the **necessary fields are included** and that **downstream consumers are subject to the same privacy constraints**.

## Designing for Compliance

You have **complete control over what gets written** to the event store – and with that comes the responsibility to handle personal data carefully. Compliance with GDPR must be **designed into the system from the start**.

Key recommendations:

- **Minimize personal data in events whenever possible**
- **Use references or pseudonyms instead of direct identifiers**
- **Document which fields contain personal data**
- **Plan for rehydration if deletion becomes legally required**
- **Consider crypto-shredding for post-hoc inaccessibility**
- **Avoid treating the event store as a general-purpose datastore**

Event sourcing and GDPR are not incompatible – but they require **conscious trade-offs and disciplined design**. By understanding the constraints and responsibilities, you can build systems that are both **event-driven and privacy-aware**.