Outsourcing and UK GDPR: what a practice actually has to do

Data security is the first objection most practices raise about outsourcing, and it is the right first objection. It is also the one most often answered badly, by providers waving a certificate and by firms accepting it.

The core point is structural rather than technical. When your practice sends client data to a provider, you remain the data controller and the provider becomes a processor acting on your documented instructions. Responsibility does not transfer with the data. If personal data is compromised, the obligation to your clients, your regulator and the ICO remains yours.

The six things that need to exist

1. A written Article 28 agreement

UK GDPR Article 28 requires a written contract between controller and processor. It is not satisfied by a services agreement with a confidentiality clause. It must cover the subject matter and duration of processing, the nature and purpose, the types of personal data and categories of data subject, and it must impose specific obligations on the processor: to process only on your documented instructions, to ensure confidentiality, to implement appropriate security measures, to engage sub-processors only with authorisation, to assist with data subject rights and breach notification, and to delete or return data at the end of the engagement.

Ask any prospective provider for their draft DPA before you discuss price. How quickly it arrives, and how much of the above it actually contains, is informative.

2. A lawful basis that still holds

You had a lawful basis for processing your client's data when you took them on. Extending that processing to a third party outside the UK does not automatically invalidate it, but it does require you to check that it still holds and that the processing remains within what the client would reasonably expect.

3. A transfer mechanism and a transfer risk assessment

Where processing happens outside the UK, you need an appropriate transfer mechanism and a documented transfer risk assessment. This is the step most often skipped. It requires you to assess the legal regime in the destination country, the practical risk to the data, and the supplementary measures in place — encryption, access control, contractual protection — that address the gap.

Accountancy data routinely includes special category data. Your assessment should reflect that rather than treating client records as ordinary business information.

4. Engagement letters and privacy notice that reflect reality

Your engagement letter should contemplate the possibility of work being transferred to a third party, and your privacy notice should describe the categories of recipient and the fact of international transfer. This is a disclosure obligation about the arrangement. It does not oblige you to name the provider to clients — that remains a commercial decision — but it does oblige you not to leave clients with an inaccurate picture.

5. Professional confidentiality, considered separately

Data protection and professional confidentiality are two distinct obligations that happen to overlap. The ICAEW and ACCA Codes of Ethics impose confidentiality duties on all information acquired through a professional relationship, which is a broader category than personal data. Satisfying UK GDPR does not automatically satisfy your Code, and both bodies publish guidance specific to outsourcing that is worth reading before you contract rather than after.

6. A breach procedure that works at your speed, not theirs

Your notification clock to the ICO starts when you become aware of a breach. If your provider investigates for a week and then sends you a tidy summary, they have consumed your notification window. The agreement needs to require notification without undue delay and in a timescale that leaves you able to meet your own obligation, and the procedure needs to give you facts as they emerge rather than conclusions after the fact.

Questions that separate providers

• Does client data leave our systems, or do your teams work inside ours under named logins we control?
• Who specifically can see our data, and how are environments segregated between your clients?
• What is on the delivery floor — personal devices, phones, removable media, printers?
• Who are your sub-processors, and how are we notified before that changes?
• What is the breach notification timescale in the contract, in hours?
• What happens to our data when we leave, and is there a charge for its return?

A provider who answers these precisely and in writing is demonstrating something a certificate cannot: that the controls exist as operational practice rather than as an audited snapshot from a date in the past.

On certificates

ISO 27001 certification is genuinely meaningful — it confirms an information security management system was independently audited against a standard. It does not confirm that a specific engagement is well run, that your data stays in your systems, or that the contract protects you. Treat it as one input into a diligence process rather than as the diligence process itself.

Equally, the absence of certification is not automatically disqualifying, provided the provider is straightforward about it and can evidence the underlying controls. What should disqualify a provider is vagueness — about where data is processed, who can see it, or what happens when something goes wrong.