What a DSAR is (and what it isn’t) in the UK
A Data Subject Access Request (DSAR) is a formal way to ask an organisation for a copy of the personal data it holds about you under UK data protection law. In practice, it’s a structured “show me what you know about me” request, covering things like account details, correspondence, call recordings, CCTV images (where you’re identifiable), internal notes linked to your profile, and basic information about how your data is used and shared.
A DSAR isn’t a magic shortcut to get every document that mentions you, and it isn’t the same as a Freedom of Information (FOI) request. FOI applies to many public bodies and asks for recorded information generally; a DSAR is specifically about your personal data, whether the organisation is public or private. It also isn’t a guaranteed way to obtain “all emails” or “the full file” if parts don’t count as your personal data, are covered by exemptions, or would reveal someone else’s information.
It’s also not a complaint process, although it can support one. If you’re disputing a decision (for example, a service issue or account action), a DSAR may help you understand what data was used, but it won’t force the organisation to change outcomes. Likewise, a DSAR doesn’t require you to use special wording—any clear request for your personal data can qualify.
For a UK DSAR process checklist, focus on: identifying the right organisation/contact, specifying time periods and systems (email, app, CCTV), providing enough details to locate your records, and being ready to confirm your identity if asked.
DSAR timelines, extensions, and what counts as ‘day one’
In the UK, most DSARs must be answered “without undue delay” and within one month. For many organisations, the clock starts on day one as soon as they receive your request (including by email, webform, letter, or social media message), not when they decide to log it internally.
Day one can shift if the organisation reasonably needs something before it can act. Common examples include:
- Identity checks: if they genuinely need proof of ID (for example, where there’s a risk of disclosing data to the wrong person), the timeline typically starts once they have enough to verify you.
- Clarification: if your request is broad (e.g., “everything you hold on me”), they can ask you to narrow it. They should still begin reasonable searches, but the one-month period is often treated as starting once you clarify what you want.
Organisations can extend the deadline by up to two further months (so up to three months total) if the request is complex or you’ve made multiple requests. They must tell you about the extension within the original one-month period and explain why.
Weekends and bank holidays count. If the deadline falls on a non-working day, many organisations respond on the next working day, but you should still treat the calendar date as the target.
Practical checklist: keep a copy of your request, note the date/time sent, save any auto-receipts, and record when you provided ID or clarification—these are the key dates for tracking the DSAR timeline.
The DSAR process checklist: step-by-step workflow from intake to close
- 1) Log the request (Day 0): Record date/time received, channel (email, web form, post, verbal), requester details, and what they’re asking for. Create a case ID and store all correspondence in one place.
- 2) Confirm it’s a DSAR: Check the wording—people don’t need to say “DSAR” or “GDPR”. If they’re asking for their personal data, treat it as a DSAR.
- 3) Acknowledge receipt: Send a short confirmation, explain the usual response timeframe, and outline what you may need next (ID, clarification, scope).
- 4) Verify identity (if needed): Use proportionate checks based on risk. If information is missing, request it promptly and document what you asked for and why.
- 5) Clarify and narrow scope: If the request is broad, ask targeted questions (date ranges, systems, specific interactions). Agree search terms where helpful.
- 6) Map data sources: List likely locations (CRM, email, ticketing, HR files, call recordings, CCTV, backups, third-party processors). Assign owners and deadlines.
- 7) Collect and preserve: Export relevant records, keep an audit trail, and avoid altering data. Note any technical limits (e.g., retention periods).
- 8) Review and redact: Remove third-party personal data where appropriate, check for exemptions, and ensure redactions are consistent and reversible only internally.
- 9) Prepare the response pack: Include the data, purposes, categories, recipients, retention, source (if not from the person), and rights information in plain English.
- 10) Deliver securely: Use encrypted files, secure portals, or recorded post. Confirm delivery and keep proof.
- 11) Close the case: Document actions taken, searches performed, decisions made, and lessons learned; update your DSAR log and retention schedule.
Identity verification and authority checks (employees, ex-employees, agents)
Before searching or sharing any personal data, confirm who is making the DSAR and whether they’re entitled to receive the information. Use a consistent, documented approach so requests are handled fairly and securely.
- Current employees: verify via internal controls first (logged-in HR portal, company email from a known address, or an in-person check). If the request arrives from a personal email, ask for additional proof.
- Ex-employees: treat as higher risk. Request two forms of evidence where proportionate (for example, photo ID plus proof of address), and match details against your records (name, previous address, employee number, dates of employment).
- Agents (including solicitors, unions, family members): require written authority signed by the data subject that clearly permits the agent to act and receive the response. Confirm the data subject’s identity separately, and verify the agent’s identity using professional credentials or contact details from an independent source.
Keep checks proportionate: only request what you need to be confident, and avoid collecting excessive documents. If you receive copies of ID, store them securely, limit access, and set a retention note (for example, delete once verification is complete unless you need to evidence your process).
If identity or authority is unclear, pause the clock while you ask for clarification, and record the date you requested it. Log: what you asked for, what was provided, who verified it, and the decision. If there’s a mismatch or suspected impersonation, escalate internally and avoid disclosing any data until resolved.
Scoping the request: clarifying questions that reduce risk and effort
Before you send a UK DSAR, tighten the scope with a few clarifying questions. This reduces delays, avoids unnecessary redactions, and helps the organisation find the right records first time.
- Which legal entity should receive it? Ask for the exact company name (and ICO registration, if they have one) and the correct DSAR contact email or portal.
- What identity checks will you require? Confirm what documents are acceptable and whether you can redact non-essential details (for example, covering document numbers) to minimise data exposure.
- What time period should we focus on? Propose a date range (e.g., “Jan 2023–present”) and ask if they can search older archives if needed.
- Which systems will you search? Request they include email, CRM/ticketing systems, call recordings, chat logs, marketing platforms, CCTV (if relevant), and archived backups where reasonably accessible.
- What identifiers should I provide? Ask what helps matching: account numbers, previous addresses, phone numbers, usernames, device IDs, or reference numbers.
- Can you confirm the preferred format? Specify you’d like a secure electronic copy (PDF/CSV) and ask how they’ll deliver it (encrypted email, secure link, portal).
- Are there third parties involved? Check whether processors, group companies, or outsourced call centres hold data and whether your request should name them.
- How will you handle exemptions and redactions? Ask them to explain any withheld information and to provide a schedule of categories withheld where possible.
Where to search: a system-by-system data map for SaaS, HR and finance teams
Use this data map to locate personal data quickly and consistently when working through a UK DSAR process checklist. Assign an owner per system, capture the search method (UI export, API, admin console), and record date ranges and identifiers used (name, email, employee ID, customer ID, device ID).
- SaaS product & app data: production database records, user profiles, preferences, in-app messages, feature flags, support chat embedded in-app, audit trails. Search by user ID/email; export relevant tables plus change history where available.
- Authentication & identity: SSO/IdP (Azure AD/Okta), MFA logs, access logs, password reset events. Pull sign-in history and account attributes tied to the requester.
- Customer support: ticketing (Zendesk/Freshdesk), live chat, call recordings/transcripts, macros/notes. Search requester email, ticket IDs, and linked organizations; include internal notes if they relate to the individual.
- Marketing & web analytics: CRM (HubSpot/Salesforce), email campaigns, form submissions, cookie consent logs, web event tools. Export contact timelines and form payloads; note that analytics may be pseudonymous unless linked.
- HR systems: HRIS (Workday/BambooHR), ATS, payroll provider, learning platforms, performance tools. Search employee ID and historical records (contracts, absence, disciplinary notes) stored in attachments.
- Finance & billing: invoicing/subscriptions (Stripe/Chargebee), accounting (Xero/NetSuite), expenses, procurement. Search by billing email, customer name, invoice number; include communications about payment issues.
- Collaboration & files: Microsoft 365/Google Workspace, Slack/Teams, shared drives, wikis. Use eDiscovery/search to find messages and documents mentioning the requester; capture file versions and sharing links.
- Security & IT: endpoint management, VPN, SIEM, incident logs. Search device IDs and usernames; include alerts that reference the individual.
Collecting, reviewing and redacting: handling third-party data and sensitive info
When you gather material for a UK DSAR, treat it like an evidence pack: complete, searchable, and safe to disclose. Start by pulling data from each system the person may appear in (email, CRM, ticketing, HR files, call logs, CCTV indexes, messaging tools). Keep an audit trail of what you searched, the date, and the keywords or identifiers used (name, email, customer ID). Export in a stable format (PDF/CSV) and store a working copy separately from the original source records.
Next, review for third-party information. If documents contain other people’s personal data (colleagues, other customers, witnesses), decide whether you can disclose it fairly. Often the practical approach is to redact names, contact details, opinions about identifiable individuals, and any identifiers that could “jigsaw” someone’s identity (unique job titles, locations, reference numbers). Where possible, consider partial disclosure (e.g., “Employee A”) rather than withholding whole documents.
Pay extra attention to special category data (health, ethnicity, biometrics), criminal offence data, safeguarding notes, and anything that could create a risk if shared. Redact by removing the data permanently (not just black boxes that can be copied). Check metadata: comments, tracked changes, file properties, hidden columns, and email headers can leak information.
Finally, quality-check redactions with a second reviewer, confirm the requester’s identity before sending, and package the response securely (encrypted download link or password-protected files sent separately). If you withhold or edit material, record the reason in your internal log so you can explain it clearly if asked.
Common UK exemptions and when to pause or limit disclosure (plain English)
Most DSARs are answered in full, but UK law allows organisations to withhold or delay some information in specific situations. These aren’t “get out” clauses—you should still respond on time, explain what you can, and only limit disclosure where it’s necessary.
Third-party information: If the records include someone else’s personal data (for example, a colleague’s statement or another customer’s details), you may need to redact it. Share what you can without unfairly revealing others’ identities, unless you have their consent or it’s reasonable to disclose.
Legal professional privilege: Communications with lawyers for legal advice or litigation are commonly withheld. This usually covers solicitor emails and notes prepared for a dispute, but not general business emails that merely mention “legal”.
Crime and taxation: You can limit disclosure if providing it would be likely to prejudice the prevention/detection of crime, apprehension/prosecution of offenders, or certain tax functions. This can justify a temporary pause while checks are made, but it should be evidence-based and reviewed.
Management forecasting and negotiations: Some information about business plans (like redundancy planning) or ongoing negotiations may be restricted if disclosure would seriously harm the process.
Health data and serious harm: In rare cases, information can be limited if disclosure is likely to cause serious harm to someone’s physical or mental health.
Manifestly unfounded or excessive requests: If a request is clearly abusive or repeated without good reason, you may refuse or charge a reasonable fee—but document why and consider narrowing the scope first.