The DSAR Playbook: Every vendor outreach template you need

The problem: your processor list is last year's spreadsheet

A DSAR is the moment your vendor inventory stops being a compliance artifact and becomes an operational clock. GDPR Article 15 gives you thirty days. Several US state laws are tighter on paper and messier in practice. India's DPDPA has its own clocks. The first week is usually wasted rebuilding the processor list, because the RoPA from last year's audit does not include the AI summarizer marketing authorized on Tuesday.

I have watched privacy teams open a ticket, pull a static vendor register, and email three DPAs they already have on file. Meanwhile the subject's mail lives in a HubSpot OAuth grant, a Chrome extension with gmail.readonly, and a departed AE's leftover Drift connect. Those processors never created a PO. Finance never saw them. They still hold personal data.

This playbook is how you build the vendor list from live OAuth inventory, send operator-reviewed outreach, and keep a clock you can show an auditor. It is not legal advice. Templates are operator-reviewed, not lawyer-reviewed. Counsel adapts jurisdiction, exceptions, and the subject-facing letter.

ScopeMantle DSAR automation does the mechanical work: snapshot inventory, pre-fill vendors, dispatch templates, attach replies to the grant record. Pricing is five dollars per employee per month billed annually, or six dollars month-to-month. No seat minimum. Custom at 500+. Start a 30-day trial.

How a DSAR actually hits OAuth vendors

OAuth is not a login. It is a standing permission for a third party to call an API as the user. If that API can return mail, Drive files, calendar attendees, or directory records, the vendor is a processor or at least a candidate you have to ask. You cannot wait for the vendor to volunteer.

IdP inventory is the discovery method you can prove. Google Admin's "Apps with access to data" and Okta's OAuth client list are contemporaneous. A RoPA row from Q3 is not. When a supervisory authority asks how you identified processors, you want an export timestamped before the first vendor email, hashed and parked in the case file.

Inference from scopes is a starting point. Vendor confirmation still belongs in the Article 15 letter. Do not tell a subject "we have no data at Vendor X" because the scope string looked narrow.

Build the vendor list before anyone hits send

1. Export third-party grants from Google Workspace and Okta. Record vendor display name, OAuth client ID, scopes, grant owner, created date, last used if the API exposes it, and user count.
2. Deduplicate by client ID, not display name. Acquisitions rename products. Client IDs stay put. Drift and Salesloft taught that lesson the hard way.
3. Filter to scopes that can hold personal data (mail, drive, calendar, profile, directory). Keep the rest in an appendix so you can defend the cut.
4. Map grant owner to business unit via HRIS title. When a vendor ignores you, you escalate to a human who actually uses the tool.
5. Cross-reference procurement DPAs. An active grant with no DPA is both a DSAR risk and a SOC 2 CC9.2 finding. Queue it; do not stall the subject clock while legal chases paper.
6. Tag missing privacy-contact emails. A letter to support@ with no ticket ID is how clocks die.
7. Snapshot the CSV. Filename it with the DSAR case ID and a date. Hash it. That file is how you prove the list was not retrofitted after the regulator asked.

If you do this by hand, budget half a day for a 500-person Workspace and another afternoon if Okta is in the mix. That is why ScopeMantle syncs daily and pre-fills the case. You can still run the procedure above without us. You just will not want to do it twice in one quarter.

Priority tiers (generic vendor classes, not customers)

You do not need sixty named vendors in a public playbook. You need a triage rule you can defend.

• Tier 1. Mail or Drive scopes, or any admin.directory grant. AI extensions and inbox tools land here. HubSpot-class CRM OAuth via Google is here if mail or contacts sync.
• Tier 2. CRM, support, and success tools with contact objects (Salesforce connected apps you can see via SSO grants, Zendesk-class helpdesk, chat widgets).
• Tier 3. Analytics with profile identifiers (Mixpanel-class, product analytics, ad pixels that also hold an OAuth grant).
• Tier 4. Dev tools with repo or ticket metadata (GitHub, Linear, Jira if they hold subject identifiers).
• Tier 5. Long-tail unattested grants under ten users. Batch them quarterly unless the subject names the tool.

Article 15: access request to a vendor

Send this to the vendor privacy team, not generic support, unless that is the only published address. Keep the case ID, legal basis, and deadline. Do not strip fields because you are in a hurry. Ambiguous requests are how vendors miss dates and you get blamed.

Dear [Vendor Privacy Team],

We received a valid Article 15 GDPR access request for [Subject Name / Identifier].
Your service [Vendor Name] appears in our processor inventory via OAuth integration [Client ID].

Please confirm whether you process personal data relating to this subject, describe categories and purposes, list sub-processors if applicable, and provide a copy of the data or explain why none exists.

Deadline: [Date + 30 days from valid request].
Contact: [Privacy Office Email].
Reference: [DSAR-ID].

Request only the fields needed to fulfill this access request. Do not send a bulk database dump.

Counsel swaps the header for UK GDPR, India DPDPA, or a US state statute. Log the send timestamp in the case. Auditors ask when the clock started. Attach the inventory snapshot hash so you can show why this vendor was on the list.

Article 17: erasure, plus the revoke you will forget

Dear [Vendor Privacy Team],

The data subject exercised the right to erasure. Your service processed data via OAuth grant [Client ID] owned by [Employee, if applicable].

Confirm deletion timeline, backup retention, and any sub-processor cascade. If you claim an exemption, cite the legal basis under Article 17(3). If no data exists, say so explicitly.

Reference: [DSAR-ID].

A deletion letter without a technical revoke is theater. The refresh token stays live. Pair outreach with revoke in governance (or Google Admin / Okta Admin if you are doing this by hand). Document vendor non-response. If a regulator later asks what you did, you need evidence of reasonable contact attempts, not a Slack thread saying "they never replied."

