GDPR Step-by-Step - Operationalise

GDPR Compliance Step-by-Step: Part 6 – Operationalise

This is the final part in my GDPR Step-by-Step series, and one that, in my cynicism, I see very few organisations even trying to attempt. I have lost count of the number of companies with whom I have tried to implement a continuous compliance program, only to have them stop once they received their initial ‘certification’. In this respect, GDPR will be no different from something like PCI.

But for GDPR, if you don’t  build the necessary knowledge / processes into everyone’s day jobs, your compliance program will falter. While data protection and privacy are everyone’s responsibility, they cannot, and will not be at the forefront of everyone’s mind as they work through an ordinary day.

There are some who are convinced that you can ‘operationalise’ the entirety of GDPR with ISO 27001. This is, of course, nonsense. However, the concept is perfectly valid in that ISO 27001’s goals are to:

  • Systematically examine the organisation’s information security risks, taking account of the threats, vulnerabilities, and impacts;
  • Design and implement a comprehensive suite of information security controls and/or other forms of risk treatment;
  • Adopt an overarching management process to ensure that the information security controls continue to meet the organisation’s information security needs

So why can’t you just replace “information security controls” with “data protection controls”? Because the entirety of ISO 27001 covers only 1 of 99 Articles in GDPR (Article 32), the rest of the Articles cover aspects of data protection that the ISO standard was never designed to encompass. Nor should it try.

That said, a lot can be learned about how to adopt GDPR’s “appropriate technical and organisational measures” by bridging them with the ISO concepts. As partially demonstrated by this white paper from IAPP and OneTrust; Bridging ISO 27001 to GDPR (my thanks to Gabriel Avigdor for bringing this to my attention).

In the end though, to operationalise GDPR you will be implementing some new concepts [to you anyway], as well as taking existing concepts to a whole new level. Still simple, and still bloody difficult, especially without appropriately qualified expertise.

Things to operationalise:

  1. Senior Leadership Commitment: Leadership commitment to cybersecurity is one thing, but GDPR has the potential to significantly impact the way an organisation performs its core function(s). The commitment from the CEO/BoD has to pay a lot more than lip service, data protection needs to be built into the company’s values and goals. They need to live and breathe this stuff or no-one else will;
  2. Governance: GDPR is the perfect program to put in the hands of governance. What other function in the organisation has both the support from senior management AND representation from all departmental verticals?;
  3. Employee On-Boarding: Lost count of the number of times I’ve harped on about this one. Go here if you want more, just add ‘data protection’ to the list of subjects HR could help address; Human Resources, the Missing Piece From Every Security Program;
  4. Employee Awareness & Training: As stated above, data protection is everyone’s responsibility, so every employee MUST receive training appropriate to their role within the organisation;
    oprovacy law
  5. Policies, Standards & Procedures: Data protection adds a whole raft of ‘paperwork’ to any organisation. Without appropriate document management, these will not keep up with the changing face of privacy law. In this respect, data protection is no difference from cybersecurity, as without your ‘paperwork’ in place you will never be compliant with anything;
  6. Risk Management: This is almost identical to the risk management performed for cybersecurity and IT; 1) measure your risk, 2) determine whether your current controls meet the risk, 3) if yes, do nothing, if no, remediate the gap(s), 4) repeat. Of course there are differences, in that a normal risk assessment will not cover the requirements of a Data Protection Impact Assessment (DPIA), but the process is VERY similar and will likely involve much the same people;
  7. Asset Management: Core to cybersecurity, and core to data protection. You cannot manage what you don’t know you have. However, while cybersecurity cares about the security controls you have in place around the data assets, data protection cares about what you’re doing with the data. This takes asset management to a whole new level, a level you have no hope of achieving if you can’t manage your data life cycle;
  8. Vendor Due Diligence: While you could almost get away from not doing this well for ‘just’ security, under GDPR your third parties must ALL be held to much higher standards. There is little room for error in both contracts and ongoing service monitoring, as you could well end up 100% liable for their failings. Controller/Processor relationships are critical;
  9. Incident Response / Breach Management: Like vendor due diligence, organisations are very lazy about getting incident response right. Not under GDPR, there will be very few excuses supervisory authorities will accept if you cannot, as a controller, report a breach after 72 hours of being notified. You will need a very good REASON;
  10. Record Keeping: Unless your organisation has fewer than 250 employees AND your processing of personal data is ‘occasional’, you will need to keep a record of your processing activities. For most this will be a manual process on a spreadsheet, but that does not mean it should not be assigned ownership and warrant frequent review at senior level.

