GDPR – The Journey of a Thousand Steps – and by the way, move your ass

I’ve been heavily involved with GDPR for more than a year. The clock is ticking, as compliance is expected by May 2018. And guess what? Nobody’s even close.

Okay, so for the noobs, what’s GDPR? The General Data Protection Regulation, or the EU Privacy Laws on steroids. Effectively, it states that EU nationals have the right to govern their own data, wherever it resides. If you’re not an EU company but have data on EU citizens, the EU can make your life difficult if you don’t follow their rules. And if you have EU partners, they’re going to want you to not make their lives difficult. Just like non-US companies often follow PCI and SOX.

So what does GDPR require? First off, basic data protection. Encryption. SoD policies. A breach notification policy.

You may have to appoint (in only certain cases, but just do it anyway) a Data Protection Officer, or DPO, whose primary function is to make sure that anybody processing data on EU folks is compliant. It’s not an ironclad requirement for everybody, but make somebody accountable regardless. It’s a gold practice. If no one person owns compliance, it won’t get done.

Next, you have to let your EU users (or data subjects) decide how their data gets handled. You have to capture their consent to hold and/or process their data. They have the right to review it, rectify it as needed, fill in missing data elements for accuracy, request a copy of it (like in a PDF), and, where appropriate, request that the data be deleted. In fact, if they decide to withdraw their consent, you’re supposed to automatically delete it.

Encryption? That’s relatively easy. There are generic solutions for that, and then very database-vendor-specific ones. For example, the vast bulk of enterprise data is held in Oracle. Encryption’s already built it, you just have to pay for it so they’ll turn it on. Then you drag the necessary tables into the encrypted space. And so on. That’s commodity stuff.

The tough part is three-fold. First, you have to LOCATE the relevant data. Which of your attributes or columns or whatever are GDPR-related? Data is anything personal, including social media data, genetic material, the usual names and numbers and addresses, etc. Data on dependents as well, if you’re tracking people’s children.

Second, you have to consolidate that data into a centralized view or views. Make it available to the data subjects for their review and rectification. That isn’t trivial. How do you centralize handfuls of data elements from multiple directories, databases, and application stores? I’ve worked with companies that have literally hundreds of these legacy repositories.

Then you have to provide some kind of interface, so that data subjects can actually interact with this stuff. Citizens don’t care that you have split their PII over Active Directory, Radiant Logic, SAP, Oracle, etc. They just want to go to one place and see All Their Stuff.

So let’s add one more consideration: automation. Nobody knows how many data subjects are going to storm the ramparts, demanding governance over their information. Since compliance hasn’t kicked in yet, there are no case studies on what to expect. Will ten percent of my users be crazy privacy addicts? Two percent? Thirty? I suppose it depends on the kind of enterprise you are. But even if it’s only 100 people the first week, you’re not going to be able to keep up with the load. “Fix my data, send me my data, delete my data.” It will get ugly quickly if you’re doing all this manually.

Wait, wait, wait. Let’s make this even more complicated. You may have my data, but that doesn’t mean I have login credentials with you. I may have been a one-time customer but I never actually registered. So NOW I have to self-register, AND I have to identity-proof. My name’s John Smith. I’m not that other John Smith, I’m this John Smith. I provide enough data points that you can verify it’s me and allow me to claim which data belongs to me, this John Smith. Yeah, this is fun stuff. I cannot stress how non-trivial this point is, right here.

The right to be forgotten, as they call it, is another weird one. If it’s eligible data, and deletion is requested, it’s supposed to apply even to backups. Good luck with that one. And of course there are plenty of exceptions to that, since you don’t want subjects to create a financial trail and then ask for it to be wiped, maybe to cover up their money-laundering.

Don’t say, “This looks so scary, I don’t know where to start,” and then paralyze yourself with inaction. I’ve already seen it. Hiding won’t make it go away. If you’re not going to be compliant by May, consider these points:

-          You’ll be in good company

-          You’ll need to show at least a best effort

Nobody will be compliant on Day One. But don’t be that guy that is way behind the rest. Show the auditors that you’ve been doing SOMETHING. Demonstrate that you’ve located / classified a portion of your data. You’ve started working on providing data subject access. Choose your data stores, for example, based on size, volume of users, sensitivity of the data, risk, whatever. Prioritize, select the most likely target(s), and start the work. You’ll also learn the lessons that will make the next round easier.

And show that you have a PLAN for the rest of it. Here’s what I’ve done, and here’s what I’m going to do. If you show nothing substantive, you may be one of those unfortunate organizations that the EU makes an example of. And be certain, they will pick people who haven’t put out a minimum of effort and beat them with a stick, to get everybody else moving.

Take the first step. Start the journey. It’s not getting any shorter.