Your SaaS vendor was breached — the notification duties that are still yours

This playbook fires the moment you learn that an organisation *outside* your control — a SaaS platform, a cloud provider, a managed service provider, an integration vendor, a payroll bureau — has suffered a security incident that may touch your data or your service delivery.

It covers the question that follows: which filings are still yours, and when are they due.

It does *not* cover your own internal incident response — if the attacker also has a foothold in your estate, run your normal IR playbook in parallel; this one only governs the notification workstream. It also does not cover vendor selection or contract negotiation, except where a contract clause is the only thing that will get you evidence in time (see the evidence section).

The defining constraint: you must file on a statutory clock using evidence that a third party controls and is not obliged to hand you quickly. Every design decision below follows from that.

The most expensive mistake is treating this as one deadline. It is at least three, and they start at different moments.

GDPR (if personal data is in scope). Under Art. 33(2) the processor notifies you "without undue delay". Your own 72-hour clock under Art. 33(1) starts when *you* become aware — and the EDPB Guidelines 9/2022 on personal data breach notification, v2.0 are explicit at §44: "in principle, the controller should be considered as 'aware' once the processor has informed it of the breach". Receipt of the vendor notice is your trigger event. Timestamp it.

> Correct a widespread myth before it costs you. It is frequently claimed that the EDPB requires processors to notify controllers within 72 hours. It does not. §45 states plainly that "the GDPR does not provide an explicit time limit within which the processor must alert the controller, except that it must do so 'without undue delay'." The only enforceable deadline on your vendor is the one in your contract — §46 specifically anticipates contractual early-notification terms that support your 72-hour duty.

NIS2 (if you are an essential or important entity). Directive 2022/2555 Art. 23(4) sets early warning at 24 hours, incident notification at 72 hours, final report at one month. Critically, the trigger in Art. 23 is a *significant incident affecting your services* — not ownership of the compromised system. A supplier breach that significantly disrupts your essential service is your significant incident. Note also that your vendor may have an independent duty of its own: Commission Implementing Regulation (EU) 2024/2690 sets binding significance thresholds specifically for cloud providers, managed service providers, MSSPs and data centres.

DORA (if you are a financial entity). Regulation 2022/2554 Art. 19, operationalised by Delegated Regulation (EU) 2025/301 Art. 5, requires the initial notification within 4 hours of classifying the incident as major and no later than 24 hours from becoming aware of it — these are cumulative conditions, not a choice. Intermediate report: 72 hours from the *initial notification* (not from awareness). Final report: one month after the intermediate. Art. 5(4) grants a weekend/holiday extension to noon of the next working day — but Art. 5(5) withdraws it for credit institutions, CCPs, trading venue operators and any entity classified essential or important under NIS2. Most readers of this playbook fall in the exclusion.

Two things matter in the first day, and neither is investigation.

1. Establish and record your awareness timestamp. Every downstream deadline is calculated from it, and a regulator will reconstruct it later from your inbox, your ticketing system and the vendor's own disclosure timeline. Capture:

• The exact time the vendor notice arrived, and through which channel (account manager email, status page, trust portal, press release, or — uncomfortably often — a journalist).
• Whether an earlier signal existed that a competent observer would say should have alerted you: an anomalous-login alert from that integration, a status-page degradation, a partner warning. If one did, document it *and* the reason it did not trigger escalation. Concealing it is far worse than explaining it.
• Who received the notice and when it reached the person authorised to declare an incident. A notice sitting three days in a shared mailbox is a governance finding, not a defence.

2. Classify against each regime you are subject to. Run all applicable tests in parallel, not sequentially:

• Was personal data for which you are controller processed by that vendor? → GDPR Art. 33 assessment.
• Is a service you provide as an essential or important entity significantly disrupted? → NIS2 Art. 23.
• Does the vendor support a critical or important function? → DORA Art. 19 classification, and start the 4-hour sub-clock the moment you classify it major.

What you do not do in this window is wait for the vendor to confirm whether *your* tenant was affected. That answer routinely takes weeks. The early-warning and initial-notification gates are preliminary by design.

By the 72-hour gate you owe a substantive notification, and you will still be missing facts the vendor has not released. File anyway, and file honestly.

Structure the submission around what you can attest to directly:

• What you know: which vendor, which service, the vendor's own published account and its timestamps, which of your data categories or business processes are in that platform, your contractual data-flow documentation.
• What you have assessed yourself: your own log review for the affected integration — OAuth token grants and consents, API call volume anomalies, unusual data egress, service-account authentication from new sources. This is telemetry *you* hold and it is often the only independent evidence available in the first week.
• What is pending vendor confirmation: explicitly labelled as such, with the date you requested it and the response deadline you set.

That third category is what separates a defensible filing from a weak one. Supervisors are experienced with third-party incidents and expect open items at 72 hours. What draws scrutiny is a notification that presents vendor marketing language as verified fact, or that quietly omits the fact that you asked for evidence and did not get it.

One procedural note worth acting on now: the EDPB adopted a common data breach notification template at its 10 June 2026 plenary, with public consultation open until 5 August 2026. It is designed to harmonise Art. 33 notifications across supervisory authorities. Map your intake fields to it now rather than discovering the mismatch mid-incident.

You are filing about an incident you cannot investigate. Your leverage is almost entirely contractual, and almost entirely pre-negotiated.

Request in writing within the first 24 hours, with an explicit response deadline tied to your regulatory gate:

