Design, deliver, and run enterprise blockchain workloads quickly and easily.
All servers and systems
You wouldn’t enjoy paying a fine of 4 percent of your company’s total revenue. But that’s the potential penalty if your company is found in violation of the European Union’s new General Data Protection Regulation (GDPR), which goes into effect May 25, 2018. As you’ve probably read, organizations anywhere in the world are subject to GDPR if they have customers in the EU and are storing any of their personal data.
GDPR compliance is a complex topic. It’s too much for one article—heck, books are being written about it, seminars abound, and GDPR consultants are on every street corner.
One challenge is that GDPR is a regulation, not a how-to guide. It’s big on explaining penalties for failing to detect and report a data breach in a sufficiently timely manner. It’s not big on telling you how to detect that breach.
Rather than tell you what to do, let’s see what could go wrong with your GDPR plans—to help you avoid that 4 percent penalty.
First, the ground rules: GDPR’s overall goal is to protect citizens' privacy, and in particular, anything that can be used to directly or indirectly identify a person. Such data can be anything: a name, a photo, an email address, bank details, social network posts, medical information, or even a computer IP address. To that end, data breaches that may pose a risk to individuals must be disclosed to the authorities within 72 hours and to the affected individuals soon thereafter.
As part of the regulations, individuals must have the ability to see what data you have about them, correct that data if appropriate, or have that data deleted, again if appropriate. (If someone owes you money, they can’t ask you to delete that record.)
Enough preamble. Let’s get into the problems.
There’s no specific wording required by GDPR, but the policies must meet the overall objectives on GDPR, as well as the requirements in any other jurisdictions in which you operate (such as the United States).
What would Alan do? Look at policies from big multinationals that do business in Europe and copy what they do, working with your legal team. You’ve got to get it right.
For example, let’s say you store information about German customers in Frankfurt. Great. But if that data is backed up to a server in Toronto, maybe not great.
Let’s take that customer data in Frankfurt. Perhaps you have a third-party provider in San Francisco that does data analytics for you, or that runs credit reports or handles image resizing. In those processes, does your customer data ever leave the EU? Even if it stays within the EU, is it protected in ways that are compliant with GDPR and other regulations? It’s your responsibility to make sure: While you might sue a supplier for a breach, that won’t cancel out your own primary responsibility to protect your customers’ privacy.
A place to start with compliance: Do you have an accurate, up-to-date listing of all third-party providers that ever touch your data? You can’t verify compliance if you don’t know where your data is.
Cloud computing of all sorts represents a challenge for GDPR compliance, especially for companies that operate both inside and outside the EU. Can you use a cloud-based CRM system to store all your customer data? What about virtual machines you’ve created and provisioned in the cloud—do you know where they are? Do you need parallel systems, one in the EU and one outside?
That’s where consultants become necessary, because the issues are probably too complex for most companies to resolve by reading the language of the regulation and making an educated guess. Remember that 4 percent thing. The cloud isn’t bad, but when it comes to GDPR, make sure your cloud services are compliant with your requirements.
One of your databases says a customer lives in the Spanish city of Seville. But another says the customer lives in Triana. Which is the most accurate? There are also several spellings of the customer’s name, one with accent marks, two without. Wait, there are several telephone numbers. Is one a landline and one a mobile? Or is one number out of date?
It’s hard to allow customers to verify their data if you’re not even sure what that data is. If you don’t have solid, unified customer records, get cracking. Yes, I know that’s really, really hard for a big company with lots of divisions, some of which may have come through acquisitions or mergers. Too bad. That’s a problem you need to solve.
Under GDPR, customers have a right to see the data you’ve collected about them. Which data do you have to show? GDPR is vague on that. The regulation is also vague on how to present that data. In terms of compliance, you should ensure that you’re doing at least the bare minimum.
My recommendation? Do only the bare minimum, for now at least.
This is even trickier. Which data do you have to let the customers change? Must you let them change their name, for example, if that’s what you used to issue them credit? Yes, you have to let them delete bank account information, such as that used for direct debits—but what happens if they go to make another purchase? What about information that says a customer frequently purchases items and then returns them or claims the products never arrived?
These are tricky issues not spelled out in GDPR. You’ll have to find your own best solution. But it’s a good idea to consider those questions immediately, because they apply to your own customers’ regulatory rights under GDPR. In other words, don’t put this discussion off until you get zapped by a regulator. (Failing to provide customers with this information won’t trigger the maximum 4 percent fine, but it might cause other penalties.)
How do you know that the person asking to review the personal information you have about Crêpes Suzette, a former customer, is actually Crêpes Suzette? That can be tricky, especially if Mme. Suzette no longer has access to the same email address or mobile phone number.
Guess what? That’s your problem to solve. Now there’s no reason that such a solution must be online: Perhaps in those rare situations, you need to ask Mme. Suzette to phone you, and then you can find another way to validate her identity. Whether you use a web form or email or ask for a phone call or even an in-person visit to the nearest brick-and-mortar office, you have to address the problem in a way that’s compatible with GDPR. It’s critical to think about such what-if boundary cases as you plan your GDPR policies, procedures, and technologies.
You’ve gone to the significant effort to rationalize and fix your customer data, and you set up a handy portal for customers to query their data online. Great!
But then someone finds a SQL Injection flaw and sucks down data on 10,000 customers in the Netherlands and Ireland. Now you’re in the newspaper, your share price has tanked, you are staring at a 4 percent penalty…and your job is on the line. Not good. While it’s important to provide a customer portal, make sure it’s well-designed, safe, and secure. (Hint: Do lots of penetration testing.)
With a 72-hour window, you need to find out about breaches. You have three days to not only detect but disclose a breach to regulators.
Too many companies take weeks or months. Forget that. That means upping your game on not only security tools but access control procedures, encryption, software testing—you name it. If there’s one long-term good that’s coming out of GDPR, it’s that it is forcing companies all over the world to get serious about security in general, and data security in particular.
Fixing privacy policies, data storage, and all sorts of security will cost a lot of money in the short term. However, it’s necessary. You know that, I know that…and the EU knows that, too.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.