Accounting firms handle some of the most sensitive personal data that exists outside of healthcare: full names, addresses, National Insurance numbers, bank details, salary and payroll records, tax history, and in many cases information about a client's spouse, children, or business partners. Under UK GDPR and the Data Protection Act 2018, almost every UK accounting or bookkeeping practice is processing personal data at a scale and sensitivity that puts real legal obligations on the firm, regardless of how small it is.
This post is not about secure file-sharing habits or which platform to use for document exchange. We've covered the operational side of secure file sharing in detail elsewhere. This post is about the legal obligations themselves: what the law actually requires a UK accounting firm to do, register, and be ready to prove, independent of which tools you use to do it.
Are You a Controller or a Processor? It Changes Your Obligations
The first question UK GDPR asks is not "do you have good security" but "what is your role in relation to this data." As the ICAEW's own guidance to members puts it, firms need to "determine whether they are acting as a data processor or data controller under UK GDPR" — and the answer is not always obvious, and can change engagement by engagement.
A data controller decides why and how personal data is processed. For most client relationships — preparing accounts, filing tax returns, advising on structure — the accounting firm is the controller. It decides what data it needs, how long to hold it, and what it's used for. Controllers carry the primary legal burden: independent compliance obligations, exposure to regulatory enforcement, and in higher-risk cases a duty to carry out a Data Protection Impact Assessment.
A data processor acts only on someone else's instructions — for example, if a firm is contracted purely to run payroll exactly as instructed by a client who retains all the decision-making authority over that data. Processors have narrower, contractually-defined obligations, but they don't get to hide behind the controller when something goes wrong.
Most accounting firms are controllers for the bulk of what they do, and this needs to be reflected in three places that often lag behind reality: the engagement letter (which should say plainly what data is being processed and in what capacity), the contracts with any software vendor the firm uses to store or move client data (where the vendor is typically the processor and the firm remains the controller), and the firm's own privacy notice to clients. If none of these documents currently say anything about data protection roles, that's a gap worth closing before it becomes someone else's question to ask during an ICO enquiry.
The ICO Registration Fee Most Firms Don't Realise They Owe
Here's the part that catches firms off guard: registering with the Information Commissioner's Office and paying the data protection fee is a separate legal requirement from having good data practices. Processing personal data electronically for business purposes generally requires paying this fee — it isn't optional, and it isn't the same thing as being GDPR-compliant. A firm can pay the fee and still be non-compliant in practice, or (more commonly) simply forget the fee exists because "compliance" gets treated as a single bucket.
Per the ICO's own fee guidance, the fee is tiered by staff numbers and turnover:
Tier 1 (micro): £52 a year — organisations with a maximum turnover of £632,000, or up to 10 staff
Tier 2 (small and medium): £78 a year — up to £36 million turnover, or up to 250 staff
Tier 3 (large): £3,763 a year — anything larger than Tier 2
The overwhelming majority of accounting and bookkeeping practices fall into Tier 1 or Tier 2, meaning the actual fee is small — but failing to register at all is what triggers enforcement action, not the size of the fee. If your firm has never explicitly registered, it's worth five minutes to check, because "we're too small for anyone to notice" is not a defence the ICO accepts.
The 72-Hour Clock: What Actually Triggers a Reportable Breach
Every accounting firm should know this number, and most can't state it precisely: under UK GDPR, a notifiable personal data breach must be reported to the ICO within 72 hours of the organisation becoming aware of it — not 72 hours from when the breach happened, from when you knew. The ICO's own breach guidance is clear that this clock starts the moment awareness exists, which means a firm without any internal process for spotting and escalating an incident quickly is already losing time it doesn't have.
Want to see how this works in practice? Explore Osuria’s client portal
Not every incident is reportable. The trigger is whether the breach is likely to result in a risk to individuals' rights and freedoms — and for an accounting firm, a breach involving client bank details, tax records, or payroll data will very often clear that bar, given the direct financial and identity-fraud implications. If the firm decides a breach doesn't meet the threshold, that decision needs to be documented and justified, not just assumed.
Separately, if a breach is likely to result in high risk to individuals, the firm also has to notify the affected people directly and without undue delay — not just the regulator. That notification needs to explain, in plain terms, what happened, the likely consequences, what the firm is doing about it, and what the client should do to protect themselves. Firms that have never drafted a breach notification template, even a rough one, are effectively planning to write it from scratch under time pressure, during the exact week client trust is most fragile.
The Retention Paradox: HMRC Says Keep It, GDPR Says Don't Keep It Too Long
This is the tension that catches even careful firms, because two entirely legitimate legal obligations point in slightly different directions.
On one side, statutory retention rules require firms to keep certain records for years. Self-employed clients must keep business records for at least five years after the 31 January filing deadline of the relevant tax year, per HMRC's own guidance — so a 2024–25 return filed by 31 January 2026 means records need to be retained until the end of January 2031. Limited companies have a longer obligation: six years from the end of the company's last financial year, with that period extending further if HMRC opens an enquiry or the accounts touch a longer-lived asset or a multi-year transaction.
On the other side, UK GDPR's storage limitation principle says personal data should not be kept for longer than is necessary for the purpose it was collected for. Six years of statutory retention is a legitimate purpose and a lawful basis for keeping that data — the tension isn't that the two rules conflict, it's that firms rarely have a documented policy that ties the two together. Without one, "necessary" quietly becomes "however long it happens to sit in an inbox or a shared drive," which is exactly the kind of indefinite, undocumented retention that turns into a liability the moment a client asks what happens to their data after an engagement ends, or a regulator asks the same question less politely.
A workable retention policy for an accounting firm generally means: knowing which records are subject to a statutory retention period and for how long, deleting or anonymising personal data that falls outside any statutory requirement once the engagement's purpose is served, and being able to point to where a given client's data actually lives so "delete after X years" is something the firm can actually execute, not just a line in a policy document nobody can action. That last part is a structural problem as much as a policy one — data scattered across personal inboxes, downloads folders, and forgotten shared drives can't be reliably found, let alone deleted, when a retention period ends.
What This Means Operationally
None of the above is solved by buying software — registration, breach response ownership, and a documented retention policy are decisions a firm has to make regardless of what tools it uses. But the practical difficulty of executing good data protection consistently does scale with how fragmented a firm's client data is. A firm that can see, for any client, exactly what documents exist, where they live, and who has accessed them is in a fundamentally better position to answer an ICO enquiry, action a retention policy, or investigate a suspected breach within the 72-hour window than a firm reconstructing the picture from email threads, WhatsApp messages, and five different shared drives after the fact.
This is the connection between data protection law and the case for a centralised, branded client workspace: not that a platform makes a firm compliant on its own, but that centralising client communication and files into one structured, access-controlled environment gives a firm the traceability and auditability that compliance work actually depends on — the same underlying structure that also, separately, saves the firm time and improves the client experience.
Getting the Fundamentals Right
Treat this as a short checklist rather than a project: confirm whether the firm is registered with the ICO and paying the correct fee tier; make sure engagement letters and vendor contracts actually state the firm's role as controller or processor; write down — even briefly — what counts as a reportable breach and who owns that decision internally; and document a retention approach that reconciles HMRC's and Companies House's statutory minimums with GDPR's requirement not to keep personal data indefinitely. None of this requires new software. All of it becomes considerably easier to execute when client data isn't scattered across a dozen uncoordinated channels.
None of this is a substitute for proper legal advice on your firm's specific obligations. But if bringing client communication and files into one secure, branded digital workspace would make the underlying accountability easier to maintain, explore the Digital Workspace or start using Osuria to see how a centralized client workspace fits alongside the compliance work you already have to do.