Co-Managed IT: Does Your Existing IT Person Need More Support?

Managed IT & Buying Guidance

Updated July 12, 2026

By Jerame Trunnell Owner of Cloud Core MSP

Co-managed IT adds an outside technical team without replacing the person who already owns IT inside the business. It fits when that internal person has valuable business knowledge and trust but cannot reasonably provide every specialist skill, project, security function, and coverage window alone. The decision is not whether the employee is “good enough.” It is whether the organization has given that person enough capacity and depth to carry the role safely.

What co-managed IT means

In a co-managed model, the organization deliberately keeps selected responsibilities with internal IT and assigns other work to a managed provider. The internal person may continue to own business alignment, user relationships, application priorities, site knowledge, and change context. The provider may supply a service desk, monitoring, after-hours response, backup operations, security specialists, cloud or network engineering, or project capacity.

This is different from fully managed IT because the internal role remains an active part of the operating model. It is also different from calling a consultant only when something breaks. Both teams should know their recurring responsibilities, decision rights, escalation paths, and evidence obligations before work begins.

Signs your existing IT person needs more support

Look for structural gaps, not a single difficult week. Co-managed IT deserves consideration when several of these conditions persist:

Coverage depends on one person: vacations, illness, training, or after-hours incidents leave no informed backup.
Urgent support repeatedly displaces planned work: lifecycle, documentation, security, and improvement projects remain open because daily requests consume the schedule.
Specialist work is unavoidable but intermittent: cloud architecture, identity security, network redesign, incident response, or recovery testing is needed without justifying every specialty as a full-time hire.
The same person performs and validates critical controls: leadership lacks an independent check on privileged access, backups, patches, alerts, or major changes.
Growth is outpacing operating discipline: new sites, users, applications, vendors, or compliance demands are added faster than standards and documentation can follow.
Key knowledge is trapped: credentials, configurations, vendor history, and recovery steps are not usable by a backup person.

These signals do not automatically require an MSP. Leadership might hire another employee, reduce scope, standardize systems, or use project specialists. Co-managed IT is strongest when the gap is recurring and spans several capabilities or coverage windows.

Five fit questions for leadership and internal IT

What should the internal person keep? Identify work where business context, relationships, or decision authority creates real value.
What is consistently uncovered? Name the exact hours, tasks, skills, projects, or independent checks that are missing.
Will the provider strengthen or bypass internal IT? The model should give the employee visibility, useful escalation, and authority appropriate to the role.
Can both teams work from shared evidence? Tickets, assets, documentation, credentials, configurations, alerts, and exceptions must not disappear into separate black boxes.
Who resolves disagreement? Leadership must name the accountable person for priority, risk, scope, and high-impact change decisions.

Include the existing IT person in this assessment. A model designed around that employee without their operational input is likely to misdiagnose the real bottleneck and create resistance for rational reasons.

When co-managed IT is the wrong fit

Do not use co-management to avoid a needed performance conversation, leave an undefined executive ownership gap, or buy a long list of tools without deciding who operates them. The model commonly fails when:

the provider markets itself as a replacement while leadership tells the employee it is only support;
both teams can open tickets but neither owns recurring problems through resolution;
internal IT loses access to documentation, administrative systems, or service evidence;
the contract lists products but not outcomes, boundaries, exclusions, and escalation;
the provider receives every difficult task while internal IT remains overloaded with intake and vendor coordination; or
leadership expects shared accountability to remove the need for a named decision-maker.

Protect the internal role before adding a provider

Write a short role charter for the internal person before negotiating the outside scope. State the outcomes they own, decisions they can make, business relationships they lead, evidence they should receive, and skills or projects the added capacity should help them develop. This prevents the provider’s standard package from quietly defining the employee’s future role.

Then map recurring work into service lanes: service desk; identity and access; endpoints; network and connectivity; cloud platforms; backups and recovery; vulnerability and patch management; security monitoring and incidents; line-of-business vendors; projects and change; asset lifecycle; and documentation. For each lane, define:

