You Find Out From the Leak Site: The First 72 Hours When the Breach Happened at Your Vendor

On 17 August 2026, Asia Insurance Post reported that a hacking group claimed mass data theft from Shell, Philips, GE, Fiserv and dozens of other organisations. A roster of that breadth follows a pattern the market has seen before: one shared platform or service provider is exploited once, and every organisation whose data passed through it becomes a victim in a single campaign. The Cl0p MOVEit Transfer campaign of 2023 worked exactly this way, with hundreds of downstream organisations learning of their exposure from the extortion group's own publication schedule rather than from any alert inside their own perimeter.

For Indian corporates and GCCs, this is the most likely shape of a first serious cyber loss. The payroll processor, the benefits administrator, the file-transfer tool, the customer-communications platform, the background-verification agency: each holds a slice of your data on infrastructure you do not monitor. When one of them is breached, your SOC sees nothing, your EDR fires nothing, and the first artefact of the incident is your company's name on a leak site, often spotted by a journalist, a threat-intelligence subscription, or a customer before anyone internal sees it.

That sequence breaks the standard incident-response playbook, which assumes you detected the intrusion, control the affected systems, and can scope the loss from your own logs. In a vendor breach you hold none of those advantages, yet every regulatory, contractual, and insurance clock starts anyway. What follows is the operational runbook for hour zero to hour 72.

The core difficulty of a vendor breach is that four separate notice obligations run on four separate triggers, and none of them waits for you to confirm the facts.

1. The CERT-In clock. The CERT-In directions of 28 April 2022, issued under Section 70B(6), Information Technology Act, 2000, require specified cyber incidents, including data breaches and data leaks, to be reported within 6 hours of noticing the incident or being brought to notice about it. The trigger is knowledge, and a leak-site listing naming your organisation is difficult to characterise as anything other than being brought to notice.
2. The DPDP clock. The Digital Personal Data Protection Act, 2023 places personal data breach duties on the Data Fiduciary, and routing the processing through a vendor acting as Data Processor does not shift them. The rules implementing the Act are phasing in, with full substantive compliance due by 13 May 2027, so the intimation machinery is arriving rather than fully operational today. Build the process now; an incident in 2027 will be judged against it.
3. The customer-contract clock. Master service agreements with enterprise customers, and especially the contracts under which GCCs process group or client data, commonly require notice of a security incident within a defined window of 24 to 72 hours. Many of those definitions trigger on suspected compromise, which a public theft claim naming your organisation plainly is.
4. The policy clock. Cyber policies condition cover on notice to the insurer, typically as soon as practicable after discovery, and many wordings separately invite or require notice of circumstances that may give rise to a claim. The leak-site listing is at minimum such a circumstance.

The uncomfortable arithmetic: the moment someone in your organisation credibly learns of the listing, all four clocks are plausibly running, and the shortest of them expires the same working day. The interaction between the 6-hour CERT-In window and the insurance programme is examined in detail in our post on CERT-In incident reporting and cyber insurance.

The instinct in the first hours is to establish whether the claim is real before doing anything formal. Resist it. Extortion groups routinely publish victim names before publishing data, sometimes exaggerate their access, and occasionally list organisations whose data they hold only indirectly. You will probably not resolve any of that within 6 hours. The runbook therefore treats the claim itself as the notifiable event and runs verification in parallel:

• Capture the listing. Screenshots, URLs, timestamps, and the exact wording of the theft claim, preserved outside the ticketing system that may later be discoverable in a dispute. Note who in the organisation saw it and when, because every clock argument will turn on that timestamp.
• Identify the plausible vendor. Map the named victim set against your vendor register. If Shell, Philips, GE, and Fiserv appear alongside you, the common element is almost certainly a shared platform, and your procurement records will usually narrow the candidates to one or two within an hour.
• Pull the contract and the data-processing schedule. You need the incident-notice clause, the cooperation and audit clause, the indemnity, the liability cap, and the schedule describing exactly what data the vendor holds.
• Convene the incident team with the vendor scenario loaded. The internal severity call cannot rest on your own telemetry, because your telemetry will be clean.
• Decide the CERT-In filing. The conservative reading is that a public claim of theft of your organisation's data, brought to your notice, is reportable even though the intrusion ran on vendor infrastructure. An initial report can state exactly that: third-party claim, vendor under investigation, scope unconfirmed, supplementary report to follow. A filing that later proves overcautious costs little. A missed 6-hour window is a recorded compliance failure that surfaces in every subsequent proceeding.

The most common self-inflicted wound in vendor-breach claims is the decision to wait for the vendor's forensics before notifying the insurer. The reasoning sounds prudent: we do not yet know whether our records are affected, so we have nothing to notify. The policy does not work that way. Notice conditions key on discovery of an incident or of circumstances that may give rise to a claim, and an extortion group publicly claiming to hold your data satisfies that language on any reasonable reading. Weeks of silence while the vendor investigates hands the insurer a late-notice argument at precisely the moment you need the relationship working.

