When a DSR Request Becomes a Treasure Hunt

For its first CTV campaign, Jennifer Aniston’s DTC haircare brand LolaVie had a few non-negotiables. The campaign had to be simple. It had to demonstrate measurable impact. And it had to be full-funnel.

LolaVie used Roku Ads Manager to test and optimize creatives — reaching millions of potential customers at all stages of their purchase journeys. Roku Ads Manager helped the brand convey LolaVie’s playful voice while helping drive omnichannel sales across both ecommerce and retail touchpoints.

The campaign included an Action Ad overlay that let viewers shop directly from their TVs by clicking OK on their Roku remote. This guided them to the website to buy LolaVie products.

Discover how Roku Ads Manager helped LolaVie drive big sales and customer growth with self-serve TV ads.

The DTC beauty category is crowded. To break through, Jennifer Anniston’s brand LolaVie, worked with Roku Ads Manager to easily set up, test, and optimize CTV ad creatives. The campaign helped drive a big lift in sales and customer growth, helping LolaVie break through in the crowded beauty category.

Learn more.

On a Tuesday morning, your very first data subject rights (DSR) request arrives like an email from the universe:

It lands in a mailbox that nobody checks regularly. Someone forwards it to legal. Legal forwards it to privacy. Privacy forwards it to security to get a read on what data is stored. Security replies with “We’ll look into it.” Meanwhile, the clock is ticking because deadlines don’t care that your internal routing is a little… aspirational.

Then comes the real fun: where is the data? The CRM, obviously. But also the data warehouse. And the support ticketing tool. And the marketing platform. And the call recordings. And maybe a Slack export. And an old vendor you “sunset” last year but never fully decommissioned.

This is how a single DSR request becomes an organizational mirror. Not unlike a privacy notice, it reflects whether your program is operational or merely theoretical.

This story may or may not resonate with you. Maybe you do have a fairly ironed-out DSR process or maybe you don’t. Maybe it’s there but every request still feels vaguely threatening and adds another gray hair. We’re here to talk a little bit about DSRs and maybe get some guidance on what to do if you still find your organization struggling with how to route, action, and respond to these requests.

A lot of people still use DSAR as shorthand, but ‘access’ is only one of the rights people can exercise depending on jurisdiction and context. DSR is the better umbrella because it forces you to design a system for multiple request types (and as those of you who’ve been around a while know, we like to be agnostic as to regulatory frameworks here), including access/know, deletion, correction, opt‑out of sale/sharing, limit use of sensitive data, portability, and sometimes objections to certain processing.

If your process only works for some times of requests or some types of data, you don’t have a DSR program—you have a data scavenger hunt with a PDF attachment. So, let’s get into the nitty gritty of what can turn your chaos into a DSR process that doesn’t risk migraines every time you open the inbox.

From an operational standpoint, the best intake channel is the one you can actually manage. Many laws require that you provide at least certain methods (often a webform and/or a toll‑free number for some businesses), but even when you offer multiple channels, you still need a single place where requests are logged and tracked.

For a clean approach, designate your primary channels (e.g., webform plus email alias) and treat everything else as a ‘capture and route’ channel. If a request comes through social media, support chat, or a random inbox, the rule is simple. Copy the request into the primary system and start the clock there.

A common failure point is that an organization mistakes ‘having a channel’ for ‘having a process.’ A DSR request that arrives but isn’t logged and acted on in a consistent and timely manner might as well not exist… until it becomes a complaint, and then it’s everyone’s problem.

I’m not advocating not to have a DSR policy. You should have one, but the success is in the details like getting SOPs in place, training employees on the processes, and following them.

Another common DSR failure mode (other than relying on ad hoc response completely) is over‑indexing on the legal analysis and under‑investing in the operational workflow.

Yes, legal exemptions matter. Yes, verification standards matter. Yes, response content matters. But most DSR pain comes from predictable operational gaps:

If you’ve ever watched a team scramble through a DSR request, you’ll recognize the pattern: people spend 80% of the effort on searching and assembling, and 20% on the actual response. That’s why the ‘ops’ part matters so much. Honestly, I might even be too conservative by saying 80%.

A strong DSR program is almost entirely about repeatability. It’s the same logic as incident response. You don’t want to invent the playbook mid-incident. Also, if you do have an incident, you’d best be prepared for an influx of DSR requests, so getting your DSR process nailed down is also another form of incident readiness.

An end‑to‑end DSR workflow has five phases: (1) intake, (2) verification, (3) search, (4) response, and (5) closure. Each phase should have an owner, a time expectation, and an evidence trail.

If you’re building this from scratch, start by writing down the ‘handoffs.’ Handoffs are where DSR requests die and then come back to haunt you as the ghost of customer past, regulator present, and plaintiff’s complaint future. Sorry, I know it’s not the holidays… but that was just too good for my nerdy little brain to not include. Every time a request moves from intake to privacy, from privacy to engineering, from engineering to vendors, and back again, that’s a handoff. Your SOP should make handoffs clearly defined, including who triggers them, what information is needed, and specific completion criteria.

Also decide early how you’ll handle clarification. Many DSR requests are broad by default (“everything you have on me”), and narrowing scope can be both reasonable and helpful. Your workflow should include a standard clarification message and a way to pause or adjust internal search steps, including the timer, while awaiting clarification (where legally permitted).

Verification is a balancing act. Under‑verify and you risk disclosing data to the wrong person. Over‑verify and you create unnecessary friction and sometimes allegations that you’re deliberately making the process hard, which can lead to regulator involvement.

A pragmatic approach is risk‑based verification. Low‑risk data (e.g., basic account info) may require less verification than high‑risk data (e.g., financial details, precise location, sensitive categories). If you have an authenticated account login, use it. If you don’t, use a verification flow that is proportionate and documented.

