TL;DR
On this page
A UK freelance bookkeeper taking on the payroll for a 15-employee agency has just become a GDPR data processor for the personal data of fifteen people, and the fear that comes with it is rational: if that data is breached, who pays? The instinct that "I'm only the bookkeeper, the agency owns the data" used to offer some comfort. After the regulator's first direct fine against a processor, it no longer does. The protection now comes from the contract, specifically three clauses that generic bookkeeping templates leave out.
pro tip
Processing a client's data makes you a GDPR data processor, and a processor can be sued directly and fined. A freelance bookkeeper contract needs a full Article 28 data processing agreement (attached as a schedule), a liability cap that limits exposure to the fees paid and excludes consequential loss, and a bad-data indemnity that shifts liability back to the client when the client supplies inaccurate records. Together they convert an open-ended risk into a bounded one.
This is the contract layer above the bookkeeper engagement letter, which sells and scopes the work. The fee that anchors the liability cap is in the 2026 bookkeeper rates report, the retainer billing is in the bookkeeper invoice template, and the general foundation is in freelance contract essentials.
You are a processor, and you can be sued directly · The full data processing agreement · The liability cap · The bad-data indemnity · Controller vs processor liability
You Are a Processor, and You Can Be Sued Directly
When you process a client's personal data on their instructions, the client is the data controller and you are their processor. Per DPO Associates, in payroll work "the accountant is the processor of the personal data it receives from the controller." That role used to feel low-risk, because liability seemed to sit with the controller. GDPR says otherwise.
Per Article 82 GDPR, retained in UK law as the UK GDPR, "any person who has suffered material or non-material damage as a result of an infringement of this Regulation shall have the right to receive compensation from the controller or processor for the damage suffered." A processor is directly liable in two situations: per Article 82(2), "where it has not complied with obligations of this Regulation specifically directed to processors or where it has acted outside or contrary to lawful instructions of the controller." The only escape is Article 82(3): a processor "shall be exempt from liability ... if it proves that it is not in any way responsible for the event giving rise to the damage."
Enforcement is now live against processors. Per Ashfords, in April 2025 "the ICO has issued a landmark fine of £3.07 million to Advanced [Computer Software Group Ltd]," and "this is the first time the ICO has directly fined a data processor under UK General Data Protection Regulation." The fine, reduced from a provisional £6.09 million, followed a ransomware attack linked to "gaps in its deployment of multi-factor authentication." Advanced is a large IT provider, not a solo bookkeeper, but the principle it establishes applies to every processor: the regulator will pursue you in your own right. That is the backdrop the next three clauses are written against.
The Full Data Processing Agreement
The engagement letter can reference data protection in passing. The contract should attach a full data processing agreement (DPA) as a schedule, because the law requires the relationship to be governed by a binding contract with specific contents. Per Article 28 GDPR, "processing by a processor shall be governed by a contract or other legal act ... that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller."
A bookkeeping DPA schedule should record, at minimum:
- The processing details: subject matter (for example, payroll administration), duration, nature and purpose, the type of personal data (names, salaries, national insurance numbers), and the categories of data subjects (the client's employees).
- Instructions-only processing: you process the data only on the client's documented instructions.
- Confidentiality and security: persons authorised to process the data are bound to confidentiality, and you take appropriate security measures.
- Sub-processors: the cloud payroll software and any subcontractor you use are sub-processors, and the DPA must address how they are authorised, because UK GDPR treats them as part of your processing chain.
- Assistance and deletion: you assist the client with data subject requests, and you delete or return the data at the end of the engagement.
The lighter, engagement-letter version of these clauses is in the bookkeeper engagement letter guide; the full schedule is what a larger or data-heavy engagement needs.
The Liability Cap
The DPA defines how you handle the data; the liability cap defines what happens financially if something goes wrong. For a solo bookkeeper, an uncapped liability is the existential clause, because the potential damage from a payroll-data breach across fifteen employees is unbounded while your fee is small.
Per Sprintlaw UK, the standard cap states that "the total liability of the Service Provider for all claims whatsoever arising under or in connection with this contract shall not exceed an amount equal to the fees paid (or payable) to the Service Provider under this contract." Just as important is the consequential-loss exclusion: per Sprintlaw, "neither party shall be liable to the other for any consequential, special, indirect, or punitive damages, or for any loss of profit, revenue, anticipated savings, or business opportunity." That exclusion is what stops a client's downstream losses, a tax penalty, lost revenue from a late filing, from landing on the bookkeeper.
The cap is not unlimited in its protection. Per Sprintlaw, a business-to-business limitation must be reasonable, because "what's fair and reasonable under the Unfair Contract Terms Act (UCTA) ... can override what's on paper." A cap set sensibly relative to the fee and supported by professional indemnity insurance is far more likely to hold than a token figure. Set the cap with reference to the fee in the 2026 bookkeeper rates report, and treat leaving liability uncapped as the contract mistake it is, covered in freelance contract mistakes.
The Bad-Data Indemnity
The cap limits liability for your own errors. The bad-data indemnity addresses errors that are not yours: the client supplies inaccurate or incomplete records, and the consequences flow from that. Accuracy of the source data is the client's responsibility, and the contract should say so.
Per Jetpack Workflow's bookkeeping service agreement, the clause reads: "The Client acknowledges that the accuracy of financial information provided is the sole responsibility of the Client, and the Bookkeeper will be held harmless from any liability resulting from the inaccuracy of the financial records provided by the Client." (Jetpack is a US source; the wording is illustrative, and the principle transfers to a UK contract.) For the losses that flow from bad data, an indemnity makes the allocation explicit. Per FigsFlow, a UK-oriented clause states that the "Client agrees to indemnify and hold harmless Accountant for direct financial losses, including reasonable legal fees, arising from the Client's failure to provide accurate financial records."
The indemnity is the mirror image of the liability cap: the cap stops your mistakes from sinking you, and the indemnity stops the client's mistakes from being charged to you. Both are needed, because a bookkeeping engagement runs on data the client controls and the bookkeeper merely processes.
Controller vs Processor Liability
The clean way to think about the whole liability architecture is the controller-processor split. The client, as controller, determines what data is processed and is responsible for its accuracy and lawful basis. You, as processor, are responsible for how you handle it: security, confidentiality, following instructions. Per DPO Associates, the distinction turns on who "determines the purpose and means" of the processing, which for routine bookkeeping is the client.
That split is what the contract operationalizes. The DPA binds you to your processor duties; the liability cap bounds what your breach of those duties can cost; and the bad-data indemnity returns the controller's responsibilities, chiefly data accuracy, to the controller. Note one trap: if you step outside the client's instructions, Article 82 treats you as liable in your own right, and you can lose the protection of acting "only" as a processor. Stay within the documented instructions, and the architecture holds. The general IP-and-liability allocation framing for freelancers is in the freelancer IP ownership guide.
Copy-Paste Clause Checklist
Bookkeeper contract data-liability checklist
Build the full contract with these clauses in the free FreelanceDesk contract generator, and pair it with the engagement letter from the bookkeeper proposal guide.
References
- Article 82 GDPR: Right to Compensation and Liability, GDPR-info.eu
- Article 28 GDPR: Processor, GDPR-info.eu
- ICO Issues Its First Fine Under the UK GDPR Against a Data Processor, Ashfords
- Examples of Limitation of Liability Clauses for Commercial Contracts, Sprintlaw UK
- A Free Bookkeeping Service Agreement Template, Jetpack Workflow
- Indemnity Clauses in Engagement Letters, FigsFlow
- GDPR in Practice: Role of Accountants, DPO Associates