How to Extend an Internal IT Team Without Giving Up Control

Nina Okonkwo August 22, 2026

How to extend an internal IT team without giving up control

An internal IT team can know the business exceptionally well and still lack the time, specialist depth, or coverage to handle every operational demand. Co-managed IT addresses that problem by dividing defined responsibilities between the internal team and an external managed service provider (MSP).

The important word is defined. Co-managed IT is not a standardized package. The label alone does not establish who answers tickets, approves identity changes, responds after hours, restores failed backups, or accepts business risk. Those details determine whether the arrangement extends the internal team or adds another layer of cost and confusion.

This guide explains how the model works, how it compares with adjacent support options, how to divide duties, what to measure, how to evaluate total cost, and which provider and contract terms deserve scrutiny.

What co-managed IT means in practice

Co-managed IT is an operating arrangement in which an internal IT employee or team and an external MSP divide responsibility for specified technology functions. The provider supplements the internal function rather than automatically replacing it.

The internal team typically contributes capabilities an outsider cannot quickly reproduce:

Institutional knowledge
Understanding of business priorities and workflows
Relationships with users and executives
Familiarity with critical or customized applications
Authority to set priorities and approve changes
Context for balancing operational risk against business needs

The provider may contribute resources that are difficult for a small or busy internal team to maintain across every domain:

Additional service-desk or engineering capacity
Network and infrastructure monitoring
Patching and endpoint-management tools
Backup oversight and recovery assistance
Cybersecurity operations support
Cloud and identity specialists
After-hours coverage
Project-specific expertise

Provider descriptions commonly present the MSP as an extension of the internal team, with responsibilities selected according to workload, skill gaps, and organizational priorities. LeafTech, for example, describes a model that combines internal knowledge of users, workflows, and business systems with outside tools, expertise, and capacity while tailoring duties to the organization’s needs (LeafTech Consulting).

That variability is central to the model. Co-managed IT can mean:

Outsourcing one function, such as security monitoring
Assigning several operational functions to an MSP
Adding overflow help-desk capacity
Obtaining after-hours escalation coverage
Engaging specialists for a migration or infrastructure upgrade
Creating an ongoing partnership that changes with demand

It is therefore better understood as an operating model, not a fixed service bundle. Two providers can both advertise co-managed IT while offering materially different responsibilities, tools, coverage hours, access rights, and service commitments.

A practical definition should answer four questions:

Ownership: Who owns each outcome?
Authority: Who may approve, change, or disable systems?
Delivery: What work and evidence must each party produce?
Escalation: Who acts when normal processes fail?

If those answers are missing, the service name is not enough.

Co-managed IT may improve coverage, provide access to specialist skills, or help move delayed work forward. Lower costs, stronger security, faster support, and less downtime are possible outcomes—not inherent properties of the model. The public material available for many such claims is largely provider-authored, so buyers should compare promises with their own baselines, contractual commitments, and measured results.

Co-managed IT versus fully managed IT and other support models

The clearest distinction between co-managed and fully managed IT is the responsibility model.

In co-managed IT, the organization retains an internal IT function and divides duties with the MSP. In fully managed IT, the MSP assumes broader responsibility for day-to-day operations and may effectively serve as the organization’s IT department.

Even that distinction is not absolute. Providers variously describe fully managed service as covering all, most, or the day-to-day portion of IT. Buyers should inspect the service schedule rather than assume that “fully managed” means every technology duty, decision, cost, and risk has transferred.

Co-managed IT versus break-fix support

In general industry usage, break-fix support refers to work purchased in response to a particular problem, such as a failed server, inaccessible application, or network outage. The customer buys a repair or a block of labor without necessarily creating a continuing operating relationship.

Managed service is generally described as recurring and proactive. It may include monitoring, scheduled maintenance, ticket handling, patching, reporting, and service reviews. A co-managed engagement can still include project or incident work, but it normally sits within an agreed division of continuing responsibilities.

A provider may combine recurring support, project work, and incident-based charges in the same agreement. The contract and service schedule should therefore take precedence over the terminology.

Co-managed IT versus staff augmentation

A useful working distinction is that staff augmentation adds an individual contractor or temporary team under the client’s direction, while co-management assigns an operating responsibility to a provider.

