Data Subject Access Request (DSAR) — The Eight Things You Owe, the Clock That Starts Before You Notice, and Where a Chatbot Hides the Data

Quick answer: The clock is the part to know first. A data subject access request (DSAR, or "subject access request" in UK usage) is the right-of-access request under Article 15 of the GDPR: a person asks what you hold about them, and you owe a copy plus eight listed pieces of information, free, within one month of receipt. A request typed into the chat widget is received when it is typed. The month is calendar-based and starts on receipt, not on recognition; the UK regulator counts forward to the same date next month, suggests treating it as 28 days to be safe, and pauses the clock only while you wait for identity information you reasonably asked for or for clarification of what information they want; it does not start the clock at all until you have settled whether a genuinely ambiguous message is a request. Beyond the clock, two things on this page matter more than the definition. First, a chatbot's inferred data is in scope: an intent label, a sentiment score or a lead score is personal data if it is tied to an identifiable person, and an access response that returns the transcript and omits the labels is incomplete. Second, a count against ourselves: eleven of our fifteen platform reviews mention GDPR, and none records whether a single contact's data can be exported or deleted from the platform. The mechanisms exist on at least three of the platforms we cover, and we did not ask.

What the request is, and what it is not

Article 15(1) gives the data subject "the right to obtain from the controller confirmation as to whether or not personal data concerning him or her are being processed, and, where that is the case, access to the personal data" together with a list of information. That is two obligations: a yes-or-no, and then a copy plus context. Article 15(3) adds that the controller "shall provide a copy of the personal data undergoing processing," free for the first copy, and, where the request came in electronically, "in a commonly used electronic form" unless the person asks otherwise.

Access has four neighbors that operators run together, and the answers differ:

Access is the one that forces you to find everything, which is why it is the expensive one. Erasure is a set of deletions; access is a search across every store, a compilation, a check for other people's data in the same transcript, and a letter. The procedure for all five, across the systems a chatbot writes to, is the chatbot data privacy guide; this entry stays on the access request.

The eight things the answer must contain

Article 15(1)(a) through (h) lists what accompanies the copy. Read against a chatbot deployment, each item has an obvious source and a less obvious one.

Item (h) is where chatbots differ from a mailing list. A lead-scoring rule that decides who gets a human callback, or a routing rule that sends low-confidence conversations to a slower queue, may or may not reach the Article 22 threshold of a decision with legal or similarly significant effects; that is a question for an adviser. What is not in doubt is that the score itself is personal data. The ICO's guidance on finding information says that "if you generate insights about a person's behaviour based on their use of your service, where this information is identified or identifiable (directly or indirectly), then it's personal information and subject to the right of access." A response that returns the transcript and omits the intent label, the sentiment score and the lead grade has returned part of the data.

Recital 63 draws one limit: the right "should not adversely affect the rights or freedoms of others, including trade secrets or intellectual property and in particular the copyright protecting the software," and then closes the loophole in the same breath: "the result of those considerations should not be a refusal to provide all information to the data subject." A prompt or a scoring formula may be a trade secret; the score assigned to the person is not.

Where the data leaves the EU, which for a US-hosted platform it usually does, Article 15(2) adds a ninth item: the person has "the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer," which in practice means naming the transfer mechanism your platform's data processing agreement relies on.

The clocks

GDPR. Article 12(3): information on action taken "without undue delay and in any event within one month of receipt of the request." The month "may be extended by two further months where necessary, taking into account the complexity and number of the requests," and the controller "shall inform the data subject of any such extension within one month of receipt of the request, together with the reasons for the delay." Article 12(5) makes the response free unless requests are "manifestly unfounded or excessive," and puts the burden of showing that on the controller.

UK. The ICO's right-of-access guidance, updated 8 December 2025, works the arithmetic out: "To calculate a month, you must start from the actual date you receive the request, fee or other requested information and count forward to the end of the same date in the following month." Weekend or public-holiday deadlines move "to the end of the next working day." Its practical suggestion is the one to adopt: "you could adopt a 28-day period to ensure that you always comply within a calendar month." Three more lines from the same guidance settle arguments operators have. "A request is not complex just because you have to rely on a processor to provide the information you need to respond," which means "the platform is slow" is not an extension ground. The clock pauses for clarification only "about the information requested," not about the format, and even then "you cannot force a person to narrow the scope of their request." And the month does not start until identity information you reasonably asked for arrives, or, where it is genuinely unclear whether a message is a request at all, until you have clarified that. So ask for either immediately; on identity the ICO's next sentence is that "it's important to avoid delays," and on unclear requests it says to contact the person "as soon as possible."

