Most independent UK solicitors’ websites — family-law boutiques, conveyancing practices, employment specialists, dispute-resolution chambers — were built by a high-street agency three or four years ago on whichever SaaS stack carried a reseller discount. WordPress on a US host, a Gravity Forms enquiry widget, a Mailchimp newsletter signup, an abandoned HubSpot trial, Google Analytics, and a “secure document upload” embed pointing to a US-resident file store. The site works. Clients find it. Enquiries come in.
It also quietly fails the SRA Code of Conduct. That gap is the question a professional-indemnity insurer — and, in the event of a complaint, the SRA itself — will eventually ask. The firm is accountable, not the agency.
This briefing sets out what is actually wrong on a typical solicitor’s site, and what a regulated-grade estate puts in its place.
The SRA Confidentiality Trifecta
Every non-compliant UK solicitors’ site fails one or more arms of the same three-way confidentiality test. We call it The SRA Confidentiality Trifecta — the framework Custodiance applies on every solicitor-site review:
- The statute arm — SRA Code of Conduct for Firms, Rule 6 (Confidentiality and disclosure).
- The statute arm, parallel — SRA Principles 2 and 7 (integrity, and acting in clients’ best interests).
- The processor arm — UK GDPR Articles 28 and 44 to 49 (data-processing agreements and transfer-risk on every sub-processor).
A typical agency-built solicitor site fails on Arm 3 silently — the form, the document upload, the CRM, the e-sign widget — and that failure propagates back to Arm 1, because confidential client information is now exposed to a transfer mechanism the firm cannot defend.
The statute, in its own words
SRA Code of Conduct for Firms, Rule 6.3 (the confidentiality duty):
“You keep the affairs of current and former clients confidential unless disclosure is required or permitted by law or the client consents.”
SRA Principle 7 (acting in clients’ best interests):
“You act in the best interests of each client.”
SRA Principle 2 (integrity):
“You act with integrity.”
Read together, these are unqualified duties. The Rule 6.3 obligation does not turn off when the data is “just an enquiry”; it does not turn off when the sub-processor is convenient; it does not turn off because the agency built it that way. A US-resident enquiry inbox holding a divorce enquiry that names a third party is a Rule 6.3 problem the moment a CLOUD Act subpoena becomes lawful third-party access.
What the firm is accountable for
As an SRA-regulated practice, three overlapping frames apply to the website:
- SRA Code of Conduct for Firms — Rule 6 (Confidentiality and disclosure). The firm owes an unqualified duty of confidentiality to every client, current and former. That duty does not stop at the matter file. It extends to every piece of personal data the firm holds about that client, including the enquiry that arrived through the website before they became a client.
- UK GDPR and the Data Protection Act 2018. The firm is the data controller. That means Article 30 records of processing, Article 28 data-processing agreements with every sub-processor, and — under Articles 44 to 49 — a lawful transfer mechanism for any personal data that flows outside the UK and EU, comprising Standard Contractual Clauses plus a written Transfer Risk Assessment.
- Professional-indemnity posture. Most PII policies for solicitors now ask, at renewal, about IT security, supplier residency, and breach-response readiness. “We do not know where the enquiry-form data lives” is not the answer a firm wants on the renewal questionnaire.
The SRA Transparency Rules are a separate but related obligation the website must handle in any case. A firm offering conveyancing, probate, immigration, employment-tribunal advice, or licensing applications to individuals must publish indicative fee information, a description of the work included, who will carry it out, and likely timescales. Most agency-built sites either bury this on a single dense page or miss it entirely.
None of those frames explicitly requires a website hosted in the UK or the EU. But every one of them eventually asks the same question: where does the client data live, who has access, and can the firm prove it? On a typical solicitor’s site, the honest answer is “the agency set it up; we do not really know.”
The four specific failures on a typical solicitor’s site
1. Client enquiry forms processed on US infrastructure
The “Make an enquiry” form on most solicitors’ websites is a HubSpot embed, a Mailchimp form, a Typeform widget, or a WordPress plugin (Gravity Forms, WPForms) sending to a US-resident inbox or storing entries in a US database. Client names, telephone numbers, and the type of matter (“I think my wife is having an affair”, “my employer dismissed me yesterday”, “I am buying a property at 14 X Street”) 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. That is a direct collision with Rule 6 confidentiality. A divorce enquiry that names a third party is not data a UK solicitor can lawfully expose to US subpoena risk without, at minimum, a written Transfer Risk Assessment on file — and the agency that set up the form almost certainly did not write one.
The standard: an enquiry form that posts to the estate’s own endpoint rather than a US form tool, relayed by Scaleway in France to the firm’s own mailbox, in its Microsoft 365 or Google Workspace tenant or at Proton in Switzerland, a country the UK and EU recognise as adequate; where submissions are stored, they sit on a server we operate at Hetzner in Germany. Every provider in the path, US-incorporated ones included, is named in the sub-processor list. Identical experience for the client; a very different posture for the firm.
2. Document-upload widgets using US-resident storage
Conveyancing practices in particular often embed an “Upload your ID and proof of funds here” widget — typically Dropbox, Google Drive, or a WordPress plugin wrapping AWS S3 in us-east-1, sometimes a Hightail or WeTransfer embed. The client’s passport scan, mortgage offer, and source-of-funds documentation all land in a US-resident bucket the firm has no real visibility into.
This is the highest-risk failure on the list. AML source-of-funds documentation, ID verification, mortgage offers, and trust deeds are precisely the data SRA-regulated firms must keep confidential to a higher bar than ordinary GDPR personal data. A US-resident upload pipeline means the firm cannot truthfully sign the IT-security section of its PII renewal.
The standard: no upload flow on a general cloud drive or a US-resident bucket. Where a firm needs document upload, it is scoped as part of the engagement: a UK or EU-resident store behind a purpose-built upload endpoint, with virus scanning and a per-matter retention rule, named in the firm’s sub-processor schedule before it takes a file.
3. Email tools storing client identifiers in US databases
If the firm sends a quarterly newsletter (“changes to stamp duty in the autumn budget”, “new rules on employment-tribunal fees”) via Mailchimp, ConvertKit, or ActiveCampaign, the entire mailing list — every former client’s name, email, and matter-type tag — lives in a US-resident database. The DPA in place (if any) was probably auto-signed during Mailchimp signup; the Transfer Risk Assessment almost certainly is not on file.
Worse, the list often carries tags such as “conveyancing-2024”, “family-divorce-2023”, or “employment-tribunal-claimant”. Those tags are themselves confidential information about former clients, sitting in a US database.
The standard: an EU-established newsletter platform (MailerLite, in Lithuania) with double opt-in, or a CRM in the firm’s own name chosen for UK or EU residency, each named in the firm’s sub-processor schedule. The same workflow, with the list and the sending both in the UK or EU.
4. Practice-management software with US-resident extensions
Most modern practice-management platforms (Clio, LEAP, Actionstep) publish their primary data-residency position clearly — Clio has UK hosting, LEAP is UK and AU. That part is sound. But the extensions, integrations, and website widgets those platforms ship — calendar embeds, intake forms, e-signature widgets, payment links — frequently route through US-resident infrastructure even when the core platform is UK or EU-resident.
A common pattern: Clio UK for the matter file, but the website’s “book a 30-minute consultation” widget is a Calendly embed (US), and the e-signature flow for the client-care letter is DocuSign (US) or HelloSign (US). The core platform’s residency posture is undermined by the widgets bolted onto the website.
The standard: audit the widgets, not just the platform. Custodiance replaces Calendly with a booking tool chosen for UK or EU residency and opened in the firm’s own name, and DocuSign with an EU-resident alternative (Yousign, France, or Skribble, Switzerland) where the firm genuinely needs e-signature on the website. Where the platform itself can issue the e-sign request directly from the matter file, the website does not need to touch it at all.
How a regulated-grade estate handles this
Custodiance runs this as a managed estate, with UK and EU data residency, to your regulator’s standard. The work that puts a solicitor’s 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, booking widget, document upload, e-signature. Each sub-processor and its residency, set against the firm’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 SRA Transparency Rules pages published properly — indicative fees, who does the work, timescales — as their own indexed pages, not a buried PDF.
- Enquiry intake. The enquiry form migrated to the estate’s own endpoint, relayed by Scaleway in France to the firm’s own mailbox, with lawful-basis and retention copy on the form, and the firm’s SRA number and complaints-procedure link in the footer (a frequent omission).
- Analytics. Google Analytics replaced with our own Plausible Community Edition server in France (cookieless). Tracking pixels removed. Every remaining cookie documented.
- Contacts and documents. The contact list moved to a CRM in the firm’s own name, chosen for UK or EU residency. Where a document-upload flow is needed, it is scoped onto a UK or EU-resident store with per-matter retention rules and named in the firm’s schedule before it takes a file.
- Documentation. Article 30 records of processing and an Article 28 DPA pack (our data processing agreement and sub-processor list) ready for the firm’s COLP or COFA, or an external compliance consultant, to review. Privacy notice updated to reflect the sub-processor list.
This is the floor of a Growth engagement, quoted after a scoping call. Where client-document upload, e-signature, and booking are in scope across several sites, that is scoped on a call.
What the firm keeps
Client relationships. Existing matter files. The firm’s reputation. The domain. The content. All of it. The practice is not migrating away from anything — it is moving the website it runs on to infrastructure that will not make a partner nervous when the next PII renewal questionnaire arrives, or when a client (increasingly common, particularly from in-house counsel and compliance-aware individuals) asks “where does the enquiry form actually land?”
The client who asks that question is the kind of client every firm wants. Having the answer is increasingly the price of keeping them.
Where this fits
The equivalent regulatory failures for accountancy practices, schools, clinics, and estate agencies follow the same residency-gap pattern. The detail on implementing the SRA Transparency Rules sits in the Rule 6 website implementation briefing. The published posture behind all of this is the Custodiance framework. When a firm is ready, the next step is to request a scoping call.
Sources & methodology
The Trifecta framework is built from solicitor-site audits and the primary regulatory text. Source attribution is given where rules or data are quoted.
- SRA Code of Conduct for Firms, Rule 6 — Solicitors Regulation Authority Standards & Regulations — https://www.sra.org.uk/solicitors/standards-regulations/code-conduct-firms/
- SRA Principles 2 + 7 — Solicitors Regulation Authority Standards & Regulations — https://www.sra.org.uk/solicitors/standards-regulations/principles/
- SRA Transparency Rules — Solicitors Regulation Authority — https://www.sra.org.uk/solicitors/guidance/price-transparency/
- UK GDPR Articles 28 + 44–49 — Information Commissioner’s Office, “International transfers” — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/
- CJEU Schrems II ruling — Case C-311/18, 16 July 2020 — https://curia.europa.eu/juris/liste.jsf?num=C-311/18
- US CLOUD Act (2018) — Clarifying Lawful Overseas Use of Data Act, Pub. L. 115-141 — https://www.congress.gov/bill/115th-congress/house-bill/4943
- Methodology: framework derived from independent UK solicitor-site audits (family, conveyancing, employment, disputes), 2025 to 2026. Last updated 1 June 2026.