There are literally dozens of other things that need to be addressed, but I think these are the big ones. It’s actually quite scary how similar these are to security. Which perhaps explains why security people get cornered with this stuff so frequently. But while there are definite similarities, even parallels, the differences are profound and must be addressed by the appropriate skill-set.

If you only get one take-away from this GDPR Step-by-Step series, I hope it’s this; There is nothing new here. In some way, shape, or form, EVERYTHING required of you for GDPR has been done before, and there are a many people out there who have done it.

All you have to do is a little homework…

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

GDPR Step-by-Step - Documentation

GDPR Compliance Step-by-Step: Part 5 – Documentation

As a consultant there’s nothing I like more sitting around a table with a bunch of really smart people simplifying complex issues and guiding them towards an appropriate and effective security program.

Then someone has to go spoil the ride by saying; “That sounds great David, when can we expect the report?” [sob] 

‘Documentation’ really should be a 4-letter word.

But with the GDPR, you have no choice. Documentation is your evidence of compliance. Even if you’re lucky enough not to have to maintain ‘records of processing activities’ (see Article 30(5)), you still have to document everything else, even WHY you don’t think you have to maintain records.

The word “appropriate” appears 115 times in the GDPR final text, and “reasonable” a further 23 times. That’s 138 times in one regulation that YOU have to make a determination of whether or not what you’re doing meets the grade. Lawyers can turn to precedent to agree what’s reasonable, where can WE turn to agree not only what’s appropriate, but to justify it?!

Here’s where the concept of Risk Management comes in, because like it or not, you WILL be taking a risk-based approach to GDPR compliance. And the one thing that risk management demands; documentation.

Note: The following is at a very high level, not comprehensive, and not representative of every organisation’s needs.

First, you will need policies. Not just the information security policies that I usually focus on, but policies that cover all relevant aspects of data protection. You will need policies on things like:

  • General Data Protection / Privacy
  • Employee Privacy
  • Third Party / Third Country Transfers
  • Data Subject Rights
  • Engagement of Processors
  • …and so on.

There are [of course] a bunch of vendors out there promising to provide every document you’ll ever need for £XX+VAT. But NONE of these #gdprcharlatans can provide the appropriate context that only comes from working with a person who knows that the Hell they are doing. These cannot just be paperwork, they must reflect your commitment to data protection by design and default, and the way you do business.

Second, you’ll need a documented record of what data you have a what you’re doing with it, but you should have taken care of this in your data discovery and business process mappings performed in Parts 2 and 3 of this series.

Third, all of your lawful bases for processing and corresponding data subject rights determined at Part 4 should be clearly articulated. Each will have its own idiosyncrasies:

  • Consent – corresponding privacy notices in clear and plain language, no ‘bundling’ of conditions etc;
  • Contractual – employee contracts, client contracts, data transfer agreements and so on;
  • Legal – [I’ll let a lawyer supply samples here];
  • Vital Interest – If lives are at stake you’d BETTER have a lawyer helping you out!;
  • Public Interest – Assuming you’re a public body, you should already have appropriate representation; and
  • Legitimate Interest – you will need to be VERY clear on how your ‘commercial’ interests are not “overridden by the interests or fundamental rights and freedoms of the data subject“.

Fourth, you will need to document all of your security controls in place around the personal data, as well as the risk assessment results that show that the controls meet the defined risk(s). Do not even THINK about showing a supervisory authority your PCI Attestation of Compliance, but a properly scoped ISO 27001 certificate would likely go a long way.

Finally, and if applicable, you will need to document your ‘records of processing activities’. Article 30(5) states; “The obligations referred to in paragraphs 1 and 2 shall not apply to an enterprise or an organisation employing fewer than 250 persons unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data as referred to in Article 9(1) or personal data relating to criminal convictions and offences referred to in Article 10.

So most of us can probably avoid the ‘high risk’ and ‘special category’ caveats, but ‘not occasional’? While ‘occasional’ is hard to define (like reasonable and appropriate), if you are processing personal data as part of a defined business process, it is unlikely that you will get away with saying “it’s only once a month” (for example).

That said, the requirement for maintaining record are not THAT onerous, unless you have hundreds of separate processes. They should also be made very clear by your supervisory authority. The UK’s ICO for example has even provided two templates, one for controllers and one for processors (near the bottom of the page).

I know this sounds like a lot, but with the exception of the lawful bases and records, you should already have the rest of this. If you don’t, not only will next week’s GDPR Step-by-Step be impossible, so will GDPR compliance.

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


Do Not Hire Companies Using GDPR Fines as a Sales Tactic

