ICAEW · Accountancy practices

Why your UK accountancy website probably fails ICAEW confidentiality

By Jordan Gilbert

In brief

UK accountancy websites typically fail ICAEW Section 114 confidentiality across four layers — US-resident enquiry forms carrying turnover bands and tax posture, US document portals holding client tax records (the highest risk under HMRC's six-year retention window), US email tools tagged by service line, and practice-management widgets routing through US-resident infrastructure. A regulated-grade estate moves inbound to in-jurisdiction routing, document flows to UK and EU object storage, and drafts the Article 30 and Article 28 documentation the practice's MLRO and PII insurer will eventually ask for.

Most independent UK accountancy websites — small ACA and ACCA-led practices, regional bookkeepers, IFAs authorised by the FCA — were built by a generalist agency a few years ago on whichever SaaS stack was convenient at the time. WordPress on a US host, a HubSpot form embed for client enquiries, a Mailchimp signup for the quarterly Budget brief, a “client portal” link pointing at Dropbox or Google Drive in us-east-1, Google Analytics, and a QuickBooks Online or Xero widget for the demo. The site works. Clients find it. Enquiries come in.

It also quietly fails the ICAEW Code of Ethics confidentiality section — and the equivalent ACCA Rulebook and IFA Code duties. That gap is the question a practice’s AML supervisor and professional-indemnity insurer will eventually ask. The practice is accountable, not the agency.

This briefing sets out what is actually wrong on a typical accountancy site, and what a regulated-grade estate puts in its place.

The ICAEW Section 114 Stack

Every non-compliant UK accountancy site fails on one or more layers of the same compliance stack. We call it The ICAEW Section 114 Stack — the framework Custodiance applies on every accountancy-site review:

  1. Layer 1 — Client enquiry forms on US infrastructure (HubSpot, Mailchimp, Typeform, or a WordPress plugin routing to a US inbox carrying turnover bands and tax posture).
  2. Layer 2 — Document portals for client tax records on US-resident storage (Dropbox, Google Drive, a OneDrive default tenant, or a WordPress S3 plugin in us-east-1).
  3. Layer 3 — Email marketing holding client lists in US databases (Mailchimp, ConvertKit, or ActiveCampaign carrying confidential service-line tags).
  4. Layer 4 — Practice-management widgets routing through US-resident infrastructure (QuickBooks embeds; the widget-versus-core-platform mismatch).

The six-year HMRC retention window means each layer’s exposure compounds annually. A document uploaded today does not leave the practice’s envelope for years, and the sub-processor list behind it must hold up over that horizon.

The statute, in its own words

ICAEW Code of Ethics, Section 114.1 (Confidentiality) — the unqualified duty:

“The principle of confidentiality imposes an obligation on all professional accountants to refrain from: (a) Disclosing outside the firm or employing organisation confidential information acquired as a result of professional and business relationships without proper and specific authority or unless there is a legal or professional right or duty to disclose; and (b) Using confidential information acquired as a result of professional and business relationships to their personal advantage or the advantage of third parties.”

ICAEW Code of Ethics, Section 114.2 extends the duty beyond active engagement:

“A professional accountant shall maintain confidentiality, including in a social environment, being alert to the possibility of inadvertent disclosure, particularly to a close business associate or an immediate or close family member.”

Read together, the Section 114 duty is unqualified, extends beyond the active engagement, and applies to “inadvertent disclosure” — which is precisely what a US-resident enquiry form, a US-resident document portal, or a US-resident newsletter tag set is. The CLOUD Act exposure is not conscious disclosure by the practice; it is inadvertent disclosure architected into the tooling.

The parallel ACCA Code of Ethics and Conduct, Section R114 mirrors this language; the IFA Code of Ethics, Section 140, carries the same obligation.

What the practice is accountable for

As an independent UK accountancy practice, bookkeeper, or IFA, four overlapping frames apply to the website:

  1. ICAEW Code of Ethics — Section 114 (Confidentiality), or the ACCA Rulebook Section B / IFA Code equivalent. The practice owes a confidentiality duty to every client, current and former, that extends beyond the engagement file to every piece of personal data the practice holds about them — including enquiries from prospective clients that arrived through the website.
  2. AML supervision. Whether HMRC, ICAEW, ACCA, or IFA supervises the practice for anti-money-laundering purposes, the Money Laundering Regulations 2017 require risk assessment, customer due-diligence record-keeping, and secure handling of identification documents. A client-document upload that lands in a US-resident bucket is a direct collision with the “appropriate security measures” expectation.
  3. UK GDPR and the Data Protection Act 2018. The practice is the data controller. That means Article 30 records of processing, Article 28 DPAs with every sub-processor, and a lawful transfer mechanism for any data flow outside the UK and EU. HMRC’s retention requirement of six years (longer for certain records) makes the residency question higher-stakes than for most sectors — the data does not leave the practice’s envelope for a long time, and the sub-processor list must hold up over that horizon.
  4. FCA principles, where authorised. If the practice is an IFA, mortgage broker, or otherwise FCA-authorised, PRIN 6 (Customers’ interests) and PRIN 7 (Communications with clients) apply to the website, and SYSC operational-risk expectations apply to supplier choices.

The website itself often does double duty as a fee-transparency and trust-building surface. Most established practices display indicative pricing patterns (“Self-assessment from £180”, “Limited company accounts from £750/year”) because it filters enquiries before they reach the partner, and because it ranks well in search and signals confidence. Hiding fees until enquiry is a holdover from a different era of professional practice.

None of those frames explicitly requires an “EU-sovereign website”. But every one of them eventually asks the same question: where does the client data live, who has access, and can the practice prove it — for the next six years? On a typical accountancy site, the honest answer is “the agency set it up; we do not really know.”

The four specific failures on a typical accountancy site

1. Client enquiry forms processed on US infrastructure

The “Request a callback” form on most accountancy websites is a HubSpot embed, a Mailchimp form, a Typeform widget, or a WordPress plugin sending to a US-resident inbox. Prospective client names, business names, turnover bands (“£100k–£250k”), sector, and the type of advice sought (“we think HMRC are about to open an enquiry on the 2023 return”) are all processed and stored on US servers.

US-resident SaaS is subject to the US CLOUD Act (2018), which allows US authorities to compel disclosure of stored data even where that data physically sits in the EU. An HMRC-enquiry prospect, an R&D-tax-credits prospect, or a director-loan-account question is exactly the kind of professional-confidentiality content that should not be casually exposed to US subpoena risk. The Section 114 duty does not draw a line at “engagement letter signed”; it covers the prospective relationship too.

The standard: an enquiry form that posts to an inbox on EU-sovereign infrastructure — Cloudflare Email Routing on UK and EU edges for inbound, an EU-resident relay for outbound. Identical experience for the client; a very different posture for the practice.

2. Document portals for client tax records using US-resident storage

Many small practices embed a “send us your records” portal on the website — typically Dropbox, Google Drive, OneDrive (Microsoft is US-headquartered; residency depends on tenant config), or a WordPress plugin wrapping AWS S3 in us-east-1. The client’s P60s, bank statements, mortgage offers, share-purchase agreements, and trust deeds all land in a US-resident bucket the practice has no real visibility into, and that the practice must retain for six years minimum under HMRC’s retention rules — six years from the end of the relevant tax year for self-assessment returns, longer for some categories.

This is the highest-risk failure on the list, because it compounds over time. A document uploaded today sits in the US-resident bucket for six years. By year four, the practice almost certainly cannot answer the question “which US sub-processor has access to this client’s 2024 bank statements” with confidence — the SaaS vendor’s terms, sub-processor list, and routing have changed multiple times. AML supervisor reviews and PII renewals become harder, not easier, with each year.

The standard: UK and EU-resident object storage (Cloudflare R2 in the LHR region, or Backblaze B2 EU) behind a purpose-built upload endpoint, with virus scanning, per-client retention tracking, and an explicit six-year retention rule. Custodiance runs client-document flows inside the same EU-sovereign envelope as the rest of the estate.

3. Email tools holding client lists in US databases

If the practice sends HMRC-deadline reminders (“self-assessment deadline in three weeks”) or Budget briefings (“autumn budget 2026 — what changed for owner-managed businesses”) via Mailchimp, ConvertKit, or ActiveCampaign, the entire client mailing list — every client name, email, and business name, often tagged by sector or service line — lives in a US-resident database. The DPA in place (if any) was probably auto-signed during signup; the Transfer Risk Assessment almost certainly is not on file.

Worse, the list is tagged in ways that are themselves confidential information: “limited-company-accounts”, “VAT-quarterly”, “R&D-credits-claimant”, “construction-CIS”. Those tags reveal the client’s tax posture, sitting in a US database. And the six-year retention runs through this too. A client who left the practice in 2025 may still be on the Mailchimp list in 2031, with all their historical tags intact, in a US database, because no list-hygiene pass has run. That is a hard story to tell an AML reviewer.

The standard: a self-hosted sender on a London-region container with an EU-resident SMTP relay, or a UK and EU-hosted email tool for the contact list. Client-portal exit is wired into a retention-pruning routine, so ex-clients leave the list automatically after the applicable HMRC retention window. The same workflow, with UK and EU residency end to end.

4. Practice-management software with US-resident infrastructure — and the Xero nuance

Most modern practice-management platforms have their own residency story, and it is worth understanding the nuance, because it is frequently misstated:

  • Xero is NZ and AU-headquartered with primary cloud infrastructure in AU. That is not the US, and it is not the EU — it is a third country with its own UK and EU adequacy position. For most UK practices, Xero is a reasonable choice with a clear story you can defend, but the AU/UK/EU transfer posture should be referenced explicitly in the records of processing, not assumed to be the same as a UK or EU provider.
  • QuickBooks Online (Intuit) is US-resident. The same CLOUD Act exposure applies as for any US SaaS. For UK practices serving UK SMB clients, that is a posture worth flagging on the engagement letter and the privacy notice.
  • FreeAgent is UK-based (owned by NatWest); UK residency.
  • Sage is UK-headquartered; residency depends on the product line.

The website often embeds a “see your Xero/QuickBooks dashboard” widget or a “log in to your client portal” link. The widget might route through US-resident infrastructure even where the core platform does not, so the audit must examine the embed script, not just the platform’s main-product page.

The standard: map every practice-management widget against the real residency of the embed, not the platform’s marketing page, and select UK and EU-resident widgets where the practice has a choice. Where QuickBooks Online is the client’s chosen bookkeeping platform, that is the client’s decision — but the practice’s public website does not need to compound the exposure by embedding the QBO widget on it.

A pattern worth borrowing from practices that do it well: publish indicative fee ranges on the website (“Self-assessment from £180”, “Limited company accounts from £750/year”, “VAT returns from £45/return”). Three reasons:

  1. It filters enquiries. Prospective clients who cannot afford the practice self-select out before booking a discovery call.
  2. It ranks in search. “Accountant Leeds price” and similar long-tail queries reward sites that actually display prices.
  3. It builds trust. The opaque-pricing era is over for SMB buyers; publishing indicative ranges signals confidence and transparency.

The indicative-fee pattern is also a useful place to differentiate the practice’s positioning — fixed-fee versus hourly, included scope, and what triggers a re-quote. Custodiance builds this into the page templates as indexed pages by service line, with scope notes, as part of the managed estate.

How a regulated-grade estate handles this

Custodiance runs this as a managed estate, in-jurisdiction, to your regulator’s standard. The work that puts an accountancy site right is the work the estate carries continuously, not a one-off remediation:

  • Audit. The current site and every third-party service it uses — forms, analytics, CRM, email, document portal, practice-management widgets. Each sub-processor and its residency, with the AU, UK, EU, and US distinctions explicit, set against the practice’s current Article 30 records (or built from scratch where none exist).
  • Hosting. The site pinned to a London region (lhr1), content and structure carried over, with the indicative-fee pages published properly — by service line, with scope notes — as their own indexed pages.
  • Enquiry intake. The enquiry form migrated to a Cloudflare-routed, EU-relay-backed endpoint, with lawful-basis and retention copy on the form — including the six-year HMRC retention rationale, which is itself the lawful basis for keeping records past the end of the engagement.
  • Analytics. Google Analytics replaced with Plausible (EU-resident, cookieless). Tracking pixels removed.
  • Documents and contacts. Where a document-upload portal is needed, an in-jurisdiction object-storage endpoint with per-client retention rules (six years from end of tax year, configurable). The client newsletter list moved to a UK or EU-hosted email tool, with retention pruning wired to client-portal exit.
  • Documentation. Article 30 records of processing and an Article 28 DPA pack drafted, ready for the practice’s MLRO or compliance partner to review. Privacy notice and AML notice updated to reflect the new sub-processor list and retention horizons.

This is the floor of a Growth engagement (£1,495/mo). Where the client portal, document upload, and secure messaging are all in scope — or where a practice wants a fractional CTO owning the roadmap and compliance posture — that is an Embedded engagement (from £6,000/mo, bespoke).

What the practice keeps

Client relationships. Existing client files. The practice’s reputation. The domain. The content. The historical document archive, migrated with retention rules now explicit. All of it. The practice is not migrating away from anything — it is moving the website it runs on to infrastructure that holds up over a six-year retention horizon, that will not make the AML supervisor nervous, and that answers the question when a finance-director prospect asks “where does the document upload land?”

That prospect is increasingly common, particularly among the data-aware in-house finance teams whose work feeds the practice. Having the answer is increasingly the price of keeping them.

Where this fits

The equivalent regulatory failures for law firms, schools, clinics, and estate agencies follow the same residency-gap pattern. The detail on implementing the ICAEW Section 114 disclosures sits in the Section 114 website disclosures briefing. The published posture behind all of this is the Custodiance framework. When a practice is ready, the next step is to request a scoping call.

Sources & methodology

The Section 114 Stack framework is built from accountancy-site audits and the primary regulatory text. Source attribution is given where rules or sections are quoted.

Custody, not marketing.

Have a senior partner read your estate against this.

A scoping call is a measured conversation about your obligations, your current setup, and what it would take to run it to your regulator's standard. No obligation, and no pressure.

Request a scoping call More briefings