An MSP may supply multiple people, tools, procedures, escalation paths, and managerial oversight. That is commercially different from buying a person’s time, but proposals sometimes blend the two approaches.

Ask whether the provider is offering:

Named labor under client direction
A pool of labor billed by time
A managed function with defined outputs
A project with acceptance criteria
Some combination of these

Do not rely on the provider’s label. Determine who directs the work, who owns the process, how performance is measured, and what happens when the assigned individual is unavailable.

Co-managed IT versus a virtual CIO

A virtual CIO is primarily a strategy and planning role. Typical concerns include technology roadmaps, budgeting, governance, risk priorities, and vendor decisions. Co-managed IT is more commonly positioned around operational capacity or specialist skill gaps.

The boundary can blur because some MSPs include virtual CIO support in broader packages. The underlying diagnosis remains useful: if tickets, coverage, or technical execution are the constraint, operational co-management may fit. If the organization lacks direction, decision rights, architecture, or investment priorities, adding operational capacity alone may not solve the problem. Anders makes a similar distinction between capacity-oriented co-management and strategy-oriented virtual CIO services (Anders).

Support-model comparison

Model	Internal IT team required?	Responsibility model	Client control	Common use case	Typical duration	Principal governance concern
Co-managed IT	Usually	Defined duties shared between internal IT and an MSP	High over retained areas; shared elsewhere	Capacity, coverage, specialist skills, projects	Ongoing or time-limited	Preventing gaps and overlap
Fully managed IT	Not necessarily	MSP assumes most or all contracted day-to-day duties	Strategic client oversight; operational control varies	Organization lacks an internal team or wants broad outsourcing	Usually ongoing	Confirming what “fully” includes
Break-fix support	No	Provider responds to a particular fault or request	Client retains overall control	Isolated repair or troubleshooting	Incident-based	Lack of proactive ownership and continuity
Staff augmentation	Usually	Client directs added personnel	High	Temporary labor or a defined skill shortage	Usually time-limited	Avoiding unclear supervision and individual dependency
Virtual CIO	No, but often complements internal or outsourced operations	Advisor supports strategy and planning	Client retains decision authority	Roadmaps, budgeting, governance, vendor direction	Fractional or recurring	Separating advice from operational accountability
Project consultancy	No	Provider delivers a defined project or work product	Shared for the project	Migration, implementation, assessment, or redesign	Fixed-term	Scope, acceptance criteria, and operational handoff

These are practical distinctions rather than universal definitions. Actual offerings may cross categories, and no model is inherently cheaper, safer, or more effective. The appropriate choice depends on the problem being solved, the duties retained internally, the quality of execution, and the contract.

When co-managed IT is—and is not—a good fit

Do not begin with “Do we need an MSP?” Begin with “What business problem are we trying to solve?”

Five categories capture many of the situations that lead organizations to investigate co-managed IT.

1. Insufficient capacity

Capacity problems become visible when routine demand consistently exceeds available labor. Signals may include:

A growing ticket backlog
Senior engineers spending substantial time on repetitive support
Preventive maintenance being deferred
Documentation falling behind
Recurring issues receiving workarounds rather than root-cause analysis
Employees waiting too long for help
Staff being unable to take uninterrupted leave

These symptoms can justify outside capacity, but they can also result from poor processes, unstable systems, or badly prioritized work. Adding people to a broken workflow may increase activity without correcting the underlying cause.

2. Missing specialist skills

A capable generalist team may still lack depth in areas such as:

Cybersecurity operations
Identity and access management
Cloud architecture
Network engineering
Backup and recovery design
Complex migrations
Compliance evidence collection

The key question is whether the need is continuing or occasional. A narrow consultancy or project contract may be more appropriate than broad co-management when the work is infrequent and clearly bounded.

3. Inadequate coverage

An internal team may perform well during business hours but have no sustainable plan for nights, weekends, holidays, sickness, or vacation. Coverage gaps become more significant when systems support multiple time zones or incidents require rapid escalation.

Coverage should be defined precisely. Monitoring alerts around the clock is not the same as having a qualified person assess an alert, contain an issue, restore service, and communicate with stakeholders.

4. Delayed projects

