I’m exploring how to ensure GDPR compliance in an event-sourced system built with Axon Framework, particularly regarding the “right to be forgotten.” I came across a thread where it’s mentioned a Axon GDPR module that uses crypto-shredding (encrypting personal data in events and deleting keys when needed). I have few specific questions about applying this module - or similar solutions:
Compatibility with Axon Framework without Axon Server
Can the Axon GDPR module (or its modern equivalent) be used in projects that rely solely on Axon Framework, without Axon Server? For example, if we’re using a custom event store (e.g., JPA or JDBC), are there any dependencies or limitations to consider? I suppose not but still want to confirm it.
Production System with Existing Data
If our project is already in production with an event store containing unencrypted historical data, how can we apply the GDPR module (or a GDPR-compliant approach)? Specifically:
How do we handle existing events - do we need to replay and encrypt them, or is there a way to integrate the module without disrupting the current event log?
Crypto-Shredding and Other GDPR-Compatible Options
Is the crypto-shredding approach (encrypting personal data and deleting the key) still considered compatible with GDPR’s? Additionally, are there other viable options to implement a GDPR-compliant solution in an event-sourced system in Axon?
I’d appreciate insights from anyone who’s implemented this, especially with recent Axon Framework versions or from Axon developer themselfs .
I assume you will find there the answer to questions 1 and 2. Regarding question 3, the answer is that it depends. Most security specialists consider it to be sufficient to comply. Any more questions? Just let me know.
I second Henk’s reply, @D3ska! Regardless, I’ll give a more extensive two cents as well:
1. Compatibility with Axon Framework without Axon Server
You can use the Axon Data Protection module without Axon Server if you want to.
2. Production System with Existing Data
Next, retroactively encrypting is an option, but would require downtime, as you are either (1) updating the domain_event_entry table or (2) making an encrypted variant of your domain_event_entry table. If you want to, you can also have a mix of encrypted and non-encrypted events. Key in this setup, is that your Serializer knows how to switch between encrypted and non-encrypted events (typically by trying and failing, or by having some built in (event-age-based) switch).
3. Crypto-Shredding and Other GDPR-Compatible Options
This is very much a country-specific question. I know that in for example Germany, crypto shredding is insufficient. However, AxonIQ has several users for the Data Protection Module spread over the globe that are perfectly fine with the crypto shredding solution.
Hence, it is tough for me, or anybody, to state whether it suffices for your use case. That’s really up to the business you’re working for I think.
.