You’ve just found yourself on the receiving end of a data breach notice from one of your software vendors.

Maybe it’s the company that handles your payroll. It could be your accounting platform, CRM, cloud storage provider, or another service your team uses every day.

The email says the vendor discovered a security incident and has started an investigation. It may say that certain systems were accessed or that the incident has been contained. Then it gives you a support address and promises further updates.

But you’re left with a question the notice may not answer: What does this mean for your business?

The first notice often arrives before the vendor knows the full extent of the breach. Its security team may still be reviewing logs, identifying affected systems, and confirming what information was accessed. That takes time, but you may need to reset accounts, check transactions, warn staff, or contact your insurer before the investigation is finished.

You don’t have to wait for the final report before asking questions. Confirm that the notice is genuine, save a copy, and start gathering the information your business needs.

First, make sure the notice is genuine

Before you respond, confirm that the email really came from the vendor.

Criminals sometimes take advantage of public breach announcements by sending fake password-reset emails or pretending to offer support. Someone who already uses the affected software is more likely to believe the message because the breach itself is real.

Avoid clicking links or calling numbers in an unexpected notice until you’ve checked it. Visit the vendor’s website by entering the address yourself, sign in through the customer portal you normally use, or contact a representative whose details you already have.

The UK National Cyber Security Centre recommends contacting an organisation through details found on its official website when you’re unsure whether a message is genuine.

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

Ask whether your business was affected

A breach at a software company doesn’t always affect every customer. The incident may have involved one product, database, office, or group of accounts.

Ask the vendor directly:

Was our account, company information, or user data affected?

If the vendor can’t give you a definite answer yet, ask whether your business is confirmed to be affected, possibly affected, confirmed not to be affected, or still under investigation.

That wording matters. “Still under investigation” does not mean your business is safe. It means the vendor has not finished checking.

Ask when you can expect a clearer answer and whether the vendor recommends taking any precautions while it investigates.

Find out what happened and when

The date the vendor announced the breach is only one part of the timeline.

Ask when the unauthorised activity began, when the vendor detected it, and when the affected systems were contained. If the vendor only knows an estimated date range, ask it to share that.

Those dates help your IT provider decide how far back to review your own records. You may need to check login activity, file transfers, account changes, invoices, payment instructions, or messages sent during the affected period.

You also need to understand what the unauthorised person was able to do.

Were they able to 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 affects what you do next. Someone viewing a customer list creates a different risk from someone obtaining login credentials or gaining access to a system connected to your network.

Ask exactly what information was involved

A statement such as “customer information may have been affected” is too broad to guide your response.

Ask the vendor which information connected to your business was involved. Depending on the software, this could include employee or customer contact details, payroll information, payment records, identity documents, contracts, files, messages, support tickets, usernames, password hashes, login records, API keys, or security tokens.

Then ask whether all customers had the same information exposed.

Two businesses may use the same software in completely different ways. One company might use a platform only to store names and email addresses. Another might have uploaded contracts, identity documents, invoices, and payment information.

So the fact that both businesses use the same vendor doesn’t mean they face the same risk.

If the vendor says the information was encrypted, ask whether the encryption keys or any system capable of decrypting the information were also affected. Encryption can reduce the risk, but only if the attacker didn’t obtain what was needed to read the data.

Was the information viewed, copied, or simply present on an affected system?

This is where the vendor’s logs become important.

If the company says there is “no evidence” that your information was copied or misused, ask what records support that statement. You should also ask whether those records cover the entire period being investigated.

“No evidence of misuse” means the investigation has not found evidence. It doesn’t always mean the vendor can prove that nothing happened.

For example, the relevant logs may not have been retained for the full period, or they may not record every action an attacker could take. That doesn’t prove that data was stolen, but you should understand how much the vendor can confirm before deciding that no further action is needed.

Check passwords and connected systems

A password reset may be part of the response, but modern software often connects to other services without asking someone to enter 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. Then ask which credentials need to be reset, revoked, or replaced.

Your IT provider should manage these changes where possible. 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, that password should be changed everywhere it was reused. A criminal who obtains one password can test it against email, banking, cloud storage, and other common services.

Ask what the vendor has done so far

A vendor may say that the breach has been contained. Usually, that means it has stopped the activity it knows about. The investigation and repair work may still be continuing.

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? And does the vendor currently consider the service safe to use?

You should also ask what work remains. Some early measures are temporary, so find out when the vendor expects to complete the permanent fixes.

NIST’s incident-response guidance explains that responding to an incident can involve several parties, including service providers, system owners, legal teams, and business leaders. Each party needs to understand what it is responsible for doing.

The vendor will handle its own systems. Your business may still need to protect its accounts, review activity, contact affected people, or meet contractual and legal requirements.

Find out what your business needs to do

Ask the vendor to give you 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 versions of the software are affected and which version your business should now be using. Also confirm whether there is a deadline for completing the work.

Find out whether the attacker could use information from the breach to create convincing scams. Names, invoice details, support history, or the names of vendor employees could make a fraudulent message look genuine.

If the vendor has found related phishing emails, fake websites, or fraudulent support calls, ask it to share examples that you can pass to your staff.

Ask whether another company was involved

Software companies often rely on other providers to host systems, process payments, send emails, store backups, or run customer support. These other providers are sometimes called sub-processors.

If the breach happened at one of these companies, ask who it was, what service it provided, and what information it held. You should also find out whether it had direct access to your data or systems and whether the software vendor still uses it.

This information may be important even if you’ve never dealt directly with the other company. Your software vendor chose that provider and should be able to explain how the incident affected the service you use.

Agree on how you’ll receive updates

When an investigation lasts several days or weeks, getting information through a general support inbox can become frustrating. Each response may come from a different person, and you may have to explain the situation again.

Ask for a named contact or an incident response team that can answer follow-up questions. Confirm where official updates will be published and how often the vendor expects to provide them.

If the company doesn’t have new information yet, it should still be able to tell you when the next update will arrive.

Once the investigation is complete, ask for a final report. It should explain what happened, what information was involved, how the breach occurred, and what the vendor has changed since then.

The NCSC’s supplier security guidance recommends setting clear incident-reporting timescales, contacts, and responsibilities in supplier contracts. After the immediate response is over, check whether your existing agreement covers these points.

Keep a record of your response

Create a folder for the incident and keep the original notice, later updates, your questions, and the vendor’s answers.

You should also record what your business did, when each action was taken, who approved important decisions, and what advice you received from your IT provider, insurer, or legal adviser.

Having this information in one place makes it easier for everyone involved to work from the same facts. It also gives you a record of how your business assessed and handled the incident if questions come up later.

Privacy authorities in several countries require organisations to document certain breaches and their response. For example, the UK Information Commissioner’s Office says organisations should record the facts, effects, and remedial action taken.

Australia’s privacy regulator recommends a response based on containing, assessing, notifying, and reviewing the breach.

The exact requirements depend on where your business operates, what information was involved, and your role in handling that information.

Decide who else needs to be involved

The vendor’s notice may create responsibilities for your business as well.

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 organisations.

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

If personal information was involved, get privacy or legal advice early. Notification requirements vary by location and 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.

Under the GDPR, for example, a software provider acting as a data processor must notify the relevant controller without undue delay. The controller may still be responsible for assessing the breach and making any required notifications.

The European Data Protection Board’s guidance also explains that a vendor can provide information in stages as the investigation develops.