Vendor Security Incident Response: The First 72 Hours

When a vendor discloses a security incident, or you learn about one before they disclose it, the first 72 hours determine whether you end up with a managed third-party event or an unmanaged extension of someone else's breach. The teams that handle this well are not faster because they think faster. They are faster because the sequence was written down before it was needed. This is that sequence.

Hour 0 to 4: verify before you mobilize

Vendor incident news arrives through unreliable channels: a journalist's tweet, a ransomware leak site, a customer asking if you are affected, occasionally the vendor itself. Verification comes first, because the response to a confirmed incident and a rumor are different, and mobilizing your organization on a rumor burns credibility you will need later.

1. Capture the source. Screenshot and archive whatever you saw, with timestamps. Leak site posts disappear; disclosure pages get edited.
2. Check independent corroboration. Vendor status page, official disclosure channels, regulator filings, credible threat intelligence. One source is a lead; two independent sources is a working assumption.
3. Check your own monitoring. If you run continuous vendor monitoring, pull the vendor's recent signal history. Score collapse, new exposed services, or leak intelligence in the preceding weeks both corroborates the event and helps date it.
4. Open the incident record now, even at "unconfirmed" status. The timestamp of when you knew is the anchor for every regulatory and contractual clock that follows. Log every action against it from this point forward.

Hour 4 to 24: assess your exposure

Exposure assessment answers one structured question: what could this vendor's compromise reach of ours? Work through five dimensions, in order, and write the answers down even when the answer is "none."

1. Data exposure. What data classes does this vendor hold, process, or transit? Pull this from the vendor record, not from memory. If your inventory cannot answer it, that gap is itself a finding for later.
2. Access exposure. Does the vendor hold credentials, API keys, tokens, or network paths into your environment? This is the dimension that turns a vendor incident into your incident, and it is the one to resolve fastest.
3. Integration exposure. Which of your systems consume this vendor's software, agents, or updates? Supply-chain style compromises propagate here.
4. Availability exposure. If the vendor goes dark for remediation, which of your business processes stall, and what is the workaround?
5. Fourth-party exposure. Is the incident actually at the vendor's own subprocessor? If so, which of your other vendors share that subprocessor? Concentration risk surfaces exactly here.

By hour 24, take interim containment on the access dimension regardless of confirmation status: rotate shared credentials and keys, review recent authentication logs for the vendor's integration points, and tighten or suspend nonessential integrations. Rotation is cheap. Regret is not.

Hour 24 to 48: engage the vendor and invoke the contract

Now the formal machinery starts. Two tracks run in parallel.

The inquiry track

Send a written incident inquiry through a channel that creates a record. Ask exactly six questions and resist the urge to send your full questionnaire:

1. What happened, and when was it detected?
2. Is the incident contained, and as of when?
3. Was our data, or access related to our account, in scope?
4. Which systems and subprocessors were affected?
5. What is the remediation status and timeline?
6. When will the next update come, and who is our named contact?

The contract track

While waiting, pull the agreement and check four clauses:

• Breach notification: what were they obligated to tell you, and by when? If the clock has already been blown, note it; it shapes both the relationship decision and any regulator conversation.
• Audit and assessment rights: most agreements grant expanded assessment rights after a security event. This is what authorizes the targeted reassessment below.
• Your own downstream notification duties: depending on the data involved, your obligations to customers or regulators may have their own deadlines that started when you learned of the event, not when the vendor confirms details.
• Termination and remedy triggers: know your options before you need them, even if you exercise none.

Hour 48 to 72: scope the targeted reassessment

Do not respond to an incident by re-sending the full annual questionnaire. It is slow, it is mostly irrelevant to the event, and a vendor mid-incident will deprioritize it. A targeted reassessment scopes to three areas only:

1. The failed control domain. If the incident was phishing-initiated, scope email security, MFA coverage, and awareness controls. If it was an exposed service, scope attack surface management and change control. Depth here, not breadth.
2. The blast radius controls. Segmentation, privileged access, logging and detection: the controls that determined how far the incident spread once it started.
3. Claims contradicted by the event. Compare what the vendor attested in their last assessment against what the incident demonstrates. An incident that disproves an attested control is a divergence finding with consequences for how much you trust the rest of the questionnaire; this is the assessed versus live posture gap made concrete.

Set response deadlines proportional to vendor criticality tiering: an illustrative standard is 10 business days for critical vendors and 20 for others. On completion, reset the vendor's monitoring baseline against the reassessed state, not the pre-incident one; the old baseline described a posture the incident just invalidated. Platforms that link monitoring and assessment on one vendor record, ThirdSentry among them, handle this step structurally, resetting baselines only when a completed reassessment closes.

The documentation an auditor will ask for

Twelve months from now, an auditor or examiner will reconstruct this event from your records. Build the file as you go, not retroactively. The checklist:

• Timestamped record of when and how you learned of the incident
• The exposure assessment across all five dimensions, including the "no exposure" answers
• Interim containment actions taken, with dates (credential rotation, integration suspension)
• The written vendor inquiry and every vendor response, with dates received
• The contract clause review and any notices formally invoked
• The targeted reassessment scope, rationale, results, and resulting risk decisions
• The final disposition: risk accepted with rationale, remediation required with deadlines, usage restricted, or relationship exited
• Any updates made to the vendor's tier, monitoring thresholds, or contract terms as a result

The disposition entry matters most. An incident file that ends without a signed decision reads as an incident that was watched, not managed.

After hour 72

The first three days stabilize the situation; they do not end it. Schedule a 30-day follow-up to verify the vendor's remediation claims, feed the event into your next tiering review, and check whether your monitoring should have caught the incident earlier than the disclosure did. Every real event is free calibration data for the thresholds you set on quieter days.

ThirdSentry keeps this whole sequence on one vendor record: the monitoring signal history that corroborates the event, the targeted reassessment, the baseline reset on its completion, and the audit trail of every decision in between. When the examiner asks what you did in those 72 hours, the answer is already assembled.