the outcome and systems in scope;
normal hours, after-hours expectations, and exclusions;
who performs routine work and who approves high-impact work;
what creates an escalation and how quickly a human must acknowledge it;
which system stores tickets, configurations, credentials, and evidence;
how failures, exceptions, and recurring problems reach leadership; and
how the lane transfers during absence, termination, or a provider change.

CISA’s Risk Considerations for Managed Service Provider Customers emphasizes understanding shared responsibilities, contracts, data handling, incident management, and supplier risk. Apply those questions even when an internal IT employee remains involved; adding a second team does not remove the customer’s need to govern the service.

Implementation handoff: a compact operating boundary

Use a RACI that reflects decisions, not job titles

RACI means Responsible, Accountable, Consulted, and Informed. “Responsible” performs the task. “Accountable” owns the outcome and decision; use one accountable party per row. “Consulted” provides input before action, and “Informed” receives the result. A person can hold more than one role, but writing both teams as jointly accountable usually hides the exact decision the matrix is supposed to expose.

NIST’s current NICE Framework components describe cybersecurity work through tasks, knowledge, skills, work roles, and competency areas. Use that task-level thinking instead of assuming one broad title such as “IT manager” or “MSP engineer” proves the required capability exists.

Copyable implementation handoff

Service lane: [identity, endpoints, network, backup, security, vendor, project, or other]

Outcome and scope: [observable result; included systems, sites, and users]

Responsible: [person/team that performs normal work]

Accountable: [one person with decision authority]

Consulted: [required input before high-impact action]

Informed: [who receives status, result, and exception notice]

Escalation trigger: [severity, elapsed time, risk, or failed dependency]

Approval boundary: [change type and named approver]

System of record: [tickets, credentials, configuration, assets, logs]

Evidence and cadence: [artifact, owner, review frequency, retention]

Absence and exit path: [backup owner, access transfer, documentation export]

Create one record for each material lane, then test it with a real scenario. For example: an identity alert arrives after hours while the internal lead is unavailable. The artifact should reveal who sees the alert, who can disable access, who determines business impact, where evidence is retained, and who communicates. If the answer still requires a phone-tree debate, the boundary is incomplete.

Unify evidence without surrendering control

Choose authoritative systems for tickets, assets, documentation, credentials, configurations, and monitoring. Both teams need enough visibility to perform their roles and challenge bad assumptions. Define export rights and an offline or independently controlled break-glass path for essential credentials. Supplier concentration matters: NIST SP 800-161 Revision 1 recommends integrating cybersecurity supply-chain risk into strategy, policies, plans, and assessments rather than treating a provider as an unexamined extension of the organization.

Evidence should show service behavior: asset coverage and exceptions, access changes, patch and vulnerability status, backup and restore results, security events, recurring incidents, project decisions, and unresolved risks. CISA’s voluntary Cross-Sector Cybersecurity Performance Goals can help smaller organizations prioritize high-impact safeguards, but the parties must still decide who performs, verifies, and accepts exceptions for each practice.

Design incident escalation as a joint operating path

Do not write “MSP handles security incidents” as one RACI row. Break the path into detection, triage, containment recommendation, containment authorization, evidence preservation, business-impact assessment, legal and insurer notification, communications, recovery validation, and lessons learned. NIST SP 800-61 Revision 3 embeds incident response across cybersecurity risk management. Your co-managed design should do the same: prevention, detection, response, and recovery responsibilities must connect.

What good co-managed support should change

Work items transferred without reassignment, duplicate effort, or missing context.
Escalations acknowledged by the correct decision-maker with evidence attached.
Service lanes with a tested backup owner and current documentation.
Recurring incidents that receive root-cause ownership instead of repeated closure.
Projects advanced without displacing critical operations or security work.
Exceptions reaching an accountable owner before their approved review date.

Set targets from your own baseline and business requirements. A co-managed model is working when ownership is clearer and capacity is more resilient, not merely when ticket counts move from one queue to another.

Related implementation guides

Use the detailed Co-Managed Service Operating Model Checklist, sequence knowledge and access transfer with the First 90 Days Provider Onboarding Guide, and establish evidence-based governance through Managed IT Reporting and Quarterly Reviews.