Third Party Incidents

Today I want to continue with playbooks, I want to focus on Third Party Incident Response (TPIR).

We have seen our share of supply-chain attacks because attackers only need to infect one company and this can give them an entry into multiple other companies. An incident originates in a vendor's environment, but the fallout lands on your company. Why? Because you have an integration in your environment.

Every integration you stand up is a potential door: the API pulling data from a partner, the platform your team plugged into last quarter, the connector that didn't really go through security vetting. Your IR Plan doesn't have specifics around TPIR — it might have a line in the contacts table that calls out who is responsible for Third Party Risk, but that's where it usually ends. This is why you need a TPIR Playbook.

As with most incidents, you are working against the clock, but with vendor incidents, you are also working to figure out where the vendor lives in your environment.

Let's use the Salesloft Drift (August 2025) breach as an example. Attackers stole OAuth tokens tied to Drift, the third-party chatbot many companies had integrated into their Customer Relationship Management (CRM) systems. From this view, you think it's a pretty straightforward point — but the reality is there are other points where the tokens reached.

Because you are working in emergency mode, it is easy to just look at the Configuration Management Database (CMDB) and assume you have all the information. But in reality, you should also be working with your Third Party Risk Management team or your business continuity team, or both. These teams have all the information you need to respond quickly.

You should bring in the business owner, because these are the people who use it every day and know the ins and outs. It is impossible to contain a connection you do not understand, and you cannot assess your notification obligations for data without its classification.

Once you understand the possible entry points, you can begin to coordinate actions. Keep in mind, going through the playbook and workflow might take time. It is possible that you will get things wrong to begin with, but the idea is to tighten your process.

Let's talk about the possible data you are gathering. I did ask Claude to create this; however, the information came from me. I wanted to give readers a visual, keep in mind, this will depend on your org and business type.

Start with how the vendor is integrated, because that tells you how you will eventually contain it. Find out where it connects, meaning which systems and which environment, because a vendor touching production database is a very different conversation.

From here, move to the data itself. What is flowing through the integration, and what is the classification of that data? Once you figure this out, you might need to work with the legal department and/or compliance. They should answer the question of "do we need to disclose, and to whom."

Data encryption, how the vendor authenticates, where those credentials live. None of this information really lives within the CMDB which is why gathering this information is crucial.

Once you have it, containment becomes a real decision instead of a guess. But that is a section of its own, and the harder half of the work.

None of this is meant to be perfect the first time around, but start with a playbook, who do you call to find business owners? what to ask? where to look for information? Every incident will teach you more and more!

What separates a TPI from a normal one is that the failure is not yours, but the response is. Your client/customers won't care whether it started inside the house or not, they will still look at you for remediation.