Phone:

Hidden from the page source until you click: friction against scrapers, not a guarantee.

Email:

[email protected]

Category:

Privacy Law

Published:

Tags:
  • uk-law
  • gdpr
  • data-protection
  • subject-access-request
  • privacy
  • ico

Subject Access Requests Under UK GDPR: What Organisations Can Legally Redact, and Where They Routinely Overreach

Ask most people what happens when they submit a subject access request to a former employer and you get some version of the same story: a PDF arrives a month later, and about a third of it is solid black rectangles. Names blacked out, whole paragraphs blacked out, sometimes entire emails reduced to a subject line and a redaction. The recipient assumes the organisation is hiding something. Often it isn't, it's just applying a template someone built years ago and never revisited. Occasionally it genuinely is hiding something, and the redaction is doing more legal work than it can actually support.

The right of access under Article 15 of UK GDPR is broad by design: confirmation that data is being processed, a copy of the data itself, and a set list of contextual information (purposes of processing, categories of data, recipients, retention period, the source of the data if not collected from the individual, and the existence of any automated decision-making). None of that is optional or subject to a "reasonable" watering-down. What organisations are entitled to withhold comes almost entirely from a separate piece of legislation: Schedule 2 of the Data Protection Act 2018, which carves specific, named exemptions out of the listed GDPR rights. If a redaction can't be traced to one of those exemptions, or to the general "reasonable and proportionate search" principle, it isn't really an exemption, it's a hope that nobody complains.

What can legitimately come out

Third-party personal data is the one that comes up constantly, because almost every internal document mentions someone other than the requester. The rule, from section 16 of Schedule 2, is not "redact anyone whose name isn't the requester's". It's a balancing test: a controller doesn't have to disclose information that identifies another individual unless that person has consented, or it's reasonable to disclose without their consent. Reasonableness turns on things like any duty of confidentiality owed to the third party, whether consent was sought, whether it was refused, and what that person would reasonably expect. A line manager's name on a formal decision they made in their professional capacity is a very different case from a colleague's home address mentioned in passing, and the ICO's guide to subject access is explicit that this has to be assessed case by case, not applied as a blanket rule.

Legal professional privilege is the other big one, set out in paragraph 19 of Schedule 2: information that would attract LPP in litigation, or that a solicitor owes a duty of confidentiality over, is exempt from the right of access entirely. But privilege has edges, and the Court of Appeal spent real effort mapping them in Dawson-Damer v Taylor Wessing. Legal advice obtained for the benefit of a trust couldn't be withheld wholesale from a beneficiary just because a law firm produced it, joint privilege doesn't work the way the firm wanted it to, and privilege under a foreign legal system doesn't automatically transplant into a UK LPP claim. The lesson generalises: "a lawyer touched this document" is not the same statement as "this document is privileged", and treating them as interchangeable is one of the most common overreaches in practice.

Beyond those two, Schedule 2 Part 1 lists a handful of narrower exemptions worth knowing exist even if you rarely need them: information about crime and taxation where disclosure would prejudice prevention or detection, confidential references given by the controller, management forecasting or planning that would prejudice the business, corporate finance information, and negotiations with the requester (so you don't have to hand someone your internal notes on your negotiating position while you're mid-negotiation with them). Each of these is specific and narrow. None of them means "anything that would be awkward to disclose".

The search itself doesn't have to be exhaustive

A separate, and often more useful, defence is that the search for data only has to be reasonable and proportionate, not exhaustive. This came from Ittihadieh v 5-11 Cheyne Gardens, where the Court of Appeal held that a company defending a subject access request didn't have to turn over every conceivable file, including one where doing so would have been, in the court's words, wholly disproportionate. The Data (Use and Access) Act 2025 has since put a version of this principle directly into statute, alongside a "stop the clock" mechanism that pauses the one-month response window while a controller genuinely needs to clarify scope or verify identity. That's a change worth knowing about, but it's a limit on how hard you have to look, not a licence to redact what you find. Those are different questions and organisations sometimes conflate them: "we didn't search the archived mailbox because it wasn't proportionate" is a defensible position; "we found it in the archived mailbox but blacked it out because it was inconvenient" is not.

Where the overreach actually happens

In practice, most bad redactions don't come from a controller cynically misreading the law. They come from three habits.

The first is treating "mentions someone else" as sufficient grounds to redact, without doing the balancing exercise at all. A performance review that says "Sarah in the team raised a concern about this" gets Sarah's name blacked out reflexively, even though Sarah raised the concern in a professional capacity, about the requester, in a document the requester has every reason to see in full. The DPA 2018 test asks whether disclosure is reasonable without consent, not whether a third party's name appears anywhere on the page.

The second is stretching "manifestly unfounded or excessive" under Article 12(5) to cover requests that are merely large or inconvenient. The ICO's own examples of manifestly unfounded requests are things like requests made purely to harass a named employee, or requests explicitly offered for withdrawal in exchange for a benefit. A request for five years of email correspondence isn't manifestly excessive just because it's a lot of work; volume and effort are exactly what the reasonable-and-proportionate search standard exists to manage, and using the excessive-request refusal as a shortcut around doing that work is the kind of thing that shows up badly in an ICO complaint.

The third, and the one that causes the most damage in enforcement outcomes, is the absence of any documented reasoning. An organisation that redacted a name after genuinely weighing confidentiality, expectations and the requester's interest, and wrote that reasoning down, is in a defensible position even if a regulator or court would ultimately have drawn the line slightly differently. An organisation that applied the same redaction because "that's what we always do to third-party names" has no defence at all, because there's no decision to defend, just a habit. If you're building or reviewing a subject access process, the redaction itself matters less than whether someone can point to which exemption was applied, to which piece of text, and why.

None of this is legal advice for a specific dispute; whether a given redaction holds up depends on the actual document, the actual relationship between requester and third party, and the actual reasoning applied at the time, which is precisely why "we always redact names" is such a weak position to be caught in.