What UK GDPR asks of you that a shared spreadsheet cannot do.

A shared spreadsheet has one access level: open it or do not. Everyone who can see the file can see every row — including leads assigned to other people, notes about clients they do not work on, and whatever historical data has accumulated at the bottom of the sheet since the file was created.

Article 5(1)(f) requires personal data to be processed in a way that ensures appropriate security, and Article 32 asks you to put technical and organisational measures in place that are appropriate to the risk. Neither names a specific technology. Both are usually satisfied by being able to say who can see what, and to change it. A shared file gives you one lever, and it is the wrong size.

The second problem is that link sharing propagates quietly. A file set to "anyone with the link" is outside your control the moment that link is forwarded, and you cannot tell from the file who currently holds it. If you cannot answer "who has access to this data today", you cannot demonstrate that your access controls are appropriate.

Article 17 gives individuals the right to have their personal data erased in defined circumstances. In a spreadsheet, the response looks simple: find the row, delete it. The difficulty is that the row is rarely the only copy.

Exported versions sit in downloads folders. An older file named something like leads-master-final sits on a laptop belonging to someone who left last year. Cloud storage may retain earlier versions of the file that still contain the deleted row, depending on how it is configured. A copy was pasted into an email to a freelancer in March. Deleting the live row addresses one of these and leaves the rest.

Article 5(2) adds a second requirement that is easy to overlook: you must be able to demonstrate compliance, not simply achieve it. A deleted spreadsheet row leaves no evidence that the record existed, that a request was made, or that you acted on it. If the same person contacts the ICO three months later, you have nothing to show.

Anyone whose data you hold can ask what you hold about them, and you must respond within one month. The deadline runs from receipt, not from the point at which someone notices the email, and a request does not have to use the words "subject access request" to count.

The work is rarely in the main sheet. Personal data about one lead is typically spread across the current file, an older file nobody deleted, a notes column, an email thread and a phone belonging to whoever handled the enquiry. Assembling all of it under a fixed deadline is a manual search of every place a colleague might reasonably have put something.

There is also a redaction problem. You cannot simply export the sheet, because it contains other people's personal data, and disclosing that would be its own breach. You have to extract one person's records and read the free-text notes for references to third parties. Those notes are disclosable, which is worth remembering before anyone types an opinion about a lead into a cell.

These are separate questions and satisfying one does not satisfy the other. Article 6 asks what your lawful basis is for processing the data at all; consent is one of six bases, and for ordinary business-to-business lead handling legitimate interests is often the more appropriate one. PECR regulation 22 is a different rule governing unsolicited direct marketing sent by electronic mail, which includes email and SMS, and it generally requires consent — subject to a limited exception within the same regulation for existing customers being marketed similar products or services.

You can have a sound lawful basis under Article 6 and still be sending messages you are not permitted to send under PECR. The two are assessed independently, and the second one is the one that generates complaints.

Where you do rely on consent, you need to be able to show who gave it, when, and to what wording. A spreadsheet column containing "Yes" records a conclusion rather than evidence. It does not capture the text the person actually agreed to, the date, or the source of the enquiry, and it can be changed afterwards by anyone with the file open, leaving no trace that it ever said something else.

Article 33 requires certain personal data breaches to be reported to the ICO without undue delay and, where feasible, no later than 72 hours after you become aware of them. Not every breach is reportable — the test is whether it is likely to result in a risk to people's rights and freedoms — but you can only make that judgement if you can see what happened.

Spreadsheets rarely produce the moment of awareness that starts the clock. There is no access log. A file attached to the wrong email, or downloaded in full by someone working their notice period, generates no signal at all. Many small businesses find out because the person affected tells them.

The second difficulty is scoping. A report has to describe the categories and approximate number of people and records concerned. If a file left the business six weeks ago, you need to know which version it was and how many rows it held at that point. With a spreadsheet that is edited continuously and never versioned deliberately, that question often has no answer.

Under section 170 of the Data Protection Act 2018 it is a criminal offence to knowingly or recklessly obtain, disclose or retain personal data without the consent of the controller. An employee who keeps a copy of the client list after leaving is potentially committing an offence in their own right.

That is worth knowing, and it is worth saying plainly that it is unlikely to help you. Prosecutions under section 170 do happen but they are uncommon, they are brought against the individual rather than compensating you, and they are not a realistic remedy for a small business that has lost its lead list to a departing salesperson.

Your own obligation is the one in Article 32: having measures in place that make this harder. Revoking access to a shared file on someone's last day does nothing about the copy they took in March, and in most cases you will not know a copy was taken. The practical difference a system makes here is not that it prevents exports, but that it records them.

Article 30 requires controllers to maintain a record of their processing activities: the purposes, the categories of people and data involved, who the data is shared with, retention periods where possible, and a general description of security measures. It is a document about your business, not a feature of your software.

Article 30(5) appears to remove this obligation for organisations below a small-organisation employee threshold, and a lot of businesses stop reading there. The conditions are cumulative. The exemption applies only where the processing is occasional, is unlikely to result in a risk to people's rights and freedoms, and does not involve special category data or criminal offence data.

Routine lead management is not occasional. If you are capturing enquiries continuously as a normal part of trading, the processing is by definition regular, and the exemption does not apply regardless of how few people you employ. The record is still yours to write — but what a proper system gives you is accurate answers to the questions it asks, rather than a reconstruction from memory.