When Your Client's Comfort Becomes Your Risk

Every MSP owner has had that call. The one where you pick up the phone and something in the practice manager's voice tells you before they've said a word that it's not a good day.

Mine came about two weeks after we'd wrapped up a couple of upgrade projects for a medical clinic. Fifteen doctors, thirty staff, everything humming along nicely. Then the practice manager rang and said, quite simply, "We can't get into our system."

It was ransomware. Full crypto lockup.

Once we got in and had a proper look, the cause was almost embarrassingly simple. The clinic ran a terminal server that all the doctors logged into, because their clinical software setup required it. One of those doctor accounts had a compromised password. That was it. That was the whole point of failure.

We went straight to the practice manager and told him plainly, these passwords need to change, now. And he took it back to the doctors.

They refused.

Why the Obvious Fix Isn't Always the Easy One

Here's the bit that a lot of people outside the industry don't understand. It's rarely a technical problem stopping you from fixing a vulnerability. It's a people problem, and often it's a power problem.

These doctors were partners in the practice. Senior, successful, used to things working the way they wanted them to work. And a request to change their password felt, to them, like an inconvenience being imposed on them by someone who didn't understand how busy they were. They wanted their system to just work. Full stop. The idea that "how it works" and "how secure it is" were the same conversation hadn't landed with them at all.

So the passwords stayed simple. And we moved on, because what else can you do when the client says no.

Except the story wasn't over.

We were lucky in one respect. Just prior to all this, we'd finished implementing a proper disaster recovery solution for the clinic. When the ransomware hit, we were able to recover the entire system. They lost about an hour of work. No ransom paid, no patient records lost. It could have been so much worse, and the DR investment is genuinely the only reason it wasn't.

But a week later, another doctor's account was compromised.

Same weakness. Same warning we'd already given. Twice now, in the space of a few weeks, the exact vulnerability we'd flagged had been exploited.

Drawing the Line

That second breach is when we changed our approach. We didn't go back to the practice manager with another request. We went back with a condition.

We told him plainly that if these passwords didn't change, we could no longer look after their network. It was too risky for us to keep our name against a system we knew had an open door in it, especially after we'd already told them where the door was.

That's the conversation that finally worked. Not because the words were dramatically different to what we'd already said, but because this time there was a consequence attached to it. He took that back into the practice, and this time it landed. We rolled out complex passwords across the board, and pushed through multi-factor authentication on top of it, which at the time was still something of a fight to get MSP clients to adopt.

Looking back now, I think there's a lesson in how we handled the escalation too, not just in the security decision itself. We were dealing entirely through the practice manager. He believed us from day one. He understood the risk completely. But he didn't have the standing, in that room, to convince a group of senior partners to change their behaviour. He was the right messenger for operational things and the wrong messenger for this one.

If I had my time again, I'd have asked to present directly to the doctors myself. Not as an accusation, just as a straightforward explanation of what a compromised account could actually cost them, in a language that meant something to people who deal in risk and outcomes every day of their working lives. I think that conversation, had earlier and from the right person, would have saved us the second breach entirely.

The Principle Underneath It

There's a broader point here that applies well beyond one clinic and one terminal server, and it's the one I keep coming back to when I talk to MSP owners now.

You have to listen to your client. You have to be genuinely conscious of what they want and what pressures they're under. But there's a line where listening turns into compromising, and once you cross that line on your own security standards just to keep a client comfortable, you've stopped being the expert in the room. You've become someone who agrees with whoever's paying the invoice, regardless of whether they're right.

In this case, the standard we compromised on was something as basic as password complexity. It sounds almost too simple to have caused a full ransomware event, but that's exactly the point. The gaps that take a business down are rarely exotic. They're the basic things that got argued away because enforcing them was uncomfortable in the moment.

As the MSP, you're not just protecting your client. You're protecting yourself, your team, and every other client on your books whose risk profile is tied to how seriously you take your own standards. If you'll bend on the fundamentals for one client because they push back hard enough, you've told yourself, and eventually your whole business, that the standard was negotiable all along.

It wasn't ten years ago when this happened, and if anything the risk has shifted rather than disappeared. Most businesses run on SaaS platforms now rather than terminal servers, and multi-factor authentication is far more standard than it was. But the underlying dynamic hasn't changed one bit. There will always be a client who wants convenience over security, and there will always be a moment where enforcing your own principles feels like the harder path in the short term.

Take it anyway. It's a lot easier to have an uncomfortable conversation about passwords than it is to make the phone call telling a client their patient records are gone.

Connect

Clarity + Focus = Results

© 2026. All rights reserved.