Subject access requests: how to redact other people's data

When someone asks an organisation for a copy of their personal data, the answer is rarely a tidy file about one person. Emails, meeting notes, HR records and case files mention colleagues, customers and witnesses too. Sending everything exposes those other people. Holding everything back breaks the requester's rights. Redaction is how you do both jobs at once.

This post is a practical guide, not legal advice.

The deadlines

Under the UK GDPR and the EU GDPR, you must respond without undue delay and within one month of receiving the request. You can extend by up to two further months if the request is complex or the person has made several requests, as long as you tell them within the first month.

In the UK, the Data (Use and Access) Act 2025 added two clarifications, summarised in the government's factsheet:

• Reasonable and proportionate searches. You must search reasonably and proportionately, but you don't need to carry out searches that are unreasonable or disproportionate.
• Stopping the clock. You can pause the deadline while you wait for information you reasonably need from the requester, such as clarification or proof of identity.

Information about other people

The UK regulator's guidance on information about other people in a subject access request sets out a sequence of questions:

1. Can you remove the other person's details and still answer the request? Often you can, by redacting names and identifying details.
2. Has the other person consented to disclosure? If they have, you disclose.
3. Is it reasonable to disclose without consent? Weigh the type of information, any duty of confidence, whether the requester already knows it, and how important it is to them.

Two warnings from the same guidance are worth repeating. First, people can be identified from context even after their name is removed, such as a job title in a small team or a reference to a specific meeting. Second, even when you withhold third-party information, you should still provide as much of the requester's own information as you can, and record why you made each decision.

A redaction routine for subject access requests

1. Collect, then de-duplicate. Email threads repeat the same text many times. Redact one copy and reuse the decision, so the same person isn't hidden in one email and visible in the next.
2. Mark third parties consistently. Hide names, email addresses, phone numbers, signatures and anything that identifies someone from context.
3. Keep the requester visible. The point is to give them their data. Over-redaction is a failure too.
4. Remove, don't cover. A black box over text in a PDF usually leaves the text underneath. Use a tool that removes it, then check the result.
5. Strip hidden content. Comments, tracked changes and hidden spreadsheet tabs travel with files. See how spreadsheets leak data.
6. Log each decision, without copying the sensitive text into the log.

Where Ombly fits

Ombly suggests names, emails, phone numbers and other identifiers across every page, lets a reviewer accept or reject each one, and exports a copy rebuilt from pixels, so nothing hidden survives. For teams, it runs on your own servers and records what was removed, by category and page, without storing the text itself. Book a call to try it on a real request.