SaaS Provider Incident Notification Guide

When a SaaS provider is breached, hundreds of customers each start their own legal clock, and most of them depend on what the provider tells them and when. Customer-side playbooks explain how to react to a vendor breach; this guide covers the other side of the table. It is for security, legal, customer success and trust teams at SaaS and cloud providers who must decide which customers to tell, how fast, in what format and with what evidence, while honouring contract terms and the provider's own regulatory duties. It covers the notification obligations that land on providers as processors, business associates and service providers, a tiered notice model, the evidence customers need to run their own investigations, and how to share an investigation without breaking privilege or confidentiality. Customer-side readers should start with the Vendor SaaS Breach Response Playbook.

Key takeaways

Your notice starts other people's clocks. A controller's GDPR clock, a bank's 36-hour clock and a covered entity's HIPAA clock often run from what they learn from you, so a late or vague notice multiplies risk across your customer base.
Contracts are usually stricter than the law. Data processing agreements and enterprise security addenda commonly set fixed hours where the law says "without undue delay", so keep a searchable register of every committed clock.
Notify per tenant, not per incident. Customers need to know whether their tenant, their users and their credentials were touched, which means tenant-level scoping from your logs before or alongside the first notice.
Give evidence, not reassurance. Time windows, affected object types, indicators of compromise and exact credential rotation steps let customers act; "no evidence of misuse" on its own does not.
Customer reports are detection signals. Several provider incidents were first spotted by customers, so a customer's report of suspicious activity tied to your service must route to incident response, not to a support queue.

Why the provider side is different

A provider holds data and credentials for many organisations at once. One intrusion can expose OAuth refresh tokens, API keys, support attachments and customer records across thousands of tenants, and each tenant has its own regulators, contracts and customers. The provider is rarely the party with the direct duty to notify regulators or individuals about the customer's data: that usually sits with the customer as controller, covered entity or regulated firm. The provider's duty is to inform the customer quickly and completely enough that the customer can meet its own duty.

That chain is visible in recent incidents. In the Okta Support System Breach 2023, a customer raised concerns on 2 October 2023 and escalated for more than two weeks before the provider confirmed the breach to affected customers on 19 October; the scope was later widened from 134 customers' files to names and email addresses of all support system users. In the CircleCI Breach 2023, the provider told every customer to rotate every secret stored on the platform and to assume they had been accessed, a clear instruction that let customers act on day one.

Which obligations reach the provider

The table lists notification duties that apply to providers in their capacity as someone else's processor or service provider. It is a summary, not legal advice. Confirm against the official text before relying on it.

Rule	Provider role	What the provider must do	Customer's downstream clock
GDPR Article 33(2)	Processor	Notify the controller without undue delay after becoming aware of a personal data breach (no fixed hours in the Regulation)	Controller notifies the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware, unless the breach is unlikely to result in a risk to individuals
GDPR Article 28(3)(f) and (h)	Processor	Assist the controller with Articles 32 to 36 (security, breach notification, impact assessment) and allow for and contribute to audits	Controller's Article 33 and 34 duties
NIS2 Article 23(1) and (2)	Essential or important entity (cloud, data centre, managed service providers and others in scope)	Notify the CSIRT or competent authority of significant incidents and, where appropriate, notify recipients of the service without undue delay; tell potentially affected recipients about significant cyber threats and the measures they can take	Provider's own regulator reporting: early warning within 24 hours, notification within 72 hours, final report within one month
HIPAA 45 CFR 164.410	Business associate	Notify the covered entity without unreasonable delay and in no case later than 60 calendar days after discovery, with the identity of each affected individual to the extent possible	Covered entity's notices to individuals, HHS and, where required, media
US bank rule 12 CFR 53.4 (and the equivalent FDIC and Federal Reserve rules)	Bank service provider	Notify at least one bank-designated point of contact at each affected bank as soon as possible after determining an incident that has materially disrupted or degraded, or is reasonably likely to, covered services for four or more hours	Bank notifies its regulator as soon as possible and no later than 36 hours after determining a notification incident
SEC Regulation S-P (as amended in 2024)	Service provider to a broker-dealer, investment adviser, fund or transfer agent	The covered institution must require, through its oversight policies, that service providers notify it as soon as possible and no later than 72 hours after becoming aware of a breach of a customer information system they maintain	Covered institution notifies affected individuals as soon as practicable and no later than 30 days after becoming aware
DFARS 252.204-7012	Contractor or subcontractor handling covered defence information	Report cyber incidents to DoD within 72 hours of discovery, preserve images and monitoring data for at least 90 days, and pass incident report numbers up the supply chain	Prime contractor and DoD response

For the customer-side view of the same rules and sample clause wording, see the Third-Party Incident Notification Clauses Guide. For the bank rule in depth, see the US Bank Computer-Security Incident Notification Rule Guide, and for regulator clocks by country, the Cyber Incident Reporting Requirements Map.

Building the contract clock register

Most providers sign hundreds of data processing agreements, security addenda and customer-paper contracts, each with its own notice wording. When an incident starts, nobody has time to read them. Build the register before you need it.

