The Request File That Answers First: Governing UK Subject Access Requests as Standing Evidence

Subject access requests are frequently managed as isolated legal events: a request arrives, the clock starts, colleagues are chased, documents are reviewed and a response is issued. The work is important, but the record it leaves behind is often thin. When a regulator, auditor or internal assurance function later asks how a decision was reached, the organisation may be able to show the final response but not the reasoning that produced it. This briefing argues for a different model: a standing subject access request evidence pack that treats the request file as a governance control, not an administrative by-product.

From Event to Control

Under the UK GDPR and the Data Protection Act 2018, a subject access request must generally be answered within one month, with limited scope for extension or clarification. The legal obligation is well understood. The governance obligation is less consistently applied. A repeatable evidence pack should make the following visible without reconstruction: what was searched, why that scope was chosen, what was withheld and on which basis, who approved the outcome, and how the response deadline was managed.

The distinction matters. A well-drafted response letter proves that a response was sent. A well-maintained request file proves that the organisation exercised control. In 2026, with regulatory attention increasingly focused on accountability evidence rather than policy statements alone, that difference is material.

Four Evidence Layers

A standing pack need not be elaborate, but it should contain four layers that connect decision-making to outcome.

1. Search scope and execution

Record the systems, repositories, custodians and date ranges considered. Where exclusions are made, state the rationale. Capture the search terms used, the date searches were run and the person responsible. For complex requests, a short scope note should explain how the request was interpreted and whether clarification was sought. This is not a technical log for its own sake; it is the evidence that the search was proportionate and directed by the request.

2. Redaction and exemption decisions

Each redaction should be traceable to a decision, not merely to a highlighted passage. A redaction schedule should identify the document or extract, the information withheld, the exemption or restriction relied upon, the reason and the reviewer. Where third-party information is removed, the schedule should show that the balancing exercise was considered. The schedule can be concise, but it must be sufficient for a different reviewer to understand the judgement.

3. Reviewer sign-off

Sign-off should be more than a name at the foot of an email. The pack should record the reviewer's role, the date of approval, the scope confirmed and any conditions attached. A second review is not necessary for every request, but the pack should show how quality assurance was applied and who was accountable for the final disclosure decision.

4. Timeliness and clock management

The request file should include a simple timeline: date received, date identity was verified, any clarification sought, any lawful clock pause, extension notice where applicable, response issued and closure. This allows the organisation to demonstrate that the one-month period was monitored and that any extension was properly considered. It also exposes avoidable delays before they become patterns.

A Concise Checklist

A practical pack can be built around the following minimum fields:

• Request register entry with a unique reference and received date.
• Identity and authority verification record.
• Scope note setting out interpretation, systems and exclusions.
• Search execution record with terms, custodians and dates.
• Retrieval index linking documents to the request.
• Redaction schedule with exemption rationale and reviewer.
• Quality assurance and final sign-off record.
• Response and disclosure log, including date issued.
• Retention and closure note.

This checklist is deliberately modest. The aim is consistency, not bureaucracy. A pack that is too heavy will be completed retrospectively and therefore lose its evidential value.

Case Study: Tightening the Audit Trail in 2026

A UK housing association with a high volume of tenant and employee requests reviewed its subject access handling during a 2026 internal assurance exercise. The review found that responses were generally issued on time, but the supporting files varied between teams. Some contained detailed search notes; others contained only the final response and a spreadsheet of documents. Redaction decisions were sometimes recorded in email threads that were difficult to reconstruct.

The organisation introduced a standing evidence pack with four mandatory sections: scope, search, redaction and sign-off. It also added a ten-day internal quality checkpoint before the one-month deadline. The checkpoint was not a new approval layer; it was a review of whether the file could answer basic questions without contacting the original handler. Within one quarter, the assurance team reported that request files were more consistent and that late-stage clarifications had reduced. The change did not alter the legal test for disclosure. It improved the organisation's ability to evidence how that test had been applied.

Operating the Model

The pack should be owned by the subject access coordinator and supported by records management, legal and information security colleagues. Data owners need to understand that their search records form part of the evidence, not background material. The DPO or privacy lead should review a sample of packs quarterly, looking for gaps in scope rationale, redaction reasoning and sign-off. Useful metrics include on-time completion, quality assurance pass rate, number of redactions overturned on review and time taken to resolve clarification requests.

The evidence pack should also connect to wider governance controls. Search records depend on good records management. Redaction decisions may depend on retention schedules and information asset registers. Timeliness depends on clear roles and escalation routes. A standing pack therefore does more than support individual requests; it exposes where the underlying governance system needs attention.

Conclusion

A subject access request is a legal entitlement, but the file that supports it is a governance artefact. Organisations that build the pack as a routine control can answer questions about scope, redaction, approval and timeliness from contemporaneous records rather than memory. The request file should not be assembled after the regulator asks. It should be designed to answer first.