The Slack alert lands at 3:47pm. By 3:48 the CISO has messaged "are we affected?" By 3:52 the VP of Engineering has messaged "should we rotate creds?" By 4:00 the General Counsel has messaged "do we need to notify customers?" You have an hour, maybe two, before someone with authority makes a decision based on whatever you can give them. And what you can give them depends entirely on how well you can answer three specific questions in the next sixty minutes.
Most security teams improvise this. The improvisation usually produces a decision. The decision is sometimes right. But the next time it happens — and it will happen, because vendor incidents at this rate are no longer rare events — the improvisation starts over from scratch. None of the analysis compounds. None of the rationale survives the week.
This is the sixty-minute triage. Three questions, in order, with the specific evidence each one demands and the lightweight artifacts that capture the work for the audit-and-next-time loop. Sized for a small security team without a dedicated GRC function. Built to run repeatedly without inventing the methodology each time.
The 60-minute timer starts now
The clock is anchored to the vendor's disclosure timestamp, not yours. The vendor published at 3:32pm; you saw it at 3:47pm; the triage window opened at 3:32. Real time matters because regulatory disclosure clocks, contractual notification requirements, and customer trust all depend on the absolute time-of-incident, not the relative time-you-found-out.
Question 1 — Are we in scope? (Minutes 0–20)
The vendor's disclosure language is the first input. Read it carefully. The single most consequential phrase is usually one of these:
"Customers using Feature X" is the disclosure language you want to see — it's specific enough to verify against your own usage data quickly. Pull the product usage record for the past 90 days (or however far back the vendor's exposure window goes), check whether you used the named feature, document the result. Either you used it (you're likely in scope) or you didn't (you're likely not). This single check resolves more triage uncertainty in 10 minutes than any other action you can take in the first hour.
Document what you find in a single artifact — name it the Scope Determination, date and timestamp it, paste the vendor disclosure language, paste your usage evidence, write the resulting probability estimate with a one-sentence rationale. This becomes both the audit trail for this incident and the reference for the next time this vendor has one.
Question 2 — What's our exposure? (Minutes 20–45)
If you're in scope or even possibly in scope, exposure is not a single number. It's the answer to a more specific question: if this incident materialized for us exactly as the vendor described, what would we actually lose?
The decomposition that produces a useful answer in 25 minutes:
What data did we share with this vendor?
Pull the vendor's data flow record from your TPRM register if you have one; from contract addenda + integration documentation if you don't. Categorize: customer PII, employee PII, financial records, source code, credentials/secrets, business confidential. The categories drive the regulatory and notification analysis later.
What systems integrate with this vendor, and at what trust level?
SSO into your environment is a Control-failure vector (highest severity). API integration with read-only data access is Confidentiality. File transfer is usually Confidentiality. Admin access from the vendor side (vendor support tools, MSP access, RMM agents) is Control. The integration type drives the failure mode profile.
What's the failure mode the incident triggered?
Read the vendor disclosure for indicators. "Unauthorized access to data" → Confidentiality. "System compromise" / "malware" → Integrity, often Control. "Service outage" → Availability. "Admin access" / "privilege escalation" → Control. The failure mode determines which of your exposures actually fires for this incident.
What controls do we have in place that compensate?
MFA on the vendor's interface (limits credential theft propagation). Network segmentation (limits lateral movement). Encryption-at-rest (limits Confidentiality impact). Backup integrity testing (limits Availability impact). The compensating controls are what reduce P(Exploitable | Affected) from worst-case to your-actual-case.
Out of this analysis comes the rough exposure number: "if we're affected, the realistic loss is in the range of $X to $Y." Not a single number. A range. With a one-line rationale per component.
"I estimate 18% exposure with a confidence interval of 8% to 32%, with expected loss in the $80K to $250K range if exposed, driven primarily by potential customer PII notification cost and credential-rotation engineering time." That sentence beats "I think we're probably fine" in every audience — board, regulator, customer, next-quarter-renewal-cycle. The precision matters not because the numbers are exact, but because they're debatable, updatable, and auditable in a way gut feel never is.
Question 3 — What should we do? (Minutes 45–60)
Now the recommendation. Four options, evaluated against the exposure estimate and the cost of each response.
Pick the option where cost + residual risk is smallest. That's the recommendation. The rationale — why this option over each of the others — is the artifact that goes to the decision-maker.
The five artifacts a sixty-minute triage produces
Each artifact is one page or less. Together they constitute the entire audit trail for the incident and the foundation for next-incident analysis at the same vendor.
Scope Determination
Vendor disclosure language, your usage evidence, probability estimate, one-line rationale. Produced in question 1.
Exposure Worksheet
Data shared, integration types, failure mode of this incident, compensating controls, exposure range with rationale. Produced in question 2.
Response Options Comparison
Four options (Accept/Mitigate/Reduce/Exit) with cost estimate, residual risk, and risk-adjusted total per option. Produced in question 3.
Decision Brief
One-paragraph recommendation, two sentences of rationale, what triggers reassessment. Goes to the CISO / GC / board for the decision call.
Mitigation Tracker (if Mitigate)
If the decision is Mitigate, the committed mitigations with owners, due dates, and completion criteria. This becomes the input to the institutional memory for the next incident.
The artifacts that compound — why this isn't just bureaucracy
The first time you run this triage, the artifacts feel like overhead. The second time you face an incident at the same vendor — and you will, because vendor incidents at this rate are not exceptional — every artifact you produced the first time is a starting point. You don't reconstruct the data-flow analysis; you read it. You don't re-debate the response options; you reference the prior comparison. The committed mitigations from last time are either complete (good, they're already reducing this incident's exposure) or incomplete (also good information — they're mitigation debt the current incident should now resolve).
The compounding is what separates a security program that improves over time from one that re-runs the same fire drill at every vendor incident.
Sixty-minute triage done well
Five short artifacts, dated and stored together. A recommendation tied to a defensible exposure estimate. A decision brief that lets the CISO make a defensible call. Mitigation commitments tracked to completion. The whole package is referenceable in three months when the auditor asks, or in nine months when the vendor has another incident.
Sixty-minute triage done badly
A Slack thread that scrolls past by Monday. A decision made by the most senior person based on gut feel. No artifact captures the rationale. The next incident at the same vendor starts from scratch. The mitigations promised after the first incident were never tracked; nobody knows whether they shipped.
What to do this week, before the next incident lands
Two things, in order:
Create the triage template once, so it's ready when you need it
Five blank artifacts (Scope Determination, Exposure Worksheet, Response Options Comparison, Decision Brief, Mitigation Tracker). One page each, in whatever document system the team already uses (Notion, Google Docs, Confluence). The template takes an hour to build; it saves the first 30 minutes of every incident going forward.
Pre-populate the data-flow record for your top 10 vendors
For each: what data flows, what integration type, what failure modes are technically possible, what compensating controls are in place. One row per vendor in a table the security team owns. When the incident lands, you read the row instead of reconstructing it. Pre-population takes a day; saves 15–25 minutes of triage time per incident at any of these vendors.
The bottom line
Sixty minutes is enough to do vendor incident triage well if you have a framework. The framework is three questions in order — are we in scope, what's our exposure, what should we do — supported by five artifacts that capture the work, ground the decision, and compound across incidents at the same vendor. Most security teams improvise this. The teams that build the framework once and run it repeatedly produce defensible decisions in the same time the improvising teams produce frantic Slack threads.
Run the triage from a framework, not from a Slack thread
vCISO Lite ships the five triage artifacts as templates pre-populated with your vendor data-flow records, your integration inventory, and your compensating controls — so when the incident lands, the team works from a structured starting point rather than from a blank page. Built for the 33 million US small and mid-sized businesses that don't have a CISO yet, but need the next Thursday-afternoon vendor incident to end with a defensible decision rather than a hope.
If you've lived the Thursday-afternoon Slack alert and want the next one to go differently, visit vcisolite.com to learn more and get started.
Where this matters next
Someone else's breach: why vendor IR is its own discipline — the strategic context for why the three-question triage exists as a distinct methodology rather than a TPRM subroutine.
Conditional exposure analysis: why your risk isn't what the vendor reported — the formal version of question 2's exposure estimation, with worked example and Bayesian updating for incidents that evolve over days.
Stay, exit, or mitigate: the vendor incident decision framework — the formal version of question 3's response selection, with risk-adjusted cost computation and decision anti-patterns to avoid.
Vendor concentration risk: the dimension per-vendor TPRM misses — the column-side analysis that surfaces when a single incident affects multiple vendors simultaneously and the triage scales horizontally.