What to Do When Your Software Vendor Has a Data Breach

Article summary: When a software vendor tells you it had a data breach, start by confirming the notice is real, since fake breach alerts are a common phishing trick. Then ask the vendor whether your account was affected, what information was exposed, and when the breach happened. Check whether any passwords, access tokens, or connected systems need to be changed. Get the vendor’s answers in writing, and bring in your IT provider, insurer, or legal adviser if your data was involved.

A data breach notice has just arrived from one of your software vendors. It might be your payroll provider, your accounting platform, your customer relationship management (CRM) system, your cloud storage provider, or another service your team uses every day.

The email says the vendor found a security incident and has started an investigation. It may say certain systems were accessed, or that the incident has been contained. It gives you a support address and promises more updates. What it may not tell you is what this means for your business.

First notices often go out before the vendor knows how far the breach reached. Its security team may still be reviewing logs, identifying affected systems, and confirming what information was accessed. That takes time. Meanwhile, you may need to reset accounts, check transactions, warn staff, or contact your insurer before the investigation ends.

You don’t have to wait for the final report to start asking questions. Below, you’ll learn how to confirm the notice is genuine and save a copy, what to ask the vendor, which passwords and connected systems to check, and who else may need to be involved.

How to tell if a vendor’s breach notice is real

Before you respond, check that the email really came from the vendor. Criminals sometimes use public breach announcements to send fake password-reset emails or pose as support staff. People who already use the affected software are more likely to believe them, because the breach itself is real.

Don’t click links or call numbers in an unexpected notice until you’ve checked it. Type the vendor’s web address yourself, sign in through the customer portal you normally use, or contact a representative whose details you already have. The Federal Trade Commission (FTC) advises that if a message could be legitimate, you should contact the company using a phone number, email, or website you know is real.

Once you’ve confirmed the notice, save the original message and any attachments. You may need them when you speak with your IT provider, insurer, legal adviser, or privacy contact.

Questions to ask a vendor after a data breach

A breach at a software company doesn’t always affect every customer. It may have involved one product, database, office, or group of accounts. Ask the vendor directly.

Was our business affected?

If the vendor can’t give a definite answer yet, ask which of these applies to your business: confirmed affected, possibly affected, confirmed not affected, or still under investigation. Pay attention to that wording. “Still under investigation” doesn’t mean your business is safe. It means the vendor hasn’t finished checking. Ask when you can expect a clearer answer, and whether the vendor recommends any precautions in the meantime.

When did the breach happen, and what could the attacker do?

The date the vendor announced the breach is only part of the timeline. Ask when the unauthorized activity began, when the vendor detected it, and when the affected systems were contained. If the vendor only has an estimated date range, ask for that. These dates help your IT provider decide how far back to review your own records. That may mean checking login activity, file transfers, account changes, invoices, payment instructions, or messages sent during that period.

Next, ask what the unauthorized person was able to do. Could they view information, copy it, change it, or delete it? Did they create new accounts, encrypt files, or use the vendor’s systems to contact customers? The answer shapes your next steps. Someone viewing a customer list is a different risk from someone getting login credentials or access to a system connected to your network.

What information was exposed?

“Customer information may have been affected” is too broad to act on. Ask which information connected to your business was involved. Depending on the software, that could include employee or customer contact details, payroll information, payment records, identity documents, contracts, files, messages, support tickets, usernames, password hashes, login records, application programming interface (API) keys, or security tokens. Then ask whether all customers had the same information exposed.

This matters because two businesses can use the same software very differently. One might store only names and email addresses on a platform. Another might upload contracts, identity documents, invoices, and payment information. Using the same vendor doesn’t mean facing the same risk.

If the vendor says the information was encrypted, ask whether the encryption keys, or any system that could decrypt the data, were also affected. Encryption reduces the risk only if the attacker didn’t get what they needed to read the data.

Was our data viewed, copied, or just stored on the affected system?

The vendor’s logs matter here. If the company says there’s “no evidence” your information was copied or misused, ask what records support that, and whether those records cover the entire period under investigation.

“No evidence of misuse” means the investigation hasn’t found any. It doesn’t always mean the vendor can prove nothing happened. Logs may not have been kept for the full period, or may not record every action an attacker could take. That doesn’t prove data was stolen. But you should know how much the vendor can confirm before you decide no further action is needed.

Which passwords and connected systems to check

A password reset may be part of the response. But a lot of software connects to other services without anyone entering a password each time. Your vendor may use single sign-on, API keys, access tokens, security certificates, or integrations with your email, accounting, payment, file-storage, or backup systems.

Ask whether any of these connections were affected, and which credentials need to be reset, revoked, or replaced. Where possible, have your IT provider make these changes. Replacing the wrong key, or disconnecting an integration without checking what depends on it, can interrupt business systems or stop information from syncing.

If an employee used the same password for the breached service and another account, change it everywhere it was reused. A criminal who has one password can try it on email, banking, cloud storage, and other common services.

What to ask about the vendor’s fixes

