Managed IT Buying Guide

Questions to ask an IT support company before choosing an MSP

A useful provider conversation should make responsibility visible. Ask what is included, what is excluded, who owns Microsoft 365, security, backups, escalation and documentation, and how the provider will help leadership understand unresolved risk and priorities.

What should you ask an IT support company? Start with scope, exclusions and ownership. A strong answer explains who handles day-to-day support, Microsoft 365 and identity, endpoints, cybersecurity escalation, backup and recovery, vendors, documentation, onboarding and offboarding, reporting and strategic planning — including what the provider does not own.

Before the sales call

Bring your business dependencies, not just a feature wish list

Provider comparisons are easier when you know which users, systems, vendors and recovery expectations matter to the business. Use the questions below to compare operating responsibility rather than marketing labels.

Support expectations

Which users, devices and locations are covered? What is the support intake and escalation path? Which requests or projects are outside recurring scope?

Microsoft 365 & identity

Who administers users, privileged roles, onboarding, offboarding, licensing and access changes? How are responsibilities shared if internal IT remains involved?

Security responsibility

Which endpoint, identity, email or incident-response responsibilities belong to the provider, which belong to other vendors, and what requires a separate scope?

Backup & recovery

What is actually backed up, what is excluded, who monitors failures, how restores are requested and what evidence is available from testing?

Documentation & vendors

Who maintains administrative ownership, asset and vendor information, diagrams or dependency notes, and how can authorized leadership obtain it when needed?

Planning & reporting

How will the provider communicate unresolved risks, lifecycle needs, project priorities and decisions instead of only closing support tickets?

1. Clarify scope and exclusions

Ask for a plain-language description of the recurring service. The important question is not whether the package has a familiar label such as “managed IT”; it is whether the business can tell what the provider owns.

  • Which users, endpoints, servers, networks and locations are in scope?
  • Which requests are included in recurring service and which are billable projects?
  • Are third-party applications and vendors supported directly, coordinated, or excluded?
  • What happens when an issue spans several providers?

2. Ask how support and escalation actually work

  • How do staff request support and how are urgent business-impacting issues escalated?
  • What information does the provider need from internal leadership or an internal IT contact?
  • If the provider cannot resolve an issue alone, who owns vendor follow-up?
  • How are recurring issues identified and raised beyond the individual ticket?

3. Define Microsoft 365, identity and employee-lifecycle ownership

  • Who creates, changes and disables user access?
  • Who reviews privileged administrator access and handles urgent revocation?
  • How are onboarding, role changes and offboarding documented?
  • Who owns collaboration and external-access configuration when it matters to the business?

4. Separate cybersecurity responsibilities from vague promises

Security is rarely one product or one provider responsibility. Ask the provider to identify the controls and escalation activities it will own, what is shared, and what remains outside scope.

  • Who owns endpoint and identity security administration?
  • What triggers escalation for suspicious activity or an incident?
  • Which responsibilities sit with a separate security, insurance, application or infrastructure provider?
  • What evidence or reporting can leadership review?

5. Make backup and recovery evidence part of the discussion

  • What systems and data are included in the recovery approach?
  • Which important systems are excluded or dependent on another vendor?
  • Who monitors backup failures and who owns corrective action?
  • How are restores tested, and what exactly was proven by the last test?

6. Ask who owns documentation and vendor relationships

  • Where are current administrative and recovery documents maintained?
  • Who records key vendors, contracts, support contacts and escalation paths?
  • Can authorized business leadership obtain required documentation during a provider transition or incident?
  • How are infrastructure and business-system dependencies documented?

7. Review onboarding and offboarding — including the MSP itself

A provider should be able to explain both how it will enter the environment and how control can later be transferred. That reduces dependence on undocumented credentials or one person’s memory.

  • What access is required during onboarding and how is it transferred securely?
  • What documentation will be created or validated?
  • How are former-provider accounts and tools reviewed after transition?
  • If you later change providers, what handoff information will be available?

8. Ask how reporting and strategic planning connect to business priorities

  • How will unresolved risk, aging infrastructure and recurring support patterns be surfaced?
  • How are projects prioritized against business impact and budget?
  • Who joins planning conversations with leadership?
  • What should the business expect to decide rather than delegate?

A comparison checklist for provider proposals

AreaAsk the provider to make explicit
SupportUsers/devices covered, intake, escalation, exclusions and project boundaries.
Microsoft 365User lifecycle, administrator roles, identity ownership and collaboration responsibilities.
CybersecurityControls managed, escalation ownership, other-vendor dependencies and evidence/reporting.
Backup & recoveryProtected scope, exclusions, monitoring, restore process and testing evidence.
Infrastructure & vendorsNetwork/server responsibilities, vendor coordination and escalation paths.
DocumentationWhat is maintained, where it is stored and how authorized leadership can obtain it.
PlanningHow risks, lifecycle needs and projects are prioritized and communicated.
TransitionOnboarding steps, access transfer and the eventual offboarding/handover process.

Scallex perspective

Compare responsibility models, not unsupported promises

Scallex uses the same questions when discussing managed or co-managed IT: what has to work, who owns each responsibility, what evidence exists and what the next priority is. A provider should be able to describe boundaries without relying on invented guarantees or vague “everything is covered” language.

Next step

Evaluate the current IT responsibility model

If the questions above reveal unclear ownership across support, security, Microsoft 365, recovery or vendors, use the Free IT Assessment for a broader review.