1. Whether *your specific tenant, instance or dataset* is in the affected scope — and, if not yet determined, the date the vendor expects to determine it.
2. The vendor's incident timeline: first anomalous activity, detection, containment, disclosure.
3. Data categories accessed or exfiltrated, at field level where possible.
4. Indicators of compromise you can hunt in your own estate — particularly any tokens, credentials or API keys the vendor issued to you or held on your behalf.
5. Whether credentials, OAuth tokens or session material granting access *back into your systems* were exposed. This is the question that converts a vendor incident into your own intrusion, and it is the one most often answered last.
6. The vendor's own regulatory filings and their reference numbers.

On point 5, the June 2026 Klue incident is the reference case: a compromised legacy credential on an integration service let an attacker obtain OAuth tokens for connected customer platforms including Salesforce, and reach data inside a number of downstream customer environments. Downstream organisations then had to file on their own account — LastPass disclosed access to customer data held in its own Salesforce instance, and 8x8 filed a Form 8-K with the SEC on 17 June 2026 over a breach at a vendor. The breach was Klue's. The filings were theirs.

If you are a financial entity, note that DORA Art. 30(2)(f) already requires contracts to oblige the provider to assist you when an ICT incident affects the service — at no additional cost or at a cost fixed in advance — and Art. 30(3)(b) requires defined notice periods and reporting obligations for contracts supporting critical or important functions. If your vendor is stalling, cite the clause.

The structural problem underneath all of this: the evidence lands in your inbox as unstructured vendor prose, and each regulator wants it as a different structured summary of the same underlying facts. Doing that mapping by hand, mid-incident, is where the 72-hour gate is actually lost. Zero Hunt's compliance engine maps a single evidence base across 32 frameworks — NIS2 including Title 13, GDPR and DORA among them — with cross-framework control mapping and ECDSA-signed reports carrying chain-of-custody by construction, so the per-regime filings are exports from one record rather than three parallel reconstructions.

Ordered by the gate that consumes each artefact:

For the awareness determination (first 24h) - Vendor notification with original headers and receipt timestamp. - Internal escalation log from receipt to incident declaration. - Any prior signal relating to that vendor, with triage disposition.

For the 72-hour filings - Data-flow and processing records for that vendor (GDPR Art. 30 register extract). - Contract extract: notification clauses, audit rights, assistance obligations. - Your own authentication and API telemetry for the affected integration, covering the vendor's stated incident window plus 30 days before. - Token and credential inventory for that vendor, with revocation status and timestamps. - Written evidence requests to the vendor, with dates and deadlines.

For the final report - Vendor forensic summary or root-cause statement. - Your independent verification of the vendor's scope claim. - Remediation record: rotated credentials, revoked consents, tightened scopes, contract changes. - Cross-references to every other filing made on the same facts. - Vendor risk-assessment update and any resulting change in vendor status.

Waiting for vendor certainty before starting your clock. The clock started when you were informed. Investigation is what you do *during* the window, not before it opens. Organisations routinely file late because they treated "we don't know if we're affected yet" as a reason not to file, when the regulation treats it as content to include in the filing.

Assuming the vendor filed on your behalf. It did not, and generally cannot. Under GDPR the responsibility to notify remains with the controller even where a processor notifies on its behalf with authorisation (EDPB Guidelines 9/2022 §48). Under DORA Art. 19(5) a financial entity may outsource reporting but "remains fully responsible" for it, and Art. 28(1) makes the same point for third-party risk generally. Outsourcing the work never outsources the duty.

Treating a multi-tenant breach as somebody else's problem. Where a processor serves many controllers affected by the same incident, EDPB §47 requires it to report the details to *each* controller — and each of those controllers owes its own assessment. Everybody assuming the largest customer will handle it produces a room full of late filings.

Never revoking the tokens. The single most common technical failure. Vendor integrations hold long-lived OAuth grants and API keys into your environment. If the vendor was breached, treat every credential it held for you as exposed and rotate it — do not wait for the vendor to confirm which specific tokens were taken. Confirmation typically arrives after the window in which rotation would have mattered.

Discovering your contract has no notification clause. Mid-incident is when organisations learn the agreement obliges the vendor to nothing more specific than "promptly". The fix is not available during the incident; it is available at renewal. Add it to the post-incident action list and treat the current incident as the business case.

Italian entities have unusually clear regulator guidance here, and it is more demanding than most organisations assume. ACN's NIS FAQ on security measures and incident notification addresses the supplier scenario directly:

• Incident on the client's systems, supplier providing services (ISB.F.1) — the notification duty under art. 25 d.lgs. 138/2024 sits with the client. ACN also notes that under measure GV.SC-01 the NIS client must ensure its supplier promptly reports security events affecting the client's services.
• Incident on the supplier's systems (ISB.F.2) — the duty sits with the supplier, *and* also with the NIS client entity where the incident is significant in relation to the client's own services and activities. This is an explicit dual notification.
• Cloud services (ISB.F.3) — duty on both client and supplier, with one carve-out: where the cloud service is IaaS or hosting of the client's own infrastructure, only the client notifies. The SaaS/IaaS distinction decides who files.

Deadlines under art. 25 mirror the directive: pre-notifica at 24 hours, notifica at 72 hours, final report at one month.

One governance item that catches organisations out: ACN determinazione 127437/2026, published 13 April 2026, introduced at art. 18 a duty to declare *fornitori NIS rilevanti* during the annual update window of 15 April to 31 May. If the vendor that just breached is not on your declared list and arguably should have been, that gap becomes visible to ACN at exactly the moment you file. Reconcile the two before you submit.

For broader NIS2 implementation context, ENISA's Technical Implementation Guidance on cybersecurity risk management measures, published 26 June 2025, is the non-binding companion to Implementing Regulation 2024/2690.