DSARs for Research Data: Handling Access, Deletion, and Portability Requests from Participants

The short answer

A data subject access request is a deadline, not a project. Under GDPR you have one month from receipt, extendable by a further two months for complex or numerous requests — but only if you tell the requester about the extension, and why, inside the original month. Under CCPA/CPRA you have 45 calendar days, extendable by another 45 with notice, and consumers may make the request free twice a year.

For research teams the hard part is almost never the deadline. It is knowing what "their data" means when someone spent forty minutes talking to you: a transcript, an audio file, a screener response, a scheduling record, an incentive payment record, a set of tagged quotes, and possibly a verbatim already sitting in a slide deck that went to the exec team last quarter.

Request volumes are climbing. Privacy vendors tracking their own platforms reported DSAR volumes up roughly 43% between 2023 and 2024, and CCPA-route requests growing several-fold since 2021. A research programme that has never received one should assume it will.

The rights that actually land on research data

CCPA/CPRA maps loosely onto access (right to know), deletion, and correction, with its own 45-day clock and its own verification rules.

Why the research exemption probably does not save you

Article 89 permits derogations from several data subject rights where personal data is processed for scientific or historical research or statistical purposes — and Article 17(3)(d) contains a matching erasure carve-out. Research teams reach for this constantly. Three reasons to be careful:

1. The derogations are national law, not self-executing. Article 89(2) lets Member States legislate derogations. Implementation varies significantly across the EU/EEA, so "the research exemption" means different things in Germany and Ireland. You cannot invoke a derogation that your governing Member State has not enacted.
2. They are necessity-bounded. A derogation applies only so far as the right would render the research purpose impossible or seriously impair it. "It would be inconvenient to re-run the analysis" does not meet that bar.
3. Commercial product research is not the archetype. The provision was written with scientific and statistical research in mind, and it comes bundled with Article 89(1) safeguards — data minimisation and, critically, using identifiable data only where the purpose cannot be achieved with anonymous or pseudonymous data.

That third clause is the useful one, and it points at the real answer.

Anonymisation is the off-switch

Article 11(2) is the most operationally valuable provision in this whole area: where you can no longer identify a data subject, the access, rectification, erasure, restriction, and portability rights do not apply — provided you can demonstrate you cannot identify them, and the requester cannot supply information that lets you.

Genuinely anonymised research data is out of scope. Pseudonymised data — a participant code with a key table sitting in someone's spreadsheet — is still personal data, and every right still applies.

This is the same structural point that governs your retention schedule: anonymisation stops the clock. Building anonymisation into synthesis rather than treating it as a cleanup task means most of your historical corpus is simply not DSAR-addressable, which is both cheaper and better privacy practice. Our guide to anonymising customer interview data covers the techniques.

The seven-step runbook

1. Log receipt and start the clock the day it arrives. A DSAR does not have to say "DSAR", does not have to be in writing, does not have to go to a privacy inbox, and does not have to cite a law. A reply to a research invitation saying "actually, delete whatever you have on me" is a valid erasure request. Brief whoever monitors your participant inbox.

2. Verify identity proportionately. You must be reasonably satisfied the requester is who they claim. You must not use verification as a stalling tactic, and you must not collect more identity data than the request warrants. If your only link to a person is the email address they interviewed from, a reply from that address is usually sufficient.

3. Scope against a data map you wrote in advance. Under time pressure is the wrong moment to discover where interview data lives. Your map should cover: the research platform, transcripts and audio, screener and recruitment records, the incentive payment trail, the analysis repository, exports sitting in a warehouse or BI tool, decks and documents containing verbatims, and every sub-processor in the chain.

4. Decide identifiability per artefact, not per study. One study routinely contains raw identifiable transcripts, pseudonymised working notes, and genuinely anonymous aggregate findings. The first two are in scope; the third is not.

5. Handle third-party data in transcripts. Participants name colleagues, managers, and customers. Those references are other people's personal data. For an access request, redact third-party identifiers unless you have that person's consent or it is reasonable to disclose without it. This is the single most common place research DSARs go wrong.

6. Propagate to sub-processors. An erasure request reaches your processors and their sub-processors — transcription providers, model providers, storage, analytics. Your DPA should already oblige them to act on it. If you cannot name the chain, you cannot complete the request; see reviewing a research vendor's DPA.

