Choosing an IT partner is different in 2026 because you are not just buying support. You are deciding who will help run, secure and govern part of your business.

For a 10 to 25 seat SME, that decision now carries more weight than it used to. Most businesses are already reliant on Microsoft 365, cloud-managed devices, third-party software and outsourced expertise. That means the quality of your IT partner is no longer just about responsiveness. It is about ownership, control and evidence.

A good provider should be able to show exactly what they manage, how they manage it, what they require from clients, and how they reduce avoidable ambiguity. If they cannot do that, the relationship may feel helpful day to day, but still leave you exposed when something breaks, drifts or falls between suppliers.

This article is not about what an MSP is. It is about how to evaluate whether an IT partner is actually fit to run a secure, standardised and accountable environment in 2026.

The key evaluation question: who owns the baseline?

Start here.

Before you compare service desks, pricing models or response times, ask a simpler question: who owns the baseline?

In practice, the baseline is the minimum acceptable state of your environment. For most SMEs, that means identity, user access, device setup, patching, malware protection, backup, monitoring and day-to-day administrative control. If nobody clearly owns that baseline, you do not really have managed IT. You have shared assumptions.

This is why “we can support whatever you have” is not always a reassuring answer. It may sound flexible, but it often means the provider has no defined target state and no clear way to judge whether your environment is secure, supportable or drifting.

A stronger answer sounds more like this: these are the controls we take responsibility for, these are the standards we work to, these are the conditions for support, and this is how we track whether the baseline is being maintained.

That is the foundation of a governed relationship. Without it, accountability becomes vague very quickly.

What should be standardised

Standardisation is one of the clearest signs that a provider can run an environment properly.

This does not mean every client must look identical. It means the provider should have a standard way of handling the parts of the estate that should not be left to chance. That usually includes user identity, device configuration, patching, endpoint protection, backup coverage, monitoring, admin roles, and joiner and leaver processes.

Why does this matter? Because standardisation affects three things at once.

It improves support, because engineers are not inheriting dozens of one-off setups and undocumented exceptions. It improves security, because the same core controls are being applied consistently rather than selectively. And it improves reporting, because it is much easier to measure the health of an estate when the basics are not different in every corner of the business.

When a provider cannot explain what is standardised, it is usually a sign that too much of the service depends on inherited setups, local workarounds and individual engineer memory. That may feel accommodating at first. Over time, it usually creates drift.

What should be mandatory vs optional

This is one of the easiest ways to separate a mature provider from a vague one.

Not everything needs to be mandatory. Some things will always vary by business. But the controls that make an SME supportable and recoverable should not sit in a grey area.

As a buyer, you should be able to ask: what is required as part of the managed environment, and what is genuinely optional?

That matters because some decisions should not be left hanging. If patching, backup, security monitoring, access controls or core device management are treated as add-ons in practice, you may end up with a service relationship where responsibility is fragmented from the start.

A good provider should draw a clean line. They should be able to explain which controls are part of the baseline they will not compromise on, and which additional services sit outside that baseline. The point is not rigidity for its own sake. The point is to avoid a situation where key protections become negotiable and accountability becomes blurred.

What good onboarding should look like

Onboarding is where a provider shows whether they can move from promise to control.

A weak onboarding process usually looks like basic access setup, a few introductory calls and an informal promise to “pick things up as we go”. A strong onboarding process is more deliberate. It should begin with discovery, establish the current state, identify risks, clarify ownership and move the environment toward a supportable standard.

For an SME, good onboarding should answer practical questions such as:

• What happens in the first 30, 60 and 90 days?

• How are existing users, devices and suppliers reviewed?

• How is admin access checked and cleaned up?

• How are unsupported devices or legacy applications handled?

• What gets fixed immediately, what gets scheduled, and what gets recorded as an exception?

• Who owns remediation if inherited issues are found?

This is especially important where Microsoft 365 is concerned. Many SMEs have inherited years of admin relationships, broad permissions and unclear access history inside their tenant. If a provider cannot explain how they review and clean up that access during onboarding, they are not really taking controlled ownership of the environment.

The test is simple: can they describe the onboarding path clearly enough that a non-technical business owner can understand how the estate moves from inherited sprawl to governed service?

What evidence and reporting should exist

One of the biggest mistakes SMEs make is confusing reassurance with evidence.

You do not need polished dashboards for the sake of it. You need reporting that proves the environment is being maintained and that the important controls are actually working.

A good IT partner should be able to show what gets reviewed, how often it is reviewed, and what the outputs look like. For most SMEs, that means reporting on patch compliance, backup success and failure, monitoring health, security alerts, key risks, and any notable systems or devices that need attention. Regular reporting also matters because it creates a record. If there is a dispute, an incident or an insurance question later, you want more than verbal reassurance that things were under control.

Ask direct questions.

• Can you show patch status across devices?

• Can you show whether backups are succeeding and whether restores are tested?

• Can you show what privileged access exists?

• Can you show what has been remediated and what remains open?

• How often are these reviews discussed with the client?

If the provider cannot answer those questions clearly, they may be doing useful work, but they are not giving you much governance visibility.

How privileged access should be governed

