Where MSPs Get Stuck

A healthcare client passes their HIPAA audit with flying colours. The documentation is thorough, the attestations are signed, the policies are in the right folder. Six weeks later, a phishing email lands in a shared inbox. A staff member clicks it. Credentials are harvested. The attacker moves laterally through a flat network for four days before anyone notices.

The client was compliant. They were not secure. And the MSP who helped them achieve compliance has to answer some very difficult questions.

This gap — between meeting a framework’s requirements on paper and actually being protected against real threats — is one of the most persistent problems in managed IT security. It is also one of the places where MSPs get most stuck, because compliance is measurable, billable, and satisfying to deliver, while actual security is harder to define, harder to sell, and significantly harder to maintain.

The problem is not that compliance is worthless. It is that compliance is the floor, not the ceiling. And too many MSPs — and their clients — are treating the floor as if it were the roof.

1. Why Compliance Feels Like Security (But Is Not)

Compliance frameworks — HIPAA, PCI-DSS, ISO 27001, NIST CSF, SOC 2, CMMC — exist for a reason. They codify minimum standards of practice that, if followed consistently, genuinely reduce risk. They are not useless. They were written by people who understand security.

But they have a fundamental structural limitation: they are written for broad applicability, audited at a point in time, and designed to prove that something existed — not that it worked.

The evidence is stark. 82% of companies that achieved compliance with major regulations still experienced a data breach within the following year. Compliance passed the audit. The breach happened anyway. Because compliance asks: ‘Did the policy exist?’ Real security asks: ‘Did the control actually work when an attacker tried to bypass it?’

The distance between those two questions is where breaches happen.

The Checkbox Trap Compliance: MFA policy documented and attested. → Reality: 12 service accounts still using passwords only. Attackers know this. Compliance: Patch management policy in place, quarterly scans completed. → Reality: Three critical CVEs from the CISA Known Exploited Vulnerabilities list unpatched for 47 days. Compliance: Incident response plan exists and staff have been briefed. → Reality: Last tabletop exercise was 22 months ago. The escalation contact left the company 8 months ago. Nobody updated the plan. Each of these passes an audit. None of them stop an attacker who has done basic reconnaissance.

2. Where MSPs Get Stuck — The Four Patterns

Pattern 1: Compliance as the Product

Some MSPs have built their security practice around delivering compliance outcomes: help clients pass audits, generate the documentation, manage the evidence collection, prepare for assessments. This is a legitimate and valuable service. The problem arises when compliance delivery crowds out actual security work — when the engineering effort goes into evidence generation rather than control effectiveness.

A client with a thick compliance binder and a flat network, no behavioural monitoring, and MFA enforcement gaps is not better protected than a client with simpler documentation and genuinely enforced controls. The binder does not stop the attack.

Pattern 2: Conflating Documentation with Enforcement

This is the most common individual control failure in compliance-first environments. A policy is written. Staff attest to having read it. The audit is satisfied. But the policy is not technically enforced — it depends on users following it voluntarily, which they often do not.

MFA is the clearest example. A ‘mandatory MFA policy’ that is not enforced by Conditional Access or identity provider controls is not actually mandatory. It is aspirational documentation. The gap between the document and the technical enforcement is exactly the gap attackers look for.

Pattern 3: Treating Compliance as a Destination

Compliance has a cadence — annual audits, quarterly scans, yearly policy reviews. This creates the impression that security is something you achieve and then maintain at a steady state. Real security is not like that. Threat actors evolve their techniques weekly. New vulnerabilities are published daily. A control that was effective six months ago may be ineffective against a technique that appeared last month.

The MSPs that protect clients well treat security as a continuous operational discipline, not a project with a completion date. The compliance calendar is one input. The threat intelligence picture, the client’s evolving environment, and the current state of their controls are equally important — and they do not wait for the annual audit cycle.

Pattern 4: Selling Compliance as Security to Clients

This one is commercially uncomfortable to acknowledge, but it is real. Compliance is easier to sell than security. It has a clear deliverable, a defined endpoint, and a certificate or report at the end that clients can show to their stakeholders. Security outcomes are harder to quantify and harder to explain.

