What is a DSAR, and does it reach data you have licensed?

What does a DSAR actually ask a company to do?#

A DSAR asks a company to act on a person's rights over their own personal information, most often to disclose it, correct it or delete it. The term comes from European data protection law, but US privacy teams now use it as shorthand for requests under state privacy laws such as the CCPA as well.

Who can send one depends on the law that applies, and for US companies the pool is wider than many assume. California's privacy law has covered employee, job applicant and business-contact information since the exemptions for those records expired on January 1, 2023, so requests can come from staff, former staff and the contacts in your CRM, not only consumers. Each law sets its own exemptions, verification rules and deadlines, so privacy teams usually keep a written procedure per jurisdiction.

• 1Access or right to know: a copy of the personal information held and, under some laws, the categories of recipients it was disclosed to.
• 2Deletion: removal of personal information, subject to exceptions such as legal holds and records the company must keep.
• 3Correction: fixing inaccurate details in a profile, contact record or account.
• 4Opt-out: stopping certain disclosures, such as sales or sharing of personal information under some US state laws.
• 5Portability: a usable export of information the person provided, where the law grants it.

Does a DSAR reach records you have already licensed?#

A DSAR reaches licensed records when the delivered copy still contains personal information about the requester. The original records in your own systems stay in scope either way; the open question is the copy now sitting with the licensee.

The deciding fact is the state of the data at delivery. If support tickets went out with names, email addresses and phone numbers intact, the licensee holds personal information that you disclosed, and your obligations may include passing a deletion request along. If those identifiers were removed and the remaining text cannot reasonably be linked back to the person, many privacy laws treat the result as outside the definition of personal information.

Why de-identification at delivery is the main control#

De-identification at delivery is the main control because it is the last point at which you decide what leaves your systems. After delivery you depend on the licensee's systems, contracts and good faith to find and remove one person's records, and with training data that can be difficult or impossible.

Operational records hide identifiers in places structured fields do not show. Ticket bodies carry email signatures and callback numbers, dispatch notes carry street addresses and gate codes, and Slack threads carry first names and nicknames. A cleanup that only drops the name and email columns leaves most of that in place.

De-identification standards pair technical steps with commitments. Under the CCPA, for example, information counts as deidentified only if the business takes reasonable measures so it cannot be associated with a person or household, publicly commits to keep it in that form and not re-identify it, and contractually obliges every recipient to comply. Other state laws set comparable conditions with differences counsel should check. Write the recipient's commitments into the license, where a privacy team can point to them, rather than leaving them in correspondence.

What should the license say about data subject requests?#

The license should say what kind of data was delivered and what happens if personal information turns up anyway. Counsel usually asks for terms that still work if the de-identification was imperfect, because no review of free text catches everything.

• 1A description of the de-identification standard the delivered records meet, with a supplier warranty that it was applied.
• 2A promise from the licensee not to re-identify anyone or link the records with other data to do so.
• 3A duty to notify the supplier if personal information is found, with an agreed path to remove it.
• 4A cooperation clause for data subject requests covering any identifiable records, including deletion from the licensee's dataset copies.
• 5Limits on onward transfer, so the records do not reach parties you never vetted.
• 6Deletion of dataset copies at the end of the term, confirmed in writing.

How to answer a DSAR when some records were licensed#

A DSAR involving licensed records is answered the same way as any other, with one added step: checking the delivery record. That step is only possible if you kept one.

Access requests raise one more point. Some laws let people ask which categories of recipients received their information, so if identifiable records were licensed, your privacy notice and your response may need to reflect that disclosure.

• 1Step 1: verify the requester and log the request under your normal procedure.
• 2Step 2: search your own systems, such as the help desk, CRM, email archive and billing system, and act on the request there.
• 3Step 3: check the delivery manifest and privacy record for each licensed package to see whether the requester's records were included and in what form.
• 4Step 4: if the package was de-identified, record why it no longer relates to the requester and have counsel confirm how to describe that in the response.
• 5Step 5: if any package was identifiable, send the request to the licensee under the license procedure and keep its written confirmation.
• 6Step 6: close the request with a note linking the response to the delivery record you relied on.

Illustrative: a scheduling software company receives a deletion request#

Illustrative: a fictional appointment scheduling software company licensed several years of support tickets from Zendesk, with related account notes from HubSpot. Before delivery it removed names, email addresses, phone numbers and signatures, replaced customer account names with random tokens, destroyed the token map and had a reviewer sample the free text.

Months later, a former customer administrator asks the company to delete all of her personal information. The privacy lead deletes her contact record in HubSpot and her requester profile in Zendesk, then opens the privacy record for the licensed package. It shows that every identifier she could be found by was removed before delivery and that no mapping back to her account exists.

With counsel, the company concludes that the licensed copy no longer relates to her and answers on that basis. The rule it records for future packages: keep the same de-identification standard, and keep each delivery manifest for as long as the license and its survival terms run.

How SourceX handles request rights in a transaction#

Request rights are mostly settled before delivery, in the Preparation step of the SourceX five-step transaction, which runs Supply, Rights, Preparation, Approval and Delivery. SourceX removes personal and confidential details at that stage, and the supplier approves the prepared package before anything leaves its control.

The privacy record sits in the SourceX Evidence Packet next to provenance, licensing rights, permitted use and release authorization. When a DSAR arrives, it is the page a privacy team needs first, because it shows what was removed, by what method, and in what form the records went out.