Subject access requests that include WhatsApp: a workable process for brokers

Contents

1. What is actually in scope
2. The clock, and the two ways to change it
3. A seven-step process the brokerage can actually run
4. The three things that go wrong with WhatsApp specifically
5. Where the tooling helps
6. Frequently asked questions

Subject access requests rarely arrive from happy clients. They land after a declined claim, after a fee dispute, after an account executive leaves for a competitor, or in the middle of an employment matter. And increasingly the request is not just about the file and the email trail: it is about the WhatsApp thread, because that is where the account executive and the client actually talked.

Most brokerages handle the email part reasonably well and then discover the messaging problem late — usually on day twenty-two of a one-month deadline, when someone realises the relevant conversation is on a departed colleague's personal handset. This is a process problem before it is a legal one. Here is how to build the process while nothing is on fire.

What is actually in scope

The right of access covers personal data about the requester, not every document that mentions their policy. That distinction matters when you are staring at four years of messages. In a broker WhatsApp thread, the personal data typically includes:

• Messages the client sent and messages you sent to them, including the metadata your system holds — timestamps, delivery and read status, which number sent what.
• Photographs and documents they shared: damage pictures, licence images, bank letters, medical notes. Attachments are personal data too, and image content can be special category data.
• Voice notes. A voice note about the client is their personal data whether or not you have ever transcribed it.
• Internal notes and opinions about the client, wherever they sit — the note on the customer record saying a client is "difficult at renewal" is disclosable, and it is worth telling colleagues that before they write it.
• Automated outputs held against the record, such as a sentiment classification or an attrition risk score, which are personal data about that person even though no human wrote them.

Location does not determine scope. If a colleague conducts brokerage business on their own phone using their own WhatsApp account, the resulting client data is being processed for the firm's purposes and can fall within a request — which is the single strongest operational argument for moving client conversations onto a shared brokerage number rather than personal handsets. See also our note on archiving WhatsApp under SYSC 9 and ICOBS, which is the same underlying discipline applied to record-keeping.

The clock, and the two ways to change it

You have one month from receipt to respond. The month runs from the day the request arrives — working day or not — to the corresponding date in the following month, and if that date falls on a weekend or bank holiday you have until the next working day.

There are two legitimate ways to move that date, and one that is not legitimate:

1. Extension. Where a request is complex, or where the same person has made a number of requests, the deadline can be extended by up to two further months. The catch is that you must tell the person about the extension, and why, within the original month. Extending quietly is itself a breach even if you deliver on time.
2. Pausing for clarification or identity. If you genuinely cannot proceed without knowing what the person wants, or without confirming who they are, the clock can stop while you wait for their answer and restart when it arrives. The UK's Data (Use and Access) Act 2025 puts this "stop the clock" position and the principle that a search need only be reasonable and proportionate onto a statutory footing; its provisions have been commenced in stages, so check the ICO's current guidance before you rely on the detail.
3. Not legitimate: pausing because you are busy, because the client also has a live complaint, or because the request looks tactical. A parallel complaint under DISP does not suspend an access request; the two run side by side on separate clocks.

Clarification is a real tool, not a stalling device. "You have asked for everything we hold. We hold roughly four years of email, a policy file and WhatsApp conversations. Would you like all of it, or the period around the 2025 claim?" is a fair question, and most requesters answer it.

A seven-step process the brokerage can actually run

Step	What happens	Who
1. Recognise	Any request for "my data" or "my messages" is logged as a SAR, whatever the wording and whichever channel it came in on — including WhatsApp itself.	Whoever receives it
2. Log and date-stamp	Record the date of receipt, calculate the deadline, and put both in the diary with an internal checkpoint at day ten.	Data protection lead
3. Verify and scope	Confirm identity by a method you already use for that client; ask a scoping question if the request is genuinely unbounded. Note the date the clock pauses and restarts.	Data protection lead
4. Search	Broking system, email, the WhatsApp business number, any personal devices used for client work, plus paper. Record where you looked, not just what you found.	Account handler and IT
5. Review and redact	Remove third-party personal data and anything covered by an exemption. This is the slow step — budget days, not hours.	Data protection lead
6. Deliver	Provide a copy plus the required supplementary information: purposes, categories, recipients, retention, and their other rights.	Data protection lead
7. Close the loop	Record what was disclosed and why anything was withheld. If a complaint follows, this file is your defence.	Data protection lead

No fee applies in the ordinary case. A charge is only available in narrow circumstances, such as further copies or a request that is manifestly unfounded or excessive, and "excessive" is a high bar rather than a synonym for inconvenient.

The three things that go wrong with WhatsApp specifically

Third parties in the thread. Insurance conversations are full of other people: the spouse on the joint policy, the named driver, the third party in the accident, the underwriter who was quoted verbatim. You must not disclose information identifying another individual unless they consent or it is reasonable to disclose without consent, and the reasoning belongs on file. In practice this means reading messages one by one rather than exporting a chat wholesale.

Group chats. A group with a commercial client's finance team mixes several people's personal data in one stream. Requests from one member of that group are noticeably harder to answer than requests about a one-to-one thread — a good reason to keep client conversations one-to-one and use the shared inbox for internal visibility.

Deletion and retention. If your retention schedule says client communications are kept for the statutory period, keep them for that period. Deleting messages after a request arrives is the worst possible moment to tidy up. Equally, do not treat "we keep everything forever" as safe: an unbounded archive makes every future request more expensive.

Where the tooling helps

Nothing removes the human review — someone still has to read the thread and make redaction decisions. What tooling changes is step 4. When client conversations run through a single brokerage number with the thread attached to the customer record, "where do we look" has one answer instead of six, and audit logs show who saw what and when. In ORIS, conversations sit against the customer alongside the flags, risk score and consent record, and customer data exports to CSV, which is enough to assemble a search but not enough to skip the review. Treat any AI-generated field — sentiment, urgency, a draft that was never sent — as disclosable unless you have a reason it is not. Other pieces on running the back office sit under organisation.

The firms that handle these well are not the ones with the best software. They are the ones where a request arriving on a Friday afternoon reaches a named person on the Friday afternoon, and where the search does not depend on whether a former colleague still answers their phone.

Frequently asked questions

Does a request made over WhatsApp count?

Yes. A subject access request can be made verbally or in writing, through any channel, and does not have to use the words "subject access request". A client messaging "send me everything you've got on my claim" has made one, which is why front-line staff need to recognise and escalate it rather than answer it themselves.

Do we have to hand over the whole chat export?

No, and usually you should not. The obligation is to provide the requester's personal data, not a raw export containing other people's. A curated set of messages, with third-party details removed and an explanation of what was withheld, meets the duty better than a dump of the thread.

What if the messages are on a former employee's personal phone?

You still have to make a reasonable and proportionate search, which may include asking that person to search their device for data processed on the firm's behalf. It is an uncomfortable conversation and the reason exit procedures should cover client conversations before the leaver's last day, not after a request arrives.

Can we refuse because the client is in dispute with us?

Not on that basis. A dispute, a complaint or a threatened claim does not switch off the right of access, although specific exemptions — legal professional privilege being the common one — may cover particular documents. Apply exemptions document by document with a recorded reason, never as a blanket refusal.

How long should a small brokerage budget for one?

Plan on the review, not the search. Firms that have done a few report the reading and redaction consuming most of the effort, particularly where there are years of messages and images. Starting on day two rather than day twenty is the single change that keeps requests inside the original month.