(And That’s OK)
The penalties for GDPR violations can be ruinous. But do organizations need to worry? Terry Ray suggests that while compliance is necessary, most companies can rest easy.
May 25 has come and gone. The European Union’s General Data Protection Regulation (GDPR) has gone into effect. The first GDPR lawsuits have already been filed. And the world still turns.
GDPR promises to be the furthest-reaching and most complex data-protection regulatory scheme the world has known, for the following reasons:
- GDPR puts supremely strict security and privacy requirements on organizations that touch personal data — whether or not third-party data processors are used.
- GDPR allows for violations to carry extremely high maximum fines — in some cases, up to the higher of €20 million or 4 percent of the violator’s annual revenue.
- Where personal data of people in the EU is concerned, GDPR essentially represents the de facto global law, spreading EU data-paranoid sensibilities nearly worldwide.
Meanwhile, in a world where headline-splashing mega-breaches occur regularly, many C-suiters and IT administrators are worried that their organizations aren’t up to par for GDPR compliance.
The bad news is that they’re probably right. For my part, I predict that nine out of every 10 enterprise organizations will fail parts of their initial GDPR audit — and that many will continue to fail their follow-up audits.
The good news is also that they’re probably right. With so much of the world unable to keep up with the strictest interpretations of GDPR (on May 25, many U.S. websites responded to GDPR by simply blocking EU visitors), practicalities will dictate how EU member-state Data Protection Authorities (DPAs) proceed. Absent a data breach or other such data incident, it is supremely unlikely that DPAs will be coming down with the full fury of their authority and fining power on those who are merely lackluster in their GDPR compliance. While minor, unbreached offenders will undoubtedly face warning letters and/or smaller fines, it’s a fair bet that DPAs (like all regulatory agencies) will be focused on chasing after the biggest, the most negligent, the unluckiest and the most politically unpopular of offenders.
To wit, as the old joke goes, “I don’t have to outrun the bear; I just have to outrun you.” In the first few years of GDPR, it’s a fair bet that most organizations won’t feel any meaningful sting for compliance problems unless they (a) repeatedly get flagged for the same violations, (b) demonstrate negligent behavior or (c) suffer a breach. This is because regulators are kind of like hackers: they go after low-hanging fruit first.
For instance, GDPR dictates some very basic data hygiene — that target organizations know what GDPR-relevant data they have where, classify it and monitor and protect it. But these “basics” of data hygiene are frequently found wanting in large and midsize enterprises. If Corporation X knows for certain that it keeps and maintains access to GDPR-relevant data in, say, 10 percent of its servers, the fact that it knows this and has it documented may already put it well ahead of the curve compliance-wise.
Eventually, however, an outside auditor is going to come in and say, “Look, I understand that in these 10 percent of your servers you have GDPR-relevant data — but you need to show me that you don’t have GDPR-relevant data in the remaining 90 percent of your servers.”
General Data Protection Means Specific Summary Data
When it comes to a secure development lifecycle (SDLC), sensitive data has a way of getting into places it shouldn’t. IT administrators often spend a lot of time focusing on what they know without worrying nearly enough about what they don’t know. Far too many major data breaches have occurred by attackers hitting places where the given organizations did not know that they had sensitive data — and, consequently, did not employ appropriate data protection, data obfuscation or other such breach-mitigation techniques.
And simply handing over to an auditor 75,000 pages of queries against a database isn’t going to cut it. No human being — or auditor, for that matter — can consume that. They need more specific, more detailed, more targeted summary data indicating who touched which file servers or which databases when — and more importantly, exactly what was accessed.
This will be the major cybersecurity learning curve from GDPR. There are enough worst-case compliance scenarios out there presently (no data protection, no data obfuscation, production data everywhere) such that it shouldn’t be too hard to avoid being on the DPAs’ most-wanted lists in, say, years one through three of GDPR. And still, best practice and perfect compliance when it comes to data protection and data hygiene will be lacking.
GDPR: General Data Protection Red Herring
This is why, in a way, GDPR almost doesn’t matter.
Enterprises on the hunt for data-protection solutions like to ask vendors if those vendors (and their customers) are compliant with this or that regulation. The question is fair, but I like to tell those organizations that it doesn’t matter what the particular regulation is and whether or not I have customers who meet it.
The reason is that these regulations — all of them — are sufficiently similar. The most fundamental aspect of every single data regulation out there is this:
You need to know who is accessing what particularized information when, where and how (and how much).
Sure, there are different flavors of data and regulations, with different reporting and tracking requirements, but either a vendor can help you with that one fundamental or they can’t. It’s like ice cream: It comes in different flavors and with different toppings, but it’s still just ice cream. It’s great — but if you don’t store it correctly, it melts into a sloppy mess.
The primary quirk about GDPR — the one that has organizations panicking — is that it involves such a breadth of data that can feasibly touch many departments, regardless of industry or vertical. We are talking about customer data that can be found anywhere and possibly everywhere.
This creates two conundrums for the would-be GDPR-compliant enterprise:
1) How do we audit all of our data and the access to it? Is it even feasible?
2) If it’s not feasible to audit all of our data and access to it as it is, how do we consolidate our data so that it is auditable?
Often, the only way to a solution to these questions is via an in-depth process of identifying (a) who needs what GDPR-relevant data and (b) how to centralize this data accordingly.
But that’s what enterprises should be doing in the first place.
As it is, most organizations lack anything resembling good data-protection hygiene. A recently released study by the Ponemon Institute revealed that 76 percent of surveyed organizations globally lack a formal and consistently applied cybersecurity incident-response plan. Meanwhile, enterprises still have problems identifying, finding and protecting private data.
Consider PCI-DSS, for instance — a fairly straightforward data-protection standard that is highly particularized and narrow about the kind of data it protects. The TJX data breach of 2005 to 2006 — at the time the largest data breach in history — occurred in the wake of TJX being cited repeatedly for noncompliance with PCI-DSS. The fallout from that breach was exacerbated by the CIO’s wishful thinking as to what PCI-DSS compliance meant. And to this day, organizations still fail their PCI-DSS audits — even though PCI-DSS was established more than 13 years ago.
In the case of GDPR, by far the broadest and most complex data regulation to date, how can we expect anything other than the repetition of history?
Don’t get me wrong, GDPR will hardly go unenforced. However, in my opinion, organizations should be able to weather the GDPR storm for a couple of years so long as they (1) generally try to do a genuinely good job on GDPR compliance, (2) begin their journey of appropriately tracking and classifying all of their data and (3) monitor all access to personal data such that auditor questions can be answered and incident response information is readily available in case of a breach — all of this so that they can stand up to enhanced regulatory scrutiny in the long run.