Operational demand often displaces migrations, infrastructure upgrades, documentation, lifecycle work, and resilience testing. An MSP can either take routine work away from internal engineers or supply project specialists directly.

Choose the arrangement according to the bottleneck. If internal engineers possess the project knowledge but lack time, outsourcing routine support may be preferable. If the missing ingredient is specialized engineering, retain routine work internally and purchase project expertise.

5. Continuity or key-person risk

A solo administrator may hold critical knowledge about credentials, integrations, vendors, recovery processes, and undocumented workarounds. Co-management can provide operational backup and create a reason to document important procedures.

It does not eliminate key-person risk automatically. If the MSP assigns one engineer and stores documentation in an inaccessible platform, the organization may simply exchange an internal dependency for an external one.

Four scenarios where co-management may fit

A solo administrator needs backup. The administrator retains user relationships, application knowledge, priorities, and approvals. The MSP handles monitoring, patching, backup oversight, after-hours escalation, and documented absence cover.

A capable team needs cybersecurity depth. Internal IT keeps identity policy, business risk decisions, and compliance ownership. The provider supplies agreed monitoring, investigation support, vulnerability-management assistance, and specialist guidance.

A company is undertaking a temporary cloud or infrastructure project. The MSP provides engineering for assessment, design, migration, and stabilization. Internal IT manages business requirements, application owners, user communication, and final acceptance.

A regulated organization needs operational support. The MSP assists with specified controls, evidence collection, patch reporting, backups, and incident workflows. The organization retains policy authority, regulatory interpretation, compliance ownership, and final risk acceptance.

When co-management may not fit

Co-managed IT may be the wrong solution when:

There is no meaningful internal IT capability with which to share responsibility
Existing staff already provide sufficient capacity, skills, and coverage
Leaders are unwilling to coordinate decisions and processes with a provider
The actual problem is weak strategy, governance, architecture, or prioritization
The need can be met more cleanly through one hire, a narrow specialist contract, or a fixed project
The organization cannot provide the internal governance effort the relationship requires

Avoid unsupported employee-count rules. Fit depends more on workload, complexity, operational risk, desired control, and current capabilities than on headcount alone.

A useful diagnostic sequence is:

Name the business symptom. What is delayed, unavailable, risky, or overly dependent on one person?
Find the root problem. Is it capacity, expertise, coverage, strategy, governance, architecture, or a combination?
Identify the minimum intervention. Would hiring, consulting, process repair, staff augmentation, co-management, or full management address that cause?
Define the expected change. Which baseline measure should improve, by how much, and within what review period?
Select the model only after the diagnosis.

Co-management should compete honestly against another internal hire, a narrower specialist engagement, and fully managed service. It is not automatically preferable to any of them.

How to divide responsibilities between internal IT and the MSP

There is no universal split. Assignments should reflect the internal team’s strengths, business context, required coverage, risk tolerance, and the provider’s demonstrated competence.

A practical starting pattern is to keep business context and final decision authority close to the organization while assigning well-defined operational work or scarce technical expertise to the provider. That is a design option, not a rule.

Illustrative responsibility matrix

The following matrix shows one possible arrangement. “Shared” should not mean ambiguous; the underlying responsibility model should still identify one accountable owner.

Function	Internal IT	MSP	Questions to settle
End-user support	Own user relationships and sensitive cases	Tier-one overflow and advanced escalation	Who receives the first ticket? What is excluded?
Employee onboarding and offboarding	Approve access and coordinate with HR	Execute approved technical tasks	Who may create, modify, disable, or delete accounts?
Business applications	Own requirements and application relationships	Provide infrastructure or escalation support	Who supports custom workflows and integrations?
Endpoints	Approve standards and exceptions	Monitor, patch, and maintain agreed devices	Which devices and operating systems are covered?
Networks	Approve architecture and major changes	Monitor, troubleshoot, and implement approved changes	Who controls configurations and emergency changes?
Monitoring	Review business impact and priorities	Operate agreed monitoring tools	Which systems are monitored, during which hours, and by whom?
Patching	Approve policy, exceptions, and maintenance windows	Test or deploy patches and report status	Who handles failed deployments and aging exceptions?
Identity and access	Own policy, approvals, and risk decisions	Administer approved changes and monitor agreed events	How is elevated access authorized and recorded?
Cloud services	Own business requirements and cost authority	Provide administration or engineering	Who may provision resources or change configurations?
Cybersecurity	Set policy and make risk decisions	Provide contracted monitoring, tooling, or incident support	Who declares an incident and authorizes containment?
Backups	Define recovery requirements	Monitor jobs, address failures, and assist restores	Who verifies recoverability rather than job completion alone?
Disaster recovery	Approve priorities and declare a disaster	Maintain agreed procedures and support execution	Who invokes the plan and communicates with the business?
Compliance evidence	Own interpretation and accountability	Supply agreed technical evidence	Which artifacts, formats, and deadlines apply?
Vendors	Own commercial priorities and key relationships	Coordinate technical cases and escalations	Who may authorize purchases or contract changes?
Architecture	Own target state and standards	Advise, design, and challenge assumptions	Who gives final design approval?
Budgeting	Own budget and investment decisions	Provide forecasts and recommendations	Which costs are estimates, commitments, or pass-through charges?
Major projects	Own the business case and acceptance	Supply project management or engineering	What are the milestones and acceptance criteria?

