MSP vs. In-House vs. Co-Managed IT: A Decision Worksheet

Managed IT & Buying Guidance

Updated July 12, 2026

By Jerame Trunnell Owner of Cloud Core MSP

The MSP-versus-in-house decision is not a contest between “control” and “outsourcing.” It is a choice about an operating system for technology: who owns business decisions, who performs recurring work, how expertise and coverage are supplied, what evidence leadership receives, and how the organization changes course. For many teams, co-managed IT is a legitimate third model rather than a temporary compromise. Compare all three against the same requirements and full cost boundary.

Define the decision before comparing models

Write a short decision statement: the business change driving the review, the services in scope, the planning horizon, and the outcomes the model must support. Examples include adding locations, reducing dependence on one person, improving after-hours coverage, recovering a project backlog, meeting customer requirements, or creating security and recovery discipline. Keep product names out of the first draft; they can prematurely turn an operating-model decision into a tool comparison.

Document non-negotiable decision rights. Leadership should normally retain business priorities, risk acceptance, budget authority, data ownership, and final approval for high-impact changes regardless of delivery model. “Managed” does not mean the organization transfers accountability for every technology or security decision.

Understand the three viable models

In-house IT

Employees perform most operational and project work. This can provide close business context, direct prioritization, and durable internal relationships. The model still needs coverage for leave and after-hours events, specialist capability, training, tools, documentation, and outside support for work the team cannot safely absorb. One employee is not automatically a complete IT department.

Managed service provider

A provider performs an agreed service scope with its people, processes, and tools. This may supply a broader bench and repeatable coverage, but only within the contract and operating design. The customer still needs an accountable internal service owner who can set priorities, evaluate evidence, coordinate business stakeholders, and govern supplier risk. CISA’s MSP customer risk considerations highlight the need to understand roles, contracts, data, incidents, and supply-chain exposure.

Co-managed IT

Internal staff retain selected lanes while a provider adds coverage or specialist capacity. This can preserve business knowledge and reduce key-person exposure, but it succeeds only with explicit operating boundaries. Each recurring task and decision needs a responsible party, one accountable owner, an escalation path, a shared evidence location, and an absence or exit plan.

Compare loaded cost, not salary against a proposal

Use your organization’s actual figures. The U.S. Bureau of Labor Statistics Employer Costs for Employee Compensation measures wages and multiple benefit categories, including paid leave, insurance, retirement, supplemental pay, and legally required benefits. IRS Publication 15 describes federal employer tax responsibilities. These sources demonstrate why salary alone is not a full employment-cost boundary; they are not a pricing formula for a particular IT role.

Calculate each model over the same planning period and separate recurring, variable, and one-time costs:

In-house: compensation, employer taxes, benefits, recruiting, onboarding, leave coverage, overtime or on-call arrangements, training, certifications, equipment, management time, tools, licenses, outside specialists, and temporary project capacity.
MSP: recurring service fees, onboarding, projects and excluded work, licenses not included, consumption charges, internal vendor-management time, contract changes, transition overlap, and exit assistance.
Co-managed: applicable in-house costs plus provider scope, shared or duplicate tools, projects, governance time, integration work, and coverage where boundaries overlap.

Do not insert a generic percentage for benefits or an assumed MSP price. Obtain finance-approved employment figures and normalize provider proposals to the same systems, users, sites, hours, responsibilities, licenses, and project assumptions.

Evaluate coverage and depth using scenarios

A staffing count does not prove capability. NIST’s NICE Framework components describe cybersecurity work using tasks, knowledge, skills, work roles, and competency areas. Build a capability map for the actual work: user support, identity, endpoints, networking, cloud, line-of-business applications, backup and recovery, security monitoring, incident response, vendor management, architecture, procurement, and project delivery.

Then test each model against scenarios rather than slogans:

