Most accounting firms that have thought about record retention at all have thought about the half that's easy to think about: how long do we have to keep this? That's a reasonable place to start, and the retention periods themselves are genuinely complicated — several different clocks running in parallel, with different trigger dates, for the same client file. But a retention period isn't a one-sided instruction to keep data until a date arrives. Both of the regimes that set those periods also say, explicitly, what has to happen next: the data has to go.
That second half is where most firms' actual practice quietly diverges from their written policy — if they have a written policy at all.
Two Regulations, One Instruction: Delete It
Under UK GDPR's storage limitation principle, personal data can't be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes" it was collected for. The ICO's own guidance is specific about what that means in practice: once data is no longer needed, an organisation should erase it or anonymise it — and critically, merely taking it offline or making it harder to find isn't enough. Data has to be genuinely "put beyond use," and that obligation extends to backups, not just the live system clients and staff actually see day to day. The ICO is equally clear that a written retention schedule, on its own, isn't the compliance step — regularly reviewing what you hold and actually deleting or anonymising what you no longer need is, whether or not a firm has a documented policy at all.
The anti-money-laundering regime is less open to interpretation. Regulation 40 of the Money Laundering Regulations 2017 sets out the records a firm must keep on client due diligence and transactions, and HMRC's own guidance states the deletion obligation directly: personal data obtained under MLR 2017 "must be deleted" once the applicable retention period has expired, unless one of a narrow set of regulation 40(5) exceptions applies — ongoing legal proceedings, a separate legal obligation to retain it, or the customer's own consent to keep it longer. There's no equivalent of "keep it just in case" built into the rule. The regulation that tells a firm to keep AML records for five to ten years is the same regulation that tells it to get rid of them once that period is up.
Put the two together and the position is unambiguous: a firm that keeps every client file indefinitely isn't being cautious. It's failing two separate, specific legal requirements at once — not because retention periods are being violated, but because nothing comes after them.
Why the Deletion Half Gets Skipped
None of this is really a knowledge gap. Most firms that have engaged with their retention obligations at all know, in general terms, that data shouldn't be kept forever. The gap is operational, and it shows up in a predictable place: retention periods are written down in a policy document, often inherited or lightly adapted from a template, while the actual client data lives scattered across email inboxes, shared drives, legacy practice-management exports, and whatever portal the firm was using three systems ago. A policy that says "delete client files five years after the relationship ends" is not self-executing. Someone, or something, has to know which files belong to which client, when that client's relationship actually ended, and then act on that date — across every format the data was ever stored in, including backups the firm may have stopped thinking about years ago.
This is also precisely the moment identified in the offboarding problem most firms underestimate: the MLR2017 clock for CDD and transaction records only starts running when a client relationship ends, which means the deletion obligation is often just beginning exactly when a file otherwise feels closed and forgettable. A firm with no reliable record of when relationships actually ended has no reliable way to know when its deletion obligations under either regime have arrived — which in practice usually means the data simply stays, by default, well past the point the law requires it to be gone.
What "Actually Deleting It" Requires
Want to see how this works in practice? Explore Osuria’s client portal
Doing the deletion half properly requires three things most ad hoc storage setups don't provide.
A trigger a firm can actually detect. Deletion dates aren't calendar dates fixed at the start of a relationship — they're calculated from events (a relationship ending, a tax year closing, a transaction completing) that have to be recorded accurately in the first place. A firm that doesn't reliably record when a client relationship ended can't reliably know when the data from it is due for deletion.
A single place the data actually lives. The ICO's requirement that deletion extend to backups is the detail that breaks most informal setups. If a client's documents exist as attachments scattered across individual staff members' email accounts, copies in a shared drive, and whatever the previous practice-management system exported before the firm switched tools, "delete it" isn't one action — it's an open-ended search with no way to confirm completeness. Centralizing documents and communications in one system doesn't just make day-to-day work easier; it's what makes a deletion request answerable at all.
A record that it happened. Both regimes are about what a firm can demonstrate, not just what it believes it did. If a regulator, an ICO investigation, or a professional-body review ever asks whether a specific client's data was deleted on schedule, "we're confident it was" is a materially weaker answer than an access-and-activity log showing exactly when a file was removed and by whom.
Where This Actually Lives
None of this calls for new software bought specifically to solve deletion. It calls for the same discipline this blog keeps coming back to from different angles: a client record that's centralized, attributable, and time-stamped for the life of the relationship — not just for the parts of it staff happen to remember. A workspace where every document and every access event is tied to a specific client, rather than scattered across inboxes and drives, is what turns "we have a retention policy" into something a firm can actually act on when a deletion date arrives, and demonstrate afterward if asked.
Osuria gives accounting firms exactly that foundation: a secure, branded client workspace where documents and communications live in one place for each client relationship, with the kind of access and activity record that makes it possible to show — not just claim — what happened and when. For the half of a retention policy that's actually an action rather than a date on a page, that record is the difference between a policy that exists on paper and one a firm can actually carry out.
If your firm's retention policy covers how long to keep records but not what happens afterward, explore the Digital Workspace or start using Osuria to see what a fully documented, centralized client relationship looks like end to end.
Sources: Principle (e): Storage limitation, ICO; ECSH33520 - Record keeping, HMRC; The Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017, Regulation 40, legislation.gov.uk