A Partner’s Problem is Your Problem: A Guide to Navigating Third-Party Breaches

Daniel Frye
VP of Product at BreachRx
Daniel Frye brings more than three decades of leadership across cybersecurity and information technology. As VP of Product at BreachRx—a SaaS innovator redefining incident response—he drives product management and strategy.

As a seasoned CISO with over a decade in the role, former CIO, CEO, and startup founder, Daniel blends deep technical and cybersecurity expertise with boardroom-level insight. He holds a B.S. in Computer Science with a focus on Real-Time Systems and an MBA in Management of Technology from Georgia Tech.

An active voice in the industry, he has delivered keynotes and panels at leading security, IT, and executive conferences, published on leadership, technology, and cybersecurity, and serves on the SANS Institute Advisory Board. He’s been certified by GIAC, ISC², CompTIA, and EC-Council.

A critical third-party vendor, one deeply embedded in your operations, has been breached. An incident like the recent major CRM platform hack serves as just one potent example. As a seasoned incident responder, I can tell you that a third-party scenario like this isn’t a matter of if, but when. The interconnected nature of modern business means a vendor’s security incident is your security incident, whether you’re ready or not.

The ripple effect is massive when a major vendor is compromised. Your data, your customers’ data, and your business operations are suddenly at risk, and you have very little direct control over how to respond to the attack. All you can do is quantify the damage and take steps to minimize the ongoing impact on your organization. A sense of panic is a natural reaction, but a methodical, calm response is what’s required.

Here’s the playbook I typically follow to handle this type of situation.

Step 1: Triage and Containment – The First 24 Hours

Your immediate goal is to stop the bleeding and understand the battlefield. Don’t assume anything; verify everything.

• Confirm the Breach: First, get official confirmation from the vendor. Look for official statements on their website, status pages, or direct communication to you as a customer. Disregard rumors and social media chatter. You need facts.
• Activate Your Incident Response Team: Assemble your core IR team, which should include representatives from security, IT, legal, communications, affected business units, and executive leadership. This is not a tech problem; it’s a business problem and is likely to have impacts on business operations. All of this work needs to be done from a centralized workspace that assigns clear roles and responsibilities – you don’t need lone wolf, grassroots IR mavericks running rampant across the business creating chaos.
• Understand the Scope: What specific products or services from this vendor do you use, and what data do you send them? The breach notification should provide details on the nature of the compromise. Your first task is to map this information to your own environment. What data might reside in the affected services, regardless of how long ago you might have sent it to them? Was it customer PII (personally identifiable information), financial data, or proprietary business information? Usually, the best way to get this information is to go directly to the source – find out from the business unit(s) that use the software vendor what they do with it day-to-day.
• Isolate and Monitor: Review all connections and integrations with the affected third party. Look for unusual activity on your own network, especially around identities, accounts, and APIs connected to their platform. Did the attackers pivot from the vendor into your environment? Immediately increase monitoring on all logs related to the vendor’s API calls, user authentications, and data exports. If necessary, consider temporarily disabling high-risk integrations until you have a clearer picture.

Step 2: Investigation and Impact Analysis

Once you’ve stabilized the situation, you need to dig deep to understand the full impact on your organization.

• Data Exposure Assessment: Work with the vendor’s support and security teams to get precise details on what data, if any, was accessed. This can be a slow and frustrating process, but it’s critical. You need to determine whose data was exposed and what that data was. This will inform not just technical actions, but also your legal and regulatory obligations. Make sure you’re keeping legal involved throughout this process.
• Review Your Logs: Your own logs are a crucial source of truth. Scrutinize authentication logs, data access logs, and API usage logs for any period specified by the vendor’s breach notification. Look for anomalous logins (e.g., from unusual geographic locations), large data exports, or changes in user permissions that you can’t account for.
• Engage Legal and Compliance: This is non-negotiable. Your legal team must be involved to assess your notification requirements under regulations like GDPR, CCPA, and others. They will guide you on what you need to report, to whom, and by when, and most importantly, how to generate defensible documentation and the steps everyone involved needs to follow to safeguard legal privilege. Failure to comply can result in severe financial penalties.

Step 3: Communication is Key

How you communicate during a crisis will define your company’s reputation long after the incident is resolved. Be clear, transparent, and timely.

• Internal Stakeholders: Keep your executive team and board informed with regular, factual updates. Arm your customer support teams with an approved FAQ so they can handle incoming inquiries consistently and accurately. Everyone needs to be responding with the same legal and executive-approved messaging, the source of truth from the pre-approved and shared incident templates, ideally from a common workspace.
• Customer Notification: If customer data was impacted, you almost always have to notify them. Don’t hide behind vague language. Tell them what happened, what data was involved, what you are doing about it, and what they can do to protect themselves (e.g., be wary of phishing emails, change passwords). Owning the narrative is always better than letting it be dictated by others.
• Regulatory Bodies & Insurance: With guidance from your legal team, ensure you meet all regulatory reporting deadlines. Consult with your legal team, as you likely need to rapidly notify your cyber insurance carrier in order to make a claim later, so don’t lose track of that task.

Step 4: Remediation and Long-Term Hardening

The immediate fire is out, but now it’s time to rebuild and reinforce your defenses.

• Mandatory Password & Key Resets: Force a password reset for all users with access to the compromised service. If single sign-on (SSO) is used, ensure the connected identity provider is secure. Reset any API keys or shared secrets between you and the vendor.
• Review and Revoke Permissions: Conduct a full audit of user permissions within the affected platform. Does every user still need the access they have? Apply the principle of least privilege. Revoke access for former employees and reduce permissions for users who don’t need extensive or frequent access.
• Strengthen Vendor Risk Management: This incident is a wake-up call, and there will be others just like it. It’s time to re-evaluate your third-party risk management program. How do you vet vendors? What are the security requirements in your contracts, and did they work as necessary? Was there anything you wish you had added in there? Do you know which vendors are getting what data? Do you have the right to audit their security controls, and are there breach notification clauses in your existing vendor contract templates that are consistent with your customer contracts? Are you tracking your third-party incidents in the same way you track others? You need to treat your key vendors’ security with the same rigor you apply to your own. Outsourcing services doesn’t mean you outsource 100% of the risk.
• Incorporate Third-Party Scenarios Into Your Future Exercises: Maybe managing this incident went great, maybe not. It doesn’t matter. Organizational memory is short, and people change jobs and companies all the time. It’s highly likely that the next incident will have new names and faces, but I’d be shocked if you never see another third-party incident ever again. Embrace that reality and start incorporating third-party risks into your incident response exercises, even if it’s nothing more than a red herring for the team to churn on during the exercise.

This isn’t just about recovering from this specific breach; it’s about building resilience for the next third-party incident, because there will always be a next one. Use this as an opportunity to mature your security program and strengthen your defenses from the inside out. Preparation is the key to future success, so get on it.