A supplier got hit by ransomware. What do we do?

Treat it as your incident until you've proved it isn't. First, cut or restrict every connection the supplier has into your environment: VPNs, API keys, shared accounts, file transfers, remote support tools. Second, work out what of yours they held: data, credentials, access, or a service you depend on. Third, decide what you owe your own customers, regulators, and insurer, because your notification duties don't disappear because the breach happened at someone else's company. Then, and only then, start the longer conversation with the supplier about what happened and when they'll be back. Most organisations do these in the opposite order and spend the first week on the phone to the vendor while their own exposure sits open.

Step one: the connections

Attackers who compromise a supplier use its access to reach its customers; that's the whole value of the position. Any route from their environment into yours is suspect until they can show you it wasn't used. Disable the VPN account, rotate the API keys, suspend the shared service accounts, block the remote-support tool, and review any recent activity from their addresses or accounts in your logs. If the supplier runs something for you, like a managed service or a hosted application, the question is whether their administrative access to your systems is still trustworthy, and the honest answer in the first days is that you don't know. NIST's supply-chain risk guidance is built around this point: a supplier relationship is a path into your organisation, and it has to be managed as one, including during their incidents (Boyens et al., 2022).

Step two: what did they hold?

Four categories, and you need an answer for each:

• Your data. Customer records, employee data, financial information, intellectual property. If they held it, assume for now it was accessible to the attacker. Ransomware groups routinely steal data before encrypting.
• Your credentials. Accounts they used to reach you, and any of your credentials stored in their systems. Rotate them.
• Their access to you. Covered in step one, but list it formally now.
• A service you depend on. If their outage is your outage, this is also a continuity problem. How long can you operate without them, and what's the workaround?

The contract should tell you what they were supposed to protect and what they owe you in notice. Pull it. If there's no breach-notification clause, or no right to audit, that's a lesson for the next contract, but it doesn't change what you need now (I've written about the limits of questionnaires in Your Vendor Questionnaire Cannot Tell You Whether the Vendor Will Fail).

Step three: your own obligations

If your customers' personal data was in the supplier's systems, you're likely the one with the notification duty, not the supplier. State breach laws generally put the obligation on the owner of the data; the processor's job is to tell you. Public companies have to consider whether the incident is material to them, which it may be even though it happened elsewhere (U.S. Securities and Exchange Commission, 2023). Tell your insurer. Tell counsel. And log what you learned and when, because the clocks run from your discovery. The full notification map is in Who do we have to notify after a breach, and by when?.

Step four: the questions for the supplier

Ask in writing, and expect vague answers at first; they're in the middle of it. What happened and when was it discovered? Which systems were affected, and were any of them the ones holding our data or access? Was data taken, and is there evidence either way? Has law enforcement been engaged? Who's running their response, and is there an outside firm? What's their recovery timeline for the services we depend on? Will they provide the forensic findings relevant to us? And: were our credentials or connections used? CISA's response checklist for ransomware victims is a reasonable reference for what a competent supplier should be doing; if their answers don't resemble it, factor that in (Cybersecurity and Infrastructure Security Agency, n.d.).

The decision you'll face: when to let them back in

The supplier will want access restored quickly, and so will your own operations. The standard for reconnecting is the same as for your own systems: they can show the entry point is closed, persistence is removed, and the systems that touch you have been rebuilt or verified. Ask for that in writing. If they can't give it, reconnect in the narrowest way that works and monitor it closely. "They said it's fine" isn't a control.

Afterwards: the contract and the map

Every organisation that goes through this discovers two things: it didn't have a current list of which suppliers hold what, and its contracts didn't give it the rights it needed. Fix both while the memory is fresh. A supplier inventory with the four categories above for each vendor is the single most useful document for the next time, and there will be a next time.

What I'd do next

If this is live, do step one today and step two by tomorrow; the supplier conversation can wait a day, your exposure can't. If you'd like help building the supplier map and the contract terms that make the next one easier, or an independent read on a supplier incident you're in now, request a briefing. More on this cluster is in Executive leadership.