Data subject access request process: how to meet the GDPR deadline every time

What is a data subject access request, and what does the process need to do?

A data subject access request is an individual asking an organisation whether it processes their personal data and, if it does, for access to that data. The right sits in Article 15 of the GDPR; Article 12 sets how every rights request is handled, including the response time and the principle that answering is free of charge. A working data subject access request process turns those two articles into a routine anyone in the organisation can follow: recognise the request, log it, confirm who is asking, find the data, review it, reply securely and keep the record.

Requests rarely arrive labelled. A customer e-mails support asking "what do you hold on me", or a caller asks for copies of recorded calls. Either can be a valid request, and the safe working assumption is that the month runs from the day it reaches anyone in the organisation, not the day it reaches the privacy team. The process therefore starts with people who are not privacy specialists, which is why the GDPR training guide puts recognising a request in the awareness every employee receives.

The same routine, with a different reply template, handles the other rights; the GDPR requirements guide explains each of them.

The deadline: one month, and when two more are possible

Article 12(3) requires information on the action taken to be provided without undue delay and in any event within one month. The period may be extended by two further months where necessary, with the reasons given to the requester. Send that notice before the first month ends, so the person is never left waiting past the original date without word. "Without undue delay" matters as much as the ceiling: a reply that could have gone out in ten days and was held until day thirty is hard to defend.

Treat the extension as an exception you can justify in writing, not a buffer. A search that simply started late is a weak reason; one spanning several entities, archives and processors is stronger. Whatever the reason, record it in the log on the day the decision is made.

Working backwards from the due date gives a timetable a mid-sized organisation can hold for most requests.

A data subject access request process in six steps

1. Recognise and log

Give every channel one route into the process: a shared mailbox or a form in your request workflow, and a simple rule that anything resembling a request is forwarded the same day. The coordinator logs it with the date of receipt and the calculated due date before doing anything else.

2. Confirm identity, proportionately

Disclosing one person's data to someone impersonating them can itself be a personal data breach. Check identity against information you already hold where you can, and ask for more only when there is real doubt.

3. Search every source

Run the search from a written plan (see the next section), with each system owner confirming what was searched and what was found.

4. Review before release

Read the material. Remove information about other people where disclosure would affect them, and route any proposal to withhold or limit information to your legal advisers; that is a legal judgement, and the reason belongs in the log.

5. Respond securely

Send the reply in a form the requester can use, through a channel that protects it: an encrypted portal or a password-protected file with the password sent separately, never an open attachment to an unverified address.

6. Close and learn

Close the log entry with the date sent and keep the response pack for your retention period. Repeated delays from the same system are an action for the programme.

Finding every record about one person

Most missed deadlines trace back to the search. The customer database is found; the ticketing tool, call recordings, interview notes and personal spreadsheets are forgotten.

The record of processing is the starting map. Each activity it lists names the categories of data and the systems behind them, so for any requester you can see which activities are likely to hold their data and which system owners must search. If the record does not name systems, add them; a record that cannot drive a search is not doing its job. The GDPR documentation guide covers how the record itself is built.

• Structured systems: CRM, HR, payroll, billing and support tools, searched by every identifier you hold, not just the name.
• Communications: mailboxes, chat and call recordings, searched with agreed terms and a defined date range.
• Unstructured files: shared drives, collaboration sites and paper files held in an organised way.
• Processors: cloud platforms, payroll bureaux and outsourced contact centres. Among the Article 28(3) terms every processor contract must carry is assistance with responding to rights requests, so ask for it in writing and set them a reply date well inside your own.

Agree search methods with IT once, in advance: who runs mailbox searches, how archives are queried and how results are exported.

What goes in the response pack

The reply confirms whether you process the person's data and provides access to it, normally as a copy. A useful reply also explains the processing, and Article 15 sets out what that explanation must cover. Most of it is information your record of processing already holds for each activity: the purposes, the categories of data, who receives it, whether it leaves the EU and EEA, and how long it is kept. Drawing it from the record keeps replies consistent.

A covering letter should say plainly what is enclosed, what was searched, what (if anything) was withheld and on what basis, and how the person can raise a concern with you or complain to the supervisory authority. Where the request came electronically, reply electronically in a format the person can open, unless they ask for something else. Article 12 makes the response free of charge in principle; any departure from that should be a decision taken with legal advice and recorded.

Evidence that the process works

The log is the proof. For each request it should show the date received, the requester, the right exercised, the due date, the verification step, the sources searched, any extension and its reason, anything withheld and why, and the date the reply was sent. It also gives management its numbers: volumes, the share answered inside the month, extensions and the systems that caused delay.

Test the process before a regulator or a client does. An internal audit samples closed requests and traces each one from receipt to reply; the GDPR internal audit guide shows where that fits in the annual programme. A rehearsal with a staff volunteer finds the system nobody knew how to search.

Data subject access requests: questions buyers ask