Does your MSP need a written information security program?

Ask a managed IT provider whether a client needs a written security policy and the answer comes fast: yes, obviously, here is why, here is what it should cover. Ask the same provider whether their own business has one, and the pace changes. Most don’t — not because they don’t know what belongs in it, but because writing policy for the business that writes everyone else’s IT strategy always loses to the queue of paying tickets.

That gap used to be private. It is becoming visible, for three separate reasons that are each showing up in a different part of an MSP’s year.

Your own renewal is starting to ask

Cyber and tech E&O underwriters have spent the last few renewal cycles tightening what they expect from MSPs specifically, not just from the small businesses MSPs support. The pattern shows up consistently in what carriers now check: MFA enforced on every account that reaches a client environment, including technician and RMM accounts; named logins rather than shared ones; role-based limits on who can push scripts or deploy changes; audit logging that is actually retained; and — the one that catches people out — contract language (usually in the MSA) that states plainly where the MSP’s responsibility for a client’s environment ends and the client’s own begins.

None of that is unreasonable. An MSP with standing access into dozens of client networks is, from an underwriting standpoint, a single point of failure with a much larger blast radius than any one client — which is exactly the profile that gets a renewal application read more closely than it used to be. A security policy you sell the idea of to every client but never had to produce for your own business is the specific gap that reading now finds.

You may be a HIPAA business associate, whether or not IT is your specialty

This one surprises MSPs who don’t think of themselves as a healthcare vendor. HIPAA’s business associate definition doesn’t ask what your business is — it asks what you can reach. If any client is a healthcare practice and your access touches clinical systems, hosting, backups, or anything else that stores or transmits patient information, you can be a business associate under the Security Rule regardless of what your service agreement calls you. That status carries its own duties, separate from anything you owe the client contractually.

The honest answer for a lot of MSPs is “not sure” — client rosters change, and a business associate determination is a role, not something you opt into. Where it isn’t confirmed, the right move is to say so and check, not to guess in either direction: assuming you’re covered when you aren’t is a real gap left unaddressed, and assuming you aren’t when you are means missing a duty that applies whether you noticed it or not.

You’re the vendor in someone else’s questionnaire

Every MSP builds the answer to a client’s “who manages this?” row — that’s a normal part of responding to a client’s own security review or cyber insurance renewal. What’s newer is how often the MSP itself gets named as a subcontractor further up the chain: a client’s bigger customer, or that client’s own carrier, pushes a security review down through the client to whoever has access to their systems, and the MSP is the row with no matching document of its own to hand back. Being asked and having nothing written down reads very differently from being asked and handing over a policy that says exactly what’s in place and what isn’t.

What a written program actually needs to say, for an MSP specifically

The content is not exotic — it is the same shape of document an MSP already recommends to clients, pointed inward instead of outward. The parts that matter most for this particular business:

• Access control for every tool that reaches a client environment — RMM, PSA, remote access — named accounts, MFA, and a real cadence for reviewing who still needs what.
• A stated boundary between MSP and client responsibility, matching whatever the MSA actually says, so the policy and the contract tell the same story rather than two different ones.
• An incident response plan that covers the case where the incident starts on the MSP’s side and spreads — who gets notified, how fast, and by whom — which is a different and harder scenario than a single client’s own plan needs to cover.
• Honest gaps. An MSP’s own policy claiming controls it doesn’t have is a worse document than none: it’s a written record pointing the wrong way, from the one business in the relationship that’s supposed to know better.

What it doesn’t do

A written program is documentation, not a determination. It doesn’t decide whether you’re a HIPAA business associate for a given client — that depends on the access you actually hold, and is worth confirming rather than assuming either way. It doesn’t rewrite what your MSA already says about splitting responsibility with a client; if the two disagree, the contract is the one that governs. And having it doesn’t make you compliant, certified, or covered by any carrier — it’s one input an underwriter or client reads, not the whole answer.

This is the situation Coverwright’s MSP path was built for. The same set of plain-English questions produces a written security program, an incident response plan, and — where a client relationship might make you a business associate but that isn’t confirmed — a document that says so honestly instead of guessing, with a remediation clause anywhere a control isn’t in place yet rather than a claim that it is.