This example leaves business applications, user relationships, architecture, priorities, approvals, policy direction, compliance ownership, and final risk decisions with internal IT. The provider handles or supports tier-one overflow, advanced escalations, monitoring, patching, backup operations, security operations, after-hours coverage, cloud engineering, and specialist projects.

A different organization might reverse the service-desk arrangement. Internal IT could run help desk and application support while the MSP manages infrastructure and security. Alternatively, the MSP could handle routine support while internal engineers focus on product systems, data platforms, or strategic applications. Morefield gives examples of keeping help desk internal while assigning strategy and security externally, or reversing that split (Morefield Communications).

Turn the matrix into a RACI

A service list says what is in scope. A RACI says how work gets done:

Responsible: Performs the task
Accountable: Owns the outcome and final decision
Consulted: Provides input before action
Informed: Receives updates

Assign these roles for every material function, not only broad service categories. “The MSP handles backups” is insufficient. Separate:

Backup-policy approval
Job monitoring
Failed-job remediation
Restoration requests
Restoration testing
Retention changes
Disaster declaration

At minimum, name accountable owners for:

Privileged and high-risk identity changes
Failed backups and failed restore tests
Missed or failed patches
Suspected security incidents
Emergency containment decisions
Vendor and cloud outages
Disaster declarations
Public or customer communication
Compliance evidence and findings
Final risk acceptance

Provider guidance commonly recommends RACI-based ownership, shared ticketing, escalation paths, access controls, service levels, and reporting as coordination mechanisms (Calance). These mechanisms still need to be adapted to the organization’s systems, legal obligations, and risk profile.

Shared responsibility without named ownership can produce omissions, duplicated work, conflicting changes, and delayed escalation. If both parties believe the other owns a failed backup or disabled account, the partnership has not shared responsibility—it has obscured it.

Governance, security, and performance controls

Governance is part of the service, not paperwork added after the technical work. Two teams can use capable tools and still produce poor outcomes if requests enter different queues, approvals are unclear, or documentation is inaccessible.

The controls below are a procurement and operating framework, not a universal cybersecurity or legal standard. Appropriate requirements vary with the environment, contract, jurisdiction, regulatory obligations, insurance conditions, and risk assessment. Qualified security, compliance, insurance, and legal advisers should review consequential requirements.

Establish one operating system for the relationship

Document the following before steady-state work begins:

The authoritative ticket-intake and tracking process
Ticket categories, priorities, and severity definitions
Escalation tiers and named contacts
Approval limits for routine, high-risk, and emergency changes
After-hours procedures
Maintenance windows and change controls
Current runbooks and configuration records
Incident histories and known problems
Service-level definitions
Reporting format, recipients, and review process

Shared ticketing does not necessarily require both parties to abandon their existing platforms. It does require reliable synchronization, an authoritative record, and clarity about where users submit requests and where performance is measured. RSM describes one provider-specific co-ticketing model based on ServiceNow, illustrating a possible technical approach rather than a universal requirement (RSM US).

Define what “24/7” means

A provider may offer one or more of the following:

Automated monitoring around the clock
Human alert review around the clock
On-call response for defined severity levels
Remote containment
Remediation work
Service restoration
User help-desk access
Continuous work until resolution

