Thoughts about the GDPR

I’ve been a bit of an outspoken critic of the GDPR on Twitter, Mastodon, and on the DefSec podcast.  I’m frequently asked to describe my issues with the regulation, and usually leave my view summarized as “it’s just a poorly written regulation”.

Many of my contacts, particularly those in the EU, do not understand the hoopla leading up to the May 25, 2018 enforcement date.  The prevailing view is that the GDPR mandates a few simple things, such as compelling me to:

• explain why I am collecting your personal data
• show you the personal data that I’ve collected about you
• delete your personal data when I no longer need it
• protect the personal data I have about you using things like encryption
• obtain your explicit permission prior to doing anything with your personal data

Those seem like noble goals, and if that’s all the GDPR did, I would not be so critical.  But as with most things in life, the devil is in the details.  The GDPR spans 99 articles and, in total, weighs in at nearly 55,000 words.  Despite the voluminous nature of the regulation, the data protection regulators of the various EU countries formed a Working Party to produce a substantial number of guidance documents on how the GDPR will be implemented an enforced, since the regulation was not specific in these areas.  Also, some individual regulators, such as France’s CNIL, have been releasing still more guidance.

With that as a background, I’ll go into my specific issues with the GDPR:

1. Most of the consternation in the IT world regarding the GDPR relates to Article 32, which defines the requirements for security and integrity of data processing.  Article 32 is intentionally vague in terms of the protections that need to be applied.  This is almost certainly in part to ensure the regulation is technology agnostic and does not become out of date as technology and threats evolve.  No doubt it’s also due to the fact that companies really don’t like to be told how to run their IT, at the level of specific controls and technologies.  There is a major disconnect between the regulation, the realities of running a business who needs to process personal data, and the realities of the threat landscape.  Perfect data security is an illusion, and breaches will happen.  Many organizations are looking down the barrel of a gun that has bullets that will poke 4% holes in their revenue, hoping the one pointed at them isn’t the one that gets fired.  The GDPR does not provide a safe harbor for organizations handling personal data.  By that I mean that the regulation doesn’t enumerate a certain set of controls that, if in place and operating correctly, would reduce or eliminate the threat of the massive potential fines.  So, organizations have to prioritize their security investments and improvements based on their understanding of the threat landscape.  But, we have plenty of objective evidence that demonstrates many organizations can’t do this effectively.  The GDPR does encourage the creation of a certification standard, but that has not come to fruition.  Many organizations seem to be latching on to ISO27001/2 as fulfilling that certification, but I’m here to dispel any notion that an ISO27k certification is, in any way, evidence that the right controls are in place and operating effectively to protect personal data.
2. The GDPR requires notification of a data breach to data protection authorities within 72 hours of detection.  As someone who has been involved in far more than my share of investigations, I’ll say that this is not reasonable in most cases.  At least it is not reasonable without providing a lot of half-baked reports, potentially including false positives.  I fear this requirement is going to drive bad behavior… If I’m not actively looking for a breach, I’m much less likely to find that one is happening or has happened.  The GDPR should encourage proactive detection and appropriate investigations.
3. The GDPR obligates both data controllers (the entity that collects and decides how to process personal data) and data processors (entities engaged by a data controller to perform some processing of personal data) to protect personal data.  This will likely have an adverse effect on IT outsourcing and other IT services because IT suppliers must ensure the data they are entrusted to process is properly protected, regardless of the wishes of their client, the data controller.  This arrangement is inevitably going to lead to significant differences in personal data protection controls between a controller a processor.  Controllers often engage an IT supplier for cost efficiency purposes, meaning that they are unlikely to want to implement a bunch of expensive new controls for something their IT supplier is responsible for performing, while the supplier, being a concentration of regulatory risk across clients, will demand more stringent (and expensive) controls than their client may be willing to tolerate.  I don’t expect that organizations are going to see this as a wake up call to in-source IT, and even if they did, I’m not sure that is good for data subjects in the long run, as IT continues to become more like a utility.  A better model would be to follow the model of nearly every other data protection regulation that exists, where the controller defines the controls required to protect the personal data they process, with penalties for negligence on the part of the supplier, and so on.
4. The regulation is so obtusely worded that the very people responsible for implementing the mandated protections do not generally understand who it does and does not apply to.  For example, many IT professionals (and indeed EU data subjects at large) seem to believe that the GDPR applies to all organizations anywhere in the world that process the personal data of an EU data subject.  This is not true to the best of my understanding: the GDPR applies to organizations that are present in the EU and process personal data of EU data subjects, and also applies to non-EU organizations that are targeting EU citizens.  This seemingly means that my blog, hosted in Dallas, TX, USA, and which does not specifically target EU data subjects, likely does not need to comply with the GDPR.

What did I miss?  Do you disagree with my observations?