When a software vendor emails to say it has had a security incident, the first notice rarely tells you what it means for your firm. It is usually sent while the investigation is still under way, yet you may need to reset accounts, warn staff or call your insurer before it ends. This checklist sets out the questions we suggest asking, and what to do on your side while you wait for answers.
Why vendor breaches matter for your firm
Asset managers, family offices and insurers in Hong Kong and Singapore rely on many software vendors: portfolio and order management, CRM, payroll, e-signature, file sharing and investor portals. Each one holds some of your data or has a route into your systems.
Managing that supplier risk is part of looking after your clients' data. The vendor investigates its own systems, but your firm still has to decide what the incident means for your clients and staff, and be able to show how you decided.
Before you reply: confirm the notice is genuine
Criminals follow public breach announcements with fake "reset your password" or "support" emails to the vendor's customers, and because the breach is real, they are easy to believe.
Don't use links or numbers in the notice. Type the vendor's web address yourself, sign in through your usual portal, or call your account manager on details you already hold. Once confirmed, save the original email and attachments in an incident folder.
The checklist: questions to ask the vendor
Send your questions in writing and ask for written answers. You won't get everything on day one, so ask the vendor which points are still being investigated and when it expects to know more.
1. Was our firm affected?
Ask whether your account is confirmed affected, possibly affected, confirmed not affected, or still under investigation. "Still under investigation" does not mean "safe". Ask whether the vendor recommends any precautions in the meantime.
2. What is the timeline?
Ask when the unauthorised activity started, when it was detected and when it was contained. These dates, even estimated, tell your IT team how far back to review sign-ins, file downloads, account changes and payment instructions.
3. Which of our data was involved?
"Customer information may have been affected" is too vague. Ask what was involved for your firm: client or staff contact details, identity documents, payroll or payment records, contracts, files, messages, support tickets, usernames, password hashes, API keys or access tokens. Two firms on the same platform can store very different data in it, so the vendor's general statement may not reflect your exposure.
If the data was encrypted, ask whether the encryption keys, or any system able to decrypt it, were also accessed.
4. Was it viewed, copied, changed or deleted?
Ask what the attacker was able to do, and whether they created accounts or used the vendor's systems to contact customers. If the vendor says there is "no evidence" that data was copied or misused, ask which logs support that and whether they cover the whole period. Finding no evidence is not proof that nothing happened: logs may not go back far enough or record every action.
5. Were logins, tokens or integrations exposed?
Many services connect to your systems without anyone typing a password: single sign-on, API keys, access tokens, certificates, and links to email, accounting, file storage or backups. Ask which were affected and which need to be reset, revoked or replaced.
Let your IT team or provider make those changes, because removing an integration or replacing a key without checking what depends on it can stop systems working. If staff sign in to the vendor with Microsoft 365 accounts, your administrator can review the vendor's app in Microsoft Entra ID and revoke sessions for affected users. Anyone who reused the vendor password elsewhere should change it everywhere.
6. What has the vendor done, and what is left?
"Contained" usually means the activity the vendor knows about has stopped. Ask what it has done (disabled accounts, patched systems, replaced exposed keys), whether an independent firm is reviewing the incident, whether the service is safe to use now, and when permanent fixes will be finished.
7. What exactly must we do?
Ask for instructions specific to your firm, in writing, with any deadlines: updates to install (and which version), accounts to reset, logs to review, integrations to remove. Ask for examples of any related phishing, such as fake invoices quoting real details, so you can warn staff.
8. Was another company involved?
Vendors rely on other providers, often called subprocessors, for hosting, email, payments, backups and support. If the breach happened at one of them, ask who it was, what data it held, whether it had access to your systems and whether the vendor still uses it.
9. How will we get updates?
Ask for a named contact, where official updates will be posted and how often. When the investigation closes, ask for a final report: what happened, what data was involved, the cause and what the vendor has changed.
On your side: records and the right people
Keep a record
Keep the notice, every update, your questions and the vendor's answers in one folder. Log what your firm did, when, who approved each decision and what advice you received. That keeps everyone working from the same facts, and shows how you handled the incident if your board, clients or auditors ask later.
Bring in the right people
Depending on the facts, involve your IT provider, compliance officer, legal adviser, senior management and whoever handles client communications. If you have cyber insurance, notify your insurer or broker as the policy requires; some policies set notice periods or require you to use approved response firms.
You may also have reporting duties under your contracts or the rules that apply to your firm, so involve whoever handles compliance early.
If personal data was involved
Get legal or compliance advice early. Whether you need to notify anyone can depend on the data involved, the likely harm, where the affected people are, your contract with the vendor and whether your firm controls the data or handles it for someone else.
- Hong Kong and Singapore: the privacy regulators in both places (the PCPD and the PDPC) publish guidance on handling and reporting data breaches. Check the current requirements with your legal or compliance adviser.
Afterwards: review the relationship
The UK's National Cyber Security Centre recommends that supplier contracts set clear incident-reporting timescales, contacts and responsibilities. If yours doesn't, raise it at renewal, and include the vendor in your regular third-party risk review. Our IT compliance audits cover vendor and third-party risk alongside your other IT controls.
Frequently asked questions
The vendor says there is no evidence of misuse. Is that enough?
It may be reassuring, but ask what logs support it, whether they cover the full period and whether the investigation is finished.
Does a vendor breach mean we must tell our clients?
Not always. It depends on whether your firm was affected, what data was involved, where the affected people are, your contracts and the rules that apply to you. Take legal or compliance advice before deciding.
Should we stop using the vendor?
A breach alone is not an automatic reason to leave. Consider what was exposed, whether the cause has been fixed and how openly the vendor answered your questions.
Sources and further reading
- Office of the Privacy Commissioner for Personal Data, Hong Kong
- Personal Data Protection Commission, Singapore
- Cyber Security Agency of Singapore
- NIST SP 800-61 Revision 3: Incident Response Recommendations and Considerations
- UK National Cyber Security Centre: Supplier assurance questions
If a vendor has reported a breach and you're not sure what it means for your firm, our cybersecurity team can help you work through the questions and check your own systems. Talk to our team. For steps individuals can take, see what to do when you get a breach notice.
