A customer emails: "Can you send me everything you have about me?" There is no form, no ticket, no obvious owner. Someone forwards it to three colleagues, and by the end of the week it is sitting in a shared inbox while a legal deadline quietly ticks down. Small teams rarely struggle with the idea of access requests. They struggle with the plumbing: who answers, how identity is checked, where the data actually lives, and what to send back.

The good news is that a workable process takes an afternoon to design and about a page to write down. Here is how to build one.

Know what actually counts as a request

A data subject access request (DSAR) is any approach from someone asking whether you process their personal data, and asking for a copy of it along with some supporting detail. The person does not have to use the phrase "subject access request", cite an article of the GDPR, fill in your template, or write to the right address. A support chat message, a phone call, a letter sent to your accountant, even a public post on your business page can qualify if the intent is clear.

Two things follow. First, anyone who talks to customers, candidates or suppliers needs to recognise a request and pass it on the same day, without trying to answer it themselves. Second, requests do not only come from customers. Employees, former employees, job applicants, contractors and the contact at a supplier can all ask. Because the deadline is generally one month, the difference between a good process and a messy one is usually measured in days.

Give requests a single front door

Pick one route in and one place to record what happens. A dedicated address such as privacy@yourcompany, monitored by at least two people, beats a personal inbox. Mention it in your privacy notice so people use it. Then keep a simple tracker, a spreadsheet is fine, with a column for each of these:

• Date received, which is when the clock starts
• Who is asking, and through which channel
• What verification you requested and when it arrived
• The deadline, plus any extension and the reason for it
• Who owns the response
• Date sent, and a short note of what was included or withheld

The tracker is what saves you nine months later, when someone asks why a request took five weeks. It also makes patterns visible: three requests from the same account in a fortnight is worth understanding.

Verify identity without turning it into an interrogation

You need to be reasonably sure the person is who they say they are. You cannot use verification as a fishing expedition or as a way to buy time. Ask for the minimum. If the request comes from the email address already on the account, replying to confirm is often enough. If it arrives from an unknown address, ask for one or two details you already hold, such as a customer number or the postcode on the last invoice.

Photo ID is reasonable when the stakes are higher: a shared device, a disputed account, a request that would expose sensitive information. If you ask for it, say why, use it only for this purpose, and delete your copy once the request is closed. Write back promptly when you need something, because the one-month period generally runs from when you have both the request and enough information to confirm identity. That timing point is worth checking with a legal adviser for your own situation.

Run the clock properly

You generally have one month to respond. You can extend by up to two further months where the request is genuinely complex or you have received several from the same person, but you must tell the person within the first month and explain the reason. An extension is not a default and not a fix for a search you have not started.

Set calendar entries the day a request lands: confirm receipt and identity requirements straight away, chase internal data owners around day 14, review the draft around day 21, and send by day 28. If you are refusing or partly refusing, reply inside the month anyway, explain why, and tell the person they can complain to a data protection authority or seek a judicial remedy.

Search widely, then decide what to send

The customer database is the easy part. Data hides in ordinary tools nobody thinks of as a system of record:

• Support tickets, chat transcripts and call recordings
• Shared mailboxes and individual inboxes
• CRM notes, meeting notes and sales pipeline comments
• Marketing lists, consent records and event sign-ups
• Invoices, payment records and delivery details
• Product usage or analytics logs tied to an account identifier
• HR files, if the requester is a current or former employee
• Backups, which you can usually describe rather than mine

Then comes redaction. Remove other people's personal data unless they consented or it is reasonable to disclose it. Remove anything covered by a valid exemption in your jurisdiction. This is the part where general guidance runs out, so take advice when a request touches ongoing disputes, confidential references, legal privilege, or another person's privacy.

Finally, the response itself. Send the data in a clear, readable format, as a PDF or a spreadsheet export, and include a short cover letter covering the purposes of processing, the categories of data, who has received it, how long you keep it, the person's rights, where the data came from, and whether automated decision-making is involved. Explain any redactions briefly rather than silently.

Make it boring, then keep it boring

Write a one-page runbook naming the person who receives requests, the person who verifies identity, the people who search each system, and the person who signs off the reply. Keep template acknowledgement and cover letters in the same folder as the tracker.

Then test it once a year with a dummy request sent from an unfamiliar address. You will find the gaps quickly: a departed employee's mailbox, a marketing tool nobody remembered, an owner who left the company. Fix those while nothing depends on it. Small teams handle access requests well when the process is unremarkable, written down, and used every time.

This is general guidance, not legal advice. Access request rules and exemptions vary by country and by situation, so speak to a qualified data protection lawyer about anything unusual.

Photo: aathif_aarifeen / Pixabay