Co-managed IT: how to split the work with an MSP

Co-managed IT is what happens when an organization already has its own IT person or team and brings in a managed services provider to work alongside them. Done well, it gives your internal staff more depth, more tools and more time for the work only they can do. Done badly, it creates two teams that each assume the other one is handling something, and a gap where problems sit until a user complains.

I manage service delivery at Ceifa, and a good share of that is co-managed work. The difference between the arrangements that run smoothly and the ones that cause friction almost never comes down to technical skill. It comes down to how clearly the work is divided, how the two teams share information, and whether they treat each other as colleagues.

Why organizations choose co-managed IT

The reasons vary, but they usually fall into a few patterns:

• A one-person IT department that cannot take a vacation without things piling up, and has nobody to think problems through with.
• An internal team that is strong on the business and its applications but does not have the time or tooling for patching, monitoring, backup checks and security alerts across every device.
• Growth that has outpaced the team, where the helpdesk queue is eating the time that should go to projects.
• Specialist gaps in areas like firewalls, network design or security, where it does not make sense to hire full time.

Whatever the reason, the goal is the same: the internal team keeps ownership of the business relationship and direction, and the provider adds capacity and process underneath.

Common ways to split the work

There is no single correct model. These are the three I see most often, and many arrangements are a blend.

The provider runs the helpdesk, internal IT runs projects

Users call or email the provider for day-to-day issues. Internal IT handles new systems, vendor relationships, business application support and anything that needs deep knowledge of how the organization works. This frees the internal team from the interruption-driven work that makes projects slip.

Internal IT is the front line, the provider is the escalation and the engine room

Users go to the person they know. That person escalates to the provider for anything beyond their depth or capacity, and the provider handles the background work: patching, monitoring, backup verification, security tooling and network gear. This model suits organizations where staff value having a familiar face on site.

Split by area

The provider owns specific domains, such as the network and firewalls, or endpoint security and backup, while internal IT owns the rest. This is clean on paper but needs very clear boundaries, because real problems rarely respect them.

Write down who owns what

The single most useful document in a co-managed arrangement is a simple responsibility table. For each area, one column says who does the work, and another says who needs to be told. It does not need to be elaborate. Areas worth listing:

• User support, by type: password resets, hardware faults, application issues, requests for new access
• New hires and departures, including who disables accounts and collects devices
• Patching for workstations, servers and network devices, and who approves reboots
• Monitoring alerts: who receives them and who acts on each kind
• Backup, including restore testing
• Security alerts and incident response
• Firewall and network changes
• Purchasing, warranties and licence renewals
• Vendor management for line-of-business software
• Documentation and passwords

The point is that every line has exactly one owner. "Both" is not an owner. When two teams share responsibility for something, it tends to be done twice or not at all.

Share the tooling, not just the work

Co-managed IT falls apart quickly when each team works from its own system and nobody can see what the other did. A few things make a real difference:

• One ticket history. Ideally both teams work in the same ticketing system. If that is not possible, agree how tickets move between them so that a user's issue is never lost in a handoff.
• Shared visibility into monitoring and patching. Internal IT should be able to see the same device health, patch status and alerts the provider sees. Hidden dashboards breed suspicion.
• One set of documentation. Network diagrams, configurations, vendor contacts and procedures live in one place both teams can edit.
• Named admin accounts. Every person with administrator access gets their own account. No shared "admin" logins, so every change can be traced to someone.
• A shared change log. Before anyone changes a firewall rule, a group policy or a server setting, it is recorded. Most "it worked yesterday" problems in co-managed environments trace back to an unrecorded change by one side.

Escalation goes both ways

People usually picture escalation as internal IT handing a hard problem up to the provider. That happens, but the reverse matters just as much. The provider will regularly hit something that needs internal knowledge: why a particular application is configured a certain way, who in finance can approve a change, whether a user's strange access is actually expected.

Agree on the route in both directions. Who on the provider side does internal IT call when something is urgent? Who internally does the provider contact, and who is the backup when that person is away? For critical issues, the answer should be a phone call, not a ticket comment that waits to be read.

It also helps to agree what each side can decide alone. A provider technician should be able to isolate an infected laptop without waiting for permission. They probably should not reorganize your file permissions without talking to you first.

Avoiding turf problems

The most common source of friction is not technical. It is an internal IT person who worries the provider is there to replace them, or a provider that behaves as if the internal team is in the way. A few habits prevent most of it:

• The internal team stays the face of IT to leadership. The provider supports their recommendations rather than going around them.
• No surprises. Neither side makes changes in the other's area without telling them. If the provider sees something wrong in an area internal IT owns, they raise it with internal IT first.
• Regular check-ins. A short standing meeting, weekly or every two weeks, to walk through open issues, upcoming changes and anything stuck. It is the cheapest insurance against misunderstandings.
• Shared credit and blameless reviews. When something goes wrong, the conversation is about what failed in the process, not whose fault it was.
• Knowledge flows both ways. The provider should leave the internal team stronger: explaining fixes, sharing documentation, involving them in projects.

When leadership sets this tone at the start, by explaining that the provider is there to support the internal team rather than replace it, most of the tension never appears.

Keep one security baseline

One area that should not be split loosely is security. Two teams with different ideas about multi-factor authentication, admin rights or patch timing will leave gaps. Agree on one standard and apply it everywhere. At Ceifa we apply one security baseline to every managed client, and in co-managed arrangements we agree up front how it fits with what the internal team already has in place.

Frequently asked questions

Does co-managed IT mean my internal IT person will be replaced?

It should not. The purpose is to add capacity and specialist depth so your internal staff can focus on the work that needs their knowledge of the business. A good provider supports your internal team rather than competing with it.

Should both teams use the same ticketing system?

Ideally, yes. One ticket history means nothing gets lost between teams and everyone can see what was done. If that is not possible, agree on a clear handoff process so every issue has a single owner at any moment.

Who should get monitoring alerts in a co-managed setup?

Decide by alert type and write it down. Often the provider receives and triages all alerts and escalates the ones that need internal knowledge, while internal IT keeps visibility of everything.

How often should the two teams meet?

A short check-in every week or two works for most organizations, plus a broader review of priorities and upcoming projects every quarter.

How Ceifa works with internal IT teams

Our co-managed IT service is built for organizations that already have IT staff and want more depth behind them. We agree the split of responsibilities with you, share our tools and documentation, and work as an extension of your team. If you want to talk through what that would look like for you, contact us. If you would rather hand over IT entirely, our managed services cover it end to end.