It's Not Your Breach. It's Still Your Problem

TL;DR: Most organizations treat their vendor relationships like a smoke detector: they set it up, assume it's working, and only find out it wasn't when something is already on fire. Vendor security (specifically the blind spots created by the tools and platforms your IT providers rely on) has become one of the fastest-growing attack vectors in cybersecurity. Third-party breaches now account for more than a third of all reported incidents globally, and the organizations affected often had no idea anything was wrong until the damage was done. Treating vendor security as a shared responsibility with your IT provider, not a delegated one, is the difference between knowing about a problem in time to respond and finding out after the fact.  

You wouldn't hand a contractor a master key to every system in your building and assume they'd handle it responsibly forever, especially once they started hiring their own subcontractors. Most businesses verify credentials, scope access carefully, and keep tabs on who can get into what. The relationship has boundaries, and those boundaries exist for good reason.

Now think about how most organizations manage their technology vendors. A contract gets signed. The vendor gets access. And then, unless something breaks, nobody thinks about it again.

That gap between "we signed with a vendor" and "we actively monitor what that vendor can reach" is exactly where attackers are building their careers right now. Third-party vendors (contractors, software providers, MSPs, and supply chain partners with privileged access) now account for 30% of all data breaches, double the rate from the prior year, according to Verizon's 2025 Data Breach Investigations Report. The financial stakes match the frequency: according to IBM's Cost of a Data Breach Report, the average third-party breach costs $4.91 million globally, and that number climbs higher in heavily regulated sectors like legal and financial services.

Here's what makes this complicated for professional services firms: your IT provider isn't just one vendor. They rely on their own stack of tools, platforms, and third-party services to manage your environment. When any link in that chain gets compromised, the exposure doesn't stop at your IT provider's door. It walks right through yours.

Table of Contents

1. How Vendor Trust Becomes Vendor Risk
2. The Blind Spot Problem: When Your Provider's Stack Is the Attack Surface
3. A Lesson From the Front Lines: Transparency as a Security Practice
4. What Professional Services Firms Need to Ask
5. Building a Vendor Security Framework That Actually Holds
6. When It's Time to Reassess Your IT Partnership
7. You Secured the Front Door. Now Check the Back One
8. Key Takeaways
9. Frequently Asked Questions

How Vendor Trust Becomes Vendor Risk

Trust is the engine that makes vendor relationships work. Your finance team processes invoices from your accounting software vendor without scrutinizing every line item the way they would a cold email from a stranger. Your IT team applies system updates from familiar platforms without treating each one like a potential intrusion. That's not laziness; it's how organizations function at scale.

Attackers understand this. When they want access to a well-defended organization, the path of least resistance is often not through the front door; it's through a vendor who already has a key.

A managed service provider's business model relies on vendor tooling, privileged access, and complete trust in their tech stack. Because of the elevated access MSPs have across their clients' environments, they're a particularly valuable target for cybercriminals. When threat groups gain access to a tool an MSP uses, compromise can spread quickly across every client that tool touches. The 2021 Kaseya VSA incident is the definitive case study: a malicious update delivered through a legitimate mechanism reached roughly 1,500 organizations worldwide through the MSPs who used the software.

What makes this model so effective for attackers is that the compromise itself is nearly invisible to the end organization. You didn't click a suspicious link. Nobody emailed a credential to the wrong address. A vendor your IT provider trusted used a tool you'd never heard of, that tool got compromised, and suddenly your environment is the blast radius of someone else's incident.

Supply chain phishing works on the same principle. Existing vendor relationships create blind spots that employees consistently overlook. Finance teams don't scrutinize invoices from familiar vendors the way they would suspicious cold emails. IT teams install urgent updates without question. The attacker doesn't need to impersonate a stranger; they inherit the trust the vendor already built.

The Blind Spot Problem: When Your Provider's Stack Is the Attack Surface

Here's the uncomfortable reality for most organizations: you can do everything right on your end and still end up in an incident report. That's because the attack surface isn't just your systems; it's every system your vendors and their vendors operate.

According to SecurityScorecard's 2025 Global Third-Party Breach Report, 35.5% of all breaches were third-party related, and 75% of those specifically targeted the software and technology supply chain. That's not a niche threat vector anymore. That's the primary one.

For professional services firms, this matters in a specific way. Your environment holds client confidential information, billing data, contracts, and, in many practices, personally identifiable information subject to state and federal privacy regulations. When your IT environment is compromised through a vendor, the exposure isn't limited to your systems; it extends to everything sitting inside them.

If your MSP operates with a small team, constrained resources, and limited telemetry, they may have reduced visibility over the upstream tools they rely on. And here's what most clients don't realize: you're probably assuming they have complete visibility into your environment when the reality is that upstream third-party platforms can create blind spots your IT provider can't easily mitigate from where they sit.

