Incident Response

Incident response is the structured process an organization follows to detect, contain, eradicate, and recover from a cybersecurity incident. A mature incident response program includes defined roles, escalation paths, communication protocols, and post-incident review processes. In third-party cyber risk management, evaluating a vendor's incident response capabilities is a standard due diligence consideration, as a vendor's ability to detect and respond to breaches directly affects the first party's risk exposure. Black Kite supports incident-driven reassessment workflows, enabling organizations to rapidly evaluate vendor exposure following a significant cyber event.

What Are the Phases of Incident Response?

Incident response typically runs through five phases, and skipping the first one is why the other four so often go badly.

Preparation, building the plans, tools, and trained team before an incident ever happens.
Detection and analysis, identifying that an incident occurred and understanding its scope.
Containment, stopping the incident from spreading further while a permanent fix is worked out.
Eradication and recovery, removing the root cause and restoring normal operations.
Post-incident activity, documenting what happened and updating the plan based on what was learned.

Preparation Determines Whether the Later Phases Work

A team without pre-built playbooks, established contacts, and rehearsed roles is designing its response from scratch in real time, during the worst possible moment to be improvising. The preparation phase is what turns the remaining four phases from an assumption into an actual capability.

Post-Incident Activity Is the Phase Most Often Skipped

Once systems are back online and the immediate pressure lifts, the temptation to close the book and move on is strong. Skipping the post-incident review is how the same root cause resurfaces in a future incident, since nothing about the plan actually changed based on what was learned.

How Does Incident Response Differ From Vendor Risk Response?

Incident response addresses a compromise of an organization's own systems; vendor risk response addresses a risk or finding discovered at a third party the organization doesn't directly control. An internal incident responder can isolate a compromised server directly. A risk team responding to a vendor incident can only request that the vendor take action, then verify independently that it actually happened. The tools differ accordingly. Internal incident response runs on direct system access; vendor risk response runs on collaboration platforms, evidence sharing, and outreach, since direct access was never an option to begin with.

Why Does a Vendor's Incident Response Capability Matter Before You Ever Need It?

Whether a vendor can actually execute an incident response is a question worth answering during due diligence, not during the incident itself. A vendor that has a documented plan but has never tested it against a realistic scenario is likely to discover its gaps in the worst possible moment, live, during an event that also affects the organizations relying on it. This is the same testing question a business continuity plan raises, applied specifically to the narrower, faster-moving discipline of handling an active security event.

A vendor inventory that already tracks which vendors are most critical makes this due diligence question easier to prioritize, since a risk team can focus incident response capability reviews on the relationships where a slow response would actually hurt, rather than reviewing every vendor with the same depth regardless of stakes.

What Slows Down Incident Response When a Vendor Is Involved?

Every step that would be immediate inside an organization's own environment becomes a request, a wait, and a verification step once a vendor is involved instead.

Delayed notification, since a vendor typically has to confirm an incident internally before disclosing anything externally.
Indirect containment, requiring the vendor's own team to execute actions the affected organization can only request.
Slower scoping, since questions about what data or systems were touched take longer to answer when the answering party isn't the one asking.

Waiting on a Notification Chain Costs Real Time

A vendor's internal escalation process adds real elapsed time before an affected organization even learns something happened. That process may involve confirming the incident, looping in legal, and drafting a customer notice. None of that delay reflects bad faith. It's simply what a vendor's own process requires before it's ready to communicate outward, and that process runs on the vendor's timeline, not the affected organization's.

Black Kite's 2026 Ransomware Report highlights Sysdig's research on JADEPUFFER, described as the first documented case of an AI agent orchestrating attack stages from reconnaissance through encryption with limited human direction, a reminder that the incidents third-party risk teams now respond to can move faster than the notification chain built to report them.

What Should a Risk Team Do When a Vendor Reports an Active Incident?

The first hour of a vendor incident report matters more for what gets asked than what gets assumed.

Ask what's confirmed versus suspected, since early incident reports often conflate the two.
Request scope specifics, which systems, which data, which of your organization's information, not a general statement that "an incident occurred."
Track the finding behind the incident, so remediation has something concrete to close once the immediate crisis passes.
Set a follow-up cadence, rather than waiting for the vendor to volunteer updates on their own schedule.

How Does Black Kite Support Incident Response Involving Third Parties?

Black Kite maps high-profile cyber events to the specific vendors affected through FocusTags®, so a risk team knows which relationships are exposed before a vendor has finished drafting its notification. The Bridge™ then gives vendors a direct channel to share evidence and remediation updates, and the same continuous monitoring that flagged risk before the incident continues tracking the vendor's posture throughout it, rather than going dark until the vendor issues a formal all-clear. Closing out the resulting findings is where vendor risk response picks up. Manufacturing organizations, where a vendor incident can halt physical production as fast as it disrupts data, tend to feel the value of that continuous visibility most directly.