These are not interchangeable. A contract should define terms such as:

Acknowledgment: The alert or ticket has been received.
Response: A qualified person has begun assessment.
Escalation: The issue has reached the specified authority or specialist.
Containment: Immediate impact or spread has been limited.
Restoration: The affected service has returned to an agreed state.
Resolution: The underlying issue has been addressed or formally closed.

Also specify whether targets apply at all times or only during covered hours, whether the clock pauses while awaiting client input, and which events qualify for each severity level.

Preserve client visibility

The internal team should request access to the documentation and records it needs to supervise the provider, operate retained functions, and support a later transition. Depending on scope, this may include:

Runbooks
Network and system configurations
Asset records
Change histories
Tickets and incident records
Patch and vulnerability status
Backup reports and restore-test results
Vendor cases
Architecture diagrams
Known-error records
Service reports

Visibility does not necessarily require ownership of the provider’s proprietary platform. It may instead be achieved through suitable access, reports, or agreed export rights. Red River recommends keeping configurations, incident histories, runbooks, and escalation procedures in systems accessible to internal IT (Red River).

Control provider access

Before access is granted, the buyer should ask the provider to document:

Who may request and authorize access
Which systems, tenants, locations, and data are covered
Whether access is named, role-based, time-limited, or otherwise restricted
How elevated accounts are authenticated and protected
What provider and subcontractor activity is recorded
Who reviews relevant records and under what circumstances
How emergency access works
How personnel or role changes trigger access review
How access is revoked at termination
What records should be retained if an incident occurs

These are diligence questions, not assertions that one configuration is legally required in every environment. Avoid shared administrator credentials where accountable individual access is practical. If provider tooling requires broad privileges, ask the provider to explain why, identify the safeguards, and demonstrate the revocation process.

Also establish what happens if the provider suffers a security incident that may affect the client. The contract should address the notification process, communication contacts, cooperation expectations, access suspension, and allocation of investigative responsibilities. The appropriate language and timing should be reviewed against applicable law, regulation, insurance, and negotiated obligations.

Measure operations and business impact

A balanced scorecard can include technical measures such as:

Ticket volume by source, service, and priority
Acknowledgment, response, restoration, and resolution time
Open-ticket backlog and ticket age
Reopened and reassigned tickets
Patch status and exception age
Backup success, failure, and recovery-test results
Escalation timeliness and quality
Recurring incidents
Change failures and rollbacks

Add business-oriented measures such as:

User or service impact
Completion of delayed projects
Progress against lifecycle plans
Audit findings and remediation status
Availability of critical business processes
Internal time recovered for agreed priorities
Quality and currency of documentation

Metrics should connect to a baseline and target. A monthly report showing hundreds of closed tickets says little if ticket quality declined, demand increased because of recurring faults, or critical projects remained stalled.

Choose an appropriate meeting cadence

Possible governance layers include:

Operational check-ins for active work and blockers
Service reviews for trends, commitments, risks, and scope
Periodic strategy reviews for roadmap, budget, architecture, and changing business needs

The cadence should match the environment. A high-change transition may need frequent meetings; a stable, narrow service may need fewer. Meeting frequency itself is not evidence of good governance—the quality of decisions, records, and follow-through matters more.

Do not assume that hiring a provider transfers the organization’s cybersecurity, compliance, legal, financial, or business obligations. Organizational leaders should obtain appropriate professional advice, understand retained obligations, validate contracted performance, and identify who may accept risk.

How co-managed IT pricing should be evaluated

Public provider material does not establish a reliable market price range or prove that co-managed IT is inherently cheaper than hiring an employee or buying fully managed support.

Provider-authored descriptions suggest that pricing may be tied to service scope and sometimes to supported users or devices. Actual proposals can also vary according to locations, assets, tools, coverage hours, service levels, and project requirements. Mindcore, for example, describes a monthly model associated with users or devices and included services, but that is a provider’s account rather than an independent market benchmark (Mindcore).

Build a total-cost comparison

Include:

