NNT: Thanks for taking the time to talk to us today. Time is of the essence with GDPR regulations being introduced in May 2018, so can we get a starting point from you in terms of the key facts? If there’s one thing everyone knows about GDPR, it’s that the regulation incorporates data breach fines of ‘up to 4% of global revenues’ – right?
DF: Unfortunately that’s where most organisations start, and they have all missed the point! I’m seeing this panic-inducing rhetoric from almost every online cybersecurity publication, lawyers, cybersecurity vendors and increasingly from cyber insurance vendors. People who should KNOW better. But the facts are that:
- the GDPR is >95% related to enforcing the RIGHT to privacy, not the potential LOSS of privacy through data breach;
- the maximum fines for ANY organization are 2% of ‘annual turnover’ for even the most egregious loss of data through breach, not 4%; and
- fines are entirely discretionary, and an appropriate security program will significantly reduce any fines levied.
So yes, the language is there, but the context, intent and likely implementation is a long way off this theoretical maximum number, and leading with this ‘fact’ in a sales pitch is highly misleading to point of being unethical.
NNT: So if the most widespread fact about GDPR is being misinterpreted, what about the other common assertion that PCI DSS or ISO 27K measures can be extended to encompass Privacy as well? If not the process and procedural aspects, surely at least the common needs for data encryption and malware defenses overlap?
DF: First, data security does NOT equal privacy. Just as loss of data through breach does not, in and of itself, equate to a loss of privacy. It’s what done WITH the data that was stolen that has the privacy implications. Plus, data security represents less than 5% of the 778 lines of the entire GDPR Articles, and the PCI DSS is – in my admittedly biased estimation – no more than 33% of a true security program. The only way PCI can help with GDPR is to use the assigned budget to do security properly. In terms of focusing on say, vulnerability management or encryption, then strategically selecting and implementing shared technologies does make sense, but highlighting this as the basis for this assertion when 95% of the GDPR has no commonality with PCI or ISO 27K is a false premise. You will never reach GDPR ‘compliance’ using PCI, but you will achieve both PCI and GDPR compliance on the way to real security.
NNT: On that basis, if neither PCI nor ISO 27K are especially suitably matched to delivering on GDPR requirements, what is the best approach to take? What kind of guidance would you give to those undertaking a GDPR project?
DF: If you really are starting at square one then my Froud on Fraud blog provides plenty of discussion on all aspects of GDPR, but the most important point to get over first is that the vast majority of the GDPR is concerned with obtaining explicit consent for the personal data collected (or other legitimate interest factors), and then ONLY using that data for purposes in-line with the permissions received. As such, GDPR should be approached as a corporate governance project, not a cybersecurity project. My view would be to get this understanding clear first, then establish a team within the organization with stewardship from a privacy expert but including sales, marketing, HR and of course, IT and Information Security.
NNT: One final question regarding the intent of the regulations that you have just summarized – even though you made it clear that GDPR and PCI have very little in common, could it be argued that some of the concepts are similar? For example, removing legacy cardholder data is one of the initial PCI tasks and likewise, identifying Personal Data and questioning the need for holding it seems to be an equally sensible place to start for GDPR?
DF: Every organization should start out the exact same way: By mapping their business processes (at both the individual asset and ‘asset interdependency’ level). This does not require a lawyer, and is something you should already be doing. If you don’t even have this in place, you will likely never be able to demonstrate the appropriateness of the ‘extent and proportionality’ of your data processing should things go wrong. If you have legacy Personal Data, document your plan to remove data over the course of a specific time frame.
In summary, there is still no such thing as 100% security, so the more you can demonstrate that your security program is appropriate to the levels of risk, GDPR fines should be the least of your problems.
[su_box title=”About David Froud” style=”noise” box_color=”#336588″][short_info id=’103906′ desc=”true” all=”false”][/su_box]
