Your Vendor Had a Data Breach: What to Do in the First 48 Hours

Last updated: 29 October 2026. You’ll find the sources at the end.

In October 2026 a lot of companies learned about a breach from someone else’s email. Ymir Link, a Japanese email-delivery service, told clients on 26 October that attackers had reached about 51.6 million records (mostly email addresses) across 50 of its systems, and JR Central, JR West, the Resona group and others then had to warn their own customers. Meanwhile, a ransomware attack on IDC Frontier’s cloud hit 495 companies and local governments. Similarly, the analytics vendor Amplitude exposed Coinbase customers’ contact data. A health plan in Denver lost data on 238,083 members because a vendor’s database key sat on a public website for about 14 months.

However, attackers did not hack any of those companies directly. Each still had to respond, and in India the law says the response is yours to make. When a vendor data breach lands in your inbox, the first hours decide how much it costs you. So this guide is a 48-hour plan for the day a supplier tells you about a breach.

Why a vendor data breach is your problem, legally

CERT-In Directions (28 April 2022). Service providers, intermediaries, data centres, body corporates and government bodies must report listed cyber incidents to CERT-In within 6 hours. The list includes “Data Breach”, “Data Leak” and “Unauthorised access of IT systems/data”. CERT-In’s FAQ (May 2022) answers the vendor question directly:

  • Any entity that notices the incident must report it. A contract cannot hand that duty to the vendor (FAQ 13).
  • The clock starts when you notice the incident or are “brought to notice” about it, so a vendor’s email to you starts your 6 hours (FAQ 24).
  • You can report what you know at the time and send the rest later (FAQ 30).
  • The rule also covers incidents affecting your data on a third party’s systems (FAQ 31).

In addition, the Directions have applied to MSMEs since 25 September 2022. You send reports to incident@cert-in.org.in; the reporting form is optional, and CERT-In accepts any readable format.

DPDP Act 2023. Your company, as Data Fiduciary, is responsible for personal data that a Data Processor handles on its behalf “irrespective of any agreement to the contrary” (section 8(1)), and may use a processor only under a valid contract (section 8(2)). The Schedule allows penalties of up to ₹250 crore for failing to take reasonable security safeguards and up to ₹200 crore for failing to report a breach. Under the DPDP Rules 2025, the breach notice to affected people and the Board, with a detailed report to the Board within 72 hours (Rule 7), applies from about 13 May 2027. Until then, however, the CERT-In rule is the one in force.

Banks, NBFCs and SEBI-regulated firms have extra rules, which we cover further down.

The 48-hour plan

First two hours: confirm and start the clock

  • Write down when and how you learned of the incident. That time starts your 6-hour CERT-In window.
  • Confirm the notice is real. Phishing that imitates breach notices is common. Instead, check through a contact you already have at the vendor, not the phone number or link in the email.
  • Name one person to lead the response and one person to talk to the vendor.
  • Pull out what you already know about this vendor: which systems it connects to, which accounts, API keys and OAuth apps it uses, and what personal data it holds. If you have no list, start one now (see the questions below).

Hours 2 to 6: preserve evidence, cut access, report

  • Export logs before you change anything. Microsoft’s guidance on the October ConnectWise incident says: “Do not delete enterprise applications as the first response.” Deleting an app or user can also remove the trail you need. CERT-In also expects you to keep ICT logs for 180 days.
  • Disable the vendor’s access. Turn off its integration, service account or app registration, revoke its OAuth grants and tokens, and disable vendor user accounts. Disabling is reversible; deleting is not.
  • Report to CERT-In within 6 hours if you are covered and the incident affects your data or systems. Then send what you know and say that more will follow.

By hour 24: rotate and hunt

  • Rotate every secret the vendor held or could read: API keys, cloud access keys, app secrets and certificates, database passwords and webhook secrets. Don’t limit this to the keys you think were exposed. In October’s developer-platform breaches (Railway, Zeabur, LiteLLM), stored keys were what the attackers were after.
  • Look for misuse, starting from before the vendor’s disclosure date. Attackers often had access for weeks: ConnectWise’s attacker tried to sign in to more than 2,250 Microsoft 365 tenants, and the Denver Health key was public for about 14 months. Then check sign-ins by the vendor’s app, new admin roles, new credentials added to apps, mailbox rules and large downloads.
  • Warn your own staff and, if needed, your customers about phishing that uses the breach. Phishers want exactly this: real email addresses tied to a brand people trust.

Day two: get facts in writing and decide on notices

  • Send the vendor the questions below and ask for written answers.
  • Decide who else you must tell: your sector regulator, business customers whose data was involved, your cyber insurer, and (from May 2027) the Data Protection Board and affected people.
  • Write a short incident note: timeline, what leaked, what you revoked and rotated, and what is still open. You will need it for CERT-In follow-ups, auditors and the next vendor review.

Technical checks by platform

The commands below come from each vendor’s documentation. We have not run the Microsoft, Google, GitHub or AWS steps in our lab, so test them on a non-critical account first.

Microsoft 365 / Entra ID

Entra admin center → Entra ID → Enterprise apps → All applications → choose the app → Permissions shows what it can access. Sign-in logs (Entra ID → Monitoring & health → Sign-in logs) have a separate “Service principal sign-ins” tab, which is where an abused app shows up.