Taking a week’s break from my Step-by-Step series in order to have one final rant [I promise] about the use of GDPR fines/penalties in marketing material. Hopefully this third attempt will sort the problem out once and for all, I DO have 400 followers after all.

In my business, I am advising everyone who will listen to not do business with ANY organisation using fear, uncertainty and doubt (FUD) as a tactic to sell. If they were offering decent services they would not have to resort to such unprofessional and unethical practices.

If you or your organisation use these tactics then you are everything wrong with the industry and I can only hope you fail. I will using the hashtag #gdprcharlatans to draw attention to more egregious lies. But if you fall for these tactics then frankly you deserve it, because you have not done your homework.

For anyone watching the industry closely, it is clear that GDPR represents a fundamental shift in how data protection is going to be addressed globally. So while the fines/penalties may be a stick to help keep things moving in the right direction, they will NEVER be anything other than “effective, proportionate and dissuasive” (Article 83(1)). This is not a do-it-once compliance project for May 25th, this is slow and steady integration of a human right into the way we do business. Permanently. Fines are not the important part.

I hereby predict that you will never see an organisation go out of business because of a fine, it will be because they were stopped from processing for egregiously breaking the rules. In other words they will deserve it.

Here is my reasoning (borrowed yet again from previous blogs):

  1. The maximum fine for ANY infringement, no matter how egregious, is 4% of the annual revenue from the previous year (in the case of an undertaking), it can be assumed therefore that 4% is what the EU considers the maximum for any fine. Therefore, a fine of €20,000,000 (Art. 83(5)) would be reserved for any individual organisation with revenue over €500,000,000 annually. Yes, that’s 1/2 a BILLION.
  2. It must also follow that if 4% is the maximum, then fines will go down the less egregious the offence. Everything you need to determine the level of ‘egregiousness’ in an offence is contained in the 11 lines of Article 83(2)(a) – (k). With words like ‘intentional’, ‘negligent’, ‘degree’, and ‘manner’, it’s clear that there is a significant amount of information to be taken into account long before a fine is even considered. A fine, IF levied, will be carefully considered and FAIR.
    e.g. For Art. 83(2)(b) – “the intentional or negligent character of the infringement” consider the answers to the following questions:
    * To what degree are the lawful bases for processing for all business processes supported by legal review and approval?
    * Was senior management aware of the organisation’s risk exposure?
    * Did senior management ignore, or actively suppress recommendations to correct processing?
    Would you fine an organisation doing its very best and has established Board-level accountability the same as one that couldn’t care less?
  3. Fines simply don’t fix the cause of the breach, and supervisory authorities KNOW that. For any breach there will be remediation and potentially reparation required, often at significant cost. So unless a breach was truly intentional or negligent, why would a supervisory authority fine an organisation for a mistake as opposed to allowing them to use what money they have left to fix the underlying issues?

To try and put all of this into a more demonstrable format, I have developed a GDPR Fine Calculator designed to do the following:

  1. Determine the level of fine for which you are potentially liable – Art. 83(4) and (5) break down, by reference to 50 other Articles/sub-Articles, which infringements incur which penalties (2% and 4% respectively). Just answer the 50 questions on the ‘Breach Questionnaire’ tab to determine which applies to you (Note: If even 1 answer is 4%, that’s what applies);
  2. Estimate the fine for which you would be liable based on the ‘egregiousness’ of the offence – Whichever fine structure you fall under based on the results of the breach questionnaire, go fill it out. Enter your organisational status (undertaking or not) and your annual revenue (in €), then answer all the questions predicated on the 11 “conditions for imposing administrative fines“.

I think you will find that unless you are unbelievably crap at absolutely everything, your fines should not be anywhere near the infamous €20M mark.

This is not to say you shouldn’t worry about fines, because if you are in fact crap OR you’re still doing absolutely nothing towards GDPR compliance, and you are breached, you will deserve every fine you get.

Please Note: The fine calculator has absolutely nothing to do with any official ‘body’, known fact, or even direct experience, it’s based entirely on my opinion and hopefully a little common sense.

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

GDPR Step-by-Step - Lawful Basis for Processing

GDPR Compliance Step-by-Step: Part 4 – Lawful Basis for Processing

If you are looking for a clear and legally accurate treatise on how to apply the 6 lawful bases for processing to your business, you have:

  1. not read any of my previous blogs;
  2. probably not read the GDPR itself; and therefore
  3. come to the wrong place

I am not a data protection/privacy expert and I am not a contracts lawyer, which are the most important skill-sets that should be used in making both the lawful basis determinations, and writing the required contracts/privacy notices/policies etc. to support those decisions. No one else is truly qualified, certainly not a cybersecurity guy like me.

