Purpose and Scope
This procedure sets out how [Organisation Name] handles requests from individuals accessing their personal data under data protection laws.
It applies to all requests from any individual, including customers, current and former staff, job applicants, and suppliers, no matter how the request arrives or who receives it.
Working through related paperwork at the same time? See also our Privacy Notice for Employees Template, UK Data Breach Response Procedure Template and US Data Breach Response Procedure Template.
Recognising a SAR
- Any request by an individual for a copy of their personal data is a SAR (e.g., “send me a copy of my file” or “what information do you hold on my account?”).
- Requesters do not need to say “subject access request”, cite data protection laws, or write it down. Verbal requests are valid.
- Requests can arrive through any channel: email, letter, phone, social media, or in person.
- Third parties (such as solicitors or family members) can submit requests. Verify written authority to act for the individual before releasing any data.
- If you are unsure whether a message is a SAR, send it immediately to [Role] to decide.
Roles and Responsibilities
- SAR Owner ([Role], Deputy [Role]): Logs, manages, reviews, and signs off on every request.
- Managers: Ensure their teams forward any potential SAR to the SAR Owner on the day they receive it.
- IT and System Administrators: Run searches across managed electronic systems when tasked.
- All Staff: Route incoming requests to [Role] immediately. Do not ignore, delay, or try to handle a SAR yourself.
Use our templates to fast-track your documentation
Customize this template and 100s of others for free in Whale, the fastest way to get your team aligned.
Procedure
1. Logging, Acknowledgment, and Verification
- Forward the request to [Role] on the same working day you receive it.
- Log the receipt date. The statutory deadline for a response is one calendar month from the date the organisation first receives it.
- Send a written acknowledgment to the requester confirming receipt and the response deadline.
- Verify the requester’s identity if genuine doubt exists. Ask for the minimum necessary ID documents only, and do not use identity checks to stall processing.
- If the request scope is unclear, contact the requester quickly to clarify.
2. Search and Data Collection
- Map out all systems and locations likely to hold the requester’s personal data (e.g., email, HR systems, CRM, booking software, CCTV, shared drives, messaging tools, and paper files).
- Search using the requester’s full name, known aliases, email addresses, employee numbers, or account IDs.
- Pause routine record deletion and retention schedules for all relevant records while the request is open.
- Save all retrieved files in a secure working folder at [File Location]. Limit access strictly to staff handling the request.
3. Review and Redaction
- Remove or redact third-party personal data unless that person consented or it is reasonable to disclose it without consent. Document the reason for every redaction.
- Apply statutory exemptions narrowly. Document which exemptions you used and the rationale for each.
- Make sure records are readable and clear. Explain internal codes, technical jargon, or abbreviations where needed.
- Compile mandatory supplementary details (processing purposes, data categories, recipients, retention periods, and individual rights). Attaching the current privacy notice usually covers this.
- Submit the finished bundle and supporting notes to [Role] for final review and sign-off.
4. Response Issue
- Send the final response bundle securely (e.g., encrypted file transfer, secure portal, or tracked mail) before the deadline.
- Include a cover letter detailing the response, explaining any redactions or exemptions, and outlining the requester’s right to complain to the supervisory authority.
- Record the dispatch date, delivery method, and an exact copy of the disclosed bundle in the central log.
Records and Review
The master SAR log lives at [File Location]. It tracks every request’s details: receipt date, ID checks, search terms, redaction notes, and response information.
Store response packages and audit trails at [File Location] for [Retention Period] after closure to handle follow-up queries or regulatory audits.
We review this procedure [Review Frequency], or after any request that runs late or prompts a complaint.
- Document Owner: [Role]
- Approved By: [Role]
- Next Review Date: [Date]
FAQs on a subject access request procedure
What is a subject access request procedure?
A subject access request procedure sets out how your organisation handles requests from individuals accessing their personal data under data protection laws.
Having it written down means the same rules apply to everyone, so managers are not making judgement calls case by case under pressure.
What does a subject access request procedure include?
This template covers recognising a SAR and procedure.
Every section is written to be filled in. The bracketed placeholders mark the decisions that are yours to make, such as timescales, approval owners and retention periods.
How to implement a subject access request procedure with Whale
Copy this template into Whale and work through the bracketed placeholders so it reflects how your organisation actually operates.
Assign it to the teams it applies to so it sits where people work rather than in a shared drive, and set a review date so it gets revisited on schedule instead of quietly going out of date.
Use our templates to fast-track your documentation
Customize this template and 100s of others for free in Whale, the fastest way to get your team aligned.