Privacy laws around the world grant individuals rights over their personal data. When someone exercises those rights, the formal request that reaches your team is a data subject request (DSR). The specific laws vary by jurisdiction like the EU, United Kingdom, Brazil, a growing number of U.S. states, and countries across Asia, Africa, and the Americas all have frameworks in place, but the core obligations are remarkably consistent: know what data you hold, respond within a defined window, and document everything. This guide covers what those obligations look like in practice.
What Is a DSR?
A DSR is a formal request from an individual to exercise privacy rights over personal data your organization holds. It’s the umbrella term covering all types of rights requests. You’ll also see DSAR (data subject access request), which refers specifically to requests for access, but individuals can request much more than that, including deletion, correction, portability, and opt-out of sale or sharing.
One important principle applies across virtually every framework: jurisdiction follows the individual, not your company’s headquarters. Under some laws that means anyone located in the jurisdiction at the time of processing; under others it means residents of the jurisdiction. Either way, a single organization can owe obligations under multiple laws simultaneously. You don’t need to memorize every statute, but you do need a data subject request management process that accommodates the variation.
What Rights Do Privacy Laws Grant?
The specific rights available to an individual depend on which law applies, but the categories are broadly consistent across frameworks. Your process needs to be able to handle all of them.
| Right | What it means |
| Access | Receive a copy of the personal data an organization holds about you, along with details about how it’s being processed. |
| Deletion / Erasure | Request that an organization delete your personal data from its systems and, where applicable, from downstream processors. |
| Correction / Rectification | Request that inaccurate or incomplete personal data be updated. |
| Portability | Receive your personal data in a structured, machine-readable format that can be transferred to another organization. |
| Opt-out of sale or sharing | Direct an organization to stop selling or sharing your personal data with third parties. |
| Restrict processing | Limit how an organization uses your data, often while a dispute about accuracy or lawfulness is resolved. |
| Object to processing | Object to specific types of processing, such as direct marketing or profiling. |
| Automated decision-making | Request human review of decisions made solely by automated systems, or opt out of automated profiling. |
| Non-discrimination | Exercise any of the above rights without receiving degraded service or pricing. |
Not every law grants every right listed above, and definitions of personal data vary across jurisdictions. But if your program can handle each of these categories, you’re positioned for the requirements you’ll encounter regardless of where a request originates. Some frameworks also require you to honor automated opt-out signals (like Global Privacy Control) as formal requests. If your program doesn’t account for those, it’s worth closing that gap. DataGrail’s Do Not Sell or Share solution can help enforce opt-out requirements across your entire data ecosystem.
How Long Do You Have to Respond?
Most privacy frameworks give you 30 to 45 days for an initial response, with extensions available in complex cases that typically bring the total maximum to around 90 days. Some frameworks set tighter windows with no extension provision at all. Extensions generally aren’t automatic, you need to notify the individual of the delay and the reason within the original response window.
The clock starts when the request is received, not when it’s validated. Mature programs set internal SLAs tighter than the legal maximum and track deadlines per request. If you’re managing requests across multiple jurisdictions, a centralized tool like DataGrail’s Request Manager can track deadlines automatically and flag requests approaching their due date before you’re at risk of a late response.
What Goes in a DSR Response?
The contents of your response depend on the type of request. Here’s what each typically requires.
| Request type | What you deliver |
| Access | Copy of personal data held, processing purposes, categories of recipients, retention periods, and information about the individual’s other rights. |
| Deletion | Confirmation that data has been deleted, any exemptions applied (with reasoning), and status of downstream propagation to processors and vendors. |
| Correction | Confirmation that data has been updated, with a description of what was changed. |
| Portability | Personal data provided in a structured, commonly used, machine-readable format (e.g., CSV, JSON). |
| Opt-out | Confirmation that sale or sharing has ceased, and propagation status to downstream systems and third parties. |
Regardless of request type, redact any third-party personal information before delivery, use a secure transmission method, and retain a copy of the response and your fulfillment documentation for your records.
How to Process a DSR
The operational steps are consistent across frameworks. The decisions within each step are where the variation shows up.
- Intake and verification. Provide a clear submission channel (e.g., a web form, dedicated email, or centralized portal) and verify the requestor’s identity before disclosing any data. Verification must be proportionate to the sensitivity of the data involved. Over-verifying opt-out requests can itself be a compliance issue in some jurisdictions. Where possible, authenticate using data you already hold rather than collecting new sensitive information. DataGrail’s patented Smart Verification™ handles this by verifying requestors against existing data without requiring government IDs or selfies. If your jurisdiction allows authorized agent submissions, maintain clear procedures for verifying agent authority.
- Scope determination. Identify which rights are being exercised, which law applies based on where the individual is located or resides, and whether any exemptions narrow the scope. A deletion request under legal hold, for example, requires documentation, not fulfillment. DataGrail can automatically apply the correct policy for a request and label any special circumstances.
- Data discovery. Locate the individual’s personal data across every system that holds it, like your CRM, marketing platforms, HR systems, SaaS tools, data warehouses, and service providers. This is where most teams lose time. If your data map is current, retrieval is straightforward. If it isn’t, you’re building the map under deadline. DataGrail’s 2,400+ integrations can search connected systems automatically to locate personal data in minutes rather than days.
- Review, act, and propagate. Review responsive data, apply any required redactions, and take the required action. Then push the request downstream: deletion and correction requests need to reach your service providers and processors too, and you need to track confirmation that those actions were completed. This downstream coordination is a core operational requirement, not something to handle ad hoc. DataGrail handles the project management of distributing and centralizing requests across partners and ensuring they meet request deadlines.
- Respond and document. Deliver the response securely within the applicable deadline. Document everything: verification steps, systems searched, exemptions applied, vendor propagation, and final delivery. This audit trail is your compliance proof if questions arise. If a request is denied, some frameworks require you to offer an appeals process. DataGrail keeps the entire record of a request easily accessible.
Common Reasons You Can Limit or Deny a Request
DSRs are not unlimited rights. There are legitimate reasons to limit or deny a request, but the burden of justifying that decision falls on your organization, and it must be documented with a specific legal basis.
| Reason | What it means |
| Legal obligation or retention | You’re required by law to retain the data (e.g., tax records, financial reporting, regulatory retention schedules). |
| Litigation hold | Data is subject to a legal hold and cannot be deleted or altered while litigation or an investigation is pending. |
| Fraud prevention | Fulfilling the request would compromise your ability to detect or prevent fraud. |
| Third-party rights | Disclosure would infringe on another individual’s privacy. This typically results in redaction rather than outright denial. |
| Trade secrets | The data requested is intertwined with proprietary information that cannot be separated without harming legitimate business interests. |
| Manifestly unfounded or excessive | The request is clearly abusive or repetitive to the point of being unreasonable. Frequency alone is generally not sufficient grounds. |
In practice, partial fulfillment with documented reasoning is far more common than full denial. You may need to redact third-party information, withhold data under legal hold, or apply a retention exemption while still fulfilling the rest of the request.
Putting It Into Practice
The principles behind DSR requirements are straightforward. The challenge is executing them consistently across every system that touches personal data, under timelines that vary by jurisdiction, at a volume that keeps growing. That’s where privacy compliance software turns a process that depends on institutional knowledge into one that’s repeatable and scalable.
DataGrail’s Request Manager provides data subject request automation across the full lifecycle, from intake and verification through data discovery, fulfillment, and documented response delivery. Combined with Live Data Map for real-time data discovery, Assessments for ongoing compliance monitoring, and AI Governance for automated decision-making obligations, it’s one connected platform built for the multi-jurisdiction reality your team faces today. Request a demo to see how it works.
