Your Vendor or IT Provider Just Got Breached: What to Do in the First 48 Hours

The Breach Notification Isn’t the End of the Problem — It’s the Start

You’ve done the work: you assessed your vendors, tiered them by risk, and got contractual breach-notification commitments in writing (see our vendor security assessment guide if you haven’t yet). Then the notification actually arrives — your IT provider, payroll processor, or a SaaS tool you rely on daily sends an email or letter informing you they were breached. Vendor assessment answers “who should I worry about” before an incident. This guide answers the much more urgent question: what do you actually do in the first 48 hours after you find out a vendor with access to your systems or data has been compromised?

Why This Situation Is Different From Your Own Breach

When your own systems are breached, you control the environment, the logs, and the response. When a vendor is breached, you’re operating with limited information, on their timeline, often learning details in stages as their own investigation progresses. You can’t patch their systems, you can’t see their logs, and you’re dependent on their disclosure being accurate and timely — which is not always the case. That asymmetry is exactly why a pre-planned response matters here: you need to move on your own containment steps immediately, without waiting for the vendor to tell you everything.

The First 48 Hours: A Step-by-Step Playbook

Hour 0-2: Confirm Scope and Access

1. Identify exactly what that vendor has access to — pull up your vendor inventory (or build one now if you don’t have it) and confirm what systems, data, and credentials are connected to this specific vendor.
2. Determine the access type — does the vendor have standing administrative access to your systems (common for IT/MSP providers), API keys and integrations (common for SaaS tools), or only your data stored on their platform (common for payroll processors and cloud storage vendors)? Each requires a different containment response.
3. Read the vendor’s actual notification carefully — note what they claim was and wasn’t accessed, and treat early statements as provisional. Initial breach disclosures are frequently revised and expanded as the vendor’s investigation continues.

Hour 2-8: Contain Your Exposure

1. Reset every credential shared with or known to that vendor — any password, API key, or access token the vendor’s systems stored or could have accessed should be treated as compromised, regardless of what the vendor’s notification claims was taken.
2. Revoke and reissue API keys and integration tokens connecting your systems to the vendor’s platform, rather than assuming the existing ones are still safe to use.
3. If the vendor has standing administrative access to your network (an MSP or IT support vendor), consider temporarily suspending that access entirely until you understand the scope of their breach — a difficult operational decision, but the exposure of leaving standing admin access active during an active vendor incident is usually the bigger risk.
4. Check your own logs for any unusual activity originating from that vendor’s known IP ranges, service accounts, or integration endpoints in the days leading up to and following the disclosure — see our log monitoring and SIEM basics guide if this isn’t already in place.

Hour 8-24: Assess Your Own Data Exposure

1. Determine what of your data lived on or passed through the breached vendor’s systems — customer PII, financial records, employee data, and intellectual property each carry different notification and regulatory obligations if exposed.
2. Check whether any of your customer or employee data specifically was confirmed accessed, not just whether the vendor’s platform generally was breached — these are different findings and the vendor’s disclosure should eventually clarify which applies to you.
3. Document everything — the vendor’s notification, your response timeline, and every action taken. This record matters for your own regulatory notification obligations and for any insurance claim; bring in outside digital forensics support if the scope or sensitivity of the data involved warrants it.

Hour 24-48: Notification and Communication Duties

1. Determine your own notification obligations — if customer or employee data was exposed through the vendor, you may have independent state data breach notification requirements regardless of the vendor’s own disclosure to affected individuals. See our guide on what to do after a data breach for the general notification framework.
2. Notify your cyber insurance carrier if you have a policy — a vendor breach affecting your data is typically a covered event, but most policies require prompt notification, and delaying can jeopardize coverage. See our guide on how to file a cyber insurance claim for the process.
3. Communicate proactively with affected customers or partners if warranted, even ahead of a formal legal notification deadline — businesses that get ahead of a vendor breach story generally retain more trust than those who stay silent until forced to disclose.

Questions to Ask the Breached Vendor Directly

• What is the confirmed scope of data accessed, and how confident are you in that scope given the current stage of investigation?
• Was our specific account or data confirmed accessed, or only potentially in scope?
• What containment steps have you taken on your end, and are they complete?
• Should we consider any credentials or API keys shared with your platform compromised?
• Will you provide a written incident summary for our own records and any regulatory notification we may need to file?
• What is your remediation timeline, and will service continue uninterrupted during that process?

After the Immediate Response: Reassessing the Relationship

Once the acute containment phase is over, a vendor breach should trigger a formal reassessment, not just a return to normal. Review the vendor’s security posture against your original tiering, confirm whether their breach notification commitment was actually honored on the timeline your contract requires, and decide — based on the facts, not just the discomfort of switching vendors — whether the relationship should continue as-is, continue with additional contractual protections, or be replaced. This is also the point to revisit your supply chain and third-party risk management approach more broadly — a vendor breach is exactly the kind of event that should prompt a fresh look at every other Tier 1 vendor relationship, not just the one that was actually hit.

Bottom Line

A vendor breach notification starts a clock, not a formality. Contain your own exposure — reset shared credentials, revoke tokens, and consider suspending standing access — before you have full clarity on what the vendor’s investigation ultimately finds, because waiting for complete information before acting gives an attacker who’s already inside a longer runway. Document everything as you go, since that record drives both your regulatory notification decisions and any insurance claim. And once the immediate response is over, treat the incident as a reason to formally reassess the vendor relationship, not just a crisis to move past.