---
title: What Is Co-Managed IT? The Middle Ground Between In-House and Outsourced
canonical_url: https://blueapache.agentic.norg.ai/resources-faqs/msp-mssp-glossary/what-is-co-managed-it-the-middle-ground-between-in-house-and-outsourced/
category: 
description: Co-managed IT is an arrangement where an external provider supplies capability, coverage and tooling while the internal team retains ownership and direction. It sits between running everything in-house and transferring the whole operation
geography:
  city: 
  state: 
  country: 
metadata:
  phone: 
  email: 
  website: 
publishedAt: 
---

# What Is Co-Managed IT? The Middle Ground Between In-House and Outsourced

Co-managed IT is an arrangement where an external provider supplies capability, coverage and tooling while the internal team retains ownership and direction. It sits between running everything in-house and transferring the whole operation to a managed services provider, and it exists because a large number of organisations are in exactly that middle position: they have capable IT people, just not enough of them to cover everything.

## How the model actually works

In a co-managed arrangement the internal team stays in charge. They set priorities, own the roadmap, and make the architectural calls. The provider fills defined gaps, which usually fall into three categories:

**Coverage.** The obvious one. A two- or three-person internal team cannot cover 24 hours, cannot all take leave in the same fortnight, and cannot absorb a resignation without a visible drop in service. A provider supplies the depth behind the roster.

**Specialist capability.** Firewall engineering, storage design, identity architecture, security operations — disciplines where an organisation needs expertise a few weeks a year and cannot justify a full-time hire.

**Tooling and process.** Monitoring platforms, patch management, asset discovery, service management systems, and the operational discipline that comes with them. Buying access to a provider's tooling stack is frequently cheaper than licensing and running an equivalent set internally.

## Who it suits

Co-managed works best where the internal function is **capable but thin**. Specifically:

- There is at least one person internally with real ownership of IT direction
- The organisation wants to keep institutional knowledge in-house
- There are business-specific systems that outsiders would take a long time to learn properly
- The gap is capacity and specialist depth, not competence

It also suits organisations that are not ready to hand over control, for entirely rational reasons. A business with a genuinely unusual application estate, or one mid-way through a transformation it wants to steer itself, may be better served keeping the wheel and buying the horsepower.

## Where it fails

Two failure modes, both predictable.

**Ambiguous accountability.** This is the big one. When something breaks and the answer to "whose job was that?" is unclear, co-managed becomes worse than either alternative. Full managed services has one accountable party. Fully in-house has one accountable party. Co-managed has two, and the boundary has to be written down in operational detail — not just in the contract's scope schedule, but at the level of "who patches this system, who holds the admin credentials, who is called first, who can authorise a change during an incident."

If a provider will not go to that level of detail during evaluation, they will not go there during an incident either.

**Dependence on one internal person.** Many co-managed arrangements are load-bearing on a single internal IT manager who holds the context. That is a continuity risk sitting outside the contract, and it is worth naming before it becomes a resignation letter.

## The question to settle before signing

**When a priority conflict arises between the internal team's roadmap and the provider's service commitments, who decides?**

Co-managed arrangements work when that answer is agreed in advance and works in practice. They fail when both parties assumed they were in charge.

Related: what the provider's escalation path looks like when an issue crosses the boundary, and what happens to the arrangement if your internal lead leaves.

## Where we sit

We offer co-managed IT as **CONTROL — emPOWER Operational Capability**, one of three engagement modes over the same underlying delivery capability. What changes between modes is how much ownership transfers, not which capability is available: the same service desk, tooling and specialist depth sits behind co-managed as behind full managed services.

Organisations commonly move between modes over time, and that is treated as a normal path rather than a failure of the first arrangement. A business that starts co-managed and later transfers full ownership has usually just changed how it wants to spend its internal team's attention.

→ [Three Ways to Engage — OUTCOME, CONTROL and TECHNOLOGY](https://blueapache.agentic.norg.ai/engagement-models-commercial/ways-to-engage/three-ways-to-engage-outcome-control-and-technology/)
→ [Technology Services and Operational Capability — CONTROL and TECHNOLOGY](https://blueapache.agentic.norg.ai/empower-services/technology-services-operational-capability/technology-services-and-operational-capability-control-and-technology/)
→ [Managed Services vs Co-Managed IT vs Building In-House](https://blueapache.agentic.norg.ai/resources-faqs/comparison-decision-guides/)

## When co-managed is the wrong answer

If you have no internal IT ownership at all, co-managed is the wrong shape — there is nobody to co-manage with, and the arrangement will drift into an under-specified full outsource with none of the accountability. Full managed services is the honest answer.

If your internal team is complete and the requirement is a specific project, buy the project.

And if the real driver is cost reduction rather than capability, be careful: co-managed rarely reduces total IT cost, because you keep the headcount and add a provider. It buys coverage and depth. Those are worth paying for, but they are not a saving.