GDPR Certification

What Will GDPR ‘Certification’ Look Like?

From my current perspective, these are the 3 most significant unknowns in the implementation of GDPR:

  1. The appropriateness of Privacy Shield (i.e. it’s not);
  2. What will ‘Representation’ look like (per Article 27); and
  3. What will ‘Certification’ look like (under Articles 42 & 43)

There will certainly be more as my knowledge grows, and you will have your own Top 3 depending on whether you know either more or less than me on the subject. Though it’s hard to imagine anyone who’s actually reading this crap knowing less.

I took on Privacy Shield last week, and I’ll take a stab at Representation at some point, but I just got through reading the European Union Agency for Network and Information Security (ENISA)’s ‘Recommendations on European Data Protection Certification1 so naturally I consider myself an expert in the field. Maybe I should create ‘Certified EU General Data Protection Regulation (GDPR) Certification Theory Foundation and Practitioner’ courses?

Basically the subject of ‘certification’ is far from straightforward. Not complicated per se, just very difficult.

For a start, what certification do you mean? Do you mean an organisation getting certified against the GDPR itself? Or do you mean someone who is certified to perform the certification?

First, it’s clear that there cannot be certification TO the GDPR, and that there will be no PCI DSS-esque tick-box exercise to perform. Instead, and only if applicable to your organisation, you will be certified AGAINST the GDPR in terms of adherence to its principles and intent. Or as ENISA puts it; “[…] compliance with the GDPR is not possible to be certified. What can be certified, is compliance with (or else: conformity to) certification criteria that are derived from the GDPR.

‘Criteria’ in this example could be as broad as; “Provide a summary of the appropriate technical and organisational measures in place.” (for Article 32). Or it could go as deep as; “For data protection, describe your encryption/anonymisation/pseudonymisation mechanism(s), including [where relevant] the cipher type and bit strength.”. Either way, it’s not telling you what to do, it’s making you demonstrate the appropriateness of what you have (i.e. compliance ‘against’, not ‘to’).

ENISA also makes it very clear that we must be specific and accurate in our terminology. ‘Certification requires the “provision of assessment and impartial third-party attestation that fulfilment of specified requirements has been demonstrated.“, whereas a ‘self-assessment‘ (first or second-party) can only lead to a self-declaration of conformity, never certification.

By far the lion’s share of organisations will be self-assessing, as hiring a third party to perform an onsite assessment would be overkill for a voluntary process (surmised from Art. 42(1) final sentence and Art. 42(3)). Yes, this could make a farce of the whole thing (like PCI SAQs), but should you BS your way through your self-assessment what do you think the supervisory authority is going to do if you appear on their radar? (Articles 58 and 83 for your reference.)

What I think this means in practice is that ‘compliance‘ will consist of demonstrating that your controls, processes, and documentation related to the processing of personal data are appropriate to meet the intent of the Regulation. And while that sentence seems to be just as wooly as the Articles 42 and 43 themselves, it should actually be very good news for you.

Why? Because it means that while no certification or even self-assessment mechanisms are available (and won’t be for some time) that compliance with the GDPR is determined by you!

Yes, you should be able to demonstrate that you are meeting the intent, and yes, you will actually have to fix what you know you’re doing wrong, but it means that May 25th is no longer a deadline, it’s an indication of your risk appetite. In other words, do you [stupidly] do nothing and wait for more definitive guidance, or do you do the best you can now until such times as a bar can be set by the supervisory authorities?

So, as I stressed way back in There is No Such Thing as GDPR Certification …Yet!, there still isn’t, and ANYONE with the word ‘certified’ anywhere near the word ‘GDPR’ is no more qualified to help you than someone who has done a few weeks of reading on their own (like me).

To reiterate one more time (for the UK):

  1. There is no certification mechanism for organisations wanting to validate GDPR/DPA compliance through a third-party;
  2. There is no official self-assessment mechanism for organisations wanting to self-assess their conformity to GDPR/DPA;
  3. There are no organisations able to provide ANY form of OFFICIAL certification program for businesses or individuals; and
  4. There are no individuals certified to a program sponsored by ANY body associated with the administration of GDPR/DPA

For certification to work in a harmonised fashion across all member states there is still a lot of work to be done. I cannot see a mechanism for certification, self-assessing etc. in place for some time. So UNTIL they officially announce one, focus on doing the basics that will be required regardless of how this issue get settled.

