There’s a lot of confusing rhetoric around GDPR (General Data Protection Regulation). I’d like to help clear up some of it. I’m not a GDPR expert; however, I am a CISO with pretty deep experience in the implementation of risk management and information security programs. I lead my own organization’s GDPR readiness activities, and I’ve studied, and passed, the C-GDPR-P Data Protection Officer/DPO certification.
A part of my job is to engage with security executives at a peer level: roundtables, focus groups, you get the picture. Despite my attempts to drive conversation down the path of cloud security, malware analysis, and microperimeterization, it seems that GDPR is the hottest subject at the moment.
The biggest misconception about GDPR is whether you can control data under the regulation – and whether you should. First off, you can’t control everything – in fact, as I’ve been telling security leaders recently, I estimate that 80% of GDPR-related data isn’t even under the control of CISOs. Take the example of the CISO for a retailer with hundreds of stores. You don’t have unilateral control as to where the data is, which departments have it, and for what reason they collected it. So how can you possibly take on the role of pseudo-data owner?
To look at this another way, it’s helpful to roll back the calendar by a few decades. Think about accountancy and marketing firms before we all had MacBooks. If GDPR came about when we were all using paper and filing cabinets for accounting, would you have asked the guys in the IT department to help you classify information, or perform a data flow analysis? You wouldn’t – because that wasn’t IT’s job.
Why then have so many companies decided that all data and processes need to be managed by IT? Of course, critical business processes are digital – certainly the overwhelming majority are. But just because data resides in a digital form, on a server with flashing lights, doesn't mean that the designer or operator of said system understands the data that is stored or processed on it.
GDPR is about empowering data subjects and putting them in control of how and where a company uses their information. It’s about ensuring that controllers (and processors) carry out data processing in a transparent fashion. It’s about making sure that information is not left lying around in servers ad infinitum just because it’s no longer of immediate use to the company storing it. While the security function can help with the “how” of data protection, we are often very little use in ascertaining the “why” of data collection.
I must write the following sentence 200 times a year: “The security function is there to apply controls commensurate with the classification of information, not to define it!” Don’t get me wrong: The CISO and her team are integral to information privacy. If we want to talk about “ownership” of GDPR, I'd say that CISOs “own” principle 6 of GDPR accountability across business functions, which says that data should be “processed in an appropriate manner to retain security.” Teams need to define if information is being processed lawfully, if we know why we collected it, we’re sure it is needed in an ongoing capacity, we have a process for updating the data, AND we only retain it for as long as necessary. After this has been determined, it’s fair to discuss with the CISO how to protect the information.
Risk management is a key consideration for the CISO and something I write about extensively (check out this four-part series on delivering meaningful metrics to boards). The company information risk management framework needs to be flexible enough to measure not only the impacts to and likelihood of confidentiality, integrity and availability, but also privacy and personal data. The DPO and CISO need to work together – assuming they’re not the same person.
Another important concept to keep in mind: GDPR isn’t a magic, be-all and end-all tool for solving compliance. It’s a regulation associated with data, ensuring that information that the organization collects and stores is for legitimate purposes, and that it is deleted when it is no longer needed. GDPR is not prescriptive in the way that PCI DSS is. For example, PCI DSS Requirement 5 talks about having and using anti-virus. There’s nothing that prescriptive in GDPR – just some nebulous terms about using state-of-the-art security.
Information privacy and security compliance surely requires a control framework for measurement, right? Let's look at compliance with PCI DSS, which is (relatively) easy. PCI DSS is a series of clearly laid-out control objectives, most of which are infosec-related. The security design/crypto team ensures that payment card data is encrypted appropriately, while the security assurance team schedules the pen test and works to remediate findings. Once they’re comfortable, they call in the Qualified Security Assessor (QSA). Compliance is given as a percentage.
Now, let's apply a GDPR lens to the compliance example above. My issue with this premise is that QSAs will not exist for GDPR. This is not a security issue to solve. Granted, a QSA's assessment that you're “PCI DSS compliant” should not be taken as a rubber-stamp that you're breach-proof (just ask Target). But at least we have a line in the sand. With GDPR, the first time you know how robust your controls are will be at the time of a breach. Isn’t that a little like taking your driving test once you've had an accident?
Compliance is not the aim of GDPR; protecting data and minimizing collection and retention of individuals’ information is the aim. So, let’s put that in scope.
There is a misconception in some quarters that GDPR applies exclusively to companies with physical infrastructure in a European country. Wrong! If you’re in Europe and you are buying a product or service in the EU, then yeah, you’re covered. Technically, citizenship isn’t the key point.
If you’re an EU citizen, living in the United States, buying U.S. goods, being shipped to a U.S. address, then no, GDPR wouldn’t necessarily apply. There are some edge scenarios to this, though: GDPR articles 3 and 4 mention that a non-EU country is in scope if it is processing information of a data subject in the European Union.
If you’re processing or storing the personal information of a European citizen, you’re in scope for GDPR. Non-European Economic Area (EAA) companies can show “equivalency” of controls – something that Americans currently deliver for the EU 1995 Directive through Privacy Shield. What is Privacy Shield going to look like post-GDPR? Certainly many of the principles will remain the same, but the interpretation and enforcement will certainly be different.
I appreciate that GDPR is going to be big business for security and risk vendors. However, there’s a danger of “silver bullet” selling – that is, claims that a solution will give you a failsafe way to address GDPR. From my point of view, security vendors can help with GDPR in the following ways:
Let’s move away from the vendor claim of “we can solve GDPR for you.”(In this post, a friend of mine lampoons over-promising vendors in a brilliant manner.) Once an organization understands where its data resides, there are technical solutions that can mitigate the risks of a data breach.
To sum up, let’s go back to the original premise of this article: that 80% of GDPR is out of the CISO’s control. What, then, is a CISO to do about the external perception that this is a security issue? It follows that for the privacy of data to be protected, it would likely be a grave mistake to allow data to leak, the kind of incident against which safeguards should exist. The best defense is therefore a good offense. That includes technology and practice-driven defense-in-depth techniques, of which every CISO should be a competent practitioner. But it also means taking a role in educating our boards, executives, and fellow employees on their role in protecting data: choosing systems and practices that support GDPR principles, and maintaining practices that safeguard customer data.