What to do when a vendor tells you they were breached

Vendor breach notices are often written by lawyers to say as little as possible. Read it for specifics: what systems were affected, when, what types of data, whether your organization's data is confirmed as involved or only 'potentially' involved, and what the vendor wants you to do. Note the date you received it; it starts your own clock for assessing the breach.

Check that the notice is genuine. Attackers sometimes send fake breach notices to get people to 'reset' credentials on a phishing page. Verify through the vendor's website or a known contact, not links in the notice.

• Is our data confirmed as accessed or taken, and which records or fields?
• What was the date range of unauthorized access?
• Were credentials, API keys, tokens or integration secrets for our account exposed?
• Was our data encrypted, and were the keys also exposed?
• Has the attacker's access been closed, and how was it confirmed?
• Are you notifying affected individuals directly, or do you expect us to?
• Have you reported to the Privacy Commissioner or other regulators?
• Who is our contact for updates, and when will we hear next?
• Will you share a summary of the forensic findings?

Assume that anything the vendor held that lets someone into your systems is burned until shown otherwise. That includes accounts your staff use on the vendor's platform, API keys and OAuth connections between your systems and theirs, service accounts or VPN access you gave the vendor, and any password reused anywhere else.

Review sign-in and API logs on your side for the breach window. If the vendor had remote access to your network, as many managed service and software providers do, treat this as a possible incident on your own network. The Canadian Centre for Cyber Security publishes guidance on supply chain and managed service provider risk that's worth reading in this situation.

Under PIPEDA, the organization in control of personal information is responsible for it, including when it is transferred to a third party for processing. Schedule 1, Principle 4.1.3 says organizations must use contractual or other means to provide a comparable level of protection while information is being processed by a third party. In practice, when a processor is breached, the controlling organization may be the one that must assess real risk of significant harm, report to the OPC, notify individuals, and keep a breach record.

Your lawyer should decide who notifies whom. Sometimes the vendor notifies individuals on your behalf; sometimes you must. Either way, document your own assessment and keep it with your breach records for 24 months.

Stolen customer lists and invoice data fuel targeted phishing. For the next several months, expect emails that reference real transactions, real names and real account numbers. Warn your finance and customer-facing staff, and tighten payment verification. See What to do when a vendor asks to change their bank details.

• Breach notification timing and content the vendor owes you.
• Security obligations and audit rights.
• Who pays for notification, credit monitoring and investigation.
• Data return and deletion at the end of the relationship.
• Whether you should keep using the vendor, and on what conditions.