Third-Party Personal Data in DSARs
Third-party data is where a straightforward Subject Access Request often stops being straightforward.
You may have found the requester’s records, but those records also mention a manager, a witness, a complainant, a colleague, a customer or a family member. Removing the other person’s name may not solve the problem. Context can identify someone just as clearly as their name.
The practical challenge is to protect other people without over-redacting the requester’s own personal information.
What counts as third-party personal data?
It is personal information relating to someone other than the requester. In a DSAR this might include a colleague’s name, contact details, witness evidence, a customer complaint, manager comments or details that identify a person indirectly through context.
The useful test is not simply “is another name on the page?”. Ask whether the information relates to another person and whether the requester could identify that person from what would be disclosed.
| Scenario | Typical issue | Review question |
|---|---|---|
| Manager named in an email | Professional role and known identity | Is disclosure reasonable in context? |
| Witness statement | Confidentiality and sensitive evidence | Can the requester’s data be separated or redacted? |
| Grievance about several colleagues | Mixed personal data | Which parts relate to the requester and which reveal others? |
| Customer complaint naming staff | Customer and employee data overlap | What can be disclosed without unnecessary third-party exposure? |
| Small-team reference without a name | Context may identify the person | Would redaction genuinely protect the third party? |
Common third-party scenarios.
The decision is not “redact or disclose” in one jump
The ICO approach is more useful if you treat it as three questions.
1. Would disclosure identify another person?
Start with the information itself and the context. Direct identifiers are obvious, but role, location, relationship and surrounding facts can also identify someone.
If the requester’s own personal data can be provided without revealing the third party, redaction or extraction may resolve the issue. If the third party remains identifiable, move to the next question.
2. Has the third party consented, and is asking appropriate?
Consent can make the decision easier, but you do not have to seek consent in every case. Sometimes asking would itself reveal information about the requester or tell the third party that a SAR has been made. In employment settings, requesting consent may also be inappropriate in some circumstances.
The point is to consider consent, not to turn it into an automatic administrative step.
3. Is disclosure without consent reasonable?
If there is no consent, you still need a case-specific reasonableness assessment. Relevant factors can include the nature and sensitivity of the information, any duty of confidentiality, whether the third party acted in a professional capacity, whether the requester already knows the information, the importance of the information to the requester and the likely impact on the third party.
There is no safe blanket rule such as “always remove employee names”.
Three situations that catch teams out
A manager’s name in a routine work email should not be treated in the same way as a confidential witness statement. Equally, withholding an entire grievance document simply because it includes several people can remove personal information the requester is entitled to receive.
A better review asks what can be separated, what genuinely identifies another person and what the surrounding context means for the disclosure decision.
| Situation | Common shortcut | Better review question |
|---|---|---|
| Known manager | Automatically redact all staff names | Is the manager already known to the requester, acting professionally, and is disclosure reasonable? |
| Witness statement | Disclose or withhold the whole statement | Can the requester’s personal data be separated while protecting the witness where appropriate? |
| Shared account or support ticket | Disclose the whole record | Which information relates to the requester and which belongs to another user? |
Better questions for common cases.
Keep a third-party data decision log
The reasoning should not live only in a reviewer’s head. A practical log should capture:
Decision log fields
- Document and location.
- Third party or identifying context.
- Why the person is identifiable.
- Whether consent was considered and, if relevant, obtained or refused.
- Whether disclosure without consent was considered reasonable.
- Proposed action: disclose, redact or withhold.
- Short rationale.
- Reviewer and QA status.
This makes the response easier to defend if the requester later challenges a redaction or complains about missing information.
Redaction checklist
Before release
- Keep the original record unchanged.
- Work from a disclosure copy.
- Record why each material redaction is proposed.
- Check whether surrounding context still identifies the third party.
- Confirm the redaction is technically secure before release.
- Run a final QA review on sensitive or complex material.
Where AI helps, and where it should stop
AI can be useful for finding likely names and identifiers, grouping documents, spotting duplicates and preparing a candidate table for human review. That can save time on large DSARs, particularly where the same people appear across hundreds of emails or files.
It should not decide whether disclosure without consent is reasonable. That decision depends on context, confidentiality, sensitivity and competing rights. Sensitive files should also only be processed in tools approved by the organisation’s privacy and security framework.
When external support can help
Third-party review becomes resource-intensive when a DSAR contains large email sets, witness evidence, complaints, sensitive HR records or information about many individuals. External support can help structure the material and prepare review-ready redaction and decision logs while the organisation retains the final disclosure decisions.
For law firms, Seifti can provide white-label operational DSAR support or help build an internal workflow with review templates, checklists and practical AI prompts.
Third-party review, structured and evidenced
We prepare the candidate list, the redaction notes and the decision log. Your team makes the disclosure call.
See our DSAR support White-label DSAR support for law firmsFAQ
Do we always need consent before disclosing third-party information?
No. Consent is relevant, but the organisation may also need to assess whether disclosure without consent is reasonable in the circumstances.
Is removing a name enough to protect the third party?
Not always. A person can still be identifiable from their role, relationship or other contextual information known to the requester.
Should we redact every employee name?
No. Third-party disclosure decisions should be case specific. Professional role, prior dealings, confidentiality, sensitivity and the surrounding context may all matter.
Do we need to record the reason for a redaction?
Keeping a clear decision log is good practice and makes the response easier to explain and evidence if challenged.
Further reading
This article is general information about DSAR practice in the UK and is not legal advice. Disclosure decisions should be taken in the context of each request.
No Comments