Picture a payroll application employees can’t access. Internal IT checks their devices. An outside provider checks the sign-in system. The software vendor asks for logs. Everyone has done something, but nobody has agreed who supplies the logs and follows up.

The scenario is hypothetical. The buying question behind it is real: when you add outside help, what work actually leaves your team’s plate?

Co-managed IT services divide agreed technical responsibilities between your internal team and an outside provider. The arrangement can add capacity, specialist skills or coverage while your team stays close to the systems and decisions it knows best. How much it helps depends on how you divide the work, including the handoffs between teams.

CTMS offers support alongside an existing internal IT team, including help desk overflow, cybersecurity support, Microsoft 365 management, monitoring and project guidance. The engagement determines which responsibilities CTMS takes on.

If you’re still deciding whether to hire or outsource, start with our comparison of internal, outsourced and co-managed IT. This guide picks up after that decision: what to delegate, and how to make the division work.

What should you outsource when you already have IT staff?

Start with the work your team can’t finish consistently, the skills it needs only occasionally, and the responsibilities that rest on one person’s availability. Define a specific assignment before you shop for a package.

Use these examples to shape a proposal. They’re possible allocations, not CTMS contract terms.

If this is the gap	Consider delegating	Keep explicitly assigned inside the business
User requests keep displacing planned work	Defined request types or help desk overflow during agreed hours	Business priorities, application context and the trigger for routing work outside
A difficult issue exceeds internal expertise	Specialist diagnosis and agreed remediation	Business impact, access authorization and approval of disruptive changes
Monitoring creates more alerts than the team can investigate	Named monitoring, triage and response duties	Risk decisions and any actions reserved for internal approval
Coverage depends on one employee	Specified duties during leave or agreed additional hours	Current procedures, a backup approver and any required physical access
A project exceeds available capacity	Scoped planning, execution or specialist tasks	Acceptance criteria, business decisions and ownership after delivery

Business priorities, spending decisions and acceptance of business risk stay with authorized people in your organization. Internal IT can advise or coordinate without holding those approvals.

For each proposed assignment, ask what your team still has to supply. If your team must investigate every request before the provider accepts it, count that retained work when you judge the capacity you’re buying.

Agree who moves unfinished work forward

Back in the payroll example, three assignments need a named owner:

1. Coordination: Who tracks the combined issue, follows up with the vendor and updates the business?

2. Execution: Who collects the requested logs and performs the next technical step?

3. Approval: Who can authorize access, spending or a change that affects operations?

One person can hold more than one assignment. Coordinating an issue doesn’t automatically grant permission to change a system.

Before you sign, ask both teams to walk through the same unresolved issue. Each should be able to name the current coordinator, the next action, who owns it and what’s blocking it. Agree on when stalled work escalates and who receives it.

Then test the handoff itself. What tells the current coordinator that the other team has accepted responsibility? What happens if the receiving team declines the work, lacks access or doesn’t respond?

Google’s incident management guidance calls for an explicit, acknowledged transfer of incident command. The outgoing commander states the handoff and stays on the call until the incoming commander firmly acknowledges it. Routine support doesn’t need Google’s full incident process. The principle worth borrowing is narrower: telling another team about work and transferring responsibility for it are two different events.

Write the fallback into the agreement. An unaccepted ticket needs a defined escalation route, including what happens when the current team’s hours end.

Test coverage when the usual employee is unavailable

A second hypothetical: your administrator is on leave. The provider receives an infrastructure alert, but the recovery instructions are out of date and the only listed approver is the person who’s away.

A technician is available. The coverage gap is still open.

Before you rely on absence coverage, walk through the work with the people expected to perform it. Confirm they can use their authorized access, find current instructions and reach a backup decision-maker. Note any actions that need someone physically present, and who that will be.

Check the service hours for each delegated function. Collecting an alert overnight, investigating it overnight and having permission to make a corrective change are three different commitments. None of them is implied by the phrase “co-managed IT support.”

For a closer look at hours, response definitions and unfinished work, see our guide to IT support response and escalation commitments.

Decide what happens when approval is missing

A third hypothetical: the provider recommends a security policy change that could affect a critical application. Internal IT understands the technical work, but the business approver is unavailable. The ticket sits in pending while each team assumes the other is chasing a decision.

Buying more technical capacity doesn’t supply missing business authority.

For changes like this, agree on who explains the impact, who obtains approval and who escalates an unanswered request. Separate work that’s authorized in advance from work that needs a fresh decision. Document emergency authority and its limits before anyone needs it. Silence shouldn’t become permission.

NIST’s incident response guidance recommends writing incident response roles into policy and giving each party the authority to carry out its duties. Where a provider takes on part of the work, it says those responsibilities should be defined clearly in the contract, along with the division of duties, information flows, coordination and the provider’s authority to act for the organization. That guidance is written for cybersecurity incidents. The broader buying lesson is to pair every assignment with the authority to carry it out.

If approval still isn’t available, record the limitation, the escalation owner and any interim measures that are already authorized. A pending status shouldn’t hide an unresolved business decision.

Check access and tools before transferring work

A provider can’t perform an assignment without the required access. That doesn’t mean every technician needs unrestricted administrative rights.

Ask how access is scoped to the assigned work, and how it’s approved, authenticated, logged, reviewed and removed. Confirm how your business retains authorized recovery access to its systems if the relationship changes. Establish where both teams can see the relevant work records, even if they use different ticketing systems.

Tool decisions need the same specificity. List which product handles each function, which policies are active, who receives alerts and who can change settings. Agree on who investigates conflicting automation before either team adds or removes software.

For example, Microsoft’s guidance on running Defender for Endpoint alongside other security tools explains that configuration choices reduce overlap between products, that responsibility for a function falls to the product actively providing it, and that protection gaps need active management as tools change. That’s a product-specific example, not a reason to strip out every overlapping tool.

Ask the provider what it would keep, replace or reconfigure in your environment, why, and how it would verify each change. Include licensing dependencies and the work your internal team will still perform.

Ask for evidence before relying on the arrangement

A responsibility table is a starting point. A walkthrough can help identify assignments the proposed access, staffing or service hours may not support.

Request evidence suited to the work you plan to delegate:

1. A sample work record showing the current coordinator, next action, approval status and accepted handoff. Use one of your own open issues, or ask for an example with other clients’ information removed.

2. A readiness walkthrough that demonstrates the required access, instructions, routing and backup contacts for the covered duties.

3. Agreement wording that matches those duties, including exclusions, additional charges and work that requires a separate project.

4. Exit terms covering business records, configuration exports, tool and license dependencies, access removal and transfer of unfinished work. Confirm formats, assistance, fees and notice requirements.

Record any unresolved prerequisites and who will clear them before the affected responsibility transfers. Don’t assume either team will absorb uncovered work.

The walkthrough may also point to a different answer. A single finite project may call for a project engagement rather than ongoing co-management. If the obstacle is an unavailable approver or an undocumented application, fix that dependency as part of the plan. And if the onsite coverage you need can’t be provided at your locations, the scope needs to change.

Bring CTMS the work your team needs help covering

Start with one real gap: requests that keep displacing planned work, a specialist issue your team can’t resolve, or a responsibility with no dependable backup.

Bring the affected systems, locations, required hours and the work your team intends to keep. That gives CTMS a concrete basis for discussing whether co-managed IT support fits and what the engagement would need to cover.

CTMS supports organizations nationwide through remote services. Onsite support depends on location, scope and need, so confirm it for your operation as part of that conversation.

Discuss co-managed support for your existing IT team with CTMS.