This article includes insights and guidance from GraVoc’s Director of Information Security, Brian Brunelle, who specializes in audit and risk management.
Third-party platforms are ubiquitous across businesses today. Your LMS, your CRM, your cloud provider, your payroll system, they’re all deeply integrated into your workflows and core to running your business. So, when one of them gets breached, it becomes your problem, doesn’t matter whether the security vulnerability was yours or not.
Recently, attackers exploited cross-site scripting (XSS) vulnerabilities in Instructure’s Canvas platform. ShinyHunters, the group behind the attack, claimed to have roughly accessed 275 million user records across more than 8,000 institutions. The Canvas attack follows multiple other third-party vendor breaches like MOVEit and Snowflake. In almost every incident, a single compromise cascades across hundreds or thousands of downstream organizations.
“This is classic supply chain risk management,” says Brian Brunelle, Director of Information Security at GraVoc. “Vendor and third-party risk are enterprise risk.”
So, how should a business respond if a third-party platform they rely on gets hacked? We have helped many organizations navigate this exact scenario. Here’s the incident response framework we recommend, before, during, and after a third-party vendor breach.
The first 24–48 hours: What to do after a vendor breach
When a platform your organization relies on is compromised, you have to take swift action. Here are Brian’s 4 recommended actions that your business should take in the first 24-48 hours after a vendor breach.
Validate the facts directly from the vendor.
Don’t react to social media or secondhand reports. Validate facts from the source. Look at what the vendor says was compromised. What’s the scope? What’s been remediated? If the vendor can’t answer clearly, that tells you something too.
Activate your incident response team.
Assess your exposure; check what data, integrations, users are connected to the affected platform.
Engage external experts as appropriate.
Depending on the scope, this may include incident response consultants, legal counsel, and your cyber insurance carrier.
Control your communication, internally and externally.
This is where most organizations stumble, and it’s where the Canvas breach offers the clearest cautionary lesson.
Communication is key
Brian points to the way Instructure’s messaging shifted over the course of the incident: “They initially communicated that they had identified the issue and closed the vulnerability. Then they had additional outages and had to re-position. Once the vendor is saying the problem is fixed and it wasn’t, that erodes confidence.”
Every downstream organization that relied on the vendor’s initial “all clear” was left exposed when the second attack hit.
When a breach puts your customers' data at risk, how you communicate matters as much as how you respond. The minute you tell your customers an issue is resolved, you own that statement, and if the vulnerability turns out to still exist, your credibility takes the hit, not the vendor's. As Brian strongly emphasizes, "Control communication. Control communication. Control communication." Don't relay the vendor's status as your own. Tell your customers what you are doing, and confirm the fix only after you have validated it in your environment.
This is Brian’s advice on how to communicate with customers in a security crisis:
- Externally: Acknowledge the event and state only what can be confirmed with 100% confidence. For instance, you can say, “We are aware of the ongoing issue with [vendor]. We are continuing to monitor and will provide updates as appropriate.” Nothing more until the facts are verified.
- Internally: Remind staff to direct all inquiries to designated individuals. No one speaks on the organization's behalf without authorization.
The prevention side: Why penetration testing matters
The Canvas breach was caused by a cross-site scripting (XSS) vulnerability. This is one of the oldest and most well-documented flaws in web application security. It’s been in the OWASP Top 10 for years. It was findable.
Brian says this clearly: “A thorough external penetration test, not just a vulnerability scan or assessment, would have uncovered this vulnerability and the potential for it to be exploited. Common tools used in web application testing, reconnaissance, and mapping would have identified the potential XSS vulnerability that a tester could have then validated. At its core, the issue is that ‘free for teacher’ accounts required less security by design but relied upon the same infrastructure as paid enterprise accounts. A standard pentest should identify this.”
A vulnerability scan identifies known weaknesses. A penetration test validates whether those weaknesses are actually exploitable and maps how far an attacker can go. They’re not the same thing and treating them as interchangeable creates security gaps.
When a breach starts at a vendor, the downstream risk flows through your integrations, your configurations, and your users. If you're not testing your own external attack surface regularly, including how third-party platforms connect to it, you're operating in the dark.
Building a third-party risk program that works
Recent research shows that every vendor breach now impacts an average of 5.28 downstream companies, the highest ratio ever recorded. Brian's recommendation is clear: "Organizations should have documented and tested incident response, disaster recovery, and business continuity programs that account for third-party risk."
Here’s what that looks like in practice:
Vendor Security Posture Assessment
Before onboarding, and periodically after, evaluate your vendors' security practices. Ask about tenant isolation, patching cadence, penetration testing frequency, and incident response capabilities. If a vendor can’t answer these questions clearly, that's a red flag.
Incident Response (IR) Planning That Includes Third-Party Scenarios
Most IR plans assume the breach happens inside your own environment. Add scenarios that cover third-party breaches and test them through tabletop exercises.
Integration and Access Auditing
Know what’s connected. Map and review any OAuth grants, API tokens, SSO integrations, and data sharing agreements. Maintain a process to revoke access quickly when a vendor is compromised.
Regular Penetration Testing of Your Own Attack Surface
Testing your external attack surface, including how third-party platforms connect to your environment, helps you understand your actual exposure before an incident.
