Is Your MSP Actually Doing What the Contract Says?

Many organizations rely heavily on a managed service provider to handle user support, Microsoft 365, backups, patching, security tools, networking, and sometimes nearly the entire technology environment. That arrangement can work very well. It can also create a blind spot. I have seen leadership teams assume that because a service appears in an agreement or on an invoice, it is being performed in the way they expect. Sometimes it is. Sometimes the contract is vague, the work is only partially covered, or no one is checking the results. An MSP should be treated as an important business partner, but also as a vendor with contractual obligations.

Start with what was actually purchased

Terms such as “managed security,” “backup management,” and “patching” can mean very different things depending on the provider and the agreement. Backup management may mean the MSP receives an alert when a job fails. That does not necessarily include investigating every failure, testing restores, or confirming that all important systems are protected. Patching may cover supported Windows workstations but exclude servers, third-party applications, network devices, or specialized systems.

An MSP may call a service “security monitoring” because the software is installed. That does not tell you whether anyone is reviewing alerts after hours or what happens when the tool identifies a serious threat.

Leadership should not rely on the service name. The agreement, statement of work, and any attached service descriptions should make clear which systems and locations are covered, what work is included, how often it is performed, what reporting is provided, and what remains the customer’s responsibility. When those details are missing, different people tend to fill in the blanks differently. That is usually where trouble begins.

Ask for evidence, not reassurance

There is nothing unreasonable about asking an MSP to demonstrate that important services are being delivered. For patching, that may include compliance reports and a list of devices that repeatedly fail. For backups, it may include job results, unresolved failures, protected systems, retention settings, and evidence of restore testing.

For endpoint security, it may include deployment coverage, inactive agents, unresolved alerts, and confirmation that someone is responsible for reviewing the platform.

For Microsoft 365, ask for privileged account reviews, licensing records, significant administrative changes, identity-control settings, and a list of unresolved security recommendations.

The purpose is not to second-guess every technical decision. It is to make sure the organization is receiving what it is paying for and that important failures are visible.

A green dashboard is not always enough. A backup can report success while excluding a critical folder. A security agent can be installed but disconnected. A patching platform can show a high overall percentage while a handful of important servers remain months behind. I have reviewed environments where the patching numbers looked excellent overall, but the few systems missing updates included some of the most important servers in the business. Reports need context.

Clarify who owns what

One of the most common problems in an MSP relationship is not poor intent. It is unclear ownership. The MSP may believe the customer is responsible for approving a change. The customer may believe the MSP is handling it automatically. A security recommendation may remain open because no one knows who has the authority, budget, or technical responsibility to act. This happens often with vulnerability remediation, firewall changes, restore testing, privileged access, unsupported systems, vendor coordination, incident response, cyber insurance controls, and compliance evidence.

These responsibilities should be assigned deliberately. Some belong to the MSP. Some belong to internal leadership. Some are shared. Shared responsibility does not mean unclear responsibility. It should still be possible to identify who performs the work, who approves major changes, who verifies the outcome, and who accepts the risk when action is deferred.

Review insurance and compliance statements carefully

This deserves particular attention. MSPs often help organizations answer cyber insurance questionnaires, customer security reviews, or compliance assessments. They may provide the technical information, but the organization is still responsible for the accuracy of the final response.

If an application states that multifactor authentication is enforced, backups are regularly tested, endpoint detection is monitored, or critical vulnerabilities are remediated within a defined period, those statements should be verified. It is not enough that a tool was purchased or that a control exists somewhere in the environment. The control has to work the way the answer says it works, and it has to keep working that way.

An inaccurate insurance response can create a coverage dispute after an incident. A weak customer response can create contractual exposure. A compliance claim without supporting evidence can fail under review. These answers are business representations, not just technical paperwork someone needs to finish.

Good MSPs should not resist reasonable oversight

Accountability does not require an adversarial relationship. A capable MSP should be able to explain its responsibilities, produce useful reports, identify exclusions, and discuss areas where the customer needs to make a decision. Clear oversight often improves the relationship because both sides are working from the same expectations.

Warning signs include recurring failures with no documented resolution, reports that show activity but not outcomes, incomplete asset records, unclear service boundaries, repeated surprises about what is not covered, and resistance when leadership asks for evidence.

An MSP can operate the technology. It cannot replace the organization’s responsibility to oversee technology risk. Someone on the customer side still needs to compare the contract with actual performance, connect technical issues to business priorities, and make sure unresolved risks reach the right level of leadership.

Trust is important. Verification is part of maintaining that trust.