[Note: But if you DO make these decisions on your own, I can certainly empathise, the above skill-sets can be expensive. Just be careful and do a LOT of homework.]

While some scenarios would seem to be obvious; like doctors requiring personal data for vital interest, lawyers requiring personal data for legal reasons, or service providers requiring personal data to fulfil a contract, the devil, truly is, in the detail. Getting this wrong not only has a direct impact on your ability to demonstrate ‘compliance’, but you may also be implementing all the wrong controls.

And that’s the point of this blog; what to actually DO with the lawful determinations once they’re made? Because there is actually a very good chance that what you end up doing is not what the lawyers told you to do, because it would just be too bloody difficult/expensive. It would probably be inappropriate as well. I can think of several examples where you will / should actually change your business processes rather than implement what would be required to maintain them in a ‘GDPR compliant’ manner.

But please don’t see this as compliance getting in the way of your business, rather you now have a compliance driver to do what you should have been doing all along. GDPR is not there to tell what to do, it’s there to have you justify what you are doing.

Before Implementing the Lawful Bases for Processing:


1. Determine if it’s the RIGHT decision – This may sound strange given what I said above, but the lawyers are only going to make decisions based on the facts / evidence provided in the Process Mapping step, they will likely have little insight into [or care about] the criticality of the business process in question. Or of the impact changes will have on the business.

For example: should the lawyers state that ‘Business Process A’ requires consent, from a technology perspective you will have to implement data subject’s rights of access, rectification, erasure, restriction, AND portability to each and every individual. Does this make sense to the business? Is it really worth the effort?

If the answer to the above is ‘No’, then you will have to change your business process to one that balances both compliance and business needs. I’m not saying you have to change the lawful basis, but maybe if you just stopped collecting certain data? Only the business can make this determination;

2. ‘Minimise’ what’s left (Data Categories) – Data Minimisation is, by itself, one of the 7 Principles of GDPR, and has to be in place by law. But now you have a really good reason to put it into effect; the less data you have, the less you have to do with it. You must ask 3 questions:

i. Do we even need the data?;
ii. Do we need ALL of these data categories?;
iii. Can we tokenise / anonymise / pseudonymise any part of what’s left?

Obviously if the answer to any of these three is ‘Yes’, do those things before doing anything else. Not only will you in one relatively simple step reduce your workload, you will have significantly reduced your risk;

3. Consolidate what’s left (Data Sources) – Just because you need something, does not [necessarily] mean that you need several of that something. In most organisations, the amount of data that is duplicated in applications/databases/spreadsheets is quite frightening. You only need ONE copy of something (along with all requisite access and resilience obviously);

4. Shut down / amend the legacy data acceptance channels (“stop the bleeding”) – Now that you’ve worked out what you need to keep, stop the bad stuff coming in. Whatever your ‘acceptance’ channels are (batch data from clients, web-based forms/registrations, third party marketing campaigns etc.), adjust them in-line with your new data source baselines; and

5. Implement appropriate data-tagging and data classification – This may sound like I’m pushing it, but in my mind there’s little point making all of the above effort if you have no way of maintaining your baseline(s) going forward. This is a blog in itself, and frankly too detailed and organisation-specific to bother, but whatever you do, you must keep ‘continuous compliance’ in mind.

Once you’ve completed the above, you can take the whole lot back to the lawyers and have them sign off …again. This is now their baseline for the creation of all necessary policies / privacy notices / data processing agreements / contract addendums and whatever else is needed. Imagine if they had tried to do this on all of your ‘broken’ processes.

NOW you can implement the relevant data subject rights. For some organisations this will be as simple as writing an API or two, for other is will involve enormous amounts of manual labour, others will simply outsource as much as they can. Whatever method you choose will be significantly easier now that you’ve implemented data minimisation.

Whatever choices you make, it will not be the lawyers making the final decisions, it will be the business. Lawyers, like IT and like cybersecurity, are only there to enable, not dictate. But oddly enough, it will be these same three groups working with the business to negotiate a workable compromise long after May 25th has come and gone.

But that’s OK, it’s not about compliance, it’s about doing what you can now, and having a plan for the rest.

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

GDPR Step-by-Step - Process Mapping

GDPR Compliance Step-by-Step: Part 3 – Process Mapping

If you have performed the data discovery exercise laid out in the last GDPR Step-by-Step blog, you will now have a bunch of data with only limited context. For data to become information, you need to provide the appropriate context, which in GDPR terms, is in the form of a ‘business process’.

Every department has at least one, and likely several individual processes that handle personal data, each in their own way. All of these need to be defined as they will each require a determination of their lawful basis for processing, and will correspond directly to the record keeping requirements of Article 30.

For example, HR will have processes for Recruiting, On-Boarding, and Benefits; Sales will have Current Client Management, New Client Prospecting, and Telesales; Marketing will run campaigns based on data from past/present/future clients, and so on. Not one of these processes use the exact same data sources, nor will they have the same deliverable. It’s that unique combination (plus a few other factors) that determines how many business processes you will need to define.

However, the first thing you have to do is start building a ‘master list’ of all data categories from which each team will then provide all other data mapping elements. Data Categories are the ‘base unit’ of the GDPR implementation and will include everything from Names, Addresses, Mobile Number, Next of Kin, Passport Number, and potentially hundreds of others (unless your business is relatively small).

This is the part that actually causes a lot of confusion for organisations; what exactly constitutes personal data? Here you must turn to the definition of direct and indirect identifiers;

  • Direct Identifiers’ are “data that can be used to identify a person without additional information or with cross-linking through other information that is in the public domain.” e.g. Passport Number, SSN/NIN, Address etc.
  • Indirect Identifiers’ are “data that do not identify an individual in isolation but may reveal individual identities if combined with additional data points.” e.g. > 80 percent of people in the US can be uniquely identified just by combining date of birth, gender and post code.

You will notice that even a Name is not a direct identifier, as there can be many people with the same name (there are over a dozen “David Frouds” on LinkedIn alone for example). But this also means that ALL data fields you have collected against an individual are potentially personal data (include ‘preferences’ like favourite dog). Just because you cannot tell who I am from a single piece of data (Salary for example), you will likely be able to do so from the combination of Department/Supervisor/Gender/Age, so all of these must be included.

Usually each department builds their own master list of data categories, but because a lot of departments may share data sources it is important that the organisation maintain a company-wide list as well. Standardisation is key.

So, now that you have a list of all data categories your business process uses, you must assign the following to each and every one:

Data Category ‘Metadata’:

  1. Category of Individual‘ – e.g. Current Employee, Potential Client, Candidate and so on. This will likely be the same for an individual business process;
  2. Category of Personal Data‘ – e.g. Contact Data, Salary Data, Performance Data and so on;
  3. Mandatory‘ – Yes or No – Is the data category in question absolutely necessary to complete the business process, or is it a nice-to-have? You would be surprised how much data is collected without a defined requirement in a regulatory, legal or contractual mandate;
  4. Responsibility‘ – Is your organisation the Controller, Joint Controller, or Processor?;
  5. Data Type‘ – Direct, Indirect, Special Category etc.; and
  6. Retention Period‘ – How long do you need to keep the data, but again, this should be compared against a defined requirement in a regulatory, legal or contractual mandate

Categorise Your Data Sources:

Unless you are completely digitally transformed or optimised, it is very likely that you not only have several sources of data for each business process, you also have data in several different locations and formats. The following should be defined against every data source:

  1. Friendly Name‘ – What does everyone call it? Does not matter what it is as long as it’s known to all concerned;
  2. Functional Responsibility‘ – Who manages the data source? Here you will need to differentiate between internal / third party AND the location of the managers i.e. in the EU, or based in a third country;
  3. Data Type‘ – database, flat-file (e.g. spreadsheet), application export and so on; and
  4. Location of Data‘ – While you will want to know EXACTLY where the data is for asset management, for now just an indication of ‘in the EU’ and ‘not in the EU’ will suffice.

Business Process Narrative:

With your data categories fully mapped you must now ‘tell the story’ of your business process in order to provide the remaining context for the legal team for them to make legal basis determinations. As well as complete the record keeping requirement per Article 30:

  1. Purpose of Processing‘ – This can be as simple as ‘Payroll’, but if it’s a little more complicated than that you must explain in detail exactly what the business process is designed to achieve. Let the lawyers summarise this appropriately;
  2. Relevant Obligations‘ – Not every business process will have entries here. But where a law, legal or even contractual obligation is present, list them here. ‘Recruiting’ will be subject to anti-discrimination laws for example;
  3. Outputs to Third Parties‘ – Does the output of your business process go to third parties? if yes, to whom?;
  4. Outputs to Third Countries‘ – Does the output of your business process go to third countries? If yes, to where?; and
  5. Description of Security Measures‘ – High level stuff; encryption (storage and transfer), pseudonymisation, RBAC, access audits and so on.

Now take all of this and give it to your legal experts for Part 4 in the GDPR Step-by-Step series; Lawful Basis for Processing.

Obviously every organisation is different and what I’ve detailed above is overkill for some and nowhere near enough for others, but these are the basics.

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