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. In GDPR terms, this context 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 fully 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 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. 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;
  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 whom?; 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!]

GDPR - Prerequisites

GDPR Compliance Step-by-Step: Part 1 – The Prerequisites

Roughly half the blogs I’ve written in the last 6 months have been about the GDPR or privacy in general. I could take this as a good sign in that it beats hands-down writing about PCI, but the reasons I write about both of these ‘regulations’ in the first place are two-fold:

  1. Organisations do so little homework on applicable regulatory compliance that they leave themselves wide open to unscrupulous vendors and consultants; and
  2. I want to do everything in my power to protect organisations from those unscrupulous vendors and consultants.

From the GDPR’s first release came the “You can get fined 4% of your global revenue!” scare tactics, Now it’s the May 25th ‘deadline’ scare tactics. Millions upon millions have already been spent on vendors spectacularly unqualified to provide GDPR services, and this will continue as long as bullet 1 above remains true.

Therefore, in a series of several blogs, I will attempt to show just how simple GDPR compliance is. That’s right, SIMPLE. Yes, it will likely be bloody difficult, perhaps even expensive (up front), but it is simple. However, while it may be relatively costly in both capital and resource costs, do you really think supervisory authorities expect you to sacrifice the lion’s share of your profits just to achieve GDPR compliance?

Let me assure you that no supervisory authority cares about compliance itself, they care about protecting the human rights of all natural persons. As long as what you do for compliance is APPROPRIATE to the risks inherent in how you process personal data, this will be enough.

As far as I’m concerned not one organisation, regardless of size, region or industry sector, has to perform anything different than the steps I’ll be laying out in this series. The steps are the same, and should always start with the ‘prerequisites’.

GDPR Compliance Prerequisites:

  1. READ IT! ALL OF YOU! – There is not one person who does business with organisations ‘established in the Union’ to whom the GDPR does not apply. Not one. You are responsible in some way of ensuring other people’s personal data is protected, and you should be aware of your rights when it comes to your own data.
    No, the GDPR is not the easiest read, but even a single pass through would remove a significant chunk of the confusion, AND put you in position to ask better questions. NB: This may help – GDPR in Plain English
  2. Senior Leadership Buy-In – Like everything else, if the top people in an organisation are ignorant and/or ambivalent, so will everyone else be. Even if someone did care, they’d get no support. Your Board of Directors don’t have to be GDPR experts themselves, but they had better take it seriously. The accountability principle will likely attract civil penalties as supervisory authorities write aspects of GDPR into national law.
  3. Stakeholder Training – This can be as simple as a one day engagement where an appropriate representative of each departmental vertical (HR, Sales, Operations etc.) undergo GDPR training bespoke to their business needs. While you’re not going to get all the way to lawful basis(es) for processing, determination of the appropriate next steps should be relatively straightforward. So should the removal of the fear-factor that has no place in this process.
  4. Designation of Project Ownership – If you already have a Governance function, this is easy, just give it to them. If you don’t, you will have to assign the initial project to someone with enough knowledge AND influence to be effective. Yes, than can be an external consultant, but it’s much better if they are an internal resource. Or even better, a team of resources.
    The list of action items at this early stage are already well defined, the most important one being the rounding up and ‘orientation’ of subject matter experts from each unique part of the business.
  5. Find Appropriate Legal/Privacy Expertise – Regardless of how much you can do yourselves, unless you already have a qualified in-house resource, you are going to need help. From determining the legal basis(es) for processing, to privacy notices, to contract clauses, parts of your business are going to change. Don’t cheap out and hire a muppet, but don’t get fleeced. Find an appropriate resource to get you through this stage. Just bear in mind there are a LOT of generous experts out there who are making their knowledge and even templates freely available. Use them where you can.

For those of you who have done a GDPR implementation engagement the above may seem like something the tooth-fairy would propose. It’s simply not realistic. And while I somewhat agree, if you don’t at least TRY to put the above in place first why are you even getting involved?

I will admit that you can begin a GDPR project without ANY of the above – that’s next week’s Step 2 -, it’s just significantly more difficult.

Again, the implementation of GDPR is simple, but only if you’re in a position to ask the right questions.

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

GDPR Deadline

