The Security Gaps Nobody Owns

I've spent a lot of my career around MSPs, and I think there's a disconnect in our industry that we don't talk about enough.

Ask an MSP what they manage for a customer and you'll probably get a fairly specific answer involving endpoints, Microsoft 365, backups, patching, security tools, monitoring, and whatever is covered by the agreement. Ask the customer the same question and you'll usually get something much simpler: "They handle our IT and security."

That's where the ownership problem starts.

The customer isn't thinking about which tool handles which piece of their environment or what was included in the last contract renewal. They bought an outcome. In their mind, someone has this stuff handled.

Meanwhile, the MSP may have a very different definition of what "handled" actually means.

We Get Really Good at Managing What Makes Noise

MSPs are incredibly good at responding to pain. Email goes down, there's a ticket. A backup fails, there's an alert. The VPN stops working, somebody calls. Naturally, we build processes, SOPs, automation, monitoring, and accountability around the things that generate noise.

Security has a nasty habit of failing quietly.

Nobody opens a ticket because SMB signing isn't enforced. Nobody calls because a workstation drifted from its approved security baseline. Nobody complains because a technician disabled a security control while troubleshooting something and never turned it back on.

Everything still works, and that's the problem. A lot of security problems don't hurt until they really f@#$ing hurt.

Managed Doesn't Always Mean Owned

Imagine a customer asks, "Are all of our workstations securely configured?"

Maybe Intune pushes some policies, Group Policy handles others, your RMM runs a few scripts, Defender handles another piece, and a vulnerability platform reports what it finds. There might be five different tools capable of touching the answer, but who actually owns it?

Who defines what securely configured means? Who verifies those settings actually landed? Who notices when they change? Who determines whether the change was intentional? Most importantly, who makes sure it gets corrected?

Tools give you capability. Ownership turns that capability into an outcome.

Then There's the Part We Don't Like Talking About

Sometimes the MSP knows there's a gap.

I've been around enough MSP conversations to hear versions of these: "We'll address that at the next contract renewal." "We don't want to rock the boat with this customer." "They aren't going to pay for that." "That's technically outside our scope." "Nothing has happened yet." "Let's wait until the QBR." "We've always done it this way for them."

And probably the most dangerous one: "If we bring this up, they're going to ask why we weren't already doing it."

None of those statements necessarily come from a bad place. Sometimes there are legitimate contractual boundaries. Sometimes the customer has rejected the recommendation before. Sometimes the MSP can't absorb another responsibility for free. Sometimes you really don't want to blow up a healthy relationship over something that needs a thoughtful conversation.

The problem is what happens next.

Six months pass. Then a year. The contract gets renewed and nobody remembers the conversation. The engineer who noticed the gap moves on. The customer continues believing their MSP is handling security, while the MSP continues operating under the assumption that this particular thing isn't their responsibility.

The temporary business decision quietly becomes a permanent security decision.

That's where we drop the ball.

The Customer Doesn't Know What They Don't Know

This is why I don't think the answer is simply making MSPs responsible for everything. That's impossible, and it isn't fair to the MSP.

The answer is making ownership painfully clear.

If you own something, own the outcome. If you don't own something, make damn sure the customer understands that you don't.

Because there's a huge difference between "We identified this risk, explained it to the customer, and they chose to accept it" and "We knew about it, but decided not to rock the boat."

One is documented risk acceptance. The other is an assumption.

And assumptions get particularly ugly after an incident.

That's when the MSP says, "That wasn't included in your agreement."

And the customer responds, "What do you mean? I thought you guys handled our security."

Technically, the MSP might be completely right. But if that's the first time the customer discovers nobody owned that risk, something went wrong long before the incident.

So How Do You Fix This Without Boiling the Ocean?

I think it starts with a customer first culture.

At a previous MSP I worked for (Shout out to Etop Technology), we built a simple process around this called "See Something, Say Something."

The idea was incredibly simple: if you saw anything during your normal day that didn't look right, you said something.

It didn't matter whether we sold the product. It didn't matter whether fixing it was included in the agreement. It didn't even matter whether it technically sat inside our little box of "ownership."

If an engineer noticed something that concerned them, they created a SSSS ticket and routed it to the client's account owner for review.

That was it.

We weren't asking every engineer to boil the ocean. We weren't telling technicians to turn every observation into a four hour investigation. And we definitely weren't saying the MSP now had to fix everything it found for free.

We were simply making sure that noticing something and owning something were two different things.

The engineer's responsibility was to raise their hand. The account owner's responsibility was to decide what happened next.

Maybe we fixed it. Maybe it became a project. Maybe it turned into a conversation at the next client meeting. Maybe another vendor owned it. Maybe the customer understood the risk and chose to accept it.

But it didn't quietly disappear because "that's not our responsibility."

And that simple process did a few really valuable things.

It gave us more legitimate reasons to connect with our customers. It surfaced issues that would normally have been ignored because they didn't generate tickets. It made security something we practiced during normal operations instead of something we talked about once a quarter.

But most importantly, it positioned us as the manager of the business outcome the customer thought they were paying us for in the first place.

There's a big difference between saying "That's not ours" and saying "That's not something we currently manage, but we noticed it, and we think you should know about it."

That second sentence is what being a trusted advisor actually looks like.

Maybe We're Asking the Wrong Question

We spend a lot of time asking MSPs, "What's in your security stack?" Maybe we should spend more time asking, "What does your customer think you own, what do you actually own, and what's sitting between those two?"

Some of those gaps should become projects. Some should become new services. Some belong to another provider. Some risks the customer may knowingly choose to accept. That's all completely reasonable.

The MSP doesn't have to own everything.

But somebody should own making sure the customer knows about it.

Because your biggest security gap might not be something missing from your stack. It might be something one of your engineers noticed six months ago, assumed wasn't their responsibility, and walked past.

See something.

Say something.

Then let the business decide what to do about it.