Recurring provider fees
Retained internal salaries, benefits, and management costs
Provider tools included in the fee
Required tools or licenses billed separately
Onboarding, assessment, and setup charges
Project and consulting work
After-hours, emergency, or holiday charges
Travel and on-site labor
Additional user, device, location, or storage charges
Internal time spent coordinating and reviewing the provider
Training and process-change costs
Contract minimums and price adjustments
Data export, knowledge transfer, and exit assistance
Parallel-service costs during transition

A low monthly fee cannot be compared fairly with an employee or another provider until the options are normalized. One proposal may include endpoint tooling, human after-hours response, project hours, and on-site support. Another may include only business-hours remote labor and automated monitoring.

Normalize at least:

Covered users, devices, systems, and sites
Coverage hours and holiday treatment
Response, restoration, and resolution commitments
Included engineering skill levels
Tool and license costs
Project capacity
On-site availability
Security and backup scope
Client-retained duties
Internal coordination requirements
Onboarding and exit costs

Questions to ask about every quote

What exact services, assets, users, and locations are included?
Which requests or events trigger extra charges?
Which software licenses and tools are included or separate?
Are onboarding, assessments, documentation, and integrations included?
Are projects billed at different rates?
What qualifies as project work rather than recurring service?
Is after-hours work included for every priority level?
Are travel and on-site labor extra?
Is there a minimum monthly spend or contract commitment?
How are additional users, devices, sites, or cloud resources priced?
How may the provider change prices during the term?
What assistance and charges apply at termination?

Compare scenarios, not slogans:

Hiring another internal employee
Buying a narrow specialist service
Using temporary staff or a project consultant
Entering a co-managed arrangement
Moving to fully managed IT

Do not manufacture savings percentages or return-on-investment estimates. Use the organization’s workload, compensation, tool, risk, and project data, then test the assumptions after implementation.

Onboarding, ongoing changes, and offboarding

A co-managed relationship should move through deliberate phases.

Phase 1: Discovery and baseline assessment

Inventory:

Users, devices, sites, networks, and cloud services
Critical applications and dependencies
Vendors and support contracts
Current tools and integrations
Existing policies, standards, and runbooks
Open incidents, known problems, and active projects
Relevant contractual, regulatory, and recovery requirements

Baseline the current state before the provider begins changing it. Useful measures include:

Ticket volume, backlog, and age
Response and resolution times
Patch status and outstanding exceptions
Backup results and recent restore tests
Recurring incidents
System or service disruptions
Documentation completeness
Project status and missed milestones

Without a baseline, later claims of improvement or deterioration are difficult to evaluate.

Phase 2: Capability and gap analysis

Compare current capability with required outcomes. Separate:

Capacity gaps
Specialist skill gaps
Coverage gaps
Process and documentation gaps
Strategy and governance gaps
Architectural weaknesses

Only the first three necessarily point toward co-managed operational support. Strategy, governance, and architecture may require different or additional work.

Phase 3: Responsibility mapping

Build the service schedule and RACI. Name accountable owners, approval authorities, escalation contacts, and evidence requirements. Resolve overlaps before work begins.

Phase 4: Access and tool integration

Provision access according to the agreed role and scope. Integrate or synchronize ticketing, monitoring, documentation, alerting, communications, and reporting.

Record:

Who owns each tool
Which records the client can access
How data can be exported
What access expires at the end of the engagement
Which licenses or configurations can and cannot transfer

Phase 5: Documentation

Validate and update:

Asset and configuration records
Network and application diagrams
Standard operating procedures
Escalation contacts
Vendor information
Recovery instructions
Maintenance windows
Known risks and exceptions

Do not treat documentation as a one-time onboarding task. Assign owners and review triggers so records remain current.

Phase 6: Escalation and recovery testing

Test actual workflows, not only written procedures:

Ticket intake and routing
Severity assignment
After-hours escalation
Emergency approvals
Account creation and revocation
Provider-access revocation
Backup restoration
Incident communication
Vendor escalation
Disaster-recovery decision paths

Testing can reveal missing contact details, inaccessible credentials, unclear authority, incompatible tools, and unrealistic assumptions before a real incident occurs.

Phase 7: Steady-state review

After initial operation:

Compare performance with the baseline
Review recurring exceptions
Correct unclear ownership
Adjust responsibilities where necessary
Confirm that internal employees know when to act, consult, or escalate
Recheck documentation and access

