An email arrives from a vendor. There was a security incident. They are investigating. They will share more when they know more. It does not say whether you are affected.
That message starts several clocks, and one of them may be regulatory. This post is what to do in the first forty-eight hours, in order. For whoever receives that email, which is often whoever the vendor happens to have an address for.
The notification will be vague, and late
Expect it. Vendor notifications are written by people balancing legal exposure against customer relationships, usually before their own investigation has concluded. They tend to arrive weeks after the intrusion, describe the scope in the broadest terms available, and avoid confirming specifics.
That is not a reason to wait. Most of what you need to do does not depend on their answers, and starting now shortens everything that follows.
Establish what they held
Before you ask them anything, answer this yourself, because you should already know and because their answer will be slower.
What data did they process for you? Which categories, whose, and how much. Your data map should tell you. If it does not, this incident is the reason to build one.
What credentials of yours did they hold? API keys you issued them, OAuth grants, a service account in your systems, SSH access, a VPN account. This list is the urgent one.
What access did they have into your environment? A support integration with read access to your production data is a very different exposure from a marketing tool holding email addresses.
Which of your customers' data is involved? This determines your own notification obligations.
If your subprocessor list and your integration inventory are current, this is a ten minute exercise. If they are not, it is the thing that will take you the longest, and that is worth remembering afterwards.
Act before they confirm anything
Three things that do not require their cooperation:
Rotate every credential they held. All of them, immediately, regardless of whether the vendor says those were affected. The cost of rotating unnecessarily is a short outage in an integration. The cost of not rotating is unbounded, and their scope assessment may change twice before it settles.
Revoke their access, or reduce it. If they have an integration into your systems, consider suspending it until the picture is clear. This is disruptive and it is reversible, which is the right shape for a decision under uncertainty.
Search your own logs for their activity. Authentication events for their service accounts, API calls using their credentials, unusual volume through their integration. You are looking for use of their access that does not match its normal pattern, and you are the only one who can see this. Widen the window well beyond the dates they gave you, because those dates usually move.
Ask them specific questions
Vague questions get vague answers. Ask for:
- The time window of the intrusion, and when they detected it.
- Which systems and data categories were accessed, specifically including whether customer data of yours was among them.
- Whether credentials issued by customers were exposed, and in what form.
- Whether they can confirm your tenant specifically was or was not accessed, and how they determined that.
- What evidence they can provide that you could show your own auditors or customers.
- Their remediation and the timeline.
Put these in writing and date them. You will need the record, and a written request tends to produce a more careful answer than a call.
Your own clock may have started
The part people miss.
If the vendor was processing personal data on your behalf, you are likely the controller and they are the processor. Their breach is your breach for notification purposes, and under GDPR your obligation runs on a 72 hour clock that starts when you become aware, not when their investigation finishes.
That means you may need to notify a regulator on the basis of an incomplete picture. This is expected, and the regulations allow for providing information in phases. Waiting for certainty is the failure mode, because certainty arrives after the deadline.
Involve whoever owns privacy immediately, even if the incident looks small. The determination of whether notification is required is a decision to make deliberately and record, not one to skip because the vendor said it was contained.
Tell your customers if their data is involved
The same principles that apply to your own incidents apply here, and there is a temptation to stay quiet on the grounds that it was somebody else's failure.
That reasoning does not survive contact with a customer who finds out independently. You chose the vendor, you sent them the data, and your customers' relationship is with you. Tell them what you know, what you have done, and when you will update them.
Afterwards, make a decision about the vendor
Not immediately, and not never.
The question is not whether they had an incident. Most organisations will. It is how they handled it: did they detect it themselves or were they told, how quickly did they notify, were their answers consistent as the investigation progressed, and did the remediation address the cause.
A vendor that detected their own intrusion, notified within days, and answered specifics is in some ways a better bet afterwards than one that has never had an incident, because you have now seen how they behave. A vendor that was told by a third party, notified after six weeks, and changed their story twice has told you something durable.
The concession
Rotating every credential a breached vendor held is disruptive, and in many incidents it will turn out to have been unnecessary. Integrations break, someone has to fix them, and it costs a day.
The trade is still right, because the decision has to be made while the scope is unknown and the asymmetry is severe. But be honest about the cost when you propose it, and have the rotation procedures ready in advance, because doing it under time pressure without a runbook is where the disruption actually comes from.
The implication
Almost everything useful in the first forty-eight hours is work you do on your own systems, without waiting for the vendor.
Which means your ability to respond is mostly determined before the email arrives, by whether you know what each vendor holds and what access they have. That inventory is the control. The response is just reading it quickly.
