A lot of small businesses and nonprofits believe they have already solved their security problem, because they pay a managed service provider to handle their IT. That belief feels reasonable. It is also, in most cases, only partly true, and the gap between what an MSP actually does and what an organization assumes an MSP does is where a lot of real exposure quietly lives.
This is not a criticism of MSPs. Most are competent, honest partners doing exactly what their contract describes. The problem is that the contract and the assumption are usually two different documents, and almost nobody reads the first one closely enough to notice.
"IT support" and "security" are related but different jobs. An MSP focused on keeping your systems running will patch software, manage your network, and resolve technical issues. That is valuable work, and it is not the same as monitoring for intrusions, enforcing MFA across every account, reviewing who has access to what, or having a tested incident response plan ready if something goes wrong.
Some MSPs bundle real security services into their offering. Many do not, or offer it as an upsell that was never discussed at signing. The only way to know which kind of relationship you have is to read the actual scope of work in your contract, not the sales conversation that preceded it.
The two incidents that opened this series make the point directly. Kaseya was a well-established software vendor serving thousands of managed service providers when a vulnerability in its platform became the delivery mechanism for ransomware at up to 1,500 downstream small businesses. Blackbaud was, and remains, one of the largest and most trusted names in nonprofit fundraising software when a 2020 breach exposed data belonging to more than 536 organizations and roughly 13 million people.
Neither vendor was small, careless, or unsophisticated. Both were breached anyway. Vendor size tells you something about their resources to respond to an incident. It tells you very little about whether an incident will happen, and it tells you nothing about how many other organizations will be affected alongside you when it does.
When a vendor holding your donor or client data is breached, most state breach notification laws still put the obligation to notify affected individuals on the organization that had the direct relationship with them, which is you, not on the vendor that actually lost the data. The nonprofits affected by the Blackbaud breach found this out directly: they had to notify their own donors, manage the fallout with their own boards, and answer their own donors' questions, based on information a vendor controlled and disclosed on its own timeline.
A well-negotiated contract can include indemnification clauses that shift some financial cost back to the vendor. Almost none can shift the operational burden of managing the response, or the trust damage of your name being in the breach notification your donors receive.
It is true that a twelve-person nonprofit is not going to negotiate custom security terms with a major cloud provider. But most of the vendors a small organization actually signs with are not hyperscale platforms. They are regional MSPs, niche SaaS tools, and mid-sized software companies that compete for every customer they can get. Those vendors will often answer direct questions, add a notification clause, or clarify a data deletion commitment simply because a prospective customer asked.
Even with the platforms where you genuinely have no negotiating power, the shared responsibility model still gives you real control. Whether MFA is enforced for your users, how access is provisioned and removed, and what data you choose to put into the platform in the first place are almost always decisions you make, not the vendor.
What these myths have in common
Each of these beliefs shifts responsibility somewhere else: to the vendor, to the MSP, to the contract's fine print, to a sense of powerlessness that feels realistic but is rarely tested. None of that is malicious or even unreasonable on its face. It is simply what happens when nobody has explicitly claimed ownership of vendor risk, so it defaults to nobody.
A note for leadership and boards
If your organization outsources IT or relies on a small number of critical vendors, and most do, this is a governance question as much as a technical one. Someone in leadership should be able to answer, in plain language, what your MSP is actually responsible for, and what falls back to you if they are not. If nobody can answer that today, it belongs on the agenda for your next leadership or board conversation, which is exactly where the final post in this series picks up.
Not sure what your MSP contract actually covers?
A 30-day Security Business Review includes a plain-language read of your current vendor and MSP agreements, so you know exactly where the coverage ends and your exposure begins.
Start a Conversation