Store the data encrypted, then delete the keys when requested.

This isn't really deleting it though. What happens if in the future technology changes and current cryptography is moot?

Then fire up a new database with the latest customer data every 18 months. And completely delete the old database once you confirm it no longer has value.

I thought the point of this is to have an exhaustive record for audit purposes.

Or just store the customer database in /tmp and reboot the server every 18 months. /s

currently it's logical deletion and time-based expiration. Actual values associated to expired entries are not fetched. Physical deletion is already in the roadmap.

My preferred method is to tokenize sensitive data before storing in the immutable logs/database.

Pruning is on the roadmap.

How is it immutable if you can prune it?

several solutions may be possible. Simplest would be to delete payloads associated to entries. While the actual data won't be there, it will still be possible to build cryptographic proofs. Then it's possible to prune by physical deleting entire transaction data, which may or not affect proof generation. However, tampering will still be subject to detection.

Are records atomically immutable or is there a set concept such that the lack of mutation can be verified over a set of records?

every change is made by appending a new transaction. immutability is intrinsic to transaction processing, it can not be disabled. Once a transaction (it may include several entries) is committed, the database state change accordingly and no change into already committed transaction may be done without clients being able to notice it. Note for this to be ensured, clients of immudb should keep track of the latest verified state. official sdks handle this for end-applications

You clone the database and remove/update the corresponding lines. GDPR does not mean, you have to fix it right away, imho.

But you have to do in a pretty short timeframe

> Under Article 12.3 of the GDPR, you have 30 days to provide information on the action your organization will decide to take on a legitimate erasure request. This timeframe can be extended up to 60 days depending on the complexity of the request.

even if they ask for more time, first communication has to come within 30 days

So, no deadline for the actual deletion? Your 'first communication' could say "your data will be deleted at some point between now and ten years from now" and be compliant?

No, it says: 30 days, maximum 60, if you need 60 you have to communicate it within the first 30 with a motivation.

It looks pretty straightforward English to me.

GDPR is published in 24 languages, including English, I don't know why people still don't get it and what's so hard to understand.

It's not a single law, it's a collection of articles, the 17th says that data should be erased without undue delay.

We don't have common law in Europe, EU is mostly civil law (emphasis on civil) or Romano-Germanic law. The only exception is Scandinavian law, which is very similar to (and a subgroup of) civil law anyway.

Article 17 does include the term "without undue delay"[0], but such vague language seems ripe for some court precedent.

A clone and remove/update per GDPR request seems like undue delay, certainly one that could be avoided by alternative architecture choices (keep the personally identifiable information (PII) in a mutable store)

[0]: https://gdpr-info.eu/art-17-gdpr/

No, it's not undue delay. That's just how it currently works and that is a fine argument.