Which customer data you may store — and which needs its own basis

A small business collects customer data not out of curiosity but because the business does not run without it. An appointment needs a name and a number, an invoice an address, the second treatment the result of the first. The General Data Protection Regulation forbids none of that. It only requires that you can say, for every entry, what it is there for.

Everything else hangs on that: the purpose decides the legal basis, the basis decides the retention, and together they decide whether a note is a harmless memory aid or a category of data with stricter rules. This article sorts that into three buckets and shows with one example where the line runs. It is orientation — your particular case is for your supervisory authority or a lawyer.

Article 5 GDPR puts six principles at the front, three of which concern you every day. Purpose limitation: data is collected for specified, explicit purposes and not further processed in a way incompatible with them. Data minimisation: only what is necessary for that purpose. Storage limitation: only for as long as the purpose supports.

To that add Article 6(1) GDPR with the list of grounds that make a processing operation lawful at all. For a service business four of them matter: performance of a contract including pre-contractual steps (point b), compliance with a legal obligation (point c), legitimate interests (point f) and consent (point a). In practice, consent most often turns up exactly where it was not needed.

That is more than taxonomy. Store an appointment only because consent was given, and you have no basis the moment the consent is withdrawn — even though the appointment is needed for the service itself. Conversely, the contract does not carry the newsletter, however warm the relationship. The legal basis follows the purpose, not convenience. And it cannot be swapped afterwards when the first turns out not to fit.

Sort your customer file into three buckets once. The exercise takes half an hour and then answers most individual questions by itself. Only the second is not yours to decide — there, the retention period for that kind of record sets the length.

The third bucket makes the work, not because it is forbidden but because it arises without a decision. A “birthday” field gets created because the software offers one; three years later nobody remembers whether it was for the greeting or an age check. Both are permissible — on different bases, with different periods.

One particularity belongs to that third row and takes a decision off your hands: against processing for direct marketing, any person may object at any time under Article 21(2) GDPR. No reason, no balancing. Such an objection is not a request you weigh, it is the end of that processing.

This is where the theory is decided. You write a note against the appointment — three versions, three legal situations:

• “Colour 7.3, 40 minutes development time” — a statement about the service. Contract, unproblematic.
• “Look at the rear brakes at the next appointment” — a statement about the thing, not about the person. Also unproblematic.
• “Scalp irritated, intolerant of ammonia” — a statement about health. And therefore a different article of the Regulation.

Article 9(1) GDPR prohibits in principle the processing of special categories of personal data; health data is named expressly. Article 4(15) defines it as data revealing information about a person's state of health, and Recital 35 takes that deliberately widely, including information arising in the course of providing a service.

The prohibition is not the end but the beginning. Article 9(2)(a) lifts it where the person has given explicit consent. “Explicit” demands more here than elsewhere: a conscious, named agreement to this entry, not a tick under general terms. In practice that is no great effort — one line on the intake form saying that the information is voluntary, what it will be used for, and that it can be withdrawn at any time.

The same line catches the note about a child (“no latex”), the dietary detail for a celebration and the note about limited mobility. The test is always the same: does this say something about the state of the person, or about the service? Where you cannot answer with certainty, treat it as a health record. That is the cheaper direction in which to be wrong.

Data minimisation sounds like going without and is in truth a way of making less work. Every field that exists gets filled at some point; every filled entry has to be maintained, named in an access request and eventually deleted. The cheapest moment to be rid of a piece of data is before it exists.

Three questions before every new field:

1. What do I do differently if something is written here? If the answer is “nothing”, you do not need the field.
2. Would something coarser do? “Over 18: yes” instead of a date of birth. “Prefers mornings” instead of somebody's working hours.
3. Who in the business has to see it? A treatment note belongs to whoever does the treatment — not on a screen at the till where the next customer reads along.

The third question has to be answered by the software, not by discipline. Where appointments, notes and invoices sit in one system, separating by role is a setting; where they are spread across paper slips, a wall calendar and a spreadsheet, it stays an intention. What that looks like for a salon is shown by the salon software, for a garage by the workshop software. The question stays the same whichever tool you pick.

The three buckets turn into one overview, and that overview is already the core of what Article 30 GDPR requires as a record of processing activities: purposes, categories of data and of data subjects, recipients, envisaged deletion periods, and a general description of the technical and organisational measures.

Article 30(5) contains an exemption for organisations with fewer than 250 employees — which in practice almost never applies. It falls away as soon as the processing is likely to result in a risk to the rights and freedoms of data subjects, as soon as it is not occasional, or as soon as special categories under Article 9 are processed. A live customer file is not occasional processing. Anyone relying on the exemption relies as a rule on a criterion their business does not meet.

The good news: the record is not a legal opinion. A table with one row per processing operation — appointment booking, invoicing, newsletter, job applications, CCTV if you have it — meets the requirement. It is kept in writing, electronic form is enough (Article 30(3)), and it goes to the supervisory authority only on request (paragraph 4).

A data protection officer does not follow from any of that. Article 37(1) requires one in three cases that typically do not apply to a small service business: a public authority, large-scale systematic monitoring as a core activity, or large-scale processing of special categories as a core activity. National rules can be added on top, and Article 37(4) is what allows that — Germany, for instance, requires one under § 38 of its Federal Data Protection Act from as a rule twenty people who continuously process personal data by automated means. That is a German particularity and expressly not an EU-wide threshold; outside the EU the question is answered by an entirely different law. Look yours up rather than inheriting somebody else's number.