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 - Data Discovery

GDPR Compliance Step-by-Step: Part 2 – Data Discovery

In truth, this should be called Data Discovery & Asset Management, because there’s absolutely no point having one without the other. Nor should these things not already be part of your standard practices.

It’s 2018 and I can think of very few businesses who don’t have data as some of their most critical assets. No businesses bothering to read my blog anyway. So if data assets are that critical, why don’t you already KNOW where all of your personal data is? Why don’t you already have a record of who has access to it, and what they are doing with it?

Assuming yours is like 99.9% of business out there, you don’t have these mappings, and the reasons are as myriad as the business themselves. And maybe it didn’t matter that much up to now, but now it does. Very much so.

Under GDPR you are responsible for:

  1. Determining your lawful basis for processing for each of your separate business processes (both internal and client facing);
  2. Implementation of data subject rights in-line with 1. (erasure, portability etc.);
  3. Data minimisation (during collection and data retention);
  4. Data confidentiality, integrity, and availability (all to defensible levels);
  5. ‘Legitimising’ all transfers of, and responsibilities for, data to third parties

…and so on.

How exactly can you perform any of these things if you don’t KNOW what you have and where it is?

So assuming you agree with me so far and you need to get started, you have 3 choices:

  1. Run a series of interviews and questionnaires with all unique departmental stakeholders to manually track this stuff;
  2. Run some form of data discovery technology to find the data on end systems / databases / other file stores etc.; or
  3. Do both at the same time

Clearly 3. is the best option because a) you’ll need to involve the departmental stakeholders anyway, and b) no manual process will ever find the stuff you had no idea was even there (which will be a lot).

While I’m not going to go into step-by-step instructions on how to run the two main processes above – which are bespoke to each business – I will provide sufficient guidance for you to ask the right people the right questions:

Interviews and Questionnaires

At a bare minimum, you will need to collect this information from the non-IT departmental verticals (HR, Sales, Finance etc.):

  1. All categories of data received (name, phone number, home address etc.) both ‘direct’ and ‘ancillary’;
    i. Direct Personal Data (DPD, my term) is any data that by itself can determine the data subject – e.g. name, email address, mobile phone number, passport number etc.
    ii. Ancillary Personal Data (APD, again, my term) is any data that in and of itself cannot be used to determine the data subject, but a combination of APDs may do so. Or the loss of this data along with the related DPD would make the breach significantly worse – e.g. salary, disciplinary actions, bonus payments, disability etc.;
  2. In which application, database, file store etc. this data is kept – not looking for mappings down to the asset tag, just a general understanding;
  3. Data retention related to each business process – e.g. all data categories related to the ‘payroll’ process must be retained for x years post termination;
  4. List of third parties – if applicable, from whom do you receive the relevant categories of data, and to whom do you share them;
  5. Other – Ideally you should also be able to determine, per business process, whether; a) you are the controller or processor for each data category, and b) the data category is ‘mandatory’ (process won’t work without it) or ‘non-mandatory (nice-to-have)

Assuming the non-IT stakeholders cannot answer the below questions, you will need to speak to those who can (from IT, InfoSec, relevant third parties etc.):

  1. Location of data sources – physical location, including end-system (e.g. host name of server, AWS instance ID, etc.), data centre, address and country;
  2. Format of data – e.g. ‘structured’ (databases, spreadsheets, tables etc.), and ‘unstructured’ (Word documents, PDFs, photos, etc.)
  3. Data ownership – someone has to be responsible;
  4. Security controls – e.g. encryption / anonymisation / pseudonymisation, and everything related to ISO 27001/NIST et al;
  5. Network and data flow diagrams – a ‘baseline’ of how personal data should flow in your environment

Data Discovery

I’m really not sure how the phrase ‘data discovery’ got lumped together with ‘business intelligence’, but that’s the way it seems on Google at least. And no matter which data discovery technology vendor you ask, they can all provide everything you need for GDPR compliance.

For those of you who remember the PCI DSS v1.0 way back in December 2004, you will also remember the disgusting land-grab of every vendor whose technology or managed services fulfilled one of the 12 requirements. You will also remember the even more disgusting price-hikes by those technology vendors, especially by Tripwire whom Visa was dumb enough to list as an ‘example’ of file integrity monitoring.

So guess what’s happening now? Because every data protection regulation requires you to know what data you have, data discovery vendors are crawling all over each other to push their wares down your throat.

But all data discovery tools are not the same, and unless you can fully define what results YOU need from one, stick to the manual process until you do. These are a few of the questions to which you need answers:

  1. Do I need a permanent solution, or can a one-time, consultant-led, discovery exercise suffice for now?;
  2. Should the solution be installed locally on self-installed server(s), an appliance, cloud-based?;
  3. Can the solution perform discovery on end-systems, databases, AND traffic ‘on-the-wire’?;
  4. How will the solution manage encrypted files / databases / network protocols?;
  5. Does the solution need to accommodate Cloud-based environments?;
  6. Do I need an agent, or agent-less solution?;
  7. Should the solution be able to perform network discovery (NMAP-esque) and some semblance of asset management to guarantee coverage?;
  8. Do you need data-flow mapping as well?;
  9. Should the solution be integrated with some form of compliance management tool?;
  10. Is this solution to be self-managed or outsourced?

…and the list goes on.

As I’ve stated many times over the almost 5 years I’ve been blogging; “No technology can fix a broken process, it can only make a good process better”. Data discovery is no different, and its many and very significant benefits will only be realised when you ask the right questions.

Don’t know the right questions? Find someone who does.

[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!]

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;