How to run a defensible SAR: a practical checklist

A subject access request is rarely challenged on the day it is answered. It is challenged months later, when the requester complains to the ICO, when the same material turns up in a tribunal, or when an internal audit asks how a decision was made. A defensible SAR is one that can answer those later questions from the record, without repeating the work.

This checklist sets out what that record needs to contain at each stage. It is written for organisations using any process, manual or otherwise. Where Redactics changes the effort involved, we say so, but the standard is the same either way.

1. Receipt and scope

• Record the date the request was received and the date the one-month clock started. If identity verification was needed, record when it was completed; the clock does not start until it is.
• Record the scope as you understand it, and any clarification sought from the requester. If you narrowed the scope, record the requester's agreement.
• Decide, and record, whether the request is complex enough to justify an extension of up to two further months. The reason must be specific to the request, not to your workload.

2. Collection

• List every system, mailbox, drive and paper file that could reasonably hold the requester's personal data. Record which were searched, which were not, and why.
• Record the search terms and identifiers used: full name, aliases, initials, email addresses, employee or customer numbers, phone numbers.
• Keep the originals. Extracted text, exports and copies are working material; the original is the evidence.
• Record duplicates rather than discarding them. The number you collected is the number you should be able to account for.

3. Identifying people

Most disclosure decisions turn on who a piece of information is about. Before reviewing content, be clear about who appears in the material: the requester under every name and identifier, and each other person with their role. Ambiguous matches, such as two people with the same surname, should be resolved deliberately and the decision recorded.

4. Review

• For each item, record the decision (disclose, redact, withhold) and the reason. Reasons should reference the exemption or provision relied on, not just "third party".
• Apply the same reasoning to the same kind of finding throughout. Reason templates help; so does a second reviewer for anything withheld.
• For third-party data, record whether consent was sought and, if not, why it was reasonable to disclose or withhold without it.
• For special category data about the requester, remember that it is the requester's own data. It is disclosed unless an exemption applies.

5. Disclosure

• Provide an index of what is disclosed and a schedule of what was redacted or withheld, with reasons at the level of detail you can defend.
• Check the output for residual text under redactions and for metadata. A redaction that can be lifted is not a redaction.
• Record how and when the package was delivered, and who approved release.

6. After the response

Keep the case record, including the audit trail, for as long as your retention policy for the underlying data requires, and at least until any complaint or litigation window has closed. When the record is deleted, record that too.

If you can produce, for any item in the package, the source it came from, the decision made about it, who made it, when and why, your SAR is defensible. If you cannot, the process needs to change before the next request, not after the next complaint.