The primary IT person is unavailable during an identity compromise.
A site opening and a security remediation project compete for the same week.
An EHR, ERP, or other critical vendor blames the network while the network provider blames the application.
A restore is required after hours and business staff must validate the recovered workflow.
A specialist skill is needed briefly but is not justified as a full-time role.
The employee resigns or the provider relationship ends with thirty days’ notice.

For every scenario, name who detects the issue, who acts, who authorizes disruptive changes, who communicates, who supplies backup coverage, and what evidence proves the result.

Price key-person, project, and transition risk explicitly

Key-person risk exists when knowledge, credentials, vendor relationships, or decision authority cannot continue without one individual. MSPs can also create concentration risk if one provider controls identity, endpoints, backups, security logs, documentation, and administrator credentials without independent customer access.

Project risk is the cost and operational consequence of delaying planned work because support consumes available capacity. Compare the realistic delivery calendar, skills, dependencies, change control, and backfill for each model. Do not count a provider’s entire staff as available to your account unless the delivery design and contract support that assumption.

Transition risk includes discovery gaps, undocumented systems, access transfer, tool removal, overlapping costs, data export, user disruption, and loss of historical evidence. NIST SP 800-161 Revision 1 recommends integrating cybersecurity supply-chain risk into risk strategy, policies, plans, and assessments. Apply that discipline to selection and exit: confirm asset, documentation, credential, configuration, ticket, log, and data portability before signing.

Copyable three-model decision worksheet

Decision horizon: [dates] Services/sites/users in scope: [scope]

Business outcome: [observable result] Accountable decision-maker: [name]

Criterion: [loaded cost / coverage / skill depth / business context / project capacity / key-person risk / security governance / recovery / supplier risk / transition]

Required condition: [what the business actually needs]

In-house evidence and gaps: [artifact, owner, assumption, unresolved risk]

MSP evidence and gaps: [contract section, evidence, owner, assumption, unresolved risk]

Co-managed evidence and gaps: [boundary, evidence, owner, assumption, unresolved risk]

Business-selected weight: [importance chosen before scoring]

Model scores: [use one consistent scale; cite evidence for every score]

Decision condition: [accepted / corrective action required / disqualifying gap]

Create one worksheet row per criterion. Define the scoring scale before reviewing proposals, and let the organization choose weights based on its risks rather than using a vendor’s template. Keep assumptions visible. A polished response without contract language, named people, or an evidence sample should not receive the same score as a demonstrated capability.

Require evidence appropriate to every model

Coverage: calendars, escalation paths, backup personnel, and after-hours boundaries.
Capability: task ownership, relevant experience, specialist escalation, and training plans.
Operations: sample documentation, asset coverage, ticket workflow, change records, and exception handling.
Security: privileged-access design, monitoring ownership, incident roles, vulnerability handling, and recovery tests.
Governance: decision cadence, risk register, project roadmap, financial visibility, and accountable owners.
Portability: customer-controlled credentials and usable exports of data, configurations, documents, tickets, and logs.

The NIST Cybersecurity Framework 2.0 is a useful outcome vocabulary for this comparison. CISA’s Cross-Sector Cybersecurity Performance Goals can help smaller organizations identify high-impact cybersecurity practices. Neither resource chooses a delivery model; use them to test whether each option can produce the outcomes and evidence your organization prioritizes.

Make the decision reversible

Choose a model that can evolve as the organization changes. Put documentation ownership, administrator access, data export, tool transition, subcontractor transparency, assistance at termination, and knowledge transfer into the operating plan and contract. Establish a review date and explicit triggers for changing the model, such as a new location, acquisition, compliance obligation, critical application, persistent project backlog, or staffing change.

The final recommendation should state why the selected model best fits the documented requirements, which risks remain, who accepted them, what must be corrected before transition, and when leadership will reassess. That is more defensible than declaring one model categorically cheaper, safer, or more strategic.

Related buying guides

Use How to Choose a Managed Service Provider for provider due diligence, examine the third-model operating boundary in Co-Managed IT, and normalize scope before price discussions with Managed IT Pricing: Why Scope Comes First.