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:


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