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.
    o
  • 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;
    o
  2. Category of Personal Data‘ – e.g. Contact Data, Salary Data, Performance Data and so on;
    o
  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;
    o
  4. Responsibility‘ – Is your organisation the Controller, Joint Controller, or Processor?;
    o
  5. Data Type‘ – Direct, Indirect, Special Category etc.; and
    o
  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;
    o
  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;
    o
  3. Data Type‘ – database, flat-file (e.g. spreadsheet), application export and so on; and
    o
  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;
    o
  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;
    o
  3. Outputs to Third Parties‘ – Does the output of your business process go to third parties? if yes, to whom?;
    o
  4. Outputs to Third Countries‘ – Does the output of your business process go to third countries? If yes, to where?; and
    o
  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!]