--- 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 keeps ownership and direction with the internal team while a provider supplies capability, coverage and tooling. This page explains how the model works, which organisations it suits, where it fails, and the accountability question that has to be answered before signing. 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 blueAPACHE sits blueAPACHE offers 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.