Onboarding duration varies with scope, environment complexity, documentation quality, integrations, and security requirements. CompassMSP states that its own onboarding generally takes 30–60 days to reach steady state, with some critical tools deployed sooner; that is a provider-specific timeline, not an industry benchmark (CompassMSP).

Plan for changing scope

A flexible agreement may allow support to expand or contract for:

Major projects
Seasonal demand
Employee absences
Acquisitions or new locations
Incidents
Changing compliance requirements
Internal hiring or departures

Flexibility must be reflected in the agreement. Specify the notice period, pricing method, approval process, and expected service impact for scope changes.

Design the exit before signing

Consider negotiating requirements for:

Current, usable runbooks
Client-controlled credentials where appropriate
An inventory of provider accounts and access paths
Exportable tickets, incidents, configurations, and reports
Defined export formats and delivery timelines
A documented access-revocation process
Knowledge-transfer sessions
Transition assistance and rates
Agreed handling of client data after termination
Cooperation with a successor team
Clear ownership of scripts, configurations, and project artifacts

Do not assume every tool is portable or every provider offers unrestricted exports. Negotiate the specific records, formats, rights, and assistance the organization needs. Data return, retention, and deletion terms should be reviewed for consistency with applicable contractual, legal, regulatory, and insurance requirements.

Provider and contract evaluation checklist

A suitable co-managed provider must be able to operate within an explicit division of duties. Technical depth matters, but so does the willingness to share visibility, respect internal authority, and work through the client’s governance processes.

Evaluate collaboration and fit

Ask how the provider has handled situations where:

Internal IT retains the help desk
The client uses its own ticketing platform
The MSP owns only security or infrastructure
Client approval is required for high-risk changes
A responsibility shifts between teams
The provider disagrees with the internal team’s risk decision
An internal employee is absent
A project transitions into ongoing operations

A candidate that insists on controlling every function may be a capable fully managed provider but a poor co-management partner.

Verify technical and operational depth

Check:

Relevant engineering skills
Coverage hours by function
After-hours escalation availability
Experience with comparable systems and complexity
Geographic and on-site support capability
Regulatory or industry experience relevant to the scope
Project-delivery capability
Staffing and succession for key provider roles
Reliance on subcontractors

Credentials, tools, and facilities can inform due diligence, but they do not by themselves establish service quality or guarantee performance.

Require a process demonstration

Ask candidates to show—not merely describe—how they would:

Receive and route a ticket
Synchronize with the internal team’s tools
Obtain approval for a privileged change
Escalate a severe incident
Document a configuration change
Report a failed backup
Track a missed patch
Maintain a runbook
Produce a service report
Export client records at termination

A process demonstration often exposes assumptions that a proposal conceals.

Define service levels precisely

Request separate definitions for:

Acknowledgment
Response
Escalation
Containment
Restoration
Resolution

For each, document:

Severity criteria
Covered hours
Clock-stopping conditions
Client and third-party dependencies
Exclusions
Reporting
Contractual remedies, if any

Reject generic “24/7 support” language that does not identify which human actions are available, for which systems, and under which conditions.

Assess provider-access security

Ask the provider to explain and demonstrate:

Named and shared account practices
Authentication controls
Privileged-access approval
Activity logging and retention
Device or location restrictions
Subcontractor access
Security-event notification
Relevant record preservation
Personnel-change procedures
Access review and termination
Available client audit or assurance rights

Determine what happens if the provider itself experiences a security incident. Notification, communication, containment cooperation, evidence access, and possible access shutdown should be addressed in advance and reviewed by qualified advisers.

Review the contract line by line

The agreement should address:

Exact in-scope services, assets, users, and locations
Client and provider responsibilities
Explicit exclusions
Coverage hours and emergency procedures
Service-level definitions and remedies
Change control and approval authority
Security and access obligations
Subcontractor use
Incident notification and cooperation
Access to data, tickets, logs, and documentation
Tool ownership and licensing
Pricing, pass-through costs, and adjustments
Project rates and acceptance criteria
Contract duration and renewal
Termination rights and fees
Knowledge transfer and transition support
Data return, retention, and deletion
Dispute and unresolved-risk escalation

Contract requirements vary by jurisdiction, industry, insurance policy, and negotiated allocation of risk. This checklist is not a substitute for legal, compliance, procurement, or security review.

