MSP security liability: why assumptions now cost you

MSP security liability is no longer a theoretical risk. There are rulings now in which the court holds the MSP responsible, not because something went wrong technically, but because the client was never demonstrably informed about the risks they were running. Six or seven years of assumptions are suddenly being weighed in legal terms. And that weighing rarely falls in favour of the party that said "we discussed that, surely".

You probably recognise the pattern. You told the client that MFA had to go on. You mentioned in a quarterly review that the backup strategy could be better. You sent three quotes for better endpoint protection. The client nodded, did not sign, and you moved on. Because there were fifty other tickets waiting.

The client, meanwhile, sits in a completely different frame. They pay an invoice every month and assume "it is sorted". What exactly is sorted, they do not know, and they are not interested either, until the moment there is ransomware on the file server. At that point the question is no longer about the threat. The question is who knew what, and above all: where is that written down.

That is the split many MSP owners are now running into. Advising, they have done for years. The duty of care is new. And the burden of proof for that duty of care sits firmly with the MSP, not with the client who "should have understood it anyway".

Proof is the new stack

What works in practice is a shift in what you record and when. Not another tool, not another dashboard for yourself. A client register that shows, per quarter: which risks were named, which choice the client made, and who signed off on that from the client side. That sounds bureaucratic and it is. But it is the difference between having an argument and having a file.

The MSPs that made this move over the past year have discovered something. The sales dynamic has flipped. Two years ago you had to push hard to sell an awareness training. Now the client asks you which evidence you can supply, because their insurer or their supply chain is asking for it. Whoever is ready with a standardised base package sells without a pitch.

What helps is a hard floor. No MFA, no client. No minimum awareness cycle, no contract. That feels harsh, but it is the only position from which you can still control your own liability. Every exception you make to win a client becomes, two years later, the exhibit showing that you did not enforce your own baseline.

Above that floor you offer layers. Frequency of checks, depth of monitoring, speed of response. That is where the client chooses. Below that floor they choose nothing, because then the model does not work. Compare it with the garage: if the brakes are gone, the car does not go back on the road, even if the owner says there is no budget.

From assumption to evidence file

The MSPs that have set this up properly do four things consistently. They hold a risk conversation with the client at least twice a year, not with the system administrator but with the board. They record the outcome in language the board itself understands, so not in CIS controls but in business impact. They have that outcome signed. And they take every deviation from the policy back to the same table, within thirty days.

That fourth point is where most stumble. Agreeing a policy in January and then doing nothing for a year is not a duty of care, that is an archive item. A client's reality changes weekly: a new employee, an MFA token switched off, a firewall rule that went out "just temporarily". If you as the MSP do not flag that to the board, you are the one who accepted the risk.

In practice this means making one person in your organisation the owner of that feedback cycle. Not a collective responsibility, because then it does not happen. Someone with a diary item every Monday: which exceptions are open, who approved them, and is that approval still valid. That costs half a day a week on a portfolio of fifty clients. That half day is the cheapest insurance you can buy.

Language is the real problem

The underrated factor in all of this is language. The average MSP talks about baselines, configurations and compliance frameworks. The solicitor, baker or care provider on the other side hears noise. And if the client does not understand your warning, that warning does not count legally as information. That is exactly where courts land.

Translate the risks into the client's business. For a law firm it is about client files and professional discipline. For the baker round the corner it is about till systems and payroll. For a care provider it is about patient data and the inspectorate. So the same technical finding needs three different explanations. That costs time, and that time has to sit in your service model, not in your consultant's margin. If you do not deliver that translation, you are no longer an MSP, you are a supplier of tools the client does not understand.

An average MSP works with somewhere between 40 and 50 tools. Every portal, every API, every update cycle. The temptation is to add another tool that promises "compliance" or "evidence". That is usually the wrong answer. The question is not which tool to add, but which three tools can go once you make a platform choice, and which hours you free up to genuinely hold those risk conversations twice a year. Proof is created at a table, not in a dashboard.

Inside a good risk conversation

A risk conversation that works does not take two hours and is not about technology. It covers three questions. What would come to a halt in this business if we were without systems for two weeks from tomorrow. Which data must never end up in the open, and who in the chain is watching that. And: which deviation from our standard policy has the board knowingly accepted in the past six months, and does that still stand. That is all the questions there are.

What you put back on the table is a single sheet. At the top the three biggest risks, ranked by impact on the client's revenue. In the middle the measures underneath them, with a status per measure: active, opened up at the client's request, or not purchased. At the bottom one line with the date, the name of the authorised signatory at the client, and a signature. No forty page annexe. No policy document nobody reads. One sheet somebody can pick up when it goes wrong, showing: this was discussed, this was chosen, this was accepted.

The MSPs that keep this up for a year notice two things. The clients who will not sign drop away by themselves, and in hindsight those are almost always the clients you had a gut feeling about already. And the clients who do sign become noticeably calmer in their ticket behaviour, because for the first time they understand what they can and cannot expect. The expectation gap that ate your margin for years closes.

The MSPs still standing in two years' time are not the ones with the most expensive security stack. They are the MSPs that have made their baseline non-negotiable, that schedule their risk conversations the way they schedule their patch cycles, and that dare to say a client who will not come along is better off elsewhere. In the MSP Late Night Performance Club, owners share exactly how they hold that conversation, which file they build, and where they let go of the clients who did not get it.