A subject access request lands in the support inbox on a Friday afternoon. Someone forwards it to engineering, and it turns out you need to produce everything your systems hold about one person — across the app, the warehouse, the CRM and whatever that legacy service is called. The clock has already started. The good news is that the hard part isn't the law; it's the plumbing. Get an authenticated request endpoint, a dependable export job and a decent audit trail in place, and a DSAR becomes a routine task rather than a fire drill.
What a DSAR actually asks of your code
The right of access sits alongside related rights — rectification, erasure, portability — and the mechanics are broadly similar. Someone asks what you hold about them; you confirm whether you're processing their data, supply a copy, and add context: why you have it, where it came from, who you share it with, how long you keep it.
The statutory deadline is one month, extendable by a further two months for complex requests. From an engineering seat, that translates into three deliverables: a way to receive and track requests, a way to gather and deliver the data accurately, and a record of both.
This is engineering guidance, not legal advice. Your obligations depend on your circumstances — exemptions, international transfers, sector rules — so involve your legal or data protection lead early rather than at the deadline.
Map the data before you build the endpoint
You cannot export what you cannot find. Before writing any code, list every place personal data lives: the primary database, the analytics warehouse, the CRM, the support tool, log storage, backups, and the processors acting on your behalf. For each one, note the owner, the fields that count as personal data, and the retention period.
Keep that map in the repository as a versioned document. A data map held in one person's head is not a data map; it's a single point of failure. Where you can, generate it: a script that scans schemas for columns matching patterns like email, phone, name or address gives you a starting inventory and, more usefully, a warning when someone adds a new one.
Designing the request endpoint
Verify identity, properly
Put the endpoint behind your normal authentication. A public form that accepts a name and an email address is an open door for someone to request another person's data. If the requester isn't a logged-in user you can verify directly — a customer, an employee — add a step: a challenge sent to a contact detail you already hold, plus manual review for anything unusual. Record the verification decision and who made it.
Process asynchronously
Gathering data across four systems can take minutes. Accept the request, return a reference, and hand the work to a background job. Model clear states — received, verifying, in progress, ready, delivered, rejected — and expose them to the support team so nobody has to ask you where things stand.
Validate the inputs
- Tie every request to a verified subject identifier rather than a free-text search.
- Rate-limit submissions per account to blunt abuse.
- Reject requests for accounts that don't exist without confirming that fact — otherwise you've built an enumeration oracle.
- Record the scope: access, rectification, erasure or portability.
Build the export around people, not tables
Structure the output around the subject's experience, not your schema. A JSON document with sections per system — account, orders, support tickets, marketing consents — is far more usable than a folder of raw table dumps, and it reduces the follow-up questions that eat into your deadline. Where portability is expected, offer CSV or JSON per section.
Redaction is not optional. A support thread contains other people's words; an order may carry a delivery address for someone else. That isn't the requester's personal data, and handing it over indiscriminately is its own incident. Build redaction into the exporter rather than relying on a human to spot it at the end.
Include the supplementary information in the same document: purposes of processing, categories of data, recipients, retention periods, the source of the data, and whether automated decision-making is involved. Deliver it as an encrypted archive with the password sent by a separate channel, behind a download link that expires and is limited in use. Never email the plain archive.
Audit logs that would hold up under scrutiny
Your audit trail is evidence, so log events rather than payloads:
- Who made the request, and when.
- How identity was verified, and by whom.
- Which services were queried, and what each returned — counts, not contents.
- Who approved, generated or downloaded the export.
- When the export was delivered, and when it was deleted.
Use append-only storage with tightly restricted access, and keep entries at least as long as you'd need to demonstrate compliance. Be disciplined about not copying personal data into the log itself: exported 412 records for subject reference 8842 is sufficient, and a full dump of what was exported would be a second copy of the very thing you're trying to control.
Edge cases worth handling before they bite
Erasure requests that arrive mid-export need a defined order of operations — decide whether erasure waits for delivery or the other way round, and write it down. Backups usually can't be edited surgically, so be straightforward in your response about what will expire and when. Watch for one person with two accounts, shared family accounts, and processors who may need the request forwarded to them or data retrieved from them depending on your contract. And where a legal hold or exemption applies, flag it explicitly rather than quietly omitting the data.
A workable sequence of work
- Write the data map and keep it current.
- Ship the request endpoint with verification and status tracking.
- Implement one exporter end to end — the messiest system first, because it sets the pattern.
- Add redaction and the supplementary information template.
- Wire up the audit trail before you process a real request, not after.
- Test with an account you control, then write a runbook so support can triage without you.
Do this while nobody is asking, and the Friday-afternoon email becomes a fifteen-minute job. Leave it until the request arrives, and you'll be reconstructing a data map under a statutory clock — which is exactly the moment you least want to be guessing.
Photo: IqbalStock / Pixabay
