GDPR for small businesses, the realistic version

This article explains terms and common practice. It is not legal advice. For binding statements about your situation, please ask a lawyer.

In small businesses, data protection tends to be either overestimated or ignored. Both cost more than they need to: the first in nerves, the second potentially in money.

The core in three sentences

Personal data is any information by which a person can be identified. Anyone processing such data needs a lawful basis, may process only as much as the purpose requires, and must be able to demonstrate that they are doing so.

The third point is the one that creates work: behaving correctly is not enough. You have to be able to show it.

What almost every business needs

• A record of processing activities. A list of which data is processed for what, how long it stays and who receives it. For a small business that is a manageable table, but it has to exist.
• A privacy policy that matches the actual website. A policy naming services that are not running is as wrong as one that omits services that are.
• Data processing agreements with every provider handling personal data on your behalf: hosting, newsletter tools, appointment booking, often IT support too.
• A route for data subject requests. Anyone asking for access or deletion is entitled to an answer within a clear deadline. Who handles that should be settled in advance.
• A deletion concept. Data may not stay indefinitely. Retention duties from other laws take precedence, and the two have to fit together.

Processing on your behalf, briefly

When a provider processes data on your instructions, you remain responsible. They are a processor, and that requires a contract with defined content: purpose, duration, type of data, technical measures, handling of sub-processors.

Not every provider is a processor. A tax adviser, for instance, processes under their own legal duties and is independently responsible.

Consent is not the default

A common misunderstanding: that everything needs consent. In fact it is only one of several lawful bases, and the least practical one, because it has to be freely given and can be withdrawn at any time.

Performing a contract needs no consent. Non-essential cookies and tracking, on the other hand, do, and beforehand.

Where the mistakes hide

• The cookie banner sets cookies before anyone clicks. Usually because a script is not genuinely blocked.
• "Reject" is hidden. Rejecting has to be as easy as accepting.
• The policy is still a template. Placeholders, or services that are not in use at all.
• Access is not limited. Everyone sees everything because it is easier.
• Legacy data lingers. Applications from 2019, records from a system that was retired.
• No record of processing activities. The single most common finding.

A sensible order

1. Create the record, you need the overview anyway.
2. Collect provider contracts, chase the missing ones.
3. Reconcile the privacy policy with reality.
4. Check the cookie banner technically: does nothing really happen before consent?
5. Set retention periods and clear out legacy data.
6. Name who handles requests.

That is achievable in a well-prepared day and covers the majority of what turns up in practice.