Skip to content

Resource

What should a managed IT provider actually handle?

Closing tickets is the floor, not the offer. Real managed IT covers the system, not just the symptoms.

The list, written plainly.

Most managed IT agreements cover helpdesk support. That's where the description usually starts and, for a lot of providers, where it effectively ends. If the same issues keep coming back and leadership still can't get a straight answer about security, backups, or Microsoft 365, the relationship is probably covering less than it should.

Here is what a managed IT provider should actually own.

Day-to-day support with root-cause follow-through

When something breaks, it gets fixed. When the same thing keeps breaking, someone finds out why. Closing the ticket is the minimum. Understanding the condition that produced it is the job.

Endpoint and patch management

Every device on the network running current patches, monitored for health, and replaced before failure becomes an emergency. This is the baseline that prevents most of what breaks.

Identity and access management

Who has access to what, reviewed on a schedule. MFA enforced across every account. Former employees offboarded the day they leave, not when someone remembers to ask. Access that was set up once and never reviewed is one of the most common sources of security exposure in mid-size environments.

Microsoft 365 managed against a written standard

Sharing permissions, mailbox rules, external access, admin separation, and licensing. Configured and maintained against a documented baseline. Most Microsoft 365 tenants have settings that were configured at setup and never revisited. That gap grows every time someone joins, leaves, or a new feature gets enabled by default.

Backup and recovery with real restore testing

A backup that runs is not the same as a backup that works. Recovery has to be tested, documented, and owned by someone before an incident makes the test mandatory. The question isn't whether backups are happening. It's whether the business can actually recover and how long that takes.

Monitoring with humans behind the alerts

Automated monitoring catches conditions. Someone has to evaluate what they mean and act on the ones that matter. An alert that fires into a queue and gets triaged two days later isn't monitoring. It's a log.

Vendor coordination

ISPs, line-of-business applications, copiers, phones, cloud platforms. Every vendor that touches the environment. When a vendor has a problem, the managed IT provider owns the coordination. The business isn't stuck in the middle between two vendors who each think it's the other's problem.

Security built into the operating standard

Endpoint protection, email security, network controls, and a cybersecurity baseline aligned to a recognized framework. Not added at renewal as an upsell. Not optional. Part of how the environment is managed from the start.

Documentation that is current

Network diagrams, system configurations, vendor contacts, credentials, and recovery procedures. Documented, maintained, and accessible when needed. An environment that exists only in the memory of the person who built it is not managed. It's borrowed time.

Lifecycle and budget planning

Hardware ages. Software versions go end of life. Licenses change. A managed IT provider surfaces these things in time to plan for them, not in time to panic when they become emergencies. Leadership should know what's coming before it arrives.

Understanding the scope of work a managed IT provider should own

This isn't our opinion. It's the standard.

You shouldn't have to take a provider's word for what managed IT should include. The list above reflects what the managed IT industry has established as the professional baseline. And what recognized security frameworks identify as the controls every business environment needs to have in place.

CIS Controls, the framework we align to, defines the specific security and operational practices that reduce risk in business environments. Most of the items on that list map directly to CIS implementation groups that apply to businesses in the 25 to 250 employee range. Patch management, access control, data recovery, audit logging. These aren't preferences. They're documented controls with a body of evidence behind them.

There's also a professional standard for what it means to call yourself a managed service provider. Industry organizations that represent MSPs have worked to define the baseline of what managed IT should include. Because the label has been applied loosely enough that it covers everything from a one-person break-fix operation to a fully structured managed environment. That distinction matters when you're evaluating who is actually accountable for your environment.

When a provider says they manage IT to a standard, ask what standard. The answer should be specific, documented, and independent of what's easiest or most profitable for the provider to deliver. If the answer is vague, that tells you something.

Why each of these matters when it's missing.

Every item on that list represents a condition that accumulates when nobody is managing it.

Endpoints that aren't patched become entry points. Access that isn't reviewed stays open after people leave. Backups that aren't tested fail when production is down. Vendors that aren't coordinated produce finger-pointing instead of resolution. Documentation that doesn't exist makes every incident harder and every transition more expensive.

None of these failures are dramatic on their own. They accumulate. By the time something forces the issue, an incident, an insurance renewal, a client security questionnaire, the gap between what's in place and what should be in place is usually larger than anyone realized.

The business consequence isn't always visible until it is. A former employee with active credentials isn't a problem until it is. A backup that was never tested isn't a problem until recovery is needed. A Microsoft 365 tenant with settings nobody has reviewed isn't a problem until a client asks who has access to their files.

You shouldn't have to find out what's missing the hard way.

How to verify a provider is actually doing these things.

A provider can claim to manage all of the above. Claims are easy. Evidence is harder.

Ask for documentation. A managed IT provider should be able to show you a network diagram, a current asset inventory, a patch status report, and a backup test log. If those don't exist or can't be produced quickly, the environment isn't being managed to a standard.

Ask who is accountable for each area. Not the company. The person or team. "We handle that" is not an answer. "This is the person responsible for reviewing access quarterly and here is how that gets reported" is.

Ask what changed in the last 90 days. A provider who is actively managing the environment can tell you what was patched, what was replaced, what access was reviewed, and what's coming up next quarter. One who can't answer that question hasn't been looking.

Ask what security looks like. If the answer involves an upsell or a separate agreement, security is not part of the operating model. It's a product being sold alongside it.

Ask for a reference from a client who has been with them for more than three years. Retention is the most honest signal about whether the relationship holds up after the sale.

What it is not.

It is not a reactive help desk. Responding to problems is part of the job. It is not the whole job.

A managed IT provider is accountable for the full environment - not just the issues that generate tickets, not just the systems that are easy to support, and not just the relationship when nothing complicated comes up. The difference between reactive support and managed IT isn't the response time. It's whether someone is looking at the full picture before something forces them to.

If you're not sure whether your current provider is covering the full picture, that's exactly what an IT Environment Review is for. We look at what's actually in place, compare it against the standard, and give you a clear answer - whether you're working with us or not.

Schedule an IT Environment Review

Common questions

Questions leadership usually asks first.

Next step

Get a clearer view of your IT environment.

Find out what is working, where the risks are, and what needs attention next.