.png)
What to Ask a Software Vendor After They Report a Data Breach
Article Summary: Confirm that the notice is genuine, then ask whether your business was affected, what information was exposed, when the breach happened, and whether any passwords, access tokens, or connected systems need attention. Keep written records of the vendor’s answers and involve your IT provider, insurer, or legal adviser when needed.
You’ve just received 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 the notice may not answer the question that matters: 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, review transactions, warn staff, or contact your insurer before the investigation ends.
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 exploit public breach announcements by sending fake password-reset emails or pretending to offer support. People who already use the affected software are more likely to believe the message because the breach 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 Center recommends contacting an organization 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:
IMAGE SOURCE: https://www.pexels.com/photo/it-technician-working-in-data-center-server-room-37605911/
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 affected, possibly affected, confirmed not 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 unauthorized activity began, when the vendor detected it, and when it contained the affected systems. 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 unauthorized person could do.
Could they view, copy, change, or delete information? Did they create new accounts, encrypt files, or use the vendor’s systems to contact customers?
The answer affects your next steps. Someone who views a customer list creates a different risk than someone who obtains login credentials or gains 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 that could decrypt the information was 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. Also ask whether those records cover the entire period under investigation.
“No evidence of misuse” means the investigation found no 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 data was stolen, but it helps you understand how much the vendor can confirm before deciding 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, change it 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 ask when the vendor expects to complete 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 its responsibilities.
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 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 and which version your business should use now. 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 vendor employees' names 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 subprocessors.
If the breach happened at one of these companies, ask who it was, what service it provided, and what information it held. Also find out whether it had direct access to your data or systems, and whether the software vendor still uses it.
This information may matter even if you’ve never dealt with the other company directly. 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 the vendor will publish official updates and how often it 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, 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.
Also record what your business did, when you took each action, who approved key 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 creates a record of how your business assessed and handled the incident if questions arise later.
Privacy authorities in several countries require organizations to document certain breaches and their response. For example, the UK Information Commissioner’s Office says organizations should record the facts, effects, and remedial action taken.
Australia’s privacy regulator recommends responding by 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 also create responsibilities for your business.
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 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.
Frequently Asked Questions
What if the vendor says there is no evidence that our information was misused?
Ask what evidence and logs support that statement, whether those records cover the full period, and whether the investigation is complete. The answer may be reassuring, but you need enough detail to understand how the vendor reached it.
Should everyone change their password immediately?
Follow the vendor’s instructions and ask your IT provider which accounts are affected. If you used the same password with the vendor elsewhere, change it on every affected account and stop reusing it.
Your IT provider should also check whether to revoke active sessions, API keys, or access tokens.
Does a vendor breach mean we must notify our customers?
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 appropriate privacy or legal advice before deciding.
Should we stop using the vendor?
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 vendor has fixed the original problem.
Also pay attention to the quality of the vendor’s communication. If it repeatedly avoids reasonable questions or cannot explain how it has secured the service, you may need to reconsider whether you’re comfortable trusting it with your data
Sources and Further Reading
NIST SP 800-61 Revision 3: Incident Response Recommendations and Considerations
UK National Cyber Security Center: Supplier Assurance Questions
UK Information Commissioner’s Office: Personal Data Breaches
European Data Protection Board: Personal Data Breach Notification Guidance
Office of the Australian Information Commissioner: Responding to Data Breaches
If a software vendor has reported a breach and you’re unsure what it means for your business, speak with your IT provider. If you don’t have one, you can always reach out to us, and we’ll help you work through it.
—
Comments