- store the data encrypted using a secondary protocol, lose the key
- rewrite the whole db
If either of these is not feasible then you should have thought longer about what tech is suitable for which application. Operating your company in a legal manner is a pretty strong factor when making such choices.
Is losing the key sufficient to comply with the law? "We didn't actually delete anything but I promise I don't remember how to decrypt it" would be acceptable for the court to not e.g. seize your drives?
It's the same as "we actually deleted the data and I promise we didn't keep any backup copies", except it's probably even easier to enforce, since you already to have to secure the key instead of the whole database.
IANAL
With GDPR right to forget you need to get rid of any identifable subject information. If you can't tell a subject from data then you comply. Encrypted data without a key is just a noise.
You are allowed to keep aggregations and hashes of data. These shouldn't allow to identify a subject. E.g. you can keep list of banned emails as MD5s to verify on sign up etc.
In this situation though, any client who still knows the key can access the data, since there is no way to remove data from the database server, or make it unavailable at the server level.
Assuming the clients and server are operated by different entities (otherwise the immutability and verifiability are not that interesting), if someone comes to the server operator with a court order and ask that data be removed, it seems like there is nothing they can do.
You can’t do much of anything if you’ve already given away the information in question — the same is true if someone copied the data itself.
You have to not give away the key in the first place, at least not to any clients that you don’t own.
E.g. following the rule “any problem can be solved with a level of indirection”, external clients get some Auth key A, which they feed to internal client, who internally maps it to some data key B, and decrypts the data and hands it back to the external client.
When the data is removed, you delete the mapping from your internal client.
> store the data encrypted using a secondary protocol, lose the key
Thing is that you have to do this upfront. I think it's very possible to get into a situation where the data you have to delete is in plaintext. Dropping the whole DB and recreate it from scratch is a bit hefty.
- store the data encrypted using a secondary protocol, lose the key
- rewrite the whole db
If either of these is not feasible then you should have thought longer about what tech is suitable for which application. Operating your company in a legal manner is a pretty strong factor when making such choices.