GDPR: May 25th is NOT a Deadline!

It seems there are only two ways to sell GDPR products and services:

  1. Tell everyone they are going to get fined €20M or 4% of their annual revenue; and
  2. Tell everyone that they only have until May 25th to get compliant or they’re in big trouble

These are both utter nonsense.

While the monster fines are a theoretical possibility (per Article 83), I would hope by that you know they will be reserved for the VERY worst offenders. If you don’t, read this from the UK’s Information Commissioner herself; GDPR – sorting the fact from the fiction. With my favourite quote being:

Issuing fines has always been and will continue to be, a last resort. Last year (2016/2017) we concluded 17,300 cases. I can tell you that 16 of them resulted in fines for the organisations concerned.”

And not one of these 16 (0.09% of the total!) was anywhere near the maximum of £500K, so forget the damned fines!! Unless of course you work for a bunch of total scumbags like Keurboom, then I hope you get completely reamed.

Anyway, so here we are, less than 3 months away from May 25th, and the ‘deadline’ for compliance is the most prevalent scare tactic!

“Get compliant before May 25th or else!!” “Deadline fast approaching!!” “Trust me, I’m a certified practitioner!!”

The thing is, “or else” what, exactly? What do you think is going to happen on May 25th? That your supervisory authority is going to be banging on your door with cries of “Article 30!! Show us your records!!“? Do you expect to receive hundreds of requests for access from people who know even less about GDPR than almost anyone reading this blog? Do you think you’ll suddenly be the subject of a class action suit?

Do you think your supervisory authority even knows who you ARE at this point? [No offence]

I’ll tell you what’s going to happen on May 25th …not a bloody thing different. It will be business as usual.

However, what WILL happen from May ONWARDS is a gradual increase in how the GDPR is enforced in each member state. Guidance from supervisory authorities will increase in-line with the real-world issues they face; certification mechanisms will be released forcing all organisations to at least review and consider them; the general public will gradually come to expect the heightened protection mechanisms and vilify those organisation who are not up to speed and so on.

To put this another way; Data Protection law is not going away and cannot be ignored. By anyone. In fact, in light of things like AI/ML, Big Data and the Internet of Things, data protection is only going to become more embedded in everything we do. It has to, and you need to keep up with it.

So the more time that passes the fewer excuses you will have for doing nothing, regardless of the size / type / industry vertical in which your business operates. In the UK for example you are already 20 years too late to be proactive. The DPA has been out since 1998 and compliance to it would have covered the lion’s share of the GDPR. Which itself has been out for almost 2 year.

While I can sympathise with organisations fumbling around but doing their best, I have little sympathy for organisations who have done nothing. It’s these folks who should be the most concerned, not for May 25th, but every day after it.

Not one organisation out there is incapable of doing these 6 things before the ‘deadline’. Not to completion perhaps, but a good chunk:

  1. Find out where all your personal data is; – [even crappy questionnaires and interviews will get you most of the way there]
  2. Map that data to the business processes that created it; – [HR, Sales, Marketing and so on…]
  3. Agree on which business processes should continue as they are, which should change, and which should stop altogether;
  4. Get rid of all instances of personal data that do not support the agreed business processes;
  5. Obtain appropriate guidance on the lawful basis(es) for processing what’s left; and
  6. Commit, in writing, at the Board level, to achieving full compliance

While this is nowhere near a full demonstration of compliance, you have done 3 things that the ICO have every right to expect. You have:

  1. reduced your risk by minimising your threat exposure – you can’t lose or misuse what you don’t have;
  2. done your best to ensure that you are supporting the data subject’s rights – the whole point of this exercise; and

I don’t care if you only achieve full compliance 5 years from now, and it’s unlikely the supervisory authorities will, if, and ONLY if:

  1. Your commitment is real;
  2. You have a plan; and
  3. You don’t get reported or breached

It’s up to you to do ENOUGH now to make sure 3. doesn’t happen, work on the rest when you can. Just make sure you can justify your timelines.

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

EU Citizen

GDPR: It’s Not Just About EU Citizens, or Residents

It is with some chagrin that I write this post. I fell for the very thing that I have warned my clients about for decades; “Read [regulation name] carefully and NEVER make assumptions, and if you don’t know something, ask someone who does!” Here I am now having to admit that I thought the GDPR was only about EU citizens.