Document each verification decision and on what basis the decision was made. Even a short note—‘verified via account login’ or ‘verified via two matching identifiers’—goes a long way when you need to show you followed a consistent process.

If you operate in jurisdictions with employment privacy obligations, DSR is not only about customers. Employee and applicant data adds complexity, including the potential for additional systems, the added likelihood of sensitive information, potential internal investigations, and legal holds.

Workplace data also raises a different kind of trust issue. If employees request access, you need a workflow that respects both the employee’s rights and the organization’s legitimate need to protect confidential business information and preserve investigation integrity.

The takeaway… treat HR systems as first‑class citizens in your DSR world. Just like your customer data (and arguably even more so than customer data depending on your industry), employee DSR requests need owners, search procedures, and clear escalation paths.

Also remember that employee data is often intertwined with other people’s data. That might include performance reviews referencing coworkers, investigation files, HR tickets, and internal emails. This is where careful redaction and review workflows matter. Even if you ultimately deny or partially fulfill a request, you want evidence that you evaluated it thoughtfully.

Most organizations can’t fulfill DSR obligations without vendor cooperation. If your vendors hold personal data (including workforce personal data), your process must include: (1) a vendor contact register, (2) standard request language, (3) tracking of vendor response timelines, and (4) an escalation mechanism that applies when vendors delay.

This is also where contracts matter. Your DPA terms should support DSR assistance and set time expectations. If a vendor refuses to delete, correct, or export data within your timelines, your DSR program becomes a hostage negotiation.

Even if you don’t have perfect contractual leverage today, documenting vendor behavior is valuable. It informs renewals, tiering decisions, and future contracting positions.

A practical best practice is to maintain a ‘vendor DSR packet’ you can send quickly. It should include the request type, identifiers you can provide, the action requested (delete/correct/export/stop processing), required completion timeline, and a request for confirmation plus evidence (where reasonable).

This isn’t about being adversarial. Providing vendors with detailed information and an organized request makes it easy for them to respond consistently. Vendors respond faster when the request is clear, standardized, and routed to the right inbox.

Deletion might seem straightforward in theory, but when we dig into systems, if often becomes more complex than we anticipated. ‘Delete’ can mean different things in systems. For instances, logical deletion means the data is no longer accessible in the product, hard deletion means the data is removed from the database, suppression means it’s kept for compliance but excluded from use, and de‑identification can also have separate standards. Further the definitions I just proposed could vary based on your system or process nomenclature.

Your process should define which meaning applies where, and how you handle backups. Backups are often not immediately deletable without harming system integrity, so many organizations implement a policy to delete from active systems and allow backups to roll off on a defined schedule while ensuring the data is not restored into production except through controlled processes. You are going to need to work with your IT group to clearly define this process and ensure that it’s working as expected when you provide confirmation to your data subjects.

Correction and limitation both have similar complexity. Correcting in one system doesn’t necessarily correct copies unless there’s some automation there to support it. The same goes for data limitation. If you set a limitation in one place, it may not flow through to other parts of your system. Your workflow should specify which systems are ‘sources of truth’ and which systems should be updated downstream and how to ensure and confirm that happens.

I love, love, love data minimization. It makes so many functions of my (and probably your) job easier. The fastest way to make DSR responses less painful is to reduce unnecessary data sprawl (also limiting data retention has a similarly awesome compounding effect).

Data minimization and privacy by design aren’t just compliance ideals. I mean, they are, and that’s why we talk about best practices, but they are also operational multipliers. If your systems collect less, copy less, and retain less, your search surface (and data breach blast radius, and storage cost, and discoverable data and much more) shrinks. DSR becomes faster, cheaper, and less error‑prone.

This is also why DSR operations should be connected to data inventory, retention schedules, and data mapping. DSR is where the program either clicks or collapses.

Here’s a bonus accelerator. Reduce identity ambiguity when you design or deploy new systems. If your systems use different identifiers for the same person (email here, phone there, internal ID elsewhere), DSR searches become harder. Clean identity resolution is a privacy operations win, not just a product optimization.

If you only operationalize one thing, operationalize the system search. A systems search SOP answers some really important questions.

This prevents two common disasters: (1) missing data because someone forgot a system and (2) over‑collection because someone exports data more than necessary to fulfill the request. Both can create new privacy risk while trying to satisfy a request.

A systems search SOP should also include escalation rules:

The micro tool below is designed for the intake reality of a DSR request. When you get a request, you need to triage it quickly, assign the right owners, and make sure the search is consistent. It won’t replace your full SOP, but it will keep you from improvising under deadline.

Use it as a ‘DSR flight plan’—especially helpful when DSR requests are infrequent and the process muscle isn’t built yet.

If you’re more mature, use the micro‑tool as a QA checkpoint. Even mature teams drift. A one‑pager forces consistency: did we verify, did we search the right systems, did we log, did we execute deletion, did we capture evidence?

Finally, reminder that the opinions expressed in this article are the opinion of The Privacy Design Lab. They are not legal advice, and no attorney-client relationship is formed by reading this article or downloading the DSR Triage & Search Planner. If you need to consult legal counsel, you can book a consult with ARLA Strategies or other legal counsel you trust!

If you’re tired of privacy advice that only works in theory, you’re in the right place.

The Privacy Design Lab exists for people who want to practice privacy, not just talk about it. It focuses on practical, repeatable ways teams actually learn. We offer hands-on workshops, downloadable systems, and the Privacy Design Lab Studio community where teams and practitioners can go deeper. Paid newsletter subscribers get access to our full archive, plus supporting materials you can actually use.

If that sounds like your kind of work, we’d love to have you.