What a Co-Managed IT Agreement Should Cover

Co-managed IT agreements fail in the gaps. Two teams, one environment, and a dozen tasks that each side assumed the other was doing. The fix is not a longer contract. It is a short list of questions answered in writing before anyone signs.

This is the list we hand to IT managers and business owners before they meet us or anyone else. Take it into the vendor meeting. If a provider cannot answer a question plainly, that is your answer.

1. Which endpoints are in scope, by name

Co-managed IT is usually priced and delivered per enrolled endpoint, so the agreement should say exactly which devices are enrolled: servers, workstations, laptops, network gear, cloud workloads. “All company devices” is not a scope; it is an argument waiting to happen when a contractor’s laptop shows up on the network.

Ask how enrollment changes. Can your team add a device without a change order? What happens to a device that is retired? The answer should be mechanical, not a negotiation.

2. Who does what, task by task

Write the split down as a table, not a paragraph. At minimum:

• Patching: operating systems, third-party applications, firmware. Who schedules, who executes, who verifies.
• Alert response: who sees endpoint and security alerts first, who closes them, and what gets escalated to whom.
• Helpdesk: who takes the user’s call, and under what conditions a ticket moves to the other team.
• Backups: who configures, who monitors, who performs restore tests, and how often.
• User onboarding and offboarding: who creates accounts, who removes them, and how fast.
• Projects: how they are scoped, estimated, and approved before work starts.

On our co-managed IT page the default split is that our engineers take alert response and patch remediation on enrolled endpoints during business hours, and your team keeps the user relationships and the business decisions. Your split may differ. The point is that it exists.

3. Who owns the tools and the licenses

Co-managed arrangements run on a shared stack: remote monitoring, endpoint protection, a ticketing system, documentation. The agreement should state who holds each license, whose name is on each vendor account, and what happens to the data in each tool if the agreement ends.

This matters more than it sounds. If the provider owns the endpoint protection license and you part ways, every device is unprotected the day the agreement ends unless the transition is planned. If the ticket history lives in the provider’s system, your team loses years of context. Ask for export rights in writing.

4. How escalation actually works

Escalation is where co-managed IT earns its keep or falls apart. The agreement should name the path: your technician hits a wall, then what? A phone number? A ticket queue with a response target? A named engineer?

Ask who on the provider’s side knows your environment. A co-managed arrangement where every escalation lands with a stranger reading documentation for the first time is a helpdesk with extra steps.

5. What “after hours” means

This is the clause most often assumed and least often read. Define business hours. Define what happens outside them: is there an emergency line? Does an engineer call back, and within what window? Does the provider work the problem or just acknowledge it? Is after-hours work included or billed separately?

The right answer depends on your business. A medical practice and a law firm have different definitions of emergency. What matters is that the definition is in the agreement and your team knows the number to call before the night it is needed.

6. Coverage when your team is out

Your IT person will take a vacation. Someone will be out for surgery. The agreement should say what the provider does during those windows: full coverage of your ticket queue, including end users? A reduced scope? Nothing?

Good co-managed providers let you book a coverage period and take the whole queue while your team is away. If a provider cannot describe how that works, your IT person is never really going on vacation.

7. Documentation: who writes it, who owns it, who can read it

Insist on three things. The provider documents your environment, keeps it current, and gives your technicians read access to it at all times. Documentation that lives only in the provider’s head, or behind a login your team does not have, is a dependency rather than an asset.

Ask what the documentation covers: network diagrams, server roles, application owners, vendor contacts, credential storage locations. Ask how often it is reviewed. The honest answer is tied to a recurring consultation, not “whenever something changes.”

8. The security split

Security is where split accountability is most dangerous, because an attacker does not care whose job it was. The agreement should state plainly who is responsible for:

• Monitoring: is a security operations center watching, during what hours, and who do they call when they see something?
• Response: who isolates a compromised device, who investigates, who decides when to involve counsel or the insurer?
• Identity: who manages multifactor authentication and access reviews?
• Email security and user training: who owns them?

If the provider operates a security operations center, ask whether it runs around the clock and where its analysts sit. Then ask what happens when the SOC calls at 3 a.m. and your IT person’s phone is off. Our cybersecurity services page describes how we handle that; whoever you choose should be able to answer it just as specifically.

9. Reporting your leadership can actually read

You should receive reporting on a cadence that matters to you, written for the people who approve the budget rather than for engineers. Ask to see a sample before signing. If it is a forty-page export of ticket counts, your CFO will never read it, and the agreement will be judged on anecdotes instead of evidence.

10. Pricing that moves for stated reasons

Per-endpoint pricing should move when the endpoint list moves and for no other reason. Project work should be estimated and approved in advance. Ask whether there is an onboarding fee and what it covers. Ask what happens to the price at renewal. None of these answers need to be zero; they need to be known.

11. How it ends

Every agreement ends eventually. The exit terms decide whether that is a handover or a hostage situation. The agreement should cover notice periods, transfer of administrative credentials, export of ticket history and documentation, and the handling of any licenses in the provider’s name.

Ask the provider to describe their last offboarding. A provider who has handled a clean exit will describe it readily. One who has not will change the subject. If you are leaving a current provider to start a co-managed arrangement, our switching IT providers page covers the transition from the other direction.

12. Who you will actually be working with

Finally, meet the engineers, not just the salesperson. Co-managed IT is a working relationship between your technicians and theirs. If the people on the call cannot speak to how they would handle your environment, the agreement is only as good as the paper.

The one-page version

Scope by device. Tasks by name. Tools and licenses by owner. Escalation by path. After-hours by definition. Coverage when you are out. Documentation your team can read. Security responsibilities split in writing. Reporting on your cadence. Pricing that moves for stated reasons. Exit terms. Real engineers.

Any provider worth signing with will welcome the list. Cyber Command answers every item on our co-managed IT page and in the first meeting, and we would rather lose an agreement on a clear answer than win one on an assumption.