California. The CCPA's counterpart is the "right to know." The Attorney General's page (updated 28 August 2026) states: "Businesses must respond to your request within 45 calendar days. They can extend that deadline by another 45 days (90 days total) if they notify you." The AG's consumer FAQ describes the disclosure as covering "the 12-month period preceding your request"; the statute as amended by the CPRA may set different look-back rules for data collected after 2022; we quote the AG's page and did not read the statute. A consumer may ask "up to twice a year, free of charge." Scope is narrower than the GDPR's: the law applies to for-profit businesses that "Have a gross annual revenue of over $25 million; Buy, sell, or share the personal information of 100,000 or more California residents or households; or Derive 50% or more of their annual revenue from selling California residents' personal information." Many businesses in our 1-to-100-employee readership sit below the revenue threshold; the second test is the one to check. It counts California residents or households whose personal information you buy, sell or share, and "share" under the CCPA reaches cross-context behavioral advertising, so a brand that pushes its Messenger or Instagram audience into an ad-platform integration can cross it without a $25 million turnover. Whether you have is a question for an adviser, not for a review site. The AG page also settles where the request goes: "It is the business that is responsible for responding to consumer requests. If you submit a request to know to a service provider of a business instead of the business itself, the service provider may deny the request." Your chat platform is the service provider. The request is yours.

Verifying who is asking

Article 12(6) lets a controller with "reasonable doubts concerning the identity of the natural person making the request" ask for "additional information necessary to confirm the identity." Recital 64 sets the standard in both directions: "The controller should use all reasonable measures to verify the identity of a data subject who requests access, in particular in the context of online services and online identifiers," and, in the next sentence, "A controller should not retain personal data for the sole purpose of being able to react to potential requests." The ICO's reading is proportionate: "Only request formal identification documents if necessary. You can use verification measures that you already have in place (eg an existing username and password)." Asking is one of the two things that legitimately hold the clock (the other is a clarification request about the information wanted), and only while you wait for the answer.

Chatbots make this easier on some channels and harder on others. A WhatsApp or Telegram conversation is tied to a number or account the person controls; a request that arrives from the same number is its own verification. An anonymous website visitor is the hard case. Intercom's help center describes visitor data as "tied to an intercom-id or intercom-session cookie until the visitor is identified or converted into a user"; a person writing to you by email to ask for "everything from my chat last Tuesday" may be someone you hold data on and cannot link to. Article 11(2) and Article 12(2) cover that case: where the controller can show it "is not in a position to identify the data subject," it need not act on the request, unless the person supplies information that enables identification. The right response is to say so and to ask for what would let you find them, not to guess.

Where a chatbot's data sits, and what the platforms give you

A single conversation can exist in five places at once, a point our GDPR compliance guide makes about erasure and that applies to access with more force: the chat platform's transcript store, the CRM record the bot wrote to, the analytics warehouse, the model provider's request logs if the bot is generative, and the export somebody made to a spreadsheet. The ICO is explicit that this is not a defense: "The right of access applies whether the personal information you hold is stored in one location or in many different locations," and "there is no technology exemption from the right of access" for archived or backed-up data.

What the platform gives you for the first of those five is documented, and it varies:

The Intercom CSAT line and the Manychat Page Inbox line are the kind of detail an access response has to get right. The first means an "everything is deleted" statement after an Intercom deletion is false in one particular; the second means a Messenger deletion in Manychat leaves a copy in Meta's inbox that your response has to name as a recipient under item (c). Whether a record the vendor keeps after deletion is still personal data, and if so which Article 17(3) ground covers keeping it, is a question for an adviser; the vendor's product behavior is not itself a ground. None of this is a criticism of the vendors, who documented it. It is the reason the inventory has to be built before the request arrives.

What our fifteen reviews record

We searched our fifteen published platform reviews on 6 September 2026. Eleven mention GDPR, almost always as a row in a compliance table marked from vendor pages. None records whether a single contact's data can be exported, and none records whether a single contact can be deleted; the strings "access request," "erasure" and "DSAR" match no review, and "delete contact," "delete data," "delete user," "delete subscriber" and "delete visitor" match none either. The three vendor mechanisms in the table above were read from help centers for this entry, not from our reviews.

That is a gap in our protocol before it is a finding about any platform. A GDPR badge in a compliance table says the vendor has a data processing agreement and, usually, a data residency option. It says nothing about whether an operator can answer a request in a month. Two questions go into the protocol as a result: whether the platform exports one contact's complete data, including conversations and custom fields, in a machine-readable file; and whether it deletes one contact irreversibly, with the exceptions named. Our methodology page carries the current dimension list.

What it costs

