When Klue's OAuth integration was compromised in June 2026, attackers used a dormant credential to harvest tokens and access data from connected Salesforce environments. The breach didn't just affect Klue's direct customers. It also impacted organizations connected to Klue through a vendor, highlighting a classic fourth-party exposure.
You can't prevent every vendor breach, but you can control how your team responds. This template provides a structured framework for managing third and fourth-party incidents from notification through resolution.
Purpose of This Template
Use this template when notified that a vendor, or your vendor's vendor, has experienced a security incident. It covers initial assessment, vendor communication, regulatory obligations, and post-incident review. The template assumes you're working under tight notification deadlines; banks have 36 hours to report to their primary federal regulator, while credit unions have 72 hours under NCUA's rule.
This isn't a substitute for your incident response plan. It's a structured workflow focused specifically on vendor-originated incidents where you need to assess impact, document decisions, and potentially notify regulators or affected parties.
Prerequisites
Before using this template effectively, ensure you have:
- Contract access: Locate the vendor agreement section on security incidents, data ownership, and official correspondence contacts.
- Data classification records: Know what data types the vendor processes and how your organization classifies them.
- Regulatory mapping: Identify which regulators you report to and what constitutes a reportable incident.
- Incident response team roster: Pre-designate roles such as incident response manager, vendor liaison, legal counsel, compliance lead, and communications lead.
- Vendor inventory: Maintain a current list of vendors, including their sub-processors and critical integrations.
If these elements aren't documented, start there. The middle of an incident is too late to figure out who owns the vendor relationship or which regulator you report to.
The Template
Phase 1: Initial Assessment (Hour 0-4)
Incident Response Manager: [Name]
Date/Time Notified: [YYYY-MM-DD HH:MM]
Vendor Name: [Legal entity name]
Notification Source: [Email/phone/portal/third party]
Initial Classification:
- Third-party breach (our direct vendor)
- Fourth-party breach (vendor's vendor)
- Uncertain (vendor won't confirm source)
Data Types Potentially Affected (check all that apply):
- Non-public personal information (GLBA-regulated)
- Payment card data
- Account credentials
- Business contact information
- Proprietary/confidential business data
- Other: [specify]
Preliminary Impact Assessment:
- Number of potentially affected records: [Unknown/Estimate/Confirmed count]
- Business units affected: [List]
- Customer-facing impact: [Yes/No/Unknown]
Phase 2: Vendor Information Request
Send this request to the official correspondence contact listed in your vendor agreement. Document the send time and method.
Subject: Security Incident Information Request, [Your Organization Name]
[Vendor Contact Name],
We received notification of a security incident affecting [Vendor Name]. To assess our obligations and coordinate our response, we need the following information by [DATE, 24-48 hours from send]:
- Timeline: When did the incident occur? When did your team learn about it? When was it contained?
- Scope: What specific data types were accessed or exfiltrated? Provide volume estimates and confirm whether the exposure included [list your specific data types of concern, e.g., "customer account numbers, Social Security numbers, or authentication credentials"].
- Root Cause: What was the attack vector? Was this a direct compromise of your infrastructure, or did it originate from a third-party integration or sub-processor?
- Containment: What steps have you taken to contain the incident? Have all compromised credentials been revoked and rotated? Has the vulnerability been remediated?
- Third-Party Dependencies: Does this incident involve any of your sub-processors or integrated services? If so, which ones, and do you have confirmation they've also contained their exposure?
- Root Cause Analysis: When will you provide a complete root cause analysis and remediation plan?
Please direct all responses to [designated vendor liaison email] and copy [legal counsel email].
[Your Name, Title]
Sent: [Date/Time]
Method: [Email/certified mail/vendor portal]
Response Received: [Date/Time or "Pending"]
Phase 3: Regulatory and Legal Assessment (Hour 4-24)
Compliance Lead Assessment:
Does the exposed data include information regulated under:
- Gramm-Leach-Bliley Act
- State breach notification laws (specify states): [List]
- Other regulatory obligations: [List]
Notification Obligations:
- Primary federal regulator notification required: [Yes/No]
- Deadline: [36/72 hours from when?]
- State notification required: [Yes/No/Assessing]
- Customer notification required: [Yes/No/Assessing]
Legal Counsel Review:
- Contract breach identified: [Yes/No/Reviewing]
- Data ownership determination: [Our data/Vendor's data/Shared]
- Liability assessment: [In progress/Complete]
Documented Decision: [Record your reasoning for notification decisions, even if you determine no notification is required. Include the date, who participated in the decision, and what factors you considered.]
Phase 4: Communication and Escalation
Internal Stakeholders Notified:
- Executive leadership
- Board (if material)
- Affected business units
- Customer service (if customer-facing)
External Communications:
- Regulatory notification submitted [Date/Time]
- Customer notification sent [Date/Time]
- Public statement issued [Yes/No]
Vendor Escalation:
- Escalated to vendor executive contact
- Requested executive briefing
- Engaged vendor's legal team
Phase 5: Post-Incident Review (90 days post-containment)
Schedule Review Date: [90 days from containment]
Review Questions:
- Did the vendor provide timely, complete information?
- Did our contract require what we actually needed during response?
- Did we have the right people on our incident response team?
- What documentation gaps did we discover?
- Should this vendor relationship continue?
Contract Amendments Needed:
- Stronger notification requirements
- Sub-processor disclosure requirements
- Recovery time/recovery point objectives
- Audit rights expansion
- Termination rights revision
Vendor Continuity Assessment:
- Backup vendor identified: [Yes/No]
- Migration plan documented: [Yes/No]
- Concentration risk acceptable: [Yes/No]
How to Customize It
Adapt the data classification checklist to match your organization's taxonomy. If you classify data as "restricted," "confidential," and "public," use those terms instead of the regulatory categories listed here.
Adjust the timeline thresholds based on your regulatory obligations. Credit unions working under NCUA's 72-hour rule have more breathing room than banks reporting under the 36-hour standard, but don't let extra time create complacency.
Add vendor-specific questions to Phase 2 based on what the vendor does for you. If they process payment card data, ask about PCI DSS compliance status. If they handle special categories of data, ask about data protection impact assessments.
Modify the post-incident review questions to reflect your vendor management maturity. If you're just building fourth-party visibility, add: "Did we know this vendor used sub-processors before the incident?"
Validation Steps
Before you file this template away, test it:
- Run a tabletop exercise: Pick a vendor, simulate a breach notification, and walk through the template with your incident response team. Time how long it takes to gather the contract, identify the regulatory obligations, and draft the information request.
- Verify your contract contacts: Confirm the official correspondence contact listed in each vendor agreement is current. Send a test message if you haven't communicated with them in the past year.
- Check your notification deadlines: Confirm your regulatory notification requirements with legal counsel. The 36-hour and 72-hour windows are federal banking standards, but your state obligations may be tighter.
- Document your Data Processing Register: If you can't quickly answer "what data does this vendor process," you'll waste hours during an actual incident. Map vendor relationships to data types now.
- Identify your fourth-party exposure: For each critical vendor, ask whether they use sub-processors or integrations. Document the answer in your vendor inventory. A quarter of financial organizations don't assess fourth-party risk, according to Ncontracts' 2026 State of Third-Party Risk Management Survey. Don't be one of them.
This template won't prevent vendor breaches. It gives you a documented, defensible process for responding to them, which is exactly what examiners will look for when they review how you handled the incident.
