When a SaaS supplier is breached, the attacker may already hold the OAuth tokens, API keys and integration credentials your organisation gave that supplier, and your own environment has no alert to tell you. This playbook template covers the hours and days after a vendor discloses, or you discover, a compromise of a SaaS product connected to your data: deciding whether you are affected, cutting the supplier's machine access, hunting for misuse, rotating every secret the supplier held or could read, and meeting notification duties. It is built from published vendor advisories and incidents such as Salesloft Drift and CircleCI, Microsoft and Google guidance, and NIST SP 800-61 Rev. 3. It is written for security operations, third-party risk and SaaS platform teams, with decision points for incident managers and executives. Adapt the bracketed text before adoption.
How to use this template
- Replace text in square brackets, such as [Organisation], [Incident Manager], [SIEM] and [Vendor Register], with your own names. "Must" is mandatory; "should" is recommended.
- Decision points are marked D1 to D5. Record each decision, who made it, when, and the evidence it rested on.
- This playbook coordinates the vendor side of the incident. For the token revocation mechanics in Microsoft Entra ID, Google Workspace and GitHub, use the OAuth Token Theft Incident Playbook; for keys found in code or logs, the Leaked Credential Response Playbook; for exposed cloud keys, the Cloud Access Key Leak Playbook.
- Assign severity with the Incident Severity Classification Matrix Template. The playbook sits under your Incident Response Plan Template.
1. Scope and triggers
1.1 This playbook applies when [Organisation] has reason to believe that a third-party SaaS provider, or an integration vendor connected to [Organisation] systems, has suffered a security incident that may expose [Organisation] data, credentials or tokens.
1.2 Triggers include:
- Vendor notice: a breach notification, security advisory, trust page update or support email from the supplier.
- Platform action: a platform provider revoking or disabling a vendor's integration, for example Salesforce removing an app from AppExchange, or Google disabling an integration.
- Threat intelligence: an advisory naming the vendor (GTIG, CISA, a national CERT) or a leak-site claim.
- Internal detection: bulk queries, unfamiliar user agents or Tor and VPN sources on an integration identity; a canary token embedded in vendor-held data firing.
- Customer or researcher report: someone outside reports [Organisation] data appearing elsewhere that only the vendor held.
1.3 The table maps the common vendor breach patterns to MITRE ATT&CK so detections and reports use consistent terms.
| Pattern | Example | ATT&CK techniques |
|---|---|---|
| Vendor stores customers' OAuth tokens and is breached | Salesloft Drift, 2025 | T1199 Trusted Relationship, T1528 Steal Application Access Token, T1550.001 Application Access Token |
| Vendor stores customers' secrets (CI/CD variables, keys) | CircleCI, 2023 | T1199, T1078.004 Cloud Accounts |
| Vendor software or update is compromised | Malicious update or package | T1195 Supply Chain Compromise |
| Customer credentials for the SaaS are stolen, platform intact | Snowflake customer accounts, 2024 | T1078.004 |
| Attacker bulk-exports data through the integration | CRM object exports | T1213 Data from Information Repositories, T1567 Exfiltration Over Web Service |
1.4 Out of scope: vendor outages with no security cause ([Business Continuity Plan]).
2. Roles and contacts
| Role | Responsibility | Named contact |
|---|---|---|
| [Incident Manager] | Owns the incident, decision points D1 to D5, the timeline and the single source of truth on vendor status | [Name, phone] |
| [SOC Analyst] | Log retrieval and hunting across the SaaS platform, identity provider and cloud accounts | [Rota] |
| [Vendor Relationship Owner] | Business owner of the supplier; knows what the product is used for and who depends on it | [From Vendor Register] |
| [Third-Party Risk Lead] | Holds the contract, security schedule, DPA and notification clauses; tracks vendor commitments | [Name] |
| [SaaS Platform Owner] | Revokes connected apps, tokens and integration users in each affected platform (Salesforce, Microsoft 365, Google Workspace, GitHub) | [One per platform] |
| [Integration Owner] | Knows which credentials the integration holds and rotates them | [From NHI inventory] |
| [Legal and Privacy] | Determines notification duties and preserves privilege | [DPO, counsel] |
| [Communications] | Customer, staff and media statements | [Name] |
| [Executive Sponsor] | Approves business-disrupting containment such as suspending a vendor | [Name] |
2.1 The [Vendor Register] must record, for each SaaS supplier, a security incident contact, the connected apps and integration identities it uses, the credentials [Organisation] has given it, and the data categories it can read. Without this list, step 3 takes days instead of hours.
3. Detection and triage
- Open the incident in [Ticketing system] and record the source, time received and the vendor's exact wording. Save the advisory; vendor pages change.
- Identify the exposure path. From the [Vendor Register] and NHI inventory, list every way the vendor touches [Organisation]: OAuth grants and connected apps, API keys issued to the vendor, service accounts or integration users, credentials stored inside the vendor product (for example CI/CD variables), SSO federation, and data the vendor processes.
- Ask the vendor for: affected period, affected products and regions, whether customer tokens or secrets were stored in the compromised systems, indicators of compromise, whether the vendor has revoked tokens on customers' behalf, and a named incident contact.
- Pull logs for each integration identity from the start of the vendor's affected period (or 90 days if unknown) to now. In Salesforce, GTIG advised reviewing Event Monitoring logs for the connected app's user and UniqueQuery events, which record executed SOQL queries. In Microsoft Entra ID, review service principal sign-ins and the audit activity "Consent to application" and "Update Application" events for certificates and secrets management.
- Hunt for misuse: bulk exports, count queries across many objects, sign-ins from Tor exit nodes or hosting providers, unfamiliar user agents (GTIG listed Salesforce-Multi-Org-Fetcher/1.0 and Salesforce-CLI/1.0 in the Drift campaign), and new credentials added to the vendor's app registration.
D1: Are we affected? Classify as Confirmed (evidence of attacker use of [Organisation] access), Exposed (our tokens or secrets sat in the compromised systems, no use seen yet) or Not exposed (the vendor confirms in writing that our tenant and credentials were outside scope). Treat Exposed as Confirmed for containment. Absence of evidence in your logs is not proof: in the Drift case the actor deleted query jobs, although GTIG noted the logs themselves were not affected.
4. Containment
- Preserve evidence first. Export the relevant platform logs before retention expires and before revoking anything that deletes history. Record app IDs, client IDs, scopes and grant dates.
- Cut the vendor's machine access. Revoke the OAuth grants and refresh tokens the integration holds; disable or suspend the integration user; deactivate API keys issued to the vendor. In Entra ID, disable sign-in for the service principal (accountEnabled false) rather than deleting it, which Microsoft warns removes evidence. Revoking delegated grants does not stop users re-consenting, so block consent to the app as well.
- Restrict what remains. If the integration must keep running, reduce scopes, enforce IP restrictions on the connected app, and shorten session timeouts.
- Disable SSO or federation trust from the vendor if the vendor's identity system was in scope.
D2: Suspend the vendor? The [Executive Sponsor] decides whether to switch the integration off entirely. Default: suspend when the classification is Confirmed or when the vendor cannot say whether tokens were stored in compromised systems. Record the business impact accepted.
5. Eradication
5.1 Rotate everything the vendor held, not only what it used. CircleCI told customers to assume any secret stored on its platform during the affected period had been accessed, and to rotate them all.
| What the vendor held or could read | Eradication action | Owner |
|---|---|---|
| OAuth access and refresh tokens | Revoke the grant; re-authorise only after the vendor's remediation is verified | [SaaS Platform Owner] |
| API keys and client secrets issued to the vendor | Issue new, narrower keys; delete the old ones; remove any credentials the attacker added to the app registration | [Integration Owner] |
| Secrets stored in the vendor product (CI/CD variables, cloud keys, SSH keys) | Rotate at the issuing system; replace with OIDC federation or short-lived credentials where possible | [Integration Owner] |
| Secrets inside data the vendor could read (support cases, CRM notes, tickets) | Search for credential patterns, then rotate what you find | [SOC Analyst] |
| Downstream secrets an app identity could reach (key vaults, secret stores) | Rotate, prioritising secrets actually retrieved | [Cloud Platform Owner] |
| User passwords of accounts linked to the integration | Reset and revoke sessions | [Identity Administrator] |
5.2 The secondary-secrets search is where most organisations fall short. In the Salesloft Drift breach the attacker searched exported Salesforce data for AWS access keys, passwords and Snowflake tokens. GTIG advised searching records for strings such as "AKIA", "snowflakecomputing.com", "password" and organisation-specific login URLs, and running a secret scanner such as TruffleHog. Each hit is a new incident handed to the Leaked Credential Response Playbook.
5.3 Remove any persistence found: new users, connected apps, credentials, mailbox rules or webhooks created during the affected period.
6. Recovery
- Verify the vendor's remediation before reconnecting: written confirmation of root cause, credential rotation on their side, and how customer tokens are now stored. Salesforce kept Drift off AppExchange pending investigation; [Organisation] should apply the same gate.
- Re-authorise with least privilege: new grant, minimum scopes, IP restrictions, a named owner and an expiry review date.
- Monitor closely for 30 days after reconnection, with alerts on the integration identity's export volume and source addresses.
- Restore data from backups if the attacker altered or deleted records.
D3: Reconnect, replace or exit? The [Vendor Relationship Owner] and [Third-Party Risk Lead] recommend; the [Executive Sponsor] decides. Exit triggers include no root cause after [30] days, refusal to share indicators, or repeat incidents. On exit, confirm data deletion and that every credential issued to the vendor is revoked.
7. Communication and notification
D4: Do we have a notification duty? [Legal and Privacy] decides, using the evidence from step 3. The vendor's breach can still be [Organisation]'s notifiable incident.
| Audience | Trigger | Timing to check | Owner |
|---|---|---|---|
| Supervisory authority (UK and EU GDPR) | Personal data breach where [Organisation] is controller, unless unlikely to result in risk | Article 33: within 72 hours of becoming aware | [DPO] |
| Data subjects | High risk to individuals | Without undue delay (Article 34) | [DPO] |
| Securities regulator (US registrants) | Material cybersecurity incident | SEC Form 8-K Item 1.05: four business days after determining materiality | [General Counsel] |
| Sector regulators and contracts | Per [Regulatory Register] and customer contracts | [Insert] | [Legal] |
| Customers and partners | Their data or integrations affected | After D4, using agreed facts only | [Communications] |
| Staff | Phishing risk using stolen data | Same day as containment | [Communications] |
7.1 Statements must distinguish what the vendor has stated from what [Organisation] has confirmed.
7.2 Where [Organisation] is itself a processor or SaaS supplier to others, notify affected customers under the contract terms; the incident may be your customers' vendor breach.
8. Post-incident review
8.1 Hold the review within [10] working days of closure using the Post-Incident Review and Root Cause Analysis Template. D5: the [Executive Sponsor] accepts or rejects each action.
8.2 The review must answer:
- How long between the vendor's affected period, its disclosure, our awareness and our revocation of its access?
- Did the [Vendor Register] list every token and secret the vendor held? What was missing?
- Which secrets were found in data the vendor could read, and why were they there?
- Did the contract give us the notification time, logs and cooperation we needed?
- Could the integration have run with narrower scopes, IP restriction or short-lived credentials?
8.3 Feed results into the third-party risk process: reassess the vendor, update contract clauses at renewal, and update this playbook.
Implementation guidance
Before the next incident. Build the per-vendor exposure record described in 2.1, sourced from your connected-app and NHI inventories. See the SaaS and OAuth App Governance Guide and the Third-Party Risk Management Guide. Add contract clauses for incident notification within [24 to 72] hours, indicator sharing, log access and a security contact. Keep secrets out of support cases and CRM records with scanning and redaction. See the Secrets Management Guide.
Rollout. Phase 1: inventory the top [20] vendors by data access and test that you can revoke each one's access in under an hour. Phase 2: run a tabletop using the Tabletop Exercise Scenario Pack, with a vendor notice arriving on a Friday evening. Phase 3: automate revocation steps in the SOC Runbook Template format. Test revocations in a sandbox tenant first, and document how to re-authorise each integration so containment can be rolled back if D1 later proves Not exposed.
Small and large organisations. A small organisation can run this with one incident lead, the SaaS administrator and outside counsel, and should prioritise the vendor exposure list. A large organisation should pre-assign platform owners per SaaS platform and expect several vendor incidents a year.
Framework mapping.
| Playbook step | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Vendor register, contract clauses | GV.SC-08, GV.SC-10 | SA-9, SR-6, SR-8 |
| Monitoring vendor activity | DE.CM-06 | AU-6 |
| Triage, containment, eradication | RS.MA-01, RS.MA-02, RS.MI-01, RS.MI-02 | IR-4 |
| Notification and sharing | RS.CO-02, RS.CO-03 | IR-6 |
Metrics. Track: time from vendor disclosure to [Organisation] awareness; time from awareness to revocation of the vendor's access (target under [4] hours for Exposed or Confirmed); percentage of vendor-held credentials rotated within [72] hours; number of secrets found in vendor-readable data; percentage of top-tier vendors with a complete exposure record; percentage of contracts with incident notification clauses.
Common failure patterns.
- Waiting for the vendor's final report before revoking. Revoke on Exposed; reconnecting is cheaper than a data theft.
- Rotating only the integration token and missing secrets stored in the vendor or pasted into data it could read, the pattern exploited in the Drift campaign.
- Confusing a customer-credential campaign with a platform breach. In the Snowflake breach, attackers used infostealer credentials on accounts without MFA; the response was customer-side credential reset, MFA and network policies, not vendor suspension.
- No list of what the vendor holds, as in the CircleCI breach, where customers had to find and rotate every secret stored on the platform.
- Deleting the app during containment and losing the audit trail needed for D1 and D4.
Standards and references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- Google Threat Intelligence Group: Data theft from Salesforce instances via Salesloft Drift (UNC6395)
- Microsoft: Compromised and malicious applications investigation
- Microsoft: Review and revoke permissions for an enterprise application
- MITRE ATT&CK: Trusted Relationship
Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · Third-Party Risk Management Guide · Cloud Incident Response Guide · Secrets Management Guide · OAuth Token Theft Incident Playbook