DataGrail, a vendor of request-automation software, reported on 9 June 2026 that "a single access or deletion request costs a medium-sized business receiving 5 million monthly unique web visitors approximately $1,524 to complete manually," a figure it attributes to Gartner without naming the document, and that "deletion requests alone" have risen "567% since 2021." Read it as vendor research with a commercial interest in the number being large. The direction is right even if the figure is for a company far bigger than most of our readers: an access request is a search across five systems, a review, a redaction and a letter, and the cost is almost entirely the time of the person who does it. The runbook in the companion guide is written to bring that, by our untimed estimate, to under an hour for a small operator whose inventory already exists.

Related terms

• Data retention policy — the period or criteria you have to state under item (d).
• Audit log — the record that a request was received, verified, answered and on what date.
• Session context — the shortest-lived data the bot holds, and still personal data while it exists.
• Chatbot analytics — the derived layer where inferred labels live.
• Sentiment analysis — an inferred label that is personal data when tied to a person.
• Lead scoring — the score that has to be disclosed and may raise the automated-decision question.
• Business Associate Agreement — the US healthcare contract, with its own access rules under HIPAA rather than these.

FAQ

What is a data subject access request?

It is a request by an individual to an organization, under Article 15 of the GDPR, for confirmation that the organization processes personal data about them and, if so, a copy of that data plus eight pieces of information: the purposes, the categories of data, the recipients, the retention period or criteria, the person's other rights, their right to complain, the source of any data not collected from them, and any automated decision-making with meaningful information about its logic. In UK usage it is a "subject access request"; under California's CCPA the closest counterpart is the "right to know."

How long do I have to respond to a DSAR?

One month from receipt under Article 12(3) of the GDPR, extendable by two further months for complex or numerous requests, provided you tell the person within the first month and give reasons. The UK ICO counts the month to the same date in the following month and suggests a 28-day internal deadline so you never miss it; it also states that relying on a processor does not make a request complex. Under the CCPA the window is 45 calendar days, extendable once by 45 days with notice.

Does a chatbot transcript count as personal data?

Yes, where the conversation can be linked to an identifiable person, which it usually can through a phone number, a messaging account, an email captured in the flow or a login. The transcript, the fields the bot extracted and the labels it inferred (intent, sentiment, lead score) are all personal data in that case. The ICO's guidance treats observed and inferred information about an identifiable person as subject to the right of access, so a response that omits the labels is incomplete.

Can I refuse a DSAR because I cannot identify the person?

If you can show you are not in a position to identify the data subject, Article 12(2) says you need not act on the request, unless the person provides additional information that enables identification. Anonymous website-chat visitors identified only by a cookie are the common chatbot case. The correct reply is to say that you cannot link them to any record and to ask for what would allow you to, not to send someone else's transcript or to stay silent past the deadline.

Is a DSAR the same as a deletion request?

No. Access (Article 15) returns a copy and context; erasure (Article 17) removes data where one of six grounds applies and no exemption does. People often ask for both in one message, and the two run on the same clock, but the work differs: erasure is a set of deletions across systems, access is a search, a compilation, a review for third-party data and a letter. Our chatbot data privacy guide sets out the procedure for each.

Do I have to answer if the request arrives through the chatbot itself?

Yes. The regulation does not restrict the channel, and Recital 59 says the controller "should also provide means for requests to be made electronically." A request typed into the chat widget is received when it arrives, so the flow should recognize the intent, capture it and route it to a human, rather than letting it fall to the fallback message. The design of that route is covered in the companion guide.

What does my chatbot platform have to do with a DSAR?