To disable an app’s service principal and review its delegated grants with Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "Application.ReadWrite.All","Directory.ReadWrite.All","DelegatedPermissionGrant.ReadWrite.All"
$sp = Get-MgServicePrincipal -ServicePrincipalId "<object-id>"
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -BodyParameter @{accountEnabled = $false}
Get-MgOauth2PermissionGrant -All | Where-Object { $_.ClientId -eq $sp.Id }

If a user account may be compromised, Revoke-MgUserSignInSession -UserId <UPN> invalidates that user’s refresh tokens and browser sessions. It works on users, not on apps. You can re-enable a disabled app at any time, and recover a deleted app for 30 days.

Google Workspace

Admin console → Security → Access and data control → API controls → App access control → Manage Third-Party App Access lists the apps your users have authorised; set the vendor’s app to Blocked. For history, Reporting → Audit and investigation → OAuth log events, filtered by the app’s OAuth client ID. API call events need an Enterprise or Education Standard/Plus edition or Cloud Identity Premium.

GitHub

Organisation owners can review and revoke fine-grained personal access tokens under the organisation’s Settings → Personal access tokens → Active tokens. Users revoke OAuth apps and GitHub Apps they authorised under their own Settings → Applications. Also check Security → Secret scanning on each repository for keys someone committed.

AWS

Find out what a vendor’s access key did (management events, last 90 days, one Region per call):

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE \
  --region ap-south-1

Run it for each Region you use. Then deactivate the key with aws iam update-access-key --access-key-id <id> --status Inactive --user-name <user>, create a new one, and delete the old key once nothing depends on it. In a confirmed breach, deactivate first and fix the broken integrations afterwards.

Your own code

If anyone ever committed a vendor key to Git, it stays in the history even after someone deletes the file. This search finds AWS-style keys in every commit (tested on Ubuntu 24.04 with git 2.43.0):

git log -p --all | grep -nE 'AKIA[0-9A-Z]{16}'

In our test repository the search found the key twice, in the commit that added the file and in the one that deleted it:

13:-VENDOR_KEY=AKIAIOSFODNN7EXAMPLE
27:+VENDOR_KEY=AKIAIOSFODNN7EXAMPLE

Then adapt the pattern to the vendor’s key format. However, rotating the key is the real fix, because rewriting Git history only hides it.

Questions to send the vendor

After a vendor data breach, ask for written answers and keep them with your incident note.

  1. When did the incident start, when was it detected, and when was it contained?
  2. Which of our data, accounts, keys or integrations were in scope? Did the attacker copy data out, or could they only see it?
  3. How did the attacker get in, and is that route closed?
  4. Which credentials or tokens linked to our account should we rotate, and have you revoked yours?
  5. What indicators (IP addresses, user agents, app IDs, file names) should we search for in our logs?
  6. Have you reported to CERT-In or another regulator? Under what reference?
  7. When will we get the next update, and who is our contact?
  8. Did any of your own suppliers play a part?

Sector rules for banks, NBFCs and SEBI-regulated firms

If you are a bank, NBFC or other RBI-regulated entity, the RBI (Outsourcing of IT Services) Directions 2023 say your service provider must report cyber incidents to you without undue delay, and you must report to RBI within 6 hours of detection by the service provider. Your contract must list the incidents the vendor reports and give you audit rights.

On the other hand, if you supply a bank or NBFC, expect those clauses in your contract: the 6-hour clock runs from your detection, not your customer’s.

Similarly, SEBI’s Cybersecurity and Cyber Resilience Framework (August 2024) makes regulated entities “solely accountable” for third-party services. It requires security measures in vendor contracts, response testing with vendors, and incident reporting through SEBI’s portal.

Prepare for the next vendor data breach

  • Keep a list of vendors with access to your systems or personal data: what they hold, which accounts and keys they use, and who the contact is.
  • Put incident terms in every contract: notice within a fixed number of hours, the information you will receive, cooperation with your CERT-In report, and audit rights. DPDP Rule 6 will require security clauses in processor contracts from May 2027.
  • Give vendors the narrowest access that works, and review it every six months. Also disable accounts for vendors you no longer use.
  • Prefer short-lived tokens and keys you can rotate in minutes.
  • Practise this plan once a year with your most important supplier.

Our free DPDP readiness check shows where your processor contracts and breach plan stand before a vendor data breach happens. If you want to know who you are dealing with before you sign, our OSINT investigation service includes vendor due diligence and checks for leaked company credentials. For October’s real examples, see our October 2026 data breaches roundup and the ConnectWise Microsoft 365 takeover.

Related guides

Sources

Checking a supplier before you sign? Our OSINT investigation service covers vendor due diligence and leaked company credentials, and our VAPT services test what an attacker could reach. Contact us for a quote.

Tags: , , , , ,
Post author avatar

Bhaskar Soni

Bhaskar Soni is a Security Engineer and the founder of Youngster Company, based in Ahmedabad, Gujarat. He works hands-on with Linux server hardening, vulnerability assessment and penetration testing (VAPT), ISO 27001 compliance and OSINT investigations. He writes practical, tested guides for IT professionals and Indian businesses, and every article on this site is written or reviewed by him.

Leave a Reply