Contract language should also match the operating documents. A polished RACI has limited value if the legal agreement contradicts it or allows scope to change without an agreed process.

Ask for relevant evidence

Request references or case studies involving comparable environments, support scopes, and constraints. Ask references about:

Escalation quality
Documentation accessibility
Staff continuity
Transparency after mistakes
Change discipline
Project handoff
Billing surprises
Exit cooperation

Testimonials selected by a provider are not representative proof. Treat them as inputs for follow-up questions, not performance guarantees.

Define success before signing

Select a small set of baseline-linked measures. Examples include:

Reducing ticket backlog and age
Achieving an agreed patch status
Completing specified restore tests
Improving after-hours escalation
Finishing named projects
Closing agreed audit findings
Bringing runbooks to a defined completeness standard
Reducing key-person dependency for named functions

For each measure, specify:

Baseline
Target
Data source
Accountable owner
Review period
Action if the target is missed

Watch for red flags

Be cautious when a provider offers:

Vague ownership or “shared responsibility” without named owners
Documentation that remains inaccessible to internal IT
Undefined escalation or severity levels
Bundled services with unclear limits
Savings or security claims without assumptions or evidence
Resistance to shared ticket and performance visibility
Broad privileged access without a clear rationale and controls
No process for testing backups or incident workflows
No credible data-export or transition process
A co-managed label paired with an insistence on controlling every function

Frequently asked questions about co-managed IT

Does co-managed IT replace the internal IT team?

Ordinarily, no. The model assumes an internal employee or team remains in place while the MSP fills defined operational, coverage, project, or specialist gaps. Internal IT may retain priorities, user relationships, business applications, architecture, approvals, and risk decisions.

The practical answer still depends on the agreement. If a provider gradually assumes nearly every function and internal roles disappear, the organization may be moving toward fully managed IT regardless of the label.

Can co-managed IT support a temporary project or employee absence?

Yes. The arrangement can be limited to a migration, infrastructure upgrade, security initiative, demand spike, leave period, or another defined need. It can also continue after the temporary need if both parties agree.

For temporary support, specify the start and end conditions, deliverables, access expiry, documentation requirements, handoff, and acceptance criteria. Otherwise, a short-term engagement can leave lingering access or knowledge gaps.

Is co-managed IT always cheaper than hiring another employee?

No. Available provider material does not establish that co-managed IT is always cheaper than hiring.

Compare the full cost of each option, including provider fees, retained labor, tools, onboarding, projects, after-hours charges, internal coordination, and exit costs. Also compare capability and coverage: an employee and a multidisciplinary provider are not equivalent units, but neither are they interchangeable substitutes for every need.

Can a company move from co-managed to fully managed IT later?

Potentially. A company may transfer more responsibilities to the provider as staffing or business needs change, or bring functions back in-house. Whether that transition is practical depends on the contract, provider capability, documentation quality, credentials, tool ownership, pricing, and knowledge-transfer terms.

Do not rely on a promise of a seamless transition. Define how scope changes are approved and priced, and maintain usable operational records throughout the relationship.

What should be included in a co-managed IT service agreement?

At minimum, consider including:

In-scope services, systems, users, devices, and locations
A responsibility matrix or RACI
Coverage hours and service levels
Ticketing, approval, escalation, and emergency procedures
Access-control, logging, and revocation terms
Security-incident notification and cooperation provisions
Reporting and governance arrangements
Pricing, exclusions, and change rules
Tool, data, credential, and documentation rights
Project acceptance criteria where relevant
Contract length, termination, knowledge transfer, and transition assistance

The agreement should make each material outcome traceable to an accountable owner. Qualified advisers should review the final terms for the organization’s legal, regulatory, security, insurance, and commercial circumstances.

The decision should not begin with an MSP package or promised benefit. It should begin with a documented diagnosis of the organization’s capacity, expertise, coverage, strategy, governance, and architecture gaps.

If co-managed IT fits that diagnosis, define the responsibility matrix, access rules, escalation process, performance measures, total cost, and exit obligations before work begins. A well-defined arrangement can extend an internal team while preserving its business knowledge and authority. A vague arrangement can create another layer of expense and accountability risk.