Data subject request management is the controlled process used to receive, assess and respond when an individual exercises a right over their personal data. Under the GDPR, these rights include access, rectification, erasure, restriction, portability, objection and protections relating to certain automated decisions.
A request may arrive through a privacy form, email, call centre, branch, social-media message, employee channel or letter. It may not use legal terminology. “Please send me everything you hold about me”, “stop using my data for marketing” and “delete my old account” can all require formal assessment.
The main operational challenge is coordination. Privacy teams rarely hold all relevant data. They depend on business units, system owners, processors, legal counsel, information security and records-management teams. A production-grade workflow must therefore combine a reliable deadline, clear ownership, controlled search and review, defensible decisions and a complete communication history.
Understand the request before starting work#
The first task is classification. Record what the person is asking for in their own words, then identify the applicable right or combination of rights.
Common request types include:
- Access: confirmation of processing, access to personal data and required information about that processing.
- Rectification: correction of inaccurate data or completion of incomplete data.
- Erasure: deletion where the conditions apply and no valid ground for continued retention overrides the request.
- Restriction: limiting processing while a dispute or condition is resolved.
- Portability: provision of eligible data in a structured, commonly used and machine-readable format, and potentially transmission to another controller.
- Objection: stopping processing based on particular grounds, including direct marketing.
- Automated decision review: obtaining safeguards in relation to certain solely automated decisions with legal or similarly significant effects.
One message can contain several rights. The system should support a primary type for reporting and multiple linked rights for execution. It should also distinguish a rights request from a complaint, ordinary customer-service query, litigation request, law-enforcement request or data breach report, while allowing related cases to be linked.
Start the clock from the correct trigger#
The European Data Protection Board explains that organisations should respond to a data subject request within one month. Where a request is complex or numerous, the period may be extended by two further months, provided the individual is informed within the initial month.
Operationally, the application should store:
- The date and time received.
- The intake channel and original message.
- The applicable legal entity or controller.
- The calculated original due date.
- The time zone and deadline-calculation rule.
- Any clarification or identity-verification activity.
- Extension eligibility, decision, approver and revised due date.
- The date and method of the extension notice.
- The final response date.
Do not allow users to overwrite the original deadline. Any revised date should sit alongside the original so that audit and management reporting remain transparent.
The organisation should define how weekends, public holidays and calendar-month calculations are handled for each jurisdiction. Legal interpretation belongs in policy and configuration, not in ad hoc user judgement.
Build intake that recognises informal requests#
A dedicated web form improves data quality, but individuals should not be forced to use one channel unless applicable law permits it. Front-line teams need a simple way to route a potential request to privacy without deciding the legal merits themselves.
A good intake record captures the requester's name and contact details, relationship to the organisation, account or employee identifiers, request text, countries involved, preferred communication channel and any representative details. It should avoid collecting excessive identification material at the outset.
Every intake should receive a unique case ID and acknowledgement. Duplicate detection should compare requester identifiers, dates and request text, but users must decide whether records are true duplicates, related requests or separate exercises of rights.
Verify identity proportionately#
Identity checks should prevent disclosure to the wrong person without creating disproportionate barriers. The workflow can support authenticated accounts, verified contact channels, security questions, document checks and manual escalation. Record the method, evidence, reviewer, outcome and date; restrict and retain identification evidence only as needed. Representatives require authority checks, and special handling may apply to employees, minors or vulnerable people. Useful statuses are Not Required, Pending, Verified, Failed and More Information Required.
Clarify scope without creating unnecessary barriers#
Broad access requests can cover emails, call recordings, case notes, transaction data, CCTV, analytics, archived records and processor-held information. Clarification can make searches more efficient, but it should not be used to narrow a valid request unfairly.
Record the proposed scope, date range, products, accounts, systems, people, locations and keywords. Preserve the requester's response and the final agreed or determined scope. If part of the request can proceed while another part is clarified, the workflow should support parallel work.
A processing inventory is especially valuable here. The requester category, product and relationship can identify likely processing activities, systems, processors and owners. Without that connection, every request begins with a manual search for where data might exist.
Create controlled search tasks#
The privacy case owner should generate search tasks for relevant system owners and business teams. Each task should specify:
- The system, repository or process to search.
- The individual identifiers and approved scope.
- The search instructions and date range.
- The assigned owner and due date.
- The required response format.
- Whether no data found must be explicitly confirmed.
- Whether data should be exported, corrected, restricted or deleted.
- Any security or transfer requirements.
Contributors should return a structured response: completed, no data found, data provided, action completed, unable to search or clarification required. They should attach evidence or provide a secure reference. The case should not progress to final review while critical tasks remain open unless an authorised exception is recorded.
Processor-held data should be included where relevant. Contractual arrangements should define support obligations and response expectations so that the controller has enough time to review the results.
Separate collection, review and disclosure#
Collected material is not automatically ready to send to the individual. The organisation must review whether the content is within scope, whether it contains the personal data of other people, whether restrictions apply, and whether the response is understandable and secure.
A useful review pipeline is:
- Collection: Receive exports and confirmations from each source.
- Normalisation: Convert data to workable formats, remove technical duplicates and organise it by source or chronology.
- Relevance review: Identify the requester's personal data and remove clearly out-of-scope material.
- Rights and restrictions review: Consider the rights and freedoms of others, confidentiality, privilege and applicable legal restrictions.
- Redaction: Mask or remove material that should not be disclosed.
- Quality assurance: Confirm completeness, consistency, readability and secure packaging.
- Approval: Obtain the required privacy or legal sign-off.
- Delivery: Send through the approved channel and retain proof.
Preserve the original, working copy, redacted output and final package as distinct, access-controlled versions.
Make decisions explicit#
Not every request will be fulfilled exactly as submitted. The organisation may fully fulfil, partially fulfil, refuse, seek clarification, extend, redirect or determine that no relevant data is processed. The application should require a decision type, rationale, legal or policy basis, approver and communication.
For erasure, outcomes may vary by category: marketing data might be deleted while transaction records remain under a legal obligation. Record what was erased or retained, why, and in which systems. Objection, rectification and restriction decisions should create executable suppression, correction, notification or hold actions with completion evidence.
Communicate clearly and securely#
A response should be concise, transparent and understandable. The case record should store acknowledgement, clarification requests, extension notices, decision notices, delivery messages and any follow-up.
Delivery security should reflect the sensitivity and volume of the material. Options may include an authenticated portal, encrypted file transfer, password-protected package with separate password delivery or verified postal service. Ordinary email may be inappropriate for a large or sensitive access package.
Record the delivery channel, destination, date, successful delivery evidence, expiry date and any failed attempts. A final response should not be marked complete merely because a file was generated.
Design the data model around one case and many tasks#
The core case should hold requester, controller, rights, dates, deadlines, status, owner, risk and final outcome. Related records should hold verification, scope versions, search tasks, systems and processors searched, collected packages, review and redaction logs, decisions, communications, operational actions, approvals, legal holds, evidence and audit history. This supports complex cases without one unmanageable form.
Measure what improves performance#
Useful data subject request metrics include:
- Requests by right, channel, controller and business unit.
- Median completion time, due-soon and overdue cases.
- Time spent in verification, search, review and approval.
- Search-task and processor performance.
- Extensions, partial outcomes, refusals, reopened cases and complaints.
- Systems causing repeated delay or incomplete searches.
- Operational actions still open after the response.
A high on-time percentage can hide quality problems if teams send incomplete responses. Combine timeliness with quality assurance findings and reopened cases.
Common data subject request failures#
Common failures include starting the clock only when privacy notices the request, excessive identity checks, coordinating searches in email, confusing whole documents with the personal data in scope and closing the case while correction, deletion or restriction actions remain incomplete. Front-line routing, proportionate verification, structured tasks and linked operational actions address these weaknesses.
Frequently asked questions#
What is a DSAR?#
DSAR commonly means data subject access request, a request under the right of access. Organisations often use the term more broadly, but “data subject request” is more accurate when the case concerns erasure, rectification, objection or another right.
How long does an organisation have to respond?#
Under the current GDPR framework, the general period is one month. It may be extended by two further months for complex or numerous requests when the individual is informed within the initial month. Specific calculations and restrictions should be legally validated.
Must a requester use a special form?#
A form can make intake easier, but organisations should be able to recognise valid requests made through other channels. Staff training and routing controls are therefore essential.
Can an organisation ask for identification?#
Yes, where necessary to confirm identity, but the request should be proportionate to the risk. The organisation should avoid collecting more identification data than needed.
Does an access request require disclosure of every document?#
The right concerns personal data and specified information about processing. Whether a full document, extract or contextual material must be provided depends on the content and circumstances. Legal review may be required.
What should DSAR software track?#
It should track intake, requester, rights, verification, scope, deadlines, searches, processor tasks, review, redaction, decisions, communications, delivery, actions, evidence and audit history.
Related Vilfora guides#
- GDPR Compliance Management: Build an Evidence-Ready Privacy Programme
- Record of Processing Activities: A Practical RoPA Guide
- DPIA Process: How to Assess High-Risk Processing
- GDPR Personal Data Breach Response: The 72-Hour Workflow
- Data Privacy Risk Management: From Data Inventory to Breach Response
Authoritative references#
- GDPR Articles 12–22 and full legal text — EUR-Lex
- European Data Protection Board: Respect individuals' rights
- EDPB Guidelines 01/2022 on the right of access
- European Commission: Information for individuals
This article provides general information and implementation guidance. It is not legal advice. Organisations should obtain advice for their circumstances and verify current EU, national and sector-specific requirements.
