GDPR in a Blockchain World

“What happens after May 25th, 2018 to data on blockchains?”
The context being around Article 17, and the "right to be forgotten".
The answer, of course is some combination of “It’s tricky”, “It depends”, and “It’s complicated”.

For the nonce, I’m going to ignore Personally Identifiable Information (PII) that’s actually placed on public blockchains. If you did that, or are doing that, well, good luck — you’re going to need it.

On the private/permissioned blockchain side, there are a couple of options out there (Note: By “private/permissioned”, I mean that the blockchains are deployed in an internal/controlled environment)

1. 1. Store PII elsewhere: This is the most obvious route, where you store PII in a separate database / storage / whatever, and you effectively do a JOIN on this data whenever you do blockchain stuff.
   The upside is that when you get an Article 17 request, you can nuke the data in this separate store and you’re done.
   The downside is, well
    — your eggs are now in the one PII basket (though you could deal with that by making it redundant, etc.)
    — you’ve lost some of the benefits of decentralization, but hey, that’s the price you have to pay
    — performance can now become a factor, since you have to do the PII lookup/JOIN each time
2. 2. Throw away the key: aka “Crypto-trashing”. Basically, you keep PII on the blockchain in encrypted form. When you receive an Article 17 request, you throw away the encryption key, effectively rendering it inaccessible.
   The upside is that this is fairly straightforward to do, assuming you’ve got a good Key Management System (KMS) in place.
   The downside, however, is
    — encryption is, and always has been, tricky. You really need to make sure that you got your KMS right, no exploitable holes, etc.
    — encrypted data becomes vulnerable over time (encryption schemes get broken, computers get more powerful, keys get leaked, etc. It’s one of the reasons key rotation is so important!). Throwing away the key removes the option of updating your encryption, which means you might end up in even bigger trouble than before!
3. 3. Throw away the data: If the blockchain is private, theoretically, you could rebuild it with the offending data removed.
   The upside is that this, unequivocally, would work.
   The downside is that this would be the mother of all PITA. Imagine having to redo terabytes of hashes every time you got an Article 17 request?
4. 4. Claim an Exception: Article 17 3 (d) has this interesting phrase for when the data is for “archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) in so far as the right referred to in paragraph 1 is likely to render impossible or seriously impair the achievement of the objectives of that processing;”
   Sooo, if your blockchain provides immutability, and if you can plausibly claim that this immutability is necessary for the “public interest, scientific or historical research purposes or statistical purposes” then you might be good to go.
5. 5. Claim an Exception v2: Mind you, if the PII you are storing is mandated by regulations (you’re a bank, this is loan data, you can’t shred the evidence that the loan was made), then hey, you’ve got a reason why you can’t delete the data. OTOH, if you’re storing somebody’s browsing behavior on the blockchain….

The bottom line here is that your best bet is to either Claim an Exception (if you can. And you better be sure that you can. Consult an attorney. Please!), or Store PII elsewhere…