What to do when your vendor has a data breach

The breached system belongs to the vendor, but every point where it meets your environment belongs to you, and none of that needs their cooperation, their timeline or their permission. Most of it can be closed in an afternoon by people who already have the access.

Preserve your own logs before you start revoking, because disablement and rotation generate their own events and some log stores are fixed-size buffers where new entries push old ones out. Export the sign-in records for the vendor's service principal, your API gateway logs filtered to their key, and your webhook receipt logs, then hold copies outside the normal retention policy. Thirty or ninety day retention is common and intrusion windows run longer.

One entry on the checklist below behaves differently. A delegated administration relationship grants an outside organisation privileged roles inside your directory, and the grant runs to that organisation and its security groups rather than to any user object you control, so disabling accounts in your own tenant does nothing to it. In a Microsoft tenant you end it from the Microsoft 365 admin center, under Settings and Partner relationships. Microsoft points customers there rather than to the Entra admin center, PowerShell or Graph, which is why these relationships survive audits that only inspect the directory.

Containment of this kind is also legal work. Section 26WF of the Privacy Act provides that where remedial action is taken quickly enough that the breach is not likely to result in serious harm, it is not an eligible data breach, and the obligation does not arise for you or for the other entities involved. Credentials rotated before anyone used them can meet that description, so record when each step completed and set it against the vendor's access window.

Two questions get merged here and should be kept apart. What you sent the vendor is knowable from your side, precisely, today. What an attacker could reach inside the vendor's systems needs the vendor. Teams stall on the second and never start the first, then arrive at day twenty with no scope of their own and no answers from anyone else.

Integration code and field mappings show which attributes cross the boundary, and export job definitions show volumes, frequencies and date ranges. Your API request logs, filtered to the vendor's principal, show what they actually pulled and when, which is both a scoping input and independent evidence of anomalous access. Where a vendor service account reads from your database, the audit trail on those tables identifies the records touched down to the row.

The real scope is almost always wider than the live integration. The vendor has held your data since the relationship began, plus whatever staff pasted into support tickets, plus their backups, plus the extract a solutions engineer took during onboarding and never deleted. Where the retention question goes unanswered, scope against the assumption that everything you have ever sent is still there, and record why you drew the boundary there.

Start from why the obligation is yours at all. The Privacy Act treats an entity as holding personal information where it has possession or control of a record containing that information, and OAIC guidance is explicit that an organisation which outsources storage while retaining the right to deal with the information, including to access and amend it, continues to hold it. Your APP 11 obligation does not travel to the vendor with the data, and neither does the notification duty that follows from holding it. A breach inside the vendor's systems can be your eligible data breach.

The assessment duty is triggered by reasonable grounds to suspect an eligible data breach, which sits well below confirmation. A credible report that your vendor has been breached, combined with your own knowledge that you send them personal information, clears that bar. Section 26WH requires a reasonable and expeditious assessment and all reasonable steps to complete it within thirty calendar days of becoming aware. The Commissioner treats thirty days as a maximum rather than a target, so spending twenty-five of them waiting for a vendor statement is a decision you will be asked to justify.

When the facts sit with someone else, the assessment becomes the record of your enquiry plus the inferences drawn from your own evidence. Document the questions asked, the date and channel, the deadline set, what came back, what did not, and what your logs and data flows establish independently. An assessment that shows its working survives the picture changing, while one that states a conclusion with nothing behind it reads afterwards as a judgement made under commercial pressure.

If the thirty days run out and you still cannot exclude serious harm, notify. The scheme has no holding state for pending vendor confirmation, and a statement to the Commissioner can be supplemented as more becomes known. A notification that later proves broader than necessary gets corrected. An assessment that quietly ran past thirty days is a failure to comply with section 26WH in its own right, sitting alongside whatever the vendor did.

Where the same personal information is held by more than one entity and the incident is an eligible data breach for each of them, section 26WM of the Privacy Act means only one of those entities needs to prepare the statement for the Commissioner and notify the affected individuals. Compliance by one discharges the others, and that is where multi-party breaches most often come apart.

The section permits one entity to carry the notification without deciding which one. If the vendor assumes its customers will notify and every customer assumes the vendor is handling it, nobody notifies, and every entity that held the information can be found to have failed to comply. Converting that permission into a decision is somebody's job: name the entity, record the decision in writing with a date against it, and tell the other parties instead of leaving them to infer it.

The Commissioner's guidance is that the entity with the most direct relationship with the individuals at risk of serious harm may be best placed to notify them. Where the breached party sits behind you as a software, hosting or managed service provider, that entity is you. Your customers have a relationship with you, have frequently never heard of the vendor, and will call your number whatever letterhead the notification arrives on. Get the vendor's intentions in writing before you send anything, so two accounts of one incident do not contradict each other.

Duplicate notification to the regulator is not the risk it is usually taken for. The OAIC counts notifications about a single incident as one primary notification with secondary notifications attached, so several entities reporting the same breach is a state the scheme was built to handle. The failure worth avoiding is the one where each entity relies on another and none of them tells the individuals.

A vendor's forensic investigation runs on their timeline, and none of your obligations pause for it. The thirty day assessment window runs from your awareness of the grounds for suspicion, and a report landing in week six does not extend it. Several other clocks are shorter and start on the same trigger, which is the moment you became aware rather than the moment the picture became clear.

Work out which of these reach you before you need them, because each carries its own definition of awareness and its own recipient. Two of them can be running while you are still trying to reach an account manager, and none of them waits for the vendor to confirm what happened. Where a threshold is genuinely arguable, decide it early and record the reasoning, since the alternative is discovering on day ten that a seventy-two hour window closed on day three.

Keep the legal assessment reasoning separate from the technical incident log, and take advice on privilege early rather than after the post-mortem is written. A candid root cause document produced without that thought is discoverable, and a frank sentence written at two in the morning reads very differently in a schedule of evidence. Tell the team on day one not to tidy the incident channel once the pressure lifts.

The list below exists because indemnities, liability caps, service credits and any negotiation that follows all turn on facts nobody will have the time or the memory to reconstruct afterwards. Each item costs minutes to capture while the incident is live and cannot be recreated once it is closed.

The post-incident review worth running after a vendor breach is mostly a contract review, because the technical remediation is usually small and the contractual gaps are usually what made the incident hard to work. Run it while the vendor's commercial team is still motivated to keep the account.

The engineering half is about reducing what the next vendor breach can cost you. Send fewer fields, because the cheapest reduction available is not handing over data the vendor's function does not require. Use short-lived credentials in place of static keys, scope an integration's permissions to the operations it performs, and keep a separate credential per vendor so revocation is surgical. Then write the revocation runbook for each material vendor while nothing is on fire: which credentials, which application registration, which jobs, in what order, and who holds the access to run it.

Black Shard works both halves of this. Incident response and vCISO engagements cover the assessment, the notification decision and the supplier posture around them, and Entra ID and Azure security reviews cover the enterprise applications, service principals, consent grants and delegated administration relationships that carry the real risk in a vendor compromise. The systems we build carry the other half, because a vendor incident always resolves to what an integration touched and when. The operations and compliance portal we built and run for GRM LAW sits on an append-only audit ledger, and the staff portal we built for Stone Leaf Capital keeps a compliance audit log capturing the actor, the action and the before and after state of every change. An organisation holding that record answers the scope question in an afternoon.