When a vendor says a breach has been contained, it usually means it has stopped the activity it knows about. The investigation and repairs may still be underway.

Ask what the company has done to secure the affected systems. Did it disable compromised accounts, revoke active sessions, patch a vulnerable system, rebuild affected servers, or replace exposed access keys? Has an independent security company reviewed the incident? Does the vendor consider the service safe to use right now?

Ask what work remains, too. Some early fixes are temporary, so find out when the permanent ones will be finished.

Incident-response guidance from the National Institute of Standards and Technology (NIST) explains that responding to an incident can involve several parties, including service providers, system owners, legal teams, and business leaders. Each one needs to know what it’s responsible for. The vendor handles its own systems. Your business may still need to protect its accounts, review activity, contact affected people, or meet contractual and legal requirements.

What your business needs to do next

Ask the vendor for customer-specific instructions in writing. You may need to install an update, reset certain accounts, review activity logs, remove an integration, check recent transactions, or warn employees about related phishing attempts. If an update is required, ask which software versions are affected, which version you should now be using, and whether there’s a deadline.

Ask whether the attacker could use information from the breach to make scams more convincing. Names, invoice details, support history, or the names of vendor employees can make a fraudulent message look genuine. If the vendor has found related phishing emails, fake websites, or fraudulent support calls, ask for examples you can pass to your staff.

Was a third-party provider involved?

Software companies often rely on other providers, sometimes called subprocessors, to host systems, process payments, send emails, store backups, or run customer support. If the breach happened at one of them, ask who it was, what service it provided, and what information it held. Find out whether it had direct access to your data or systems, and whether your vendor still uses it.

It’s worth asking even if you’ve never dealt with that company. Your vendor chose it, and should be able to explain how the incident affected the service you use.

How to get updates from the vendor

Investigations can last days or weeks. A general support inbox gets frustrating when each reply comes from someone new and you have to explain the situation again. Ask for a named contact or incident response team who can answer follow-up questions. Confirm where official updates will be published and how often. Even with no new information, the vendor should be able to tell you when the next update is due.

When the investigation is complete, ask for a final report covering what happened, what information was involved, how the breach occurred, and what the vendor has changed since.

Supplier security guidance from the UK National Cyber Security Centre (NCSC) recommends setting clear incident-reporting timescales, contacts, and responsibilities in supplier contracts. Once the immediate response is over, check whether your agreement covers these points.

How to document your response

Create a folder for the incident. Keep the original notice, later updates, your questions, and the vendor’s answers. Record what your business did and when, who approved important decisions, and what advice you got from your IT provider, insurer, or legal adviser. With everything in one place, everyone involved works from the same facts. You also have a record of how your business assessed and handled the incident if questions come up later.

Every US state has its own breach notification law, as do Washington, D.C., Guam, Puerto Rico, and the US Virgin Islands. The FTC’s Data Breach Response guide for businesses outlines the steps to take and who to contact. Exact requirements depend on where your business operates, what information was involved, and your role in handling it.

Who else to involve: insurers, legal advisers, and customers

The vendor’s notice may create responsibilities for your business too. Depending on what happened, you may need help from your IT provider, legal or privacy adviser, cyber insurer, senior management, or communications team. You may also need to contact affected customers, employees, regulators, or other organizations.

If the incident may be covered by cyber insurance, review your policy and notify your broker or insurer as required. Some policies require prompt notice, or the use of approved legal, forensic, or incident-response providers.

If personal information was involved, get privacy or legal advice early. Notification rules vary by location. They may depend on the type of information, the likely harm, your contract with the vendor, and whether your business controls the information or processes it for someone else.

In Washington, for example, a business that holds personal information it doesn’t own must notify the owner immediately after discovering a breach, if the information was, or is reasonably believed to have been, acquired by an unauthorized person. The owner then has to notify affected Washington residents, and the state attorney general if more than 500 residents are affected.

Conclusion

If a software vendor has reported a breach and you’re not sure what it means for your business, reach out to us and we’ll help you work through it.

Frequently asked questions

What does “no evidence of misuse” mean after a vendor breach?

Ask what evidence and logs support that, whether they cover the full period, and whether the investigation is complete. The answer may be reassuring, but you need enough detail to see how the vendor reached it.

Should we change all our passwords after a vendor breach?

Follow the vendor’s instructions and ask your IT provider which accounts are affected. If a password used with the vendor was also used elsewhere, change it on every affected account and stop reusing it. Your IT provider should also check whether active sessions, API keys, or access tokens need to be revoked.

Do we have to notify our customers about a vendor’s data breach?

Not always. It depends on whether your business was affected, what information was involved, where the affected people are located, your contracts, and the laws that apply. Get privacy or legal advice before deciding.

Should we stop using a vendor after a data breach?

A breach alone doesn’t automatically mean you should leave. Look at what happened, how much information was exposed, how the vendor responded, and whether the original problem has been fixed. Watch how the vendor communicates, too. If it keeps avoiding reasonable questions, or can’t explain how it has secured the service, you may need to reconsider whether you’re comfortable trusting it with your data.