Lawful Basis for Processing

GDPR: Getting to the Lawful Basis for Processing

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:

  1. 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;
  2. Communications Channels – e.g. phone, email, fax, snail-mail etc;
  3. 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);
  4. 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:

  1. Functional Responsibility – Who manages the data source(s), internal resources or outsourced third party(ies)?;
  2. 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;
  3. Data Source Format – e.g. database, flat file, email, pdf etc. This has implications for security safeguards;
  4. 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:

  1. 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);
  2. 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);
  3. 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;
  4. Responsibility – are you the Controller, Joint Controller, or a Processor? The lawyer will likely make this determination for you anyway;
  5. 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:

  1. 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;
  2. Categories of Individual;
  3. Categories of Personal Data; and
  4. 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:

  1. Develop a complete set of relevant data protection policies and standards to adequately demonstrate that the organisation is demonstrating accountability (Art. 5(2));
  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“.
  3. Third parties will require a Data Processing Agreement (DPA);
  4. Ensure that the contracts in place with third party data sources include guarantees that the data was collected fairly and lawfully;
  5. 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; 
  6. 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;
  7. Perform a Legitimate Interest Assessment (LIA) to ensure that the organisation’s interests are appropriately “balanced against the individual’s interests, rights and freedoms“;
  8. Perform a Data Protection Impact Assessment (DPIA) if necessary;
  9. Add contingencies for variances in national laws if applicable;
  10. 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!]

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:

o

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