Data protection clauses for small business contracts

Why data protection clauses belong in everyday contracts

If your business touches other people's information — a client's customer list, a subcontractor's payroll details, a mailing list — you are handling personal data. Under the UK GDPR and the Data Protection Act 2018, that comes with obligations. What surprises many sole traders and small firms is how much of those obligations can be pinned down, in advance, in the contract itself.

Good data protection clauses do three things. They make clear who is responsible for what. They force you to think through your own processes before something goes wrong. And they give you something concrete to point at if a client, a customer, or the Information Commissioner's Office asks awkward questions later. Vague assurances are not enough — the law expects specifics, and so should your contracts.

Say who is the controller and who is the processor

Start by defining roles. A controller decides why and how personal data is used. A processor acts on the controller's instructions. Many small businesses are both, depending on the deal. If you run a marketing agency handling a client's mailing list, you are usually the processor for that data and the controller for your own client contact records.

If you are a processor, Article 28 of the UK GDPR requires a written contract containing certain terms. In practice, include clauses that:

• state that you will only process the data on the controller's documented instructions;
• require confidentiality from anyone you allow to access the data;
• cover your security obligations and any sub-processors, including how you get consent to use them;
• require you to help the controller respond to individual rights requests, such as subject access requests;
• set out what happens to the data when the contract ends — deletion or return.

If you are the controller, you still want clarity. Spell out what you will do with the data, and make sure the client is not quietly expecting you to do something else.

Name your lawful basis, plainly

Every processing activity needs a lawful basis. The common ones are consent, contract, legal obligation, vital interests, public task, and legitimate interests. Rather than dropping a single line saying "we rely on legitimate interests", link each purpose to a basis.

For example: "We process your contact details to perform the services under this agreement (contract), and to send occasional service updates (legitimate interests). We will not use your data for third-party marketing without your consent."

That level of detail is short, readable, and defensible. It also helps you spot problems early — if you cannot name a basis for a particular use, you probably should not be doing it. If special category data is involved, such as health information, say so and identify the additional condition you rely on.

Security measures: be specific, not reassuring

"Appropriate technical and organisational measures" is the phrase in the legislation, but it is a poor clause on its own. Clients and auditors want to know what you actually do. Write down the measures that are genuinely in place, and do not promise more than you can deliver.

• encryption of data at rest and in transit;
• access controls, unique accounts, and multi-factor authentication;
• staff training and confidentiality undertakings;
• device management and patching routines;
• backups, and how restoration is tested;
• physical security for paper records and hardware.

Keep the list honest. A clause promising enterprise-grade controls that a two-person business cannot maintain is a liability, not a comfort. It is perfectly acceptable to say that measures will be reviewed periodically and may be updated, provided the standard never drops below what the law requires.

Retention periods and what happens at the end

Data should not be kept indefinitely "just in case". Your contract should state how long each category of data is held, or the criteria used to decide. For instance: "Client project files are retained for six years from the end of the contract to meet accounting and limitation requirements. Marketing consent records are retained until consent is withdrawn."

Then deal with the ending. When the engagement finishes, will you delete the data, return it, or both? Who confirms the deletion, and within what timescale? Where data sits in backups that cannot be selectively edited, say so, and explain that it will be deleted on the normal backup cycle. Ambiguity here causes more disputes than almost anything else.

Breach procedures and who tells whom

A personal data breach is any security incident leading to accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of personal data. Not every breach needs reporting to the ICO, but you cannot make that judgement if nobody notices.

Build a notification chain into the contract. If you are a processor, you should tell the controller without undue delay after becoming aware of a breach — often within 24 or 48 hours by agreement, so the controller can meet its own 72-hour reporting deadline. Include what information you will provide: what happened, the categories and approximate number of individuals affected, likely consequences, and the measures taken.

Internally, name a person responsible for breach handling and keep a simple log. Regulators look favourably on businesses that can show a documented process, even when something has gone wrong.

A short checklist before you sign

Before any contract goes out, run through these points:

• Are controller and processor roles stated clearly?
• Is each processing purpose matched to a lawful basis?
• Are sub-processors named, or is the approval process described?
• Are security measures specific and accurate?
• Are retention periods and end-of-contract actions defined?
• Is there a breach notification route and timescale?
• If data leaves the UK, is the transfer mechanism identified?

None of this needs to be intimidating. A few well-drafted paragraphs, reviewed when your processes change, will serve you far better than a template copied from elsewhere. If a client sends you their own data processing agreement, read it against the list above — and push back on anything you cannot honestly deliver. Getting this right is not just compliance; it is how you build the kind of trust that keeps good clients coming back.