I have made no secret of my distain for organisations and individuals who consider themselves qualified to determine their client’s lawful basis for processing without having the necessary education or experience to do so. Just reading the GDPR a few times and doing some homework (like me), or taking the “Certified” GDPR Practitioner course (or equivalent), does NOT qualify you to talk legal matters with anyone. Don’t try.
On the other hand, a privacy lawyer (or equivalent subject matter expert) is just as likely to be spectacularly unqualified to get the information required to make the legal determinations in the first place. It is even more unlikely that they can manage the project from start to finish. Even if they could, there’s no way they’d be available, or affordable.
So what you end up with is either someone(s) who can only get you most of the way, or someone(s) only able to take you over the finish line.
In reality, getting to the point of, then actually determining the lawful basis, were never a single person’s responsibility. The work necessary in gathering everything ‘legal’ needs is 99% of the effort, requires only very limited data protection knowledge, and done properly, should make retaining a true privacy expert significantly more cost effective. Depending on the size and complexity or your organisation, perhaps even redundant.
In GDPR Compliance Step-by-Step: Part 3 – Process Mapping I spelled out all of the basic information required for a determination of lawful basis, but here I want not only give it some real-world context based on experience, but provide an example of a completed form.
I have developed a spreadsheet that anyone can use to gather all of the information a lawyer would need to not only make a determination of the lawful basis for process, but then give you every action item necessary to get each of your defined business processes GDPR compliant. I call it the ‘Data Inventory / Detailed Process Narrative’ or ‘DI/DPN’ for short. You can download it, and its corresponding instruction manual, here: http://www.davidfroud.com/downloads/
Please take a minute to review…
For the purposes of this exercise, let’s assume that the ‘Business Function’ you’re trying to ‘legalise’ is sales related. We’ll call it “New Client Acquisition” (download completed example here), and these are the steps to follow:
Step 1: Find a person who is best suited to describe, in significant detail, the process you’re trying to justify. In this example it will be someone whose job it is to process the data on a prospective client list received from a third party broker;
Step 2: Shadow this person while they perform the actual function, record all of the following:
- Data Repositories – e.g. spreadsheets, a CRM, network shares and so on. Everywhere the data has touched, or is going to touch at some point. Give them a ‘friendly name’, one everyone uses to refer to that source;
- Communications Channels – e.g. phone, email, fax, snail-mail etc;
- Data Fields Used – e.g. first name, last name, work email, work mobile etc. Record not only the ones actually used, but those that are available, as this has implications later for security safeguards (specifically access control);
- Determine Any Data Outputs – Does the data the salesperson uses then go TO anyone else outside of the organisation for further action?;
Step 3: From relevant departments, gather all of the following ancillary information related to the data repositories, as it’s unlikely the salesperson will either know or care:
- Functional Responsibility – Who manages the data source(s), internal resources or outsourced third party(ies)?;
- Location of the Data – While the location of data should be known to its exact location (it IS an asset), for the purposes of this process a determination of ‘in the EU’ or which ‘third country’ will suffice;
- Data Source Format – e.g. database, flat file, email, pdf etc. This has implications for security safeguards;
- Security Controls (a.k.a. Safeguards) – for the internally controlled data sources, what security controls are in place on the data? e.g. encryption, RBAC, network segmentation etc.;
Step 4: Complete all of the following against every data field in use:
- Category of Individual(s) – Here you will need to have pre-determined exactly what your organisation will use as categories e.g. ‘Employee – Former’, ‘Client – Current’, ‘Third Party’ etc. (See the ‘Metatags‘ tab on the DI/DPN template for an example);
- Category of Personal Data – Again, you will need to have a pre-determined your categories e.g. ‘Core Personal Data’, ‘Contact Data’, ‘Financial Data’ etc. (again, see the ‘Metatags‘ tab);
- Mandatory – What data fields do you absolutely have to have to perform the function? Mark them with a ‘Yes’. If they are just nice-to-haves put ‘No’, and you later will need to either justify their continued use, or get rid of them;
- Responsibility – are you the Controller, Joint Controller, or a Processor? The lawyer will likely make this determination for you anyway;
- Data Type – Directly Identifiable (DID), Indirectly Identifiable (IID), or Sensitive (SPD). While not a hugely important factor, this could have implications down the road if you’re claiming anonymisation of data, or are disclaiming profiling.
Step 5: Complete the Detailed Process Narrative’ tab of the DI/DPN spreadsheet.
While a lot of this is regurgitation from the DI tab, there are several fields you’ll need to populate with the information you’ve collected above. In the end, the only things you absolutely HAVE to provide to get to an initial determination of the lawful basis for processing are the:
- Purpose of Processing and Process Description – it’s critical that these are detailed enough that a lawyer knows exactly what you do to the data, and what result you get from it;
- Categories of Individual;
- Categories of Personal Data; and
- determination of Controller or Processor
Literally everything else is used to get you compliant.
Step 6: Hire an appropriate data protection expert. While I keep using the word ‘lawyer’, there are many data protection experts out there who perfectly capable of getting you to the lawful basis for processing. The issue is that vast majority of the work an expert does is after the determinations are made.
Even I can tell you that in the example above the lawful basis for processing is Article 6(1)(f) – Legitimate Interest, I can even tell you the data subject rights that you now have enable as a result …because a lawyer told me (see Annex A of the DI/DPN Instruction Manual).
What I CAN’T do is everything else:
- Develop a complete set of relevant data protection policies and standards to adequately demonstrate that the organisation is demonstrating accountability (Art. 5(2));
- Data transfers between legal entities under the same corporate umbrella still require some form of “legally binding and enforceable instrument” e.g. an Intra-Company Data Transfer Agreement (ICDTA) using “standard data protection clauses“.
- Third parties will require a Data Processing Agreement (DPA);
- Ensure that the contracts in place with third party data sources include guarantees that the data was collected fairly and lawfully;
- Data transfers to third countries outside of an ‘adequacy’ decision will require either a DTA, binding corporate rules, a Code of Conduct, and/or certification when it becomes available;
- All correspondence to the prospect will need to contain links to an opt-out mechanisms backed by not only an appropriate privacy notice, but all information required by the data subject to exercise their relevant rights;
- Perform a Legitimate Interest Assessment (LIA) to ensure that the organisation’s interests are appropriately “balanced against the individual’s interests, rights and freedoms“;
- Perform a Data Protection Impact Assessment (DPIA) if necessary;
- Add contingencies for variances in national laws if applicable;
- and so on…
And if YOU can’t do that stuff, you need to find someone who can.
Step 6 seems like a lot, but this is a worst case scenario and most qualified experts have an extensive portfolio of templates from which to choose. I am therefore convinced that if you can provide a completed DI/DPN for your relevant business process, the steps to make you fully GDPR compliant are actually very straightforward.
Honestly, there’s really nothing in the first 99% of this process that you should not be doing anyway.
[If you liked this article, please share! Want more like it, subscribe!]