Waiting for this certification mechanism before you do anything towards compliance is no different from letting yourself drown until someone throws you a life preserver. The first steps in ANY GDPR project are as simple as they are common sense:

  1. Find your personal data;
  2. Map the data to your business processes;
  3. Get rid of everything you don’t need;
  4. Protect the rest with appropriate security controls; and
  5. Determine your lawful basis(es) for processing.

ALL of these things can be done now by anyone, and once they are done, the remaining aspects of GDPR implementation will be reasonably self-evident. Yes, 5. may be difficult for non-legals, but you’d be amazed at the number of qualified people out there willing to help for next to nothing in return.

Basically stay away from anyone promising you certification of any sort, and just keep swimming.

[If you liked this article, please share! Want more like it, subscribe!]

1 My thanks to Gabriel Avigdor and for his direct guidance/advice and for his excellent blog;

GDPR Fines

GDPR and Cybersecurity, a Very Limited Partnership

If a security vendor has ever told you that the GDPR is imposing fines of up to 4% of annual global revenue for data breaches, they are either:

  1. ignorant of the standard; and/or
  2. lying to you.

Being generous, they may not actually know they are lying, the General Data Protection Regulation (GDPR) isn’t exactly easy to decipher, but even a cursory review tells a rather obvious story. I will attempt to address the following assumptions in the course of this blog:

  1. The GDPR is >95% related to enforcing the RIGHT to privacy, not the LOSS of privacy through data breach;
  2. The maximum fines for ANY organisation are 2% of ‘annual turnover’ for even the most egregious loss of data through breach, not 4%; and
  3. Fines are entirely discretionary, and an appropriate security program will significantly reduce any fines levied.

Wait, there are 2 types of privacy!?

Ask a lawyer in the EU what privacy is and s/he’ll likely quote Article 12 of the Universal Declaration of Human Rights: “No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks.

From a GDPR perspective, this equates to two of its three fundamental aspects. Grossly simplified these are:

  1. Explicit consent; and
  2. Legitimacy of processing.

In other words, the vast majority of the GDPR is concerned with obtaining explicit consent for the personal data collected, and then ONLY using that data for legitimate purposes in-line with the consent received.

Even when GDPR refers to ‘security’, it is more concerned with these two fundamentals than it is with security of the data itself. That is what they mean by “security of processing“.

However, from a cybersecurity professional’s perspective – and the third fundamental aspect of the GDPR – privacy also involves loss. i.e. The data was stolen during a breach, or somehow manipulated towards nefarious ends. This is a very important part of the GDPR, Hell, it’s a very important part of being in business, but it should never be used to sell you something you don’t need.

Maximum fines?

Of the 778 numbered or lettered lines of text in the GDPR Articles section, there are only 26 that relate directly to data security (or 3.34%). These are contained within Articles 5, 25, 32, 33 and 34.

Per Article 83(4)(a) (a.k.a. ‘2% fines’) – “(a) the obligations of the controller and the processor pursuant to Articles 8, 11, 25 to 39 and 42 and 43;

While Article 5 is contained within Article 83(5)(a) (a.k.a. ‘4% fines’), all but one line refers to security of processing, not the security of the data.

So, if it can be assumed that if the maximum fine for ANY data breach, no matter how egregious, is 2% of the annual revenue from the previous year (in the case of an undertaking), that 2% is what the EU considers the maximum for a fine to qualify as “effective, proportionate and dissuasive” (per Article 83(1)). Therefore, a fine of €10,000,000 would be reserved for any organisation with revenue over €500,000,000 annually. Fines are never there to put you OUT of business!

It must follow that if 2% is the maximum, then fines will go down the less egregious is your offence. Everything you need to determine the level of ‘egregiousness’ is contained in the 11 lines of Article 83(2)(a) – (k). Words like ‘intentional’, ‘negligent’, ‘degree’, and ‘manner’ are bandied around, all of which can be answered by you.

In this spreadsheet, I have taken a stab at adding specific questions to each of the (a) – (k) line items. Answer them all truthfully and you’ll get an indication of what I consider to be an appropriate fine based on your annual revenue: GDPR Fine Worksheet. Caveat: I am NOT a lawyer, and this is based entirely on my own experience, not anything resembling known fact.

Finally, bear in mind that as per Article 58(2), there are many ‘corrective powers’ that a supervisory authority can resort to long before levying a fine, including simple warnings (Article 58(2)(a)). Fines should be considered as a worst case scenario in their own right, let alone the amount.

