Necessary for the Business vs Necessary in Data Protection Law
Organisations often say they need personal data because their process or product won't work without it, but this necessity isn’t always the same as that in data protection law. This post explains the gap between the two, how it shows up in practice, and three questions to test whether your processing is necessary in law.
@honza_kahanek on Unsplash
“But We Need It”
A choice is not a need.
Where an organisation says a process won’t work without certain data, it is right about its own setup, but the law is asking a different question. The question is, is there a reasonable, less intrusive way to achieve your goal?
If the answer is no – business and data protection necessity align. (But remember that is the start of the analysis, not the end: you still need a lawful basis and, for special category data, a condition.)
If the answer is yes – it is not necessary in the eyes of the UK GDPR.
Necessary under Data Protection Law
Legal necessity here is described in case law and guidance, so I will leave you with quotes from the horse’s mouth.
It is:
More than useful or convenient, but not absolutely essential either, i.e. “reasonably necessary”:
“… [N]ecessity is well established in community law [when the UK was still an EU member] as part of the proportionality test. […] Indeed, in ordinary language we would understand that a measure would not be necessary if the legitimate aim could be achieved by something less.”*
In the same spirit, the Information Commission says that you cannot rely on how you have chosen to run your business:
“It is not enough to argue that handling the personal information is necessary because you operate your business in a particular way. The question is whether the use of personal information is objectively necessary for your stated purpose, not if it’s a necessary part of your chosen methods.“**
Necessary for the Business
I understand the pain of different teams where necessary for the business isn’t the same as legal necessity. It’s a conversation I am sure many DPOs have had.
Necessity for the business usually means: “We can’t do it our way without this data.” It describes how things are built, not whether they had to be built that way.
When you designed the process yourself, the data feels necessary because the process depends on it; but you chose the process.
Take Serco Leisure as an example:
They decided biometric clocking in was operationally needed…
… yet fobs and ID cards, as the less intrusive methods, would have done the job just as well.
The ICO (at the time) found Serco had not shown why fobs or ID cards wouldn’t do the job, so the biometric processing was not necessary or proportionate.***
When the product you bought needs the data, the tool can’t work without the data, so the necessity looks built in. The question is whether you need that method for your goal, not whether the vendor’s product needs the data. For example:
An employer buys a productivity platform that takes regular screenshots of staff screens.
The tool needs screenshots to function, but the employer’s goal of knowing work is getting done can usually be met through task tracking, output and line management.
Therefore, screenshots are unlikely to be necessary under data protection law.
Compare and contrast with:
An online retailer buys a facial age estimation tool to confirm customers are over 18.
The tool needs a facial image to work, but that only settles the vendor’s necessity, not the retailer’s.
The retailer still has to compare it with the alternatives. Here the tool may well win: uploading an ID document reveals far more, and some estimation tools delete the image straight away.
The test isn’t that bought-in tools fail, but that the retailer must do the comparison itself.
Query Necessity Early On
Both scenarios come down to the same mistake: a choice treated as a need. Whether you designed the process or bought the product, the processing must be necessary for your purpose, not just for your chosen method.
The practical point is timing. Necessity is decided at the design or procurement stage.
Questions you can ask:
What are we actually trying to achieve, without naming the process or the product?
Is there a less intrusive way to get there?
If we’re not using the less intrusive option, can we show why it wouldn’t work?
Ask those questions before the contract is signed or the system is built, and document the answers. It is far easier to choose the less intrusive option at the start than to ask colleagues to re-do later, or explain to a regulator why you didn’t.
* South Lanarkshire Council v Scottish Information Commissioner [2013] UKSC 55, para 27 (Lady Hale)
** https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/a-guide-to-lawful-basis/#Necessary accessed 16.10.2026
*** https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2024/02/ico-orders-serco-leisure-to-stop-using-facial-recognition-technology/ accessed 18.10.2026