Co-managed IT: who owns what between your IT lead and an MSP?
If you already have a capable internal IT lead, the question is not whether to replace them. It is whether a managed service provider can remove the work that keeps dragging them away from business priorities.
Co-managed IT can work well when the internal lead keeps business context and decision authority while the provider adds service-desk capacity, specialist skills, monitoring and project delivery.
It fails when both sides assume the other owns the same risk. A user request sits in two queues. A security alert is seen but nobody is authorised to act. A project starts without a named decision-maker. Holiday cover exists in theory, not in the operating process.
The useful buyer question is: who owns each result, who does the work, and who makes the final call? This guide gives Brisbane and South East Queensland businesses a practical starting map.
What does co-managed IT actually mean?
Co-managed IT is a shared operating model. Your employee or internal team remains responsible for agreed business-facing work, while an external provider owns agreed technical or delivery functions. The exact split is negotiated; there is no universal version that fits every business.
For some organisations, the internal lead handles priorities, applications and staff relationships while the provider runs day-to-day support, Microsoft 365 administration, device management and security monitoring. For others, internal IT keeps frontline support and uses the provider for escalation, projects, security depth and leave coverage.
That is different from fully managed IT, where the provider takes broader day-to-day responsibility, and different from project consulting, where a supplier delivers a defined outcome but does not own the ongoing environment.
Connected Platforms' managed IT service page describes both fully managed arrangements and work alongside an internal IT coordinator. The proposal and agreement should still name the exact responsibilities.
A practical responsibility map
Use this as a discussion tool, not a ready-made scope. Every row should end with one accountable owner, a backup owner, an escalation path and a measurable service expectation.
| Area | Internal IT can retain | The provider can own | Joint decision |
|---|---|---|---|
| User support | Business context, VIP priorities and requests that need an internal decision. | Service desk, triage, technical resolution, escalation and ticket reporting. | Request channels, priority rules, handoffs and who updates the user. |
| Microsoft 365 and identity | Approval for access, role changes and business-data ownership. | Administration, configuration, user changes and agreed security controls. | Permission model, exceptions and change authority. |
| Devices and patching | Business standards, purchasing approval and exception decisions. | Device management, health visibility, operating-system and approved third-party patching. | Supported-device standards and replacement priorities. |
| Security operations | Business risk decisions, policy ownership and executive communication. | Covered endpoint, identity, email and security-monitoring services within the agreement. | Incident authority, escalation contacts and after-hours boundaries. |
| Backup and recovery | Business recovery priorities and acceptable downtime or data loss. | Microsoft 365 backup and monitoring of selected server and workstation backup products where included. | Recovery objectives, testing and any separately scoped disaster-recovery work. |
| Vendors and licences | Commercial approval, business relationships and application ownership. | Technical coordination with approved internet, phone and software suppliers. | Renewals, changes, responsibility gaps and supplier escalation. |
| Projects and change | Business case, stakeholder alignment and acceptance of the result. | Technical design and delivery for separately approved work. | Scope, assumptions, price, owner, timing and acceptance criteria. |
| Planning and budget | Final priorities, budget recommendations and business decisions. | Technology options, risk visibility, roadmap inputs and costed recommendations. | The 12-month plan, sequence and named next actions. |
Connected Platforms' published AGE case study shows one version of this split: the internal IT lead retains context, oversight and technology direction; Connected Platforms handles most day-to-day support and agreed project delivery; both teams plan together. It is an example, not a universal template.
Five ways co-managed IT goes wrong
Two queues, no owner
Users choose whichever contact feels faster. Requests are duplicated, missed or bounced between teams. Publish one intake path and one handoff rule.
Access without authority
The provider can see the environment but cannot approve a change; internal IT assumes the provider will act. Document technical access and decision authority separately.
Security language stays vague
“24/7 monitoring” does not automatically mean a staffed user helpdesk or unlimited after-hours labour. Define what is monitored, who is called and what action is authorised.
Projects leak into support
A migration, integration or office move becomes a stream of informal tickets. Separate ongoing support from project scope, price and acceptance.
The internal lead gets sidelined
The provider starts making business-facing decisions without context, or management bypasses its own IT lead. Keep internal accountability explicit.
Co-managed, fully managed or project-only?
| Model | Best suited to | Main advantage | Main trade-off |
|---|---|---|---|
| Co-managed IT | A business with a capable internal IT lead or small team that needs capacity, coverage or deeper technical skills. | Keeps internal context while adding a wider delivery team. | Requires disciplined role, queue and escalation design. |
| Fully managed IT | A business that wants one provider accountable for day-to-day support, management, security coordination and planning. | A simpler responsibility model for management and staff. | Costs more than occasional help and can be excessive for a simple environment. |
| Project or consulting support | A capable internal team with a defined migration, security uplift, review or specialist problem. | Buys targeted expertise without changing ongoing ownership. | Does not solve recurring service-desk capacity or leave coverage. |
If you only need a defined piece of work, IT consulting may be cleaner than forcing the need into a managed-service contract.
How should you compare co-managed IT costs?
Do not compare an employee salary with a provider's monthly fee as if they buy the same thing. Salary is only one part of internal capacity; a provider fee may include people, tools, licences, monitoring and service management. The reverse is also true: an external fee does not replace the business knowledge, authority and relationships held by a good internal IT lead.
Connected Platforms' current public benchmark for its fully managed service is $310 per supported user each month, with onboarding quoted separately and typically about $4,400. That is not a published co-managed rate. A co-managed proposal should reflect the work your internal team keeps, the work the provider owns, the included products and any separately approved projects.
Review the current managed IT pricing guide, service inclusions and standard agreement before comparing the headline numbers.
Eight questions to settle before signing
- Which team owns the first response for each request type?
- Who has authority to approve access, security and configuration changes?
- What stays in the recurring fee, and what becomes separately approved project work?
- What does the provider monitor after hours, and what action can it take?
- Who owns backup monitoring, recovery priorities and recovery testing?
- How are holidays, sickness, resignations and major incidents covered?
- Which system is the source of truth for tickets, assets, documentation and roadmap actions?
- What evidence will management receive that the shared model is working?
Co-managed IT is usually a good fit when
- Your internal IT lead knows the business but is overloaded by support or project demand.
- You need broader technical depth without removing internal accountability.
- Leave coverage, escalation or security monitoring has become fragile.
- Management is willing to define decision rights and use one operating process.
It may be the wrong fit when
- You only need a single project or occasional specialist advice.
- Your internal team and provider cannot agree who owns priorities or user communication.
- You expect unlimited work without a defined recurring scope and project boundary.
- You want to outsource accountability while keeping every decision informal.
Start with the responsibility map, not the tool list
Before comparing products or ticket volumes, map the work your internal IT lead must retain, the work that needs a wider team, and the decisions management will still own. Then ask each provider to price that exact operating model.
If you want to test whether co-managed, fully managed or project support fits your business, book a call with Connected Platforms. We will map the responsibilities first and say plainly if a different model makes more sense.
Book a Call