This is one of the most important evaluation points in 2026.

Your IT partner may have the ability to administer your Microsoft 365 tenant, your users, your devices, your security controls and your data. That access needs to be narrow, deliberate and reviewable.

In plain English, that means four things.

First, privileged access should be limited to what is actually needed. Second, admin accounts should be separate from everyday user accounts. Third, privileged access should be strongly protected, typically with MFA. Fourth, partner access should be reviewed regularly and removed when it is no longer needed. Microsoft’s current guidance is clear on these points, and GDAP exists specifically to support more granular, time-bound partner access rather than broad standing permissions.

For an SME evaluating a provider, the right questions are straightforward:

• Who has admin access to our tenant today?

• Are those privileges proportionate to the work being done?

• Are privileged accounts separate from normal accounts?

• Is MFA enforced?

• How is partner access reviewed, reduced and removed over time?

You do not need to become a Microsoft licensing expert to ask those questions. You just need to be clear that provider access to your estate should be governed, not assumed.

How exceptions should be handled

Every SME has awkward realities.

There may be an older device that has not yet been replaced, a specialist application with limited vendor support, a legacy workflow nobody wants to disturb, or a permission structure built around one long-standing member of staff. The issue is not whether exceptions exist. The issue is whether they are controlled.

A good provider should have a documented exception process. That means exceptions are identified, recorded, assessed, given an owner, reviewed against risk, and paired with a plan where possible. An unsupported device should not simply remain in service forever because replacing it is inconvenient. A special-case permission should not stay in place indefinitely because nobody wants to revisit it.

This is one of the clearest differences between reactive support and governed service. Reactive providers tend to accommodate exceptions ad hoc. Stronger providers make exceptions visible and finite.

As a buyer, ask: how do you document exceptions, how do you review them, and who owns the decision if a risk is accepted for a period of time?

If the answer is vague, it usually means the provider is used to absorbing inconsistency rather than reducing it.

How supplier overlap should be managed

Many SMEs do not have one IT supplier. They have several.

That might include broadband, telephony, a line-of-business software vendor, a security tool provider, an outside consultant, a website agency, or a previous MSP still holding access somewhere in the estate. This is normal. What matters is whether responsibility is clear when those suppliers overlap.

A good IT partner should be able to explain where their responsibility starts and stops, what gets documented, who leads incident coordination, and how third-party dependencies are managed. If an incident affects Microsoft 365, broadband and a third-party application at the same time, who owns the coordination? If a former supplier still has access, who identifies and removes it? If another vendor is responsible for a business-critical application, who manages the boundary between endpoint support and application support?

These are not edge-case questions. They are basic operating questions.

The NCSC’s current guidance puts real weight on clear contracts, explicit roles, incident notification, reporting and responsibility for third parties used to deliver the service. Its supply chain guidance also reflects a wider shift: supplier cyber security is now something organisations are expected to scrutinise, not simply trust.

If no one can explain how overlap is managed, then accountability is not clear. It is just postponed.

Red flags

Some warning signs are worth taking seriously early.

• No clear answer on who owns the baseline

• A promise to support “anything” without a defined standard

• No structured onboarding path

• Vague answers on reporting or review cadence

• Broad admin access with little explanation

• No documented approach to exceptions

• Unclear responsibility when other suppliers are involved

• Contracts that describe service levels but not ownership, access boundaries or incident handling

None of these red flags is dramatic on its own. Together, they usually point to the same issue: the provider may be set up to respond to tickets, but not to govern an environment properly.

The right next step is diagnostic

If you are reviewing your current provider or considering a switch, do not start with price alone.

Start by testing whether a provider can answer the evaluation questions in this article with clarity and consistency. Who owns the baseline? What is standardised? What is mandatory? How does onboarding work? What evidence exists? How is privileged access governed? How are exceptions handled? What happens when suppliers overlap?

That gives you something much more useful than a sales pitch. It gives you a way to assess whether a provider can take accountable ownership of a secure, supportable environment.

For broader context, see Managed IT Services and Cyber Security & Cyber Essentials hubs.

If you want to clarify where your current gaps, risks and ownership issues sit before making any provider decision, start with the Security Triage / Baseline Review page. 

Book a Security Triage Call

Learn about the Security Baseline Review

Download CE-baseline Checklist

FAQs

What should an SME ask before switching IT provider?

Ask who owns the baseline, what is standardised, which controls are mandatory, how onboarding works, what reporting exists, how privileged access is governed, how exceptions are handled, and how supplier overlap is managed.

What reports should a managed IT provider give you?

At a minimum, you should expect reporting on patching, backup success and failure, monitoring health, security alerts, key open risks and notable issues that need remediation.

How much admin access should an IT provider have to Microsoft 365?

Only what is needed to do the agreed job. That access should be limited, reviewed regularly, protected with MFA and separated from everyday user activity. GDAP is designed to support a more granular, time-bound model of partner access.

Can multiple IT suppliers still work if accountability is clear?

Yes, but only if roles, responsibilities, incident handling and third-party dependencies are documented clearly. If those boundaries are vague, supplier overlap usually creates gaps rather than resilience.