Co-managed IT is a setup where your in-house IT staff keep running your technology and an outside provider takes on agreed parts of the work, usually monitoring, patching, overflow help desk and security. Nobody is replaced. The point is coverage your team cannot give on its own.
It sits between two models most people already know. With fully in-house IT, your own staff do everything. With fully managed IT, a provider runs it all and you may have no IT staff at all. Co-managed IT is the middle path, and it only works when both sides know exactly where their half ends.
What co-managed IT means in practice
Your internal team stays in charge. They know the business, the people and the systems that make money, and that knowledge is hard to replace. The partner adds what a small team runs out of: hours, specialist depth and cover when someone is on vacation or out sick.
In a typical arrangement the internal team keeps:
- Strategy, budgets and vendor decisions
- The line-of-business systems only they understand
- Day-to-day relationships with department heads
- Final say on changes to anything critical
The partner usually takes:
- Around-the-clock monitoring and alert triage
- Patching and routine maintenance on a schedule
- Help desk overflow, so tickets do not wait on one busy person
- Security work that needs specialist time, such as hardening and reviews
Co-managed vs fully managed vs in-house IT
The three models differ less in tools than in who owns the outcome.
- In-house IT. Your staff run daily IT, set direction and cover after hours through whoever is on call. It fits large teams with depth in every area.
- Co-managed IT. Your staff run daily IT and set direction, with a partner on agreed tasks and after-hours cover. It fits one or a few IT people stretched thin.
- Fully managed IT. The provider runs daily IT and after-hours cover, and sets direction with you. It fits businesses with no dedicated IT person.
Managed IT services and in-house IT are not really rivals. The question is how much of the load your own people should carry, and which parts they are best placed to keep.
Who does what: a sample split
This is where most co-managed arrangements succeed or fail. A written split, agreed before work starts, avoids the "I thought you had that" moment. A starting point:
- Help desk. Shared first contact; the partner takes overflow and after hours. Agree which tickets go where.
- Patching and updates. Your team approves timing; the partner applies and reports. Agree the maintenance windows.
- Backups. Your team owns the policy; the partner runs them and tests restores. Agree who signs off a restore test.
- Security monitoring. The partner watches alerts around the clock; your team receives the reports. Agree who acts on a live incident.
- Microsoft 365 administration. Your team owns licenses and access; the partner handles routine changes. Agree who can create admin accounts.
- Compliance evidence. Your team owns the audit; the partner supplies logs and records. Agree where the evidence is stored.
Your version will look different. What matters is that every row has a name in it and nobody has to guess.
When co-managed IT fits
Co-managed IT tends to fit when most of these are true:
- You have at least one capable IT person, and they are the bottleneck
- Tickets wait when that person is busy, away or asleep
- Security work keeps slipping behind urgent fixes
- You need a specialist skill for a project, not a full-time hire
- You want to keep internal knowledge in-house rather than hand it all over
Fully managed IT is usually the better fit when nobody inside the business owns IT, or when the "IT person" is really an office manager covering it on the side. In that case a co-managed split leaves the internal half of the table empty.
The objections worth taking seriously
Ask IT managers about co-managed IT and the same worries come up. They are fair worries, and a good arrangement answers each one in writing.
"We will lose control"
You should not. The internal team sets priorities and approves changes to critical systems. If a partner needs to make changes without asking, the agreement should say which ones, in advance.
"The partner will lock us out of our own tools"
Insist that you own your accounts. Admin credentials, monitoring dashboards and documentation should stay accessible to your team at all times, and leaving the arrangement should never mean losing your own data or history.
"When something breaks, everyone will blame each other"
This is the one that hurts most, and the fix is the split above. Name who leads on each kind of incident, how the other side is pulled in, and who talks to the business while it is being fixed. Agree it before the first outage, not during it.
"They will not understand our setup"
Then the onboarding was too short. A partner should spend real time learning your environment and writing it down before taking any work on.
How a good handoff works
A co-managed arrangement starts with documentation, not tickets. Expect the first weeks to cover:
- Discovery. Every system, account, vendor and dependency, written down.
- Access. Named accounts for the partner, never a shared login, with multi-factor authentication (MFA) on every one.
- Runbooks. How routine tasks and common incidents are handled, step by step, so either side can follow them.
- Escalation. Who is called, in what order, for what kind of problem.
If a provider wants to skip straight to taking tickets, that is a warning sign. The documentation they build is also yours to keep.
Compliance: who holds the evidence?
When two teams share IT work, compliance gets one extra question: whose records prove a control actually happened? Under HIPAA, GDPR or NIST, an auditor wants evidence, not intentions, and evidence split across two ticket systems is easy to lose.
Decide early where logs, access reviews and backup test records live, and make sure your internal team can produce them without waiting on the partner. Our post on the compliance questions you should be able to answer covers the basics, and our cybersecurity and compliance work is built around the same frameworks.
Questions to ask before you sign
- Which tasks will you own, and which stay with us, in writing?
- Who leads during an incident, and how are we kept informed?
- Do we keep full admin access to every tool you use on our systems?
- What does onboarding cover, and what documentation do we get?
- If we end the arrangement, what do we take with us?
A provider that answers these clearly is one you can share the work with. One that gets vague on access or exit terms is telling you something.
What to do next
Start with the split. List what your team handles today, mark what keeps slipping, and you will know whether you need a partner for part of the load or for all of it.
If you would rather hand over more of it, our managed IT service lays out what we take on, and for businesses in the city there is a page on managed IT services in NYC. Either way, you reach a real engineer, not a ticket queue, and a conversation is the quickest way to see what fits.