This isn't an indictment of any particular provider. It's a description of how the ecosystem is structured. Your IT provider uses endpoint monitoring tools, remote management platforms, identity management systems, ticketing software, and sometimes customer intelligence platforms. Each of those carries its own vendor relationships, update mechanisms, and access permissions. The security chain extends far beyond what most clients ever think to ask about.

The practical question isn't whether your IT provider is competent. It's whether both of you have visibility into the vendor risk that sits between them and the upstream tools they depend on.

A Lesson From the Front Lines: Transparency as a Security Practice

In mid-2026, Huntress (a cybersecurity company that protects MSPs and their clients) disclosed publicly that it had been affected by a supply chain breach involving Klue, a market intelligence platform Huntress used internally. The Icarus threat actor had compromised Klue and exfiltrated data from multiple downstream customers. Huntress was one of them.

What happened next is worth paying attention to.

Rather than waiting to be named in a third-party report or staying quiet until forced to respond, Huntress published a full disclosure blog within days. They shared what they knew about the Klue incident, what they knew about their own exposure, and what they knew about the threat actor. Their framing was direct: the cybersecurity industry sits within a fragile ecosystem where supply chain risk means any organization can be affected by upstream events without any fault of their own.

That kind of transparency is rare, and it's worth naming as a model for how vendor security incidents should be handled. Huntress wasn't compromised because of a failure in their core security practices. They were reached through a vendor they used for a business intelligence function, a different layer of their stack entirely from the security tools they're known for. The incident demonstrated something important: even organizations whose entire business model is built around cybersecurity can be exposed through a vendor relationship.

What Huntress did right was refuse to let that reality become a reason for silence. They disclosed promptly, shared indicators of compromise, engaged with affected parties, and continued updating their post as new information emerged.

For professional services organizations evaluating their IT providers, that behavior (not just the security controls, but the transparency and incident response posture) is worth asking about directly. How does your provider communicate when something goes wrong upstream? What's the notification protocol? How quickly would you know?

What Professional Services Firms Need to Ask

Most vendor security conversations between IT providers and their clients stay at the surface level: Is your SOC 2 current? Do you have cyber insurance? When was the last penetration test?

Those questions aren't wrong, but they're incomplete. They evaluate the vendor's security posture in isolation, without accounting for the upstream risks the vendor itself carries. Here are the questions that get closer to the real picture.

What tools does your MSP use to manage our environment, and what are the access levels for each? Remote monitoring and management platforms, endpoint detection tools, identity systems, ticketing software: each one should be on your radar. You don't need to audit every tool yourself, but you should know what's in the stack and what it touches in your environment.

How does your provider vet the vendors in their own stack? Do they require SOC 2 reports from their tools? Do they monitor for vendor security incidents in real time, or do they rely on vendors to self-report? Is there a formal third-party risk management process, or is it more informal?

What's the notification protocol if a vendor in their stack is compromised? Time matters in incident response. If your IT provider's remote management tool has a critical vulnerability actively being exploited, how quickly will you know? What's the communication chain?

How is vendor access scoped and limited? Least privilege is a principle that should apply to vendors as much as to employees. Tools used to manage your environment should have access to the specific systems and functions they need, not open-ended administrative permissions across everything.

What's the incident response plan for a supply chain event? High-profile incidents like Kaseya, SolarWinds, and 3CX have made supply chain response a core competency expectation. Your IT provider should have a documented approach for responding when a tool in their stack is compromised, not just when your environment is directly attacked.

These aren't adversarial questions. They're partnership questions, and a good IT provider will welcome them.

Building a Vendor Security Framework That Actually Holds

A vendor security framework doesn't need to be a 50-page document. For most professional services firms working with an MSP, it needs to accomplish three things: visibility, accountability, and response readiness.

Visibility means knowing what vendors have access to your environment, at what permission levels, and through what mechanisms. This includes both the vendors you've contracted with directly and the tools your IT provider operates on your behalf. An updated inventory isn't a one-time exercise; it needs to be maintained as the vendor ecosystem changes.

Accountability means making vendor security expectations explicit in your agreements. That includes notification timelines if a vendor in your provider's stack is compromised, disclosure requirements for material security incidents, and confirmation that your provider maintains their own vendor risk management practices. The goal isn't to hold vendors to an impossible standard; it's to ensure accountability is built into the relationship rather than assumed.

Response readiness means having a plan before you need one. If your IT provider's primary remote management tool went down tonight because of an active exploitation incident, what would happen? Who calls whom? What systems get isolated? What do you tell clients if their data may have been in the path of the breach? A 90-minute tabletop exercise with your IT provider once a year can surface gaps in the plan before an incident does it for you.