Extract the commitments: for every contract, record the notice trigger ("security incident", "personal data breach", "unauthorised access"), the clock (for example 24, 48 or 72 hours, or "without undue delay"), the clock start (awareness, confirmation, determination), the named recipient and channel, and any required content fields.
Normalise triggers: map each contract trigger to your internal severity levels so the incident commander can see which customers are owed a notice the moment an incident is classified.
Record designated contacts: the bank rule requires notice to a bank-designated point of contact, falling back to the CEO and CIO or two people of comparable responsibility. Collect a security contact for every customer at onboarding and revalidate it yearly.
Flag regulated customers: tag tenants that are banks, HIPAA covered entities, SEC-registered firms, defence contractors or NIS2 entities, because their downstream clocks are short and fixed.
Standardise your paper: offer a default addendum with a single clock you can actually meet. Accepting a different clock per customer creates obligations you cannot track under pressure.

Keep the register in a system that incident responders can query by tenant ID, not in a contract repository only legal can search. See the DORA Article 30 Contract Provisions Guide for the assistance and notice terms EU financial customers must put in ICT contracts.

A tiered notice model

Notification is a sequence, not a single email. The model below is an NHI Mgmt Group recommendation that fits the clocks above; adjust it to your contracts.

Notice	When (NHI Mgmt Group recommendation)	Audience	Minimum content
1. Early alert	Within 24 hours of a reasonable belief that customer data, credentials or service integrity is affected	Security contacts of potentially affected tenants	What is known, the time window under review, immediate protective steps (revoke or rotate named credential types), next update time, a named contact
2. Confirmed impact	Within 72 hours, or earlier where a contract requires it	Affected tenants, individually	Tenant-specific findings: affected objects, users, tokens or keys, first and last activity times, indicators of compromise, source IP addresses and user agents seen
3. Status updates	At a fixed cadence (for example daily) until containment, then weekly	All affected tenants plus a public status or trust page where the incident is widely known	What changed since the last update, revised scope, remediation completed
4. Final report	When the investigation closes	Affected tenants, under confidentiality	Root cause, full timeline, controls changed, evidence customers can give their auditors and regulators

Two rules make the model work. First, do not hold notice 1 until the forensics firm has finished: the regulator clocks of your customers do not wait for your root cause. Second, say what is unknown. A notice that says "we have not yet determined whether refresh tokens were accessed; rotate them now" is more useful than silence.

Tenant-level scoping and the evidence customers need

Customers cannot assess their own exposure from a generic statement. Before or alongside notice 2, produce a tenant-scoped extract from your telemetry.

Credential exposure: list every token, key, OAuth grant, webhook secret and service account credential belonging to the tenant that sat in an affected store, with creation date and last use. In the Salesloft Drift Breach 2025, all active Drift access and refresh tokens were revoked on 20 August 2025, after the 8 to 18 August theft window, and Google advised all Drift customers to treat connected tokens as potentially compromised.
Data object exposure: which tables, files, support cases or attachments were read or exported, with counts. Support attachments are a recurring problem: browser HAR files, logs and screenshots often carry session cookies or keys (ATT&CK T1539 Steal Web Session Cookie, then T1550.004 Web Session Cookie).
Activity records: provide or make downloadable the audit log entries for the tenant in the incident window, in a documented format and time zone (UTC), so customers can join them with their own SIEM data.
Indicators: attacker IP addresses, autonomous systems, user agents, OAuth client IDs and file hashes, labelled with a Traffic Light Protocol marking so customers know how far they may share them.
Rotation instructions: exact steps for each credential type, the order to do them in, and whether the provider has already revoked anything on the customer's behalf.

The Snowflake Breach 2024 shows the opposite boundary: the platform was not exploited, and about 165 customer accounts were accessed with infostealer credentials on accounts without MFA. Even when the cause is customer-side, providers are asked for detection queries, login records and hardening guidance, and Snowflake later announced a phased block on single-factor password sign-ins.

Running a shared investigation

Large customers will want to join the investigation. Plan the boundaries in advance.

Set up a customer liaison cell: a small team, separate from the core forensic team, that handles customer questions, tracks commitments and feeds facts from the incident log to customers.
Agree what you share and under what terms: legal counsel decides whether forensic reports are shared in full, summarised or under a common interest arrangement. Decide this per incident, early, and record it.
Use a joint bridge for major customers: one scheduled call per day with a written summary afterwards beats dozens of unscheduled calls that pull responders off the work.
Coordinate with other providers: when integrations are involved, revocation may need the platform on the other side, as when Salesforce disabled Salesloft integrations, or GitHub, Atlassian and AWS coordinated token rotation after the CircleCI breach. Keep contacts at your main integration partners.
Preserve evidence for customers' regulators: retain the logs and images that underpin each tenant's findings for as long as your contracts and rules require; DFARS 252.204-7012 sets at least 90 days from the report for covered defence information.

For governance and decision rights across parties, see the Major Incident Coordination Across Third Parties Guide.