Notifying early also unlocks the part of the policy that matters most in the first 72 hours: the incident-response provisions. Most Indian cyber wordings give access to a breach coach, panel forensics, and panel legal counsel, and most condition the payment of those costs on the insurer's prior consent.

Be precise about what you notify. A notice of circumstance describing the leak-site claim, the suspected vendor, and the categories of data potentially involved preserves the position under the current policy period, which matters if the loss develops slowly and the renewal falls in between. Where the vendor's outage also interrupts your own operations, check whether the programme's contingent or dependent business interruption section responds, a coverage examined in our review of cyber business interruption cover for Indian corporates.

In a vendor breach, the contract with the vendor is a recovery instrument sitting alongside the insurance programme, and the first 72 hours determine how much of it survives.

Invoke the cooperation and audit clauses in writing and demand four things: confirmation of whether your data was in scope, the indicators of compromise, access to or summaries of the forensic reports, and a timeline of the intrusion. Vendors under mass-incident pressure triage their responses toward the customers who ask formally and early. A GCC processing group data should simultaneously alert its parent, because the parent's contracts and regulators may impose their own obligations on the same facts.

Read the indemnity and the limitation of liability before making demands. Many Indian vendor contracts cap liability at a multiple of annual fees, a figure that collapses against breach-response costs at scale, and some carve data breaches out of the cap. Knowing which contract you hold shapes whether the realistic recovery route is the vendor's indemnity, the vendor's own cyber policy, or your insurer's subrogation rights against the vendor after paying your claim.

Two mistakes in this window damage the recovery permanently. The first is signing anything the vendor circulates in the crisis, particularly settlement communications or amended terms containing releases; a release signed for a goodwill credit can extinguish your insurer's subrogation rights and give the insurer a defence against your own claim. The second is failing to send a litigation-hold style preservation demand, because vendor log retention is often 30 to 90 days and the evidence that proves your records were exfiltrated may age out while the vendor's investigation runs.

By the second day, the defining feature of the incident is the confirmation gap: you cannot yet establish whether your records are in the stolen set, and you may not be able to for weeks. The vendor controls the evidence, the attacker controls the disclosure schedule, and your customers and regulators are asking questions now.

Three workstreams fill the gap productively:

• Reconstruct your own data footprint at the vendor. From your side of the integration: what fields were sent, over what period, for which populations, and what the retention terms said. If the vendor held five years of payroll files when the contract required deletion after one, that reconstruction defines your realistic worst case and becomes the basis for scoping notification, whatever the vendor eventually confirms.
• Draft communications that state knowledge honestly. Customers and employees should be told what is known (a vendor incident is claimed, an investigation is running, specific data categories were held by the vendor) and what is not yet known (whether their records were taken). Overclaiming certainty in either direction creates liability: premature all-clear statements are the ones read back in later proceedings.
• Keep the regulators updated. Supplement the initial CERT-In report as facts firm up. Under the DPDP framework the Data Fiduciary owns the relationship with affected individuals, so the notification decision remains yours even though the facts sit with the vendor; plan the intimation content on the assumption your worst-case scoping is right.

Speed here is a financial control, and increasingly the attacker sets the pace. With 26% of malicious breaches in India AI-generated, per IBM's 2026 report, campaigns move from access to mass exfiltration to publication faster than manual vendor forensics move to confirmation. How AI-accelerated campaigns interact with supply-chain exposure and policy wordings is covered in our post on AI-accelerated ransomware and supply-chain cyber resilience.

IBM's 2026 Cost of a Data Breach Report, released on 3 August 2026, put India's average total breach cost at a record Rs 25.5 crore, with 39,500 records compromised in the average incident, up from 38,200 in 2025. The same report quantified the value of preparation: Indian organisations with no AI or security automation paid an average of Rs 31.6 crore per breach, against Rs 21.3 crore for those with extensive deployment, a gap of Rs 10.3 crore on a single event.

In a vendor breach, the automation that matters is the kind that shortens your own clocks: continuous monitoring of leak sites and threat-intelligence feeds so the listing is spotted in hours, a maintained vendor register mapped to data categories so the plausible source is identified the same day, and pre-drafted notification templates for CERT-In, customers, and the insurer so the filings are edits rather than compositions. None of this requires a large security estate. It requires deciding, before the incident, who owns each clock.

The insurance-side preparation is equally specific. Check that the programme's definition of a computer system extends to systems operated by service providers on your behalf, that contingent business interruption is present rather than assumed, that the notice condition names a mailbox someone actually monitors on weekends, and that panel arrangements are documented in the incident plan so consent is a phone call rather than a research project. And test the limit against the benchmark: a tower sized before the vendor-breach era rarely survives comparison with the 2026 numbers, an exercise worked through in our post on testing a cyber limit against the Rs 25.5 crore benchmark.

Much of this turns on exact wording: how discovery is defined, when consent is required, whether vendor systems are inside the insuring clause. Sarvada gives brokers and risk managers searchable, side-by-side access to Indian insurer cyber policy wordings, so a vendor-breach scenario can be walked through the actual clauses before the leak site makes it real. To compare wordings for your programme, Request Access.