Co-Managed IT: Where the MSP and IT Team Split Work

Co-managed IT is not just extra helpdesk

Co-managed IT is a working arrangement where an internal IT team keeps responsibility for some functions while an MSP takes responsibility for others.

That sounds simple. In practice, the difficult part is deciding exactly where the boundary sits.

A company might keep desktop support and office infrastructure internally while the MSP handles after-hours monitoring, Microsoft 365 administration, cybersecurity and specialist projects. Another company might keep security and architecture in-house but outsource the service desk, patching and infrastructure operations.

Neither model is automatically better. The useful question is whether the split matches the skills, capacity and risk of the business.

The worst version of co-managed IT is two teams doing the same job with different tools and no clear owner. The best version gives the internal team more capacity without creating another layer of confusion.

That means the contract should describe responsibilities in operational terms. "IT support" is too vague. "MSP handles Level 1 tickets, Microsoft 365 administration and server patching; internal IT owns application support and final approval for privileged access" is much more useful.

Start by dividing responsibilities

Before choosing an MSP, make a list of the work your IT team actually performs.

Do not start with job titles. Start with activities.

For example:

Function	Internal IT	MSP
User support	Primary	Overflow
Service desk	Owns	After-hours
Microsoft 365	Shared	Administration
Endpoint management	Shared	Operations
Patching	Approval	Execution
Network	Primary	Specialist support
Cybersecurity	Oversight	Monitoring
Backup	Oversight	Operations
Projects	Business owner	Technical delivery
Strategic planning	Primary	Advisory

This is only an example. Your split may look completely different.

The important point is that each responsibility needs an owner. "Shared" should not mean "everyone assumes somebody else is doing it".

Take patch management. The internal team may decide which systems can be patched and when. The MSP may execute the updates and report failures. That is a sensible split.

But if a patch fails on a critical server, somebody must own the escalation. If nobody owns that step, the division of responsibility has created a gap.

The same applies to security alerts. If the MSP monitors an EDR platform but the internal team is responsible for incident decisions, the escalation route needs to be explicit.

Co-managed IT therefore starts with a responsibility matrix, not a marketing package.

Where co-managed IT makes sense

The strongest use case is usually a company that already has capable IT staff but has a capacity or coverage problem.

An internal team may understand the business extremely well but have limited time for security operations, patching, cloud administration or projects. Hiring another specialist for every gap is expensive and can create a team that is difficult to keep busy outside a narrow area of work.

An MSP can fill those gaps without taking ownership of everything.

This can work particularly well for:

After-hours coverage. Your internal team handles normal business hours while the MSP monitors critical systems outside those hours.

Specialist skills. The internal team understands the business applications while the MSP provides expertise in areas such as Microsoft 365, networking, cloud platforms, security or backup.

Overflow support. A major project, staff absence or sudden increase in tickets can overwhelm a small IT team. An MSP can absorb some of the workload.

Security operations. Internal IT may own security decisions while the MSP operates monitoring, endpoint controls or vulnerability management.

Infrastructure projects. The internal team remains the business owner while the MSP supplies additional engineering capacity for migrations, upgrades or redesigns.

Routine operations. Patching, backup checks and device maintenance can consume significant operational time even when nothing is going wrong. Moving some of this work to an MSP allows internal staff to concentrate on higher-value work.

A managed IT service desk can be used for a defined support boundary rather than replacing the entire internal IT function.

The key is that the MSP should add capacity or capability, not simply create another queue.

The tools and processes have to meet in the middle

Co-managed IT often fails because the teams operate as separate islands.

If the internal IT team uses one ticketing system and the MSP uses another, information can disappear between them. If the internal team monitors endpoints but the MSP independently changes security policies, nobody has a complete picture.

You need shared visibility.

That does not necessarily mean both teams need identical tools. It means each side must have access to the information required to perform its responsibilities.

Tickets need clear ownership and escalation. Changes need records. Device information needs to be accurate. Security alerts need a defined path from detection to decision.

Access also needs to be controlled carefully.

An MSP may require privileged access to perform its work. That does not mean every technician should have unrestricted administrator access to every system.

Use named accounts where possible. Apply MFA. Limit privileges according to the work being performed. Review access periodically, particularly when personnel or responsibilities change.

The same principle applies to the internal team. Co-managed IT is not a reason to give everyone administrator rights simply because multiple teams need to troubleshoot problems.

A good security posture review can help identify these ownership and control gaps before they become operational problems.

What people get wrong about co-managed IT

The first mistake is thinking co-managed means "our IT team tells the MSP what to do".

That creates an expensive technician-on-demand arrangement rather than a properly designed operating model.

The MSP should have clearly defined responsibilities and authority within its scope. If it is responsible for patching servers, for example, it needs the access, maintenance windows and escalation process required to do that job properly.

The second mistake is outsourcing the unpopular work while keeping all the accountability internally.

If the MSP owns backup operations, the contract should define what it monitors, what constitutes a failure, how failures are escalated and how restore testing is handled. Simply paying someone to "manage backups" does not transfer the business risk.

The third mistake is creating overlapping responsibility.

Suppose both the internal team and MSP are responsible for endpoint security. Who approves policy changes? Who investigates alerts? Who isolates a device? Who communicates with management during an incident?

If those questions have no clear answers, the arrangement will become messy during the exact situation where clarity matters most.

The fourth mistake is treating the MSP as a competitor to the internal team.

That creates defensive behaviour. Internal staff may withhold information because they are worried the MSP will replace them. The MSP may then lack the context required to operate effectively.

The relationship works better when both parties understand their boundaries and the business measures the combined IT function rather than individual teams.

The fifth mistake is assuming co-managed IT automatically costs less.

It can be financially sensible, but the objective is not simply to minimise the monthly invoice. You are buying capacity, specialist knowledge, coverage or operational consistency.

If the internal team still has to redo the MSP's work, the cheaper contract is not actually cheaper.

What to actually do in order

First, document what the internal IT team does today. Include support, identity, Microsoft 365, endpoints, networks, servers, cloud, security, backups, vendors and projects.

Second, identify the gaps. Separate them into capacity, coverage, specialist knowledge and strategic capability. These require different solutions.

Third, decide what you want the MSP to own. Avoid vague phrases. Define the actual tasks and systems.

Fourth, establish who makes decisions. The MSP may execute a technical change, but the business may still need to approve the risk, timing or cost.

Fifth, define escalation. For every critical function, specify what happens when the normal process fails. This is particularly important for security incidents, failed backups, critical outages and privileged-account issues.

Sixth, align the tools. Make sure ticketing, documentation, monitoring and asset information can be shared without creating unnecessary duplication.

Seventh, define access properly. Use named accounts, MFA and least privilege. Decide which MSP roles can access which systems and how that access is reviewed.

Eighth, establish measurable service expectations. These might include ticket response, escalation times, patch compliance, backup monitoring, project reporting or security-alert handling. Do not measure only ticket volume. Measure whether the underlying work is being completed.

Ninth, review the arrangement regularly. A company with 50 employees may need a very different split after it grows to 150. The right operating model changes as the business changes.

For organisations considering offshore delivery, the same principles apply. Geographic location is secondary to ownership, coverage, access control, communication and measurable responsibilities. A Sri Lankan delivery team can work with an overseas internal IT function, but the operating model still needs to define who owns each decision and how escalation works.

The practical goal is straightforward: keep the capabilities that genuinely benefit from being inside the business, and use the MSP where external scale, coverage or specialist expertise makes more sense.

Co-managed IT is not about having two IT departments. It is about building one operating function with two contributors and no gaps between them.