7. Respond in writing, and record what you did. Say what you disclosed or deleted, what you withheld and why, and what remains. Keep the record — proving you handled a request correctly is itself an accountability obligation, and that record is one of the few things you keep after deleting everything else.

The hard cases

A quote already published in a report. If the quote is attributed or reasonably identifiable, it is personal data and erasure reaches it. If it is genuinely anonymous in context, it is not. The lesson runs backwards into your process: attribute quotes to participant codes in decks, never to names and job titles at named employers, which are frequently identifying in combination.

Audio with more than one voice. A recording containing a participant and a colleague contains two people's personal data. Deleting for one may mean deleting the artefact.

Aggregate analysis derived from their interview. Once findings are aggregated to the point that no individual is identifiable, the analysis survives an erasure request. You do not have to re-run your study; you do have to remove the identifiable inputs.

Incentive payment records. These usually have an independent legal basis — tax and accounting retention obligations — that survives an erasure request. Say so explicitly in your response rather than silently keeping them. See research participant incentives and taxes.

Where Koji helps

Koji is built so that the awkward parts of a DSAR are lookups rather than archaeology. Interview data is organised per participant and per study rather than scattered across recordings, notes, and calendar entries, so scoping a request is a query instead of a search party. Data can be exported in structured form, which is what a portability request wants, and deleted when a participant asks.

Koji's six structured question types — open_ended, scale, single_choice, multiple_choice, ranking, and yes_no — help more than they look like they should. Structured responses carry stable question IDs from interview plan through to report, so a participant's quantitative answers are addressable fields rather than prose to be re-read. When you need to produce "everything we hold about this person" in a month, typed data is the difference between an afternoon and a fortnight.

Because Koji's AI interviewer runs asynchronously over a link, there is no third-party meeting recorder holding a second copy of the conversation — one fewer sub-processor to chase on an erasure request, and one fewer place for a copy to survive.

For enterprise data-handling arrangements, contact the Koji team.

Common mistakes

• Waiting for the word "DSAR". Most requests arrive as ordinary sentences in ordinary replies.
• Assuming Article 89 covers commercial product research. It is national-law dependent, necessity-bounded, and written for scientific research.
• Treating pseudonymised data as out of scope. If a key exists anywhere, every right still applies.
• Forgetting the exports. Warehouse tables, BI dashboards, and CSVs in someone's downloads folder are in scope.
• Disclosing third-party names in an access response. Redact colleagues mentioned in transcripts.
• Missing the extension notice. If you need the extra two months under GDPR, you must say so within the first month, with reasons.

Frequently asked questions

How long do I have to respond to a DSAR? One month from receipt under GDPR, extendable by two further months for complex or numerous requests if you notify the requester within the first month. Under CCPA/CPRA it is 45 calendar days, extendable by another 45 with notice.

Does a participant have to use the word "DSAR" or cite a law? No. A request is valid however it is phrased, whoever receives it, and whether or not it is in writing. Train anyone who monitors participant communications to recognise and escalate one.

Can I refuse deletion because the data is research data? Rarely. Article 89 derogations and the Article 17(3)(d) erasure carve-out depend on Member State implementation, are limited to what is necessary to avoid making the research impossible or seriously impaired, and were written with scientific research in mind. Do not assume they cover commercial product research.

Does an erasure request mean I have to redo my analysis? No. Genuinely anonymous aggregate findings are not personal data and survive the request. You must remove the identifiable inputs — transcript, audio, identifiers, and attributed quotes.

What about anonymised interview data? If you can demonstrate you can no longer identify the individual, Article 11(2) means the access, rectification, erasure, restriction, and portability rights do not apply. Pseudonymised data with a key does not qualify.

Do I have to delete incentive payment records? Usually not. Tax and accounting retention obligations provide an independent legal basis that survives an erasure request. State this explicitly in your response instead of quietly retaining them.

Related Resources

• Structured Questions Guide — the six question types and the addressable, typed data they produce
• GDPR-Compliant AI User Research — the legal bases and participant rights underneath every DSAR
• CCPA/CPRA Compliance for Customer Research — the US route, its 45-day clock, and verification rules
• Research Data Retention and Deletion — the schedule that determines how much data a DSAR can even reach
• Anonymizing Customer Interview Data — the techniques that take data out of scope entirely
• Reviewing a Research Vendor DPA — the contract clauses that make sub-processors act on your requests
• Research Participant Incentives and Taxes — why payment records outlive an erasure request