Under the GDPR the platform is your processor; under the CCPA, your service provider. The request is addressed to you and the deadline is yours. What the platform provides is the mechanism for its own copy of the data: Manychat and Intercom document a per-contact export and an irreversible deletion, Tidio documents a per-visitor deletion, and Manychat and Intercom each name an exception (Meta's own inbox copy, CSAT records) that your response has to reflect. Our fifteen reviews do not yet record these mechanisms, which is a gap we are adding to the protocol.

Sources

• Regulation (EU) 2016/679 (General Data Protection Regulation), read 6 September 2026 at gdpr-info.eu. Specifically: Article 15(1), the right of access, quoted for the "confirmation as to whether or not personal data concerning him or her are being processed" formula and the eight items (a) to (h); Article 15(3), the copy and the "commonly used electronic form" rule; Article 12(2) and Article 11(2), on a controller "not in a position to identify the data subject"; Article 12(3), the one-month deadline, the "two further months" extension and the duty to inform "together with the reasons for the delay"; Article 12(5), the free-of-charge rule and the "manifestly unfounded or excessive" exception; Article 12(6), the "reasonable doubts concerning the identity" provision; Article 16, 17, 20 and 21 for the comparison table, including Article 20(1)'s "structured, commonly used and machine-readable format"; Recital 59, the "means for requests to be made electronically" sentence; Recital 63, the "rights or freedoms of others, including trade secrets" limit and the "should not be a refusal to provide all information" sentence; Recital 64, the "all reasonable measures to verify the identity" standard. Quoted as the regulation's text, not as advice about its application. gdpr-info.eu/art-15-gdpr
• UK Information Commissioner's Office, Right of access guidance, pages "What should we consider when responding to a request?" and "How do we find and retrieve the relevant information?", both carrying the note "08 December 2025 - the right of access guidance was updated," read 6 September 2026: the calendar-month calculation, the next-working-day rule, the 28-day suggestion, the "not complex just because you have to rely on a processor" sentence, the stop-the-clock rule and its limit to "the information requested," the "cannot force a person to narrow the scope" sentence, the "Only request formal identification documents if necessary" sentence, the "one location or in many different locations" sentence, the "no technology exemption" sentence and the "insights about a person's behaviour" passage. UK GDPR guidance, cited here because it is the most detailed regulator reading of the same Article 12 and 15 text. ico.org.uk
• California Attorney General, California Consumer Privacy Act (CCPA), page marked "Updated on August 28, 2026," read 6 September 2026: the 45-day and 90-day wording, the 12-month look-back, the twice-a-year rule, the three applicability thresholds, the definition of "share" as cross-context behavioral advertising, and the service-provider sentence. The page states it is "not legal advice, regulatory guidance, or an opinion of the Attorney General." The statute itself (Cal. Civ. Code §1798.130) was not read for this entry because the legislature's site did not render for us; the AG's wording is quoted instead. oag.ca.gov/privacy/ccpa
• Manychat Help, Managing User Data / GDPR Compliance, article 14281070595100, "Updated September 01, 2026," read 6 September 2026: the four contact-menu options, the ".json file containing all their information" sentence, the deletion scope, the "You can't undo this action" and "Unknown with the 'deleted' status" sentences, and the Facebook Page Inbox caveat. help.manychat.com
• Intercom Help, How to export your Intercom data for GDPR (article 1636975, dated 24 January 2025) and Contacts FAQs (article 8827723, "Updated over 2 weeks ago" on the read date), read 6 September 2026: the "individual users, subsets of users or specific time periods as CSV or JSON files" sentence; the "Delete data" tab and its "Settings > Data > People > Delete Data" route, the 7-day retrieval window and "permanently destroyed," the CSAT exception, the reporting note, and the "tied to an intercom-id or intercom-session cookie" sentence. intercom.com/help
• Tidio Help Center, Privacy Policy and GDPR Compliance, article 5462910440220, "July 18, 2025 Updated," read 6 September 2026: the Contacts > delete path and the "email address, name, chat conversation history, etc." scope; the absence of a per-visitor export in that article is our observation, not the vendor's statement. help.tidio.com
• OpenAI, Data controls in the OpenAI platform, read 6 September 2026: "abuse monitoring logs are generated for all API feature usage and retained for up to 30 days," the note that such logs "may contain certain customer content, such as prompts and responses," and the Zero Data Retention description. platform.openai.com/docs/guides/your-data
• DataGrail, The $1.5M DSR Problem: What DataGrail's Research Found, Ian Phippen, 9 June 2026, read 6 September 2026: the "$1,524 to complete manually" and "567% since 2021" figures, which the post attributes to Gartner without naming the document; no Gartner document was read. DataGrail sells request-automation software and the figure is cited as vendor research. datagrail.io
• Chatbotscape review corpus, searched 6 September 2026 and published so the count reproduces. Denominator: ls sample-reviews/*-review.md | wc -l returns 15. grep -rliE "gdpr" sample-reviews/*-review.md returns 11 paths (aisensy, blip, botpenguin, botpress, chatbase, intercom, landbot, sendpulse, typebot, voiceflow, wati). grep -rliE "access request|dsar|erasure" sample-reviews/*-review.md returns 0. grep -rliE "delete (contact|data|user|subscriber|visitor)" sample-reviews/*-review.md returns 0. The loose check grep -li "delet" sample-reviews/*-review.md returns 5, and each hit was read: they are UI captions (an inbox actions column, a tool-catalog screenshot), an account-termination row and similar, none of them a per-contact deletion or export capability, so the narrow count stands. Published as a transparency statement about a gap in our review protocol; the silence is evidence that we did not ask, not that the platforms lack the mechanism.
• Ahrefs Keywords Explorer, US overview, queried 6 September 2026: the volume, difficulty, parent-topic and SERP-feature figures in this entry's keyword note.
• Chatbotscape evaluation methodology. /methodology (continuously updated).