Appropriate security program?

There is no such thing as 100% security, so the more you can demonstrate that your security program is appropriate to the levels of risk, fines should be the least of your problems. As long as you have everything from senior leadership buy-in, to incident response, to disaster recovery and breach notification – you know, the basics! – it is not a foregone conclusion that fines will even be considered.

Go here for more on what a security program should look like: What is a Security Program?

In conclusion…

In the UK, if you are an organisation that processes personal data and you were already a) complying with the Data Protection Act (DPA), and b) doing security properly, GDPR compliance would require only relatively minor adjustments. For those that weren’t, you have a lot of work to do now once the supervisory authority has the powers that GDPR bring to bear, and not much time to do it in (May 25, 2018).

That said, don’t do anything for compliance alone. Do it for the business, do it properly, and compliance will fall out the back end. So while it is reprehensible that security vendors are trying to exploit the GDPR for profit, if you fall for it it’s entirely your fault.

By the way, if you’re a business that is predominantly centered around the processing of personal data, the Article 58(2)(f) – “to impose a temporary or definitive limitation including a ban on processing;” can take you offline indefinitely. And yes, you can be fined on top of that.

I hate to say it, but don’t do anything until you’ve spoken to a lawyer.

[If you liked this article, please share! Want more like it, subscribe!]

ISO 27001 Certification

How to Begin Your ISO 27001 Certification Project

There are many consultants with significantly more ISO 27001 experience than I have. And type “how to begin ISO 27001” into Google and you’ll get ~8.2 million hits. So what makes me think I can do any better?

Actually, I not saying I can, but I am saying that my style of consulting seems to be conducive to getting such difficult projects off the ground quickly. Or at all for that matter. No security project is more difficult that implementing an ISMS.

In last week’s blog; ISO 27001 Certification, Is It Really Worth It? I stated that the top 5 reasons that ISO certification projects fail are:

  1. Grossly underestimating the level of effort;
  2. Doing it just to land a big contract (or for marketing purposes);
  3. Tying the certification to an overly aggressive deadline;
  4. Ignoring the expert help; and
  5. Having no business goals in mind.

It follows therefore that to make certification a success, you must overcome these challenges at a minimum. Sadly, nothing I say from this point point forward will be in any way new. Some of what I have to say has been said dozens of times by me, and thousands of times by my peers and betters.

The Challenges

  1. Grossly underestimating the level of effort – Symptomatic of one thing; asking the wrong questions. If you had asked the right people the right questions you would KNOW just how difficult an ISO certification project is. No certification should be undertaken lightly, but there are more than enough ISO experts out there to make the level of effort abundantly clear.
  2. Doing it just to land a big contract (or for marketing purposes) – While I can empathise with this one, allowing what amounts to greed to provide the entire impetus for something that requires a fundamental shift in culture is naive at best. The promise of a big contract can, and often does, provide the initial business case for ISO certification. But to then focus entirely on doing just enough to land that project is a total waste of time and effort. Many good consultants will rightly walk away from such projects. It’s our reputation too.
  3. Tying the certification to an overly aggressive deadline – Usually an extension of 2 above, and will invariable derail the project before it begins. If all you’re focused on is a looming deadline, nothing will be done properly, nor will it be sustainable. Remember, ISO certification requires 6 month health checks, an unsustained ISMS will result in the removal of your certification. Quite right too.
  4. Ignoring the expert help – You don’t go to the doctor and tell them you have a brain tumour. You tell them you have a headache and let them do the rest. So why would you hire an ISO expert them argue with every step of the way just because you don’t like what you hear? A good consultant will not ask you for anything they already have, or they do not need, so either do the work or stop the project if it’s too much.
  5. Having no business goals in mind – Contracts, even very large ones, are not business goals, they are a means to achieving a business goal. Done correctly, an ISMS can enable almost every goal you’d care to mention. Done correctly. Before you begin your project, find out what your CEO’s goals are and map the ISMS efforts to them. Miss this step and you will fail every time.

I use the word ‘recommend’ very carefully, but I HIGHLY recommend that you put all the relevant stakeholders through a 1 day ISMS training session to set the scene. Without this context, you will have no support.

If the CEO can’t even make an appearance at this session, that will tell you all you need to know about how your project is going to go.

[If you liked this article, please share! Want more like it, subscribe!]