The first data subject access request feels manageable. Someone emails asking for a copy of their data, you dig around, and you send something back. The tenth request in a busy month is a different story. Now you're juggling deadlines, hunting through systems, and worrying about whether you exposed someone else's data by accident.
A data subject access request, or DSAR, is any request from a person to exercise their rights over their personal data. Handle them one at a time and each one steals a day from someone. Handle them as a workflow and they become routine. This guide covers the rights involved, the deadline you're working against, and how to build a process that holds up when the volume climbs.
The rights behind a request
People whose data you hold can exercise several rights, and a single request can touch more than one. You need to recognize which right applies before you can answer it.
- Access. The person can ask for a copy of their personal data and information about how you use it. This is the most common request and the one people mean when they say "DSAR."
- Rectification. They can ask you to correct data that's wrong or incomplete.
- Erasure. They can ask you to delete their data, sometimes called the right to be forgotten. It isn't absolute, so you can refuse when you have a legal reason to keep the data.
- Portability. They can ask for their data in a structured, common format they can take elsewhere.
- Objection. They can object to certain processing, like direct marketing, and you have to stop unless you have overriding grounds.
Recognizing the right matters because each one has a different answer. An erasure request you can't fully honor still needs a documented reason. A portability request needs a machine-readable export, not a PDF. Logging the request type from the start keeps the response honest.
The clock: one month, and when you can extend
You have one month to respond, counted from the day you receive the request. For most teams that's plenty of time, until three requests land in the same week and the person who knows where everything lives is on vacation.
You can extend by up to two further months when a request is genuinely complex or when someone sends several at once. The catch is that you have to tell the person within the first month, and you have to explain why. An extension you forget to communicate isn't an extension, it's a missed deadline. So the clock has to be visible from the moment a request arrives, not something you reconstruct later.
Start the clock immediately
Log the request the day it arrives, even before you know what it's asking for. The deadline runs from receipt, not from the day you get around to reading it. A request sitting in a shared inbox for a week has already eaten a quarter of your time.
Verify who's asking
Before you hand over anyone's personal data, you have to be sure the request comes from the actual data subject. Sending a full profile to an impostor is a breach, not a good deed.
Verification should be proportionate. For an existing account, confirming control of the registered email or authenticating through the normal login is usually enough. For a sensitive request from someone you can't easily identify, you can ask for more, but you can't demand so much documentation that you turn verification into an obstacle. Record what you checked and when, so the decision is defensible later.
Find where the person's data lives
The hard part of any access or erasure request isn't the response. It's knowing every place the person's data actually sits. Miss a system and your "complete" copy is incomplete, and your erasure leaves data behind.
This is where a current record of processing activities earns its keep. If you already know which activities process personal data, which categories they hold, and which systems and processors are involved, finding a person's footprint becomes a lookup instead of a search party. Without that map, every request turns into an investigation, and the answer is only as good as the memory of whoever happens to be around.
Redact everyone who isn't the requester
A person has the right to their own data, not to everyone else's. Real records are messy. A support ticket mentions a colleague, an email thread includes three people, a note names an account manager. Before you release anything, you have to redact the personal data of third parties, unless they've agreed or it's reasonable to disclose it.
This is slow, error-prone work when you do it under deadline pressure. Building redaction into the workflow as a required step, with a second reviewer for anything sensitive, keeps a rushed export from becoming its own breach.
Build a workflow, not a fire drill
Every DSAR runs through the same stages: receive, verify, locate, gather, redact, review, respond, and record. When those stages live in someone's head, quality depends on who caught the request. When they live in a workflow with an owner at each step, quality stays constant no matter the volume.
OptiTech logs each request, assigns an owner, and tracks the deadline against the record of processing activities in the OptiTech Console. The owner sees what type of request it is, when it arrived, and when it's due. The link to your processing register shows where the person's data lives, so locating it isn't guesswork. Every action leaves evidence, so when someone asks how you handled a request last quarter, the trail is already there.
That trail matters twice. It proves to a regulator that you responded properly, and it shows a prospect's security team that you take rights seriously. The same workflow that keeps you compliant becomes something you can point to.
Turn a burden into a signal
Enterprise buyers ask how you handle data subject rights, because it tells them how you'll handle their customers' data. "We have a documented DSAR workflow with owners and deadlines" is a far better answer than "we deal with those as they come in."
A trust center backed by your OptiTech program lets you show that posture without a meeting. Buyers see that you have the process, the records, and the controls, and one more question answers itself.
Start small. Log every request in one place, put a name on each stage, and connect the workflow to your record of processing activities so locating data stops being the bottleneck. Do that once and the tenth request in a busy month feels like the first.
Ready to make DSARs routine? Book a demo and see how OptiTech logs each request, assigns an owner, and tracks every deadline.