Security assessments for the vendors in your provider's stack should be an ongoing expectation, not a one-time onboarding checkbox. Monitoring for vendor security incidents shouldn't stop after contracts are signed and systems are integrated; it's an active, continuous practice in any environment that takes third-party risk seriously.

That's not a compliance requirement. It's what the organizations that have survived supply chain incidents learned the hard way.

When It's Time to Reassess Your IT Partnership

Not every IT provider approaches vendor security the same way, and the gap between providers who take it seriously and those who don't is wider than most clients realize.

Signs that the conversation needs to happen: your provider can't tell you what tools they use to manage your environment, or why. They don't have a clear answer on their own vendor risk management practices. They've never proactively raised a third-party security incident with you. Their incident response plan treats "a vendor we use got compromised" as someone else's problem.

Signs of a provider worth staying with: they can walk you through their stack, explain the access controls on each tool, and tell you what happens if any one of those tools is compromised. They notify you promptly when something upstream changes. They treat your questions about vendor risk as reasonable and answer them directly. And when something does go wrong in their ecosystem, you hear about it from them first.

The relationship between a professional services firm and its IT provider should function like any other trusted advisory relationship: candid, accountable, and built on information sharing rather than assumptions. Vendor security is one area where "we trust them" isn't a sufficient answer, no matter how long the relationship has been running.

If your current provider can't meet that bar, that's worth knowing. If they can, that's worth recognizing. Either way, the only way to find out is to ask.

You Secured the Front Door. Now Check the Back One

Vendor security blind spots aren't a sign that something is broken in your current IT relationship. They're a feature of how modern technology ecosystems are built: layered, interconnected, and increasingly difficult to fully audit from any single vantage point. What the Huntress disclosure demonstrated, and what years of supply chain compromise data confirm, is that no organization is immune to upstream exposure. The question isn't whether it can happen. It's whether you're positioned to know about it quickly and respond effectively when it does.

That's a different conversation than most firms are having with their IT providers right now. It requires moving past the surface-level security checklist and into the harder questions about stack transparency, vendor oversight, and incident response for events that don't originate inside your own walls. Those conversations aren't comfortable, but they're the ones that matter.

Heroic Technologies works with law firms and professional services organizations across Oregon, Washington, and California that treat technology as a strategic investment, not a cost center. Vendor security isn't a line item in their service model; it's built into how they manage every layer of the environment they're responsible for, including the tools they use to do it.

If you've never had the vendor security conversation with your current IT provider, there's no better time than before an incident makes it urgent for you. Reach out to the Heroic Technologies team to start the conversation.

Key Takeaways

• Third-party and vendor-related breaches now account for 30% of all cybersecurity incidents globally, double the rate from the prior year, according to Verizon's 2025 Data Breach Investigations Report.
• Your IT provider's vendor stack is part of your attack surface, whether or not you've ever seen a list of what's in it. The security chain extends well beyond the tools you've contracted for directly.
• Huntress's transparent disclosure of the Klue supply chain breach is a model for how IT providers should handle upstream incidents: prompt, detailed, and proactive rather than reactive.
• The right vendor security questions go beyond SOC 2 and cyber insurance. Focus on stack transparency, access scoping, notification protocols, and incident response for supply chain events specifically.
• A working vendor security framework covers three things: visibility into who has access to what, accountability built into contracts and agreements, and a tested response plan before you need it.
• Professional services firms carry elevated exposure because of the confidentiality obligations and regulatory requirements surrounding client data. Vendor risk isn't an IT problem; it's a business risk problem.
• "We trust our provider" isn't a vendor security strategy. Trust should be built on documented practices and clear communication, not assumptions.

Frequently Asked Questions

1. If my IT provider gets compromised through one of their tools, am I legally liable for my clients' data?
Potentially, yes. Your obligations to protect client data under applicable regulations don't pause because the breach originated with a third party. Courts and regulators evaluate whether you had reasonable safeguards in place, which includes how you vetted and monitored your IT provider. The fact that your provider was the proximate cause doesn't necessarily insulate you from downstream liability. Legal counsel familiar with data privacy law should be part of any incident response plan.

2. What's the difference between my IT provider's security posture and their vendor security posture?
Your provider's security posture covers how well they protect their own systems, staff, and operations. Their vendor security posture covers how well they manage the risk that flows in from the external tools and platforms they rely on to serve you. A provider can have strong internal controls but weak oversight of upstream tools, and that gap is exactly where many recent high-profile incidents have originated. Both matter, and it's worth asking about them separately.

3. How often should we revisit vendor security with our IT provider?
At a minimum, annually. But any time there's a material change in either party's technology stack, the conversation should happen again. That includes when your provider adds a major new tool to their environment, when there's a significant security incident affecting commonly used platforms, or when your firm adds new applications or data flows. An annual security review that explicitly covers upstream vendor risk is a reasonable expectation to build into any MSP relationship.