The result is that some MSPs sell compliance programmes under security language — ‘we will make you HIPAA compliant, which means your data is protected’ — when the honest version is ‘we will help you meet the regulatory standard, which is a starting point for protection, not a guarantee of it.’ Clients who believe they are protected because they are compliant are clients who will be genuinely surprised when an incident occurs. And that surprise lands on the MSP.

3. What the Difference Looks Like in Practice

Dimension	Compliance Focus	Actual Security Focus
Question it answers	‘Are we meeting the standard?’ — a point-in-time snapshot reviewed at audit.	‘Are we actually protected?’ — a continuous, evolving assessment of real risk.
Time horizon	Backward-looking. Evidence is gathered to prove what happened during the audit period.	Forward-looking. Controls are designed to prevent what has not happened yet.
Standard it measures against	A regulatory framework (HIPAA, PCI-DSS, ISO 27001, NIST) written for general applicability.	The specific threat landscape facing this client, in this industry, with this infrastructure.
MFA enforcement	Documented: ‘MFA policy exists and is attested to by staff.’	Operational: MFA is enforced on every account, with Conditional Access blocking non-compliant devices.
Patch management	Policy documented, audit evidence of patches applied, quarterly scanning completed.	Every critical CVE patched within defined window, tracked against CISA KEV, no known-exploited vulnerabilities outstanding.
Incident response	IR plan exists, has been reviewed, staff are aware it exists.	IR plan has been tested in a tabletop exercise, escalation paths are validated, runbooks are current.
What passes the audit	Good documentation. Evidence of controls existing. Policy attestations.	Effective risk reduction. Adversaries cannot easily exploit what the framework was designed to protect.

Compliance focus vs. actual security focus — the operational difference across seven dimensions

The last row in that table is the one worth sitting with. What passes the audit is documentation and policy evidence. What actually reduces risk is whether an attacker can succeed. Those are different tests. A mature MSP designs controls to pass the second test, and treats the first as the by-product.

4. How to Unstick the Compliance vs. Security Conversation

The path forward is not to deprioritise compliance. It is to position compliance correctly — as the baseline that real security is built on top of, not the ceiling that defines how secure the client is.

Practically, this means:

• Be explicit with clients about what compliance does and does not guarantee: A compliant organisation is one that has met a defined standard. That standard does not adapt to the specific threat actors targeting their industry. Honest framing builds more trust long-term than a compliance certificate that later feels hollow.
• Enforce controls technically, not just documentarily: MFA should be enforced by the identity platform. Patch windows should be automated and tracked against real vulnerability data. Backup testing should generate a record. The control should be provable without relying on staff to follow policy voluntarily.
• Test controls, do not just review them: Tabletop exercises for incident response. Simulated phishing for user awareness. Periodic assumption-of-breach testing that asks: if an attacker had a foothold in this environment right now, what would they be able to do? The answers are often uncomfortable — and always useful.
• Separate the compliance programme from the security programme in your service design: Compliance support is a service. Continuous security operations — monitoring, detection, response, hunting — is a different service. Clients who buy one should understand clearly what they are and are not getting from each.

The MSPs who navigate this well tend to describe compliance and security as a sequence rather than synonyms. Compliance first — because the regulator requires it and clients need it for their contracts. Then security on top of that baseline — because compliance is where you start, not where you stop.

The Bottom Line

A passed audit is not a promise of protection. It is proof that, at a given point in time, a set of documented controls existed. Attackers do not check audit reports before choosing their targets. They look for gaps — in MFA enforcement, in patch cadence, in monitoring coverage, in flat networks where one compromised account becomes a free pass to everything.

The MSPs who are genuinely protecting clients are the ones who have stopped treating compliance as the goal and started treating it as the starting line. The gap between the two is where they earn their keep — and where the clients who experience incidents wish their providers had been working all along.

About TechMonarch TechMonarch provides white-label Managed IT, NOC, and SOC services to MSPs globally. The continuous monitoring, detection, and response work we do is the security layer that sits above the compliance baseline — the operational discipline that compliance frameworks describe but do not deliver on their own. If you want to talk about what that looks like for your clients, we are easy to reach. Get in touch: www.techmonarch.com