The "Right to be Forgotten" under the General Data Protection Regulation (GDPR) is a legal concept that allows individuals to request that their data be erased from an organization's records if it is no longer necessary for the purpose for which it was collected, or if the individual withdraws their consent. This right applies in certain circumstances and may be balanced against other important interests such as freedom of expression or the public interest in access to information.
To cater to the Right to be forgotten under GDPR, a business must:
Verify the identity of the individual making the request
Assess the validity of the request and whether the right to erasure applies
Delete all personal data held about the individual
Inform any third parties with whom the data has been shared
Keep a record of the request and the steps are taken to comply with it
Businesses need to have processes in place to handle such requests and to ensure that all data is securely deleted. This can be more complicated the more data we store on people.
What is an Event Store?
An event store is a database designed for storing events in an event-driven architecture. In event-driven systems, events are used to represent changes in state or actions taken, and they form a log of all activities in the system. An event store is used to store these events and provide an append-only record of all changes in the system.
The events stored in an event store can be used to recreate the current state of the system, and they can also be used to drive business processes and inform other parts of the system. The events can be used to track the history of a system, and they can also be used for auditing, analytics, and debugging purposes.
As you can imagine, this gives us the following contradiction:
The right to be forgotten means we need to remove personal data upon request
The event store is appended only, and we do not delete things from it.
In effect, the event store, a critical source of truth of event-driven systems, cannot be compatible with GDPR. Or can it?
Workarounds
There are a few workarounds for this, and depending on the scenario and the scale of your operation, some may be more desirable than others.
Redact the Event Store
The idea of an event store is not to be queried by the end user, the reason it exists is so that we can hydrate services with data stored there. After that, services should listen to regular events and act on those. If the name of a person is stored in the event store, even if we were to redact it there, the data would still be in the services. We would have to go into all services and redact them there. This is not a recommended approach. It feels messy because the cat is already out of the bag.
Emit a 'Right to be Forgotten' event
We could also build into our services, a kill switch for the data about a person. When a service receives this event, containing a user ID, it will redact all the data for that user.
Depending on the number of users, and the databases in use, this might not be a desirable mechanism. Furthermore, we may not catch the failure to develop this feature during code reviews. We might forget this feature during development.
Store the Personal Data Encrypted
We can store the data encrypted in the event store and allow that encrypted data to be passed through into services.
Services also store the encrypted version
When a user is created in the system, we also generate a secret key. We store this key away from the user data.
When we want to decode the user data, we use the secret key
When we want to remove access to the data, we delete the secret key, preventing it from being decoded in the future.
Effectively, it does not matter if the data is stored in any services or event stores, since it's encrypted. To remove access, we remove the key used to decrypt it.
Conclusion
We can take care of the right to be forgotten, even when our data is splashed across several services, even with multiple database technologies. Depending on the architecture at hand and how far you want to go, even at scale there is a solution.
To summarise, for this to happen we need:
An event store that supports storing certain fields encrypted
A way to store users' keys against their ID
A way to decrypt user data using the key at the API level
A way to take 'Right to be forgotten' requests that prove identity
A way to delete the user keys upon request
A graceful way to handle the fact that data is redacted in the user interface