Formats and channels

Direct notice: email to the registered security contact plus an in-product banner for tenant administrators. Do not rely on a single channel: contacts go stale and email can be compromised.
Trust or status page: a public page for widely known incidents, with dated updates and a changelog. It reduces inbound questions but never replaces tenant-specific notice.
Machine-readable data: indicators in a structured format (CSV or STIX) and audit log extracts through an API or a secure download, not as email attachments.
Templates ready: pre-approved wording for each notice tier, reviewed by legal. The Incident Communication Plan Template covers holding statements, status page cadence and approvals; the Customer Breach Notification Letter Template covers letters to individuals.

Decision guidance

Notify everyone or only confirmed tenants? If a credential store or shared component was reached, notify every tenant whose secrets were in it; confirmation can follow. If access is proven to be limited to specific tenants, notify those tenants individually and publish a general statement only if the incident is public.
Revoke for customers or ask them to rotate? Where you can revoke tokens or keys centrally without breaking critical workloads, do it and say so. Where revocation would cause outages, tell customers exactly what to rotate and by when, and offer a grace window you control.
Small provider or large? A small provider can keep the register in a spreadsheet and run notices from one inbox, provided the security contact list is current. A large provider needs register data joined to tenant IDs, automated scoping queries and a liaison cell that scales.
Public disclosure: a provider that is itself a public company may also have its own disclosure duties; see the SEC Cybersecurity Disclosure Rules Guide. Coordinate public and customer statements so customers do not learn of their exposure from the press.

Where identity fits

Provider incidents are increasingly about machine credentials: OAuth tokens held for integrations, API keys stored as environment variables, support service accounts and signing keys. The Okta case started with a service account credential saved in an employee's personal browser profile. Know which customer credentials you hold, where, and how to revoke them in bulk, and make that inventory part of incident preparation. See the SaaS Provider Tenant Isolation and NHI Guide.

Detection and measurement

Customer report routing: time from a customer's report of suspicious activity tied to your service to triage by the security team. Target hours, not days.
Clock compliance: percentage of contractual and regulatory notices sent within their committed clock, measured per incident and per exercise.
Contact freshness: percentage of tenants with a security contact validated in the last 12 months.
Scoping speed: time to produce a tenant-level exposure extract after an incident is declared.
Bulk revocation time: time to revoke all tokens or keys of one type across all tenants, tested in exercises.
Scope revisions: number of times initial scope statements were widened; frequent widening signals that early notices claim more certainty than the evidence supports.

Common failure patterns

Treating customer reports as support tickets: in the Okta case, a customer's early report did not lead to a confirmed breach notice for more than two weeks.
Waiting for root cause before the first notice: customers' regulator clocks run while forensics continue.
Generic statements: "a small number of customers may be affected" with no tenant-specific facts forces every customer to assume the worst.
Narrow early scope: stating a firm number in the first notice and widening it later damages trust more than stating uncertainty plainly.
Unknown secrets in support data: support systems hold HAR files, logs and pasted keys that nobody inventoried, so their exposure is missed during scoping.
Untracked bespoke clocks: enterprise contracts with clocks shorter than the standard addendum that no responder knows about.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	RS.CO-02, RS.CO-03, RS.MA-01, GV.SC-08	Notify internal and external stakeholders, share information, coordinate response with third parties, include suppliers and customers in incident planning
NIST SP 800-53 Rev. 5	IR-6, IR-6(3), IR-4(10), IR-7, SR-8	Incident reporting, supply chain coordination of reporting and handling, response assistance, notification agreements
NIST SP 800-61 Rev. 3	CSF 2.0 Community Profile for incident response (April 2025)	Incident response as part of risk management, including information sharing
ISO/IEC 27001:2022 Annex A	5.20, 5.24, 5.26, 5.28	Security in supplier agreements, incident management planning, response, collection of evidence
CIS Controls v8.1	Control 17 Incident Response Management	Contacts, reporting processes and exercises

Practitioner checklist

Build a contract clock register with trigger, clock, clock start, recipient and content fields, queryable by tenant ID.
Collect and revalidate a security contact for every customer every year.
Tag tenants subject to bank, HIPAA, SEC, DFARS and NIS2 rules.
Pre-approve wording for early alert, confirmed impact, update and final report notices.
Route customer reports of suspicious activity to incident response, with a defined triage time.
Prepare tenant-scoped queries for credential, data object and activity exposure.
Test bulk revocation of each credential type you hold for customers.
Agree with counsel how forensic findings are shared and under what terms.
Exercise a multi-tenant notification scenario at least once a year and measure clock compliance.

Standards and references

This guide summarises notification duties for practitioners and is not legal advice. Related NHI Mgmt Group resources: Vendor SaaS Breach Response Playbook · Third-Party Incident Notification Clauses Guide · Breach Notification Laws by Country Guide · API Abuse and Data Scraping Response Playbook

SaaS Provider Incident Notification Guide: Notifying Customers, Meeting Contract Clocks and Investigating Together