Article 20: portability (narrower than people think)

Dear [Vendor Privacy Team],

Provide a structured, commonly used, machine-readable export for [Subject Identifier] where processing is based on consent or contract and carried out by automated means. Confirm format (JSON or CSV) and a secure delivery mechanism.

Deadline: [Date].
Reference: [DSAR-ID].

Portability is not a second access request. Counsel filters which vendors receive this template. Do not blast it to every OAuth client on the inventory. That is how you create noise, miss the real processors, and teach vendors to ignore you.

Worked examples (generic, not customer stories)

Example A: HubSpot via Google OAuth. Marketing connected HubSpot with mail and contacts scopes. Article 15 goes to HubSpot's published DPA / privacy contact, citing the client ID from inventory. You do not start with a generic "please delete this person from your CRM" ticket. You ask what they process for this subject, then decide erasure separately.

Example B: departed employee, grants still live. The subject is a former contractor. IdP disable happened on Friday. Monday, three AI tools still hold gmail.readonly. Erasure DSAR is not complete until those grants are revoked and vendors confirm deletion or "no data." This is also a CC9.2 sample waiting to happen. See the deprovisioning model.

Example C: AI extension, gmail.readonly. Same pattern as Context.ai. Treat it as Tier 1. Mail content is likely processed. Send access first. If the subject asked for erasure, revoke the client ID across the workforce if the tool is unattested, not just the one mailbox.

Clock, reminders, and who owns what

Day 0 is identity verification, not the email that landed in a shared inbox. Use the KYC process you already have. Do not invent a new one mid-case.

• Day 7. Reminder to non-responders. Same case ID. Same deadline.
• Day 21. Escalate to the vendor account owner in procurement or the grant owner's manager.
• Day 28. Counsel decides extension, partial response, or regulator-risk language in the subject letter.

Roles stay separate even when the inventory is shared. Privacy owns the case and the subject letter. Security owns grant revoke on erasure. Procurement owns the DPA chase. Legal owns exceptions and the final send. ScopeMantle is the single inventory, not a substitute for those roles.

Median close time belongs on the board report template. The example slide in that template uses an 18-day median against a 30-day target. Pick a target your team can hit with the inventory you actually have, then publish it. Do not invent a number for the deck.

Operator checklist per case

• Subject identity verified under the existing process.
• Inventory snapshot hashed and stored with the case ID.
• Internal systems searched against a confirmed systems list, not tribal knowledge.
• Tier 1 vendors emailed in parallel with case ID, basis, and deadline.
• Erasure cases: OAuth revoke executed and logged, not just requested.
• Exceptions recorded with legal sign-off and an expiry, not a permanent "we always skip this vendor."
• Partial vendor packs documented. The subject letter explains the limitation after counsel review.
• Close letter is an operator draft plus counsel review. Never the reverse.

What to tell an auditor or a regulator

They will ask three things: how you knew who processed the data, when you asked them, and what you did when they stalled.

1. "Processor discovery is the OAuth grant export from Google Workspace and Okta, timestamped before first send. Here is the hash."
2. "Outreach used operator-reviewed templates adapted by counsel. Here are send logs and delivery receipts, redacted."
3. "Non-response followed day 7 / 21 / 28. Erasure included IdP revoke, not only a deletion letter."

Do not claim the templates are lawyer-reviewed. Do not claim HIPAA coverage. ScopeMantle is not HIPAA attested and offers no BAA. Do not claim a DPDPA certification. Map evidence to CC9.2 and Article 32 as operational controls, not as a legal opinion.

Mistakes that burn the clock

• Using last year's RoPA without an OAuth diff.
• One email to support@ with no ticket, no case ID, no deadline.
• Forgetting sandbox orgs and agency-owned grants (Salesforce-class tools are famous for this).
• Promising the subject thirty days while the internal SLA is undefined.
• Sending Article 20 to every vendor because someone said "be thorough."
• Closing erasure while refresh tokens are still valid.
• Letting an MSP send subject-facing mail without client counsel. See MSP DSAR white-label.

Where ScopeMantle saves time

You can run this playbook in a spreadsheet. Plenty of teams do, once. The second DSAR in the same month is when the export is already stale. ScopeMantle keeps Google and Okta inventory current, scores vendors so you send Tier 1 first (risk scoring), and files vendor PDFs on the grant record. Microsoft Entra is Beta / roadmap. Inventory there is partial until GA.

Post-breach volume is the stress test. Drift and Context.ai both produced a spike in "do you still have our people's data" mail. Pre-build the client-ID-to-privacy-contact map now. Security revoke and privacy outreach are parallel tracks, not a single queue.

What to do this week

1. Export Google Admin third-party app access and Okta OAuth clients. Deduplicate by client ID.
2. Pick one closed DSAR from the last quarter and rebuild its vendor list from that export. Count how many processors the original case missed.
3. Load the three templates into your case tool. Add case ID, deadline, and client ID fields. Do not let people delete them.
4. Name the day-7 / 21 / 28 owners. If that is one person, say so. Do not pretend you have a team of four.
5. If you want the inventory to stay current, start a 30-day trial. Read the companion vendor inventory blog, OneTrust alternative for DSAR ops, and DPDPA checklist for India.

Honest limits

Templates are operator-reviewed, not lawyer-reviewed. No fabricated customer counts on customers. We are in a design-partner phase and we price in public: $5 annual / $6 monthly, no seat min, custom 500+. HIPAA is not attested. Entra is labelled Beta. Children's data, special-category data, and law-enforcement exceptions are counsel's filter, not a product toggle.