It’s not.

The WORD ‘citizen’ never even appears in the Regulation. Not once. In fact, I’ll go so far as to say that it’s not even about EU residents, because that word never appears in the Regulation either. Neither of these words is what GDPR means by “in the Union“.

I take some very limited solace from the fact that I have never claimed to be a privacy expert, but my ongoing mission of pushing everyone to actually read the GDPR carefully makes me something of a hypocrite. So apologies for that, I should have known better.

But even now that I have read the relevant Recitals and Articles, and asked real experts for guidance, I am still only able to make assumptions. I know that somewhere, someone(s) knows exactly what all of this means in practice (and precedent) as there is very little ‘arbitrary’ about the law. Hopefully these someone(s) jump in at the supervisory authority level.

So the real point of this blog is NOT to impart knowledge, or instruct, I am unqualified to do so. It is to gather feedback, or even opinion on the below interpretation(s). And yes, I have reached out to both the ICO and Art. 29 WP for clarity, but I doubt I’ll get much back anytime soon.

[Note: I won’t name the people who have provided the following guidance (unless they want me to), but I thank them for it. That said, if I’m still way off the mark the blame is entirely my own.]

First, the KNOWN Facts:

  1. Nowhere in the GDPR, or any referenced document [of which I am aware], are the phrases ‘data subject’ and ‘natural person’ tied to ‘EU citizenship’ or even ‘EU residency’;
  2. Recital 2 states – “The principles of, and rules on the protection of natural persons with regard to the processing of their personal data should, whatever their nationality or residence, respect their fundamental rights and freedoms, in particular their right to the protection of personal data. […]” – [this is, after all, a human right];
  3. Recital 14 states – “The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data. […]” – [it does not matter who or where they are];
  4. Recital 22 states; – “Any processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union should be carried out in accordance with this Regulation, regardless of whether the processing itself takes place within the Union.” – [a business established in the Union can [with caveats] process the data anywhere in the world, GDPR still applies];
  5. The phrase – “[…] in the Union […]” appears frequently in relation to scope and/or applicability – [i.e. regardless of nationality and location];
  6. Article 3(1) states – “This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not.” – [regardless of 4. above, GDPR still applies]; and
  7. Article 3(2) states – “This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to […]” – [applies to non-EU establishments if they ‘target’ people in the Union]

Now, the Assumed ‘Facts’:

  1. If your personal data is collected and processed while you are physically IN the Union, and Article 3(1) or 3(2) apply, it does not matter what your nationality is, nor does it matter where you live normally. GDPR applies.;
    Scenario: A US citizen is on holiday in the UK and orders something from an e-commerce merchant ‘established’ in the Union. The site collects personal information. GDPR applies.
  2. For processing of personal data outside of Article 3(1) and 3(2), it doesn’t matter whether you’re an EU citizen or not, GDPR does NOT [necessarily] apply;
    Scenario: Someone ‘in the Union’ orders online from a merchant based in the US, who has made no effort whatsoever to market/aim their services to anyone outside of the US. All payments must be in USD. Just because they agree to ship the merchandise to the EU does not, by itself, put the merchant ‘in-scope’ for GDPR, even if they do collect personal data.
  3. Even if you are not ‘in the Union’, the processing of your personal data by an establishment whose activities provide the context for the processing are in the Union, is in scope for the GDPR;
    Scenario: A citizen, including non-EU, is on holiday in the US and orders online from an e-commerce merchant ‘established’ in the Union. GDPR applies.

In the end it’s becoming clear that being an EU citizen does not give you rights anywhere outside of the boundaries of Union law. It is also clear that regardless of your nationality, or where you live, doing business with Union-based organisations may give you rights that it’s quite possible you are not receiving in your own country (especially in the US).

And not that I’m particularly bright, but for me to make such a fundamental mistake in interpretation further supports my contention that you should only ever take guidance from proven privacy experts. This is just too important to rely on people who have only recently jumped on the bandwagon.

Again, I am not saying that any of my assumptions/interpretations are facts. I actually expect to be corrected. About the only benefit you can get from this is you should now have your own questions to ask.

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

Have You Forgotten About the ‘Cookie Law’?

You’ve all heard of the Cookie Law, right?

If the answer is no, and your business has a website that uses cookies (or other ‘online identifiers’), I would suggest you do a little homework. The upcoming EU ePrivacy Regulation not only expands significantly on that law (which is actually a Directive), it includes a fine structure on par with the GDPR.

The Cookie Law is actually the EU ePrivacy Directive  and was responsible for the incredibly irritating banners that pop-up on almost every website in the EU. About the only good news for some organisations is that the banners will likely go away under the new Regulation.

Even for those who are aware of the ePrivacy Regulation (perhaps have even read it), there is still a great deal of confusion. Not just related to the contents of it, but as to whether or not it’s even relevant with the GDPR already covering ‘privacy issues’.

Just 15 minutes of research reveals the following:

  1. The ePrivacy Regulation “particularises and complements” the GDPR – In other words, ePrivacy is an expansion on a single aspect of the GDPR. In this case ‘electronic communications’ (e.g. the ‘online identifiers’ referred to in Recital 30);
  2. ePrivacy covers Article 7 of the Charter of Fundamental Rights of the European Union (“the Charter”), the GDPR covers Article 8;
  3. It’s not just about cookies, it covers EVERY aspect of electronic communication. Including; “…calls, internet access, instant messaging applications, e-mail, internet phone calls and personal messaging provided through social media.“, and all ‘metadata’ relevant to the communication channels themselves;
  4. Unlike the GDPR, it does not just apply to ‘natural persons’, but to ‘legal persons’ as well. i.e. business-to-business; and
  5. It has the most significant impacts in the area of marketing.

So, if your business has a website, performs marketing, or communicates with clients over ‘electronic channels’, you are in scope.

So why isn’t there anywhere near the kind of panic and hype over this Regulation as there is GDPR? If anything, I’d say this one has greater impact on most business, with a far greater degree of negative impact on how you are currently conducting your business. Just ask an online publisher what they think of it and brace yourself for the answer.

Imagine, for example, you provide online content free of charge. Your revenue is driven by online advertising which is in turn personalised to the viewer by cookies. Under ePrivacy you could no longer rely on pop-up banners to force acceptance of cookies, instead you have to rely on the viewer accepting cookies by default in THEIR web browser. Not only that, the Regulation is basically suggesting that all browsers should be ‘blocking all cookies by default’, then, in plain language, walk every citizen through changing the defaults to more ‘merchant-friendly’ settings.

However, here are a few bloody BRILLIANT outcomes:

  1. Unsolicited marketing phone calls should use a prefix on their numbers so you know what it is before answering! And no, they cannot get around this by blocking the caller ID;
  2. Inclusion of your personal data in ‘publicly available directories‘ (a.k.a. marketing lists) must be done with consent; and
  3. Any kind of “listening, tapping, storing, monitoring, scanning or other kinds of interception, surveillance or processing” of your personal data is strictly forbidden (the usual deprecations apply, e.g. ‘pubic interest’)

Not surprising that during the ‘Stakeholder Consultation’ conducted from 12 April to 5 July 2016 that 83.4% of citizens were for it, but 63.4% of businesses were against it. The lobbying that has taken place to soften the wording, while fruitless so far, has had the likely impact of delaying the enforcement of the regulation beyond the proposed data of 25 May, 2018 (yep, same date as GDPR, that’s how closely they are linked).

So I frankly have no idea why GDPR is such a big deal and ePrivacy is so obscure, but you just know it’s because only one of these is easily monetised by snake-oil merchants. GDPR attracted cybersecurity “professionals” because it’s about ‘data protection’, and lawyers because of the ‘lawful bases for processing’ and the requirement for DPO.

ePrivacy on the other hand provides no easy remedies, but you know they’re coming.

The bottom line here is that if you’re not familiar with it, get familiar, it WILL impact you. Once again, for those in the UK the ICO has lots of material on its website, but look for Privacy and Electronic Communications Regulations (PECR)¹ instead. Like how the DPA is the UK’s implementation of GDPR, PECR is ePrivacy.

Happy reading.

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

¹ (Hopefully the acronym will be pronounced/known as the ‘Pecker Law’ which should give our American friends a good laugh).