Co-managed IT: how it works when you have an internal IT person

Short answer: Co-managed IT is a shared-responsibility model where an MSP fills specific gaps around an internal IT person rather than replacing them. The internal person usually keeps the high-context work – user relationships, vendor coordination, strategic IT, day-to-day helpdesk. The MSP layers in what one person cannot realistically do alone – 24/7 security monitoring, after-hours coverage, advanced tooling, specialist knowledge, and backup for vacation or illness. For SMBs in the 50-to-200 employee range with one to three internal IT staff, co-managed typically costs $60 to $150 per user per month – significantly less than hiring a second or third internal person, and usually produces better operational outcomes than a full MSP replacement would.

If you have one IT person and they are drowning, the instinctive answer is “hire a second one.” The economic answer is often “co-manage instead.” This article covers what co-managed IT actually means in practice, the common models, how to split scope cleanly so there is no confusion, when co-managed is the right fit, when it is not, and what the cost comparison really looks like against the alternative of another full-time hire.

What co-managed IT actually is

Co-managed IT (sometimes called co-managed services, CoMITS, or hybrid IT) is an engagement model where an MSP provides defined services alongside an existing internal IT function. Both parties share responsibility for the IT operation, but they are doing different things. Done well, the MSP fills capability gaps, the internal person retains context and strategic ownership, and users get a materially better IT experience than either party could deliver alone.

It is distinct from two other common models:

Fully managed IT replaces internal IT entirely. The MSP is the IT department. There is no internal IT role beyond a business-side liaison (often the CFO, COO, or office manager).

Outsourced project work is one-time or narrow-scoped external engagement – an M365 migration, a firewall replacement, a compliance audit – bolted onto an internal team for a specific deliverable. It is not ongoing.

Co-managed sits in between: ongoing, shared, defined by scope rather than by the complete absence or presence of internal IT. The MSP vs in-house comparison is the baseline either-or framing; co-managed is what happens when neither binary answer fits.

When co-managed is the right answer

Co-managed tends to be the right model when one or more of these patterns applies:

One IT person is overwhelmed but a second hire cannot be justified. The existing person is working 50+ hours, carrying every domain (helpdesk + security + networking + compliance + strategy), and increasingly dropping balls on the less-visible work. A second hire costs $110K to $145K fully loaded. A co-managed engagement at $60 to $100 per user per month for a 75-person business costs $54K to $90K annually – and usually covers more ground than a second hire would, because the MSP brings multiple specialists instead of one generalist.

Internal IT is senior enough to run strategy but too stretched for operations. The IT director or internal lead is the right person to design the roadmap and manage vendor relationships, but they cannot also be the person who patches servers at 11pm or triages malware alerts at 3am. Co-managed offloads the operational layer to the MSP while the internal lead keeps authority over direction.

The business needs 24/7 coverage but only has business-hours internal staffing. Security incidents, system outages, and account compromises happen off-hours. One internal IT person cannot be on-call 168 hours a week. A co-managed engagement typically includes MSP after-hours and weekend coverage for P1 incidents while the internal team owns business-hours work.

Compliance or security requirements exceed internal capacity. Regulated industries often need SOC 2 readiness, HIPAA security rule management, CMMC preparation, or continuous vulnerability management that a generalist internal IT person cannot run alone. The MSP brings the specialized security function without requiring you to hire a dedicated security engineer.

The business is growing faster than IT hiring can keep up with. From 40 users to 100 users in 18 months is a common SMB growth pattern. Co-managed lets the internal team scale with the MSP’s capacity rather than racing headcount against growth.

There is a specific gap the internal person cannot fill. Sometimes the gap is narrow – cloud architecture, networking, Microsoft 365 advanced configuration, backup operations. Co-managed lets you buy exactly the specialty you need without hiring a full person.

When co-managed is not the right answer

Co-managed has real failure modes. Situations where it usually does not work:

The internal IT person is not senior enough to run the relationship. Co-managed requires someone on the client side who can evaluate MSP work, coordinate scope, and push back when the MSP is doing something wrong. A junior tech who is the only IT person in the company typically cannot do that. In those cases, fully managed IT often works better – the MSP runs the full picture, the business hires someone senior when ready.

The internal IT person is territorial or resistant. Co-managed involves giving up control of some domains. If the internal person sees the MSP as a threat rather than a force multiplier, the relationship usually fails – not because the MSP is bad, but because overlapping responsibilities without cooperation create gaps and duplication. Start with a conversation with the internal person before signing anything.

Scope cannot be cleanly defined. If you cannot write down in a page who owns what, co-managed will produce constant confusion. “The MSP kind of handles security, except the parts we do” is not a workable scope. Either define clearly or use a model with clearer lines.

The business does not have enough headcount to justify both internal and external IT. A 20-person business rarely benefits from both. Pick fully managed or pick internal, not both. Co-managed starts being economically rational somewhere around 50 users, depending on industry.

Internal IT and MSP tooling conflict. If the internal person insists on one RMM or one EDR and the MSP is standardized on a different one, running both creates operational headaches. This is solvable at the contract stage – but if neither side will budge, co-managed does not work.

Common co-managed models

Several common patterns for splitting scope. Most engagements are a variation on one of these, adapted to the specific business.

Model 1: MSP owns security and tooling, internal owns helpdesk and operations

The most common co-managed pattern in 2026.

MSP responsibilities:

• 24/7 security monitoring (EDR, MDR, SOC services)
• Email security management
• Backup operations and testing
• After-hours on-call for P1 incidents
• Security baseline maintenance (patching cadence, MFA policy, conditional access)
• Compliance-related activities (evidence collection, audit preparation)
• Specialized consulting (cloud architecture, network design, migrations)
• Security tooling licensing and management (RMM, EDR, MDM)

Internal IT responsibilities:

• Day-to-day helpdesk for business-hours tickets
• User onboarding and offboarding (with MSP automation)
• Hardware procurement and deployment
• Line-of-business application relationships
• Vendor management for non-IT technology
• Strategic IT roadmap and budgeting
• User training and policy enforcement

This split works because the internal person owns the high-context, user-facing work while the MSP owns the infrastructure-heavy, specialist, or 24/7 work. Users have one face for day-to-day requests. The MSP is invisible to most users unless something big happens.

Model 2: MSP provides after-hours and overflow, internal owns business hours

For businesses that need 24/7 coverage but have strong internal capacity during the workday.

Business hours (internal):

• All helpdesk
• All monitoring and response
• All project work
• Strategic planning
• Vendor coordination

After-hours (MSP):

• P1 incident response
• Monitoring escalation after internal business hours
• Weekend coverage
• Holiday coverage
• Vacation coverage for key internal staff

This model is cheaper than full co-managed because MSP engagement is narrower. For a 100-person business with a 2-person internal IT team, expect $40 to $70 per user per month depending on the after-hours SLA tightness.

Model 3: MSP provides a specific specialty, internal runs operations

The internal team runs the business, and the MSP fills one specific gap.

Common specialty engagements:

• Cybersecurity operations (SOC, MDR, incident response)
• Cloud architecture and Microsoft 365 advanced configuration
• Compliance operations (SOC 2, HIPAA, CMMC)
• Network engineering (firewall, switch, wireless architecture)
• Backup and disaster recovery

This is the narrowest model. Pricing is either a flat monthly retainer for defined scope, or a per-hour block arrangement. For a 75-person business with strong internal IT engaging an MSP for security operations alone, expect $20 to $40 per user per month.

Model 4: MSP provides bench depth, internal owns the day

The business has one or two internal IT people who handle the core work. The MSP provides specialist capacity on demand – for escalations, for projects, for coverage during absences.

This is the loosest model. Scope is defined by a retainer (“up to X hours per month of MSP labor across defined specialties”) rather than by continuous service. Pricing is typically a monthly retainer plus overage rates. For a 50-person business with one internal IT person, expect $2,500 to $8,000 per month retainer depending on included hours.

Model 5: Tooling-only co-managed

The MSP provides tooling (RMM, EDR, backup, MDM, security stack) and licenses, but the internal team operates it. The MSP provides vendor management, tuning, support, and escalation when the internal team hits a wall.

This is sometimes called “MSP tools, internal operations.” It is cheap – $30 to $60 per user per month – but only works when the internal team has the capacity and skill to run the tooling properly. Most SMBs that try this version end up with underused tooling because operating EDR, MDR, and backup at the level they need requires more specialization than a generalist internal IT person can maintain alongside everything else.

How to split scope without confusion

The single biggest failure mode in co-managed IT is overlap and gap – two parties both thinking they handle something, or neither handling it. Avoiding this requires a written scope document that everyone signs off on.

The scope matrix

Build a matrix with every IT domain on the rows and four columns: Internal owns, MSP owns, Shared, Escalation path. A domain is “shared” only when both parties genuinely contribute (rare – use sparingly). Most domains should be cleanly internal or cleanly MSP.

Domain	Internal	MSP	Shared	Escalation
Helpdesk tier 1 (password resets, login issues, common app support)	X			Internal first, MSP on ticket aging >4 hours
Helpdesk tier 2 (complex app issues, specific configuration)	X			MSP on internal tier 2 escalation
EDR monitoring and incident response		X		MSP first, internal informed
Email security alerts and tuning		X		MSP first, internal informed
MFA policy and enforcement		X		MSP designs, internal supports users
Backup operations		X		MSP first, internal on restore requests
Patch management		X		MSP runs, internal coordinates application-specific windows
User onboarding	X			Internal runs, MSP automates provisioning
User offboarding			X	Internal initiates, MSP executes technical steps
Hardware procurement	X			Internal owns, MSP advises on specs
Hardware deployment	X			Internal owns, MSP on enrollment automation
M365 admin		X		MSP manages, internal approves policy changes
Line-of-business app admin	X			Internal owns vendor relationships
Network monitoring		X		MSP alerts, internal on network troubleshooting
Firewall policy changes			X	Internal requests, MSP implements
Compliance evidence collection		X		MSP runs, internal signs off
Strategic IT planning	X			Internal leads, MSP provides input
After-hours P1 response		X		MSP leads, internal informed
Vendor escalation (non-IT tech)	X			Internal owns

This is a template, not a prescription. Your matrix will differ. The key is that every domain has exactly one primary owner, and the escalation path is explicit.

Tooling ownership clarity

Separate question: who owns the tooling? Four patterns:

MSP tooling, MSP operated. MSP brings RMM, EDR, MDM, etc. under their licensing. Internal team has read access for visibility but MSP operates the platforms. This is the cleanest split.

MSP tooling, shared access. MSP brings the tools but both teams have write access. Useful when internal IT wants operational visibility and the ability to resolve tier 1 issues without escalation. Requires clear “who touches what” rules.

Internal tooling, MSP operates. Business already owns the tooling licenses. MSP operates the platforms under their labor engagement. Less common but valuable when the business has specific tooling requirements.

Internal tooling, internal operated. Tooling-only co-managed model. MSP provides licensing and support, internal operates.

The first pattern is the easiest and most common. Deviation from it should be deliberate and documented.

Ticket routing and escalation

Where tickets land is a frequent source of confusion. Either:

• All tickets start internal. Users call internal IT. Internal IT decides what to handle and what to escalate to MSP. MSP visible to users only through specific escalations.
• Split routing by category. Password resets and app help go internal; security alerts and incidents route directly to MSP. Users may see both.
• All tickets start MSP. MSP is the front door. Internal IT is consulted on context-heavy tickets. Uncommon in co-managed but possible.

Pick one. Document it. Train users on it. Do not let tickets flow through whichever channel happens to be answered first.

The cost comparison vs hiring a second IT person

The math that drives most co-managed decisions.

Scenario: 75-person professional services firm

Current state: One internal IT person making $95K base, $125K fully loaded. They are overwhelmed, working 50+ hours, and the business is either considering a second hire or considering an MSP.

Option A: Hire a second IT person

• Second mid-level IT hire, $95K base, $125K fully loaded
• Additional tooling (since both now need visibility): $8K/year
• Training, certifications: $4K/year
• Total Year 1: $137K

Capacity gained: one more person doing the same mix of work. Still 40-hour business-hours coverage. Still no specialization depth. Still no after-hours coverage. Still vulnerable to either person’s illness, vacation, or departure.

Option B: Co-managed IT (Model 1)

• MSP co-managed engagement at $80 per user per month for 75 users: $6,000/month = $72,000/year
• No second IT hire
• Internal person keeps current role, now focused on high-context work
• Total Year 1: $72K

Capacity gained:

• 24/7 security monitoring and response
• After-hours and weekend P1 coverage
• Specialist depth (security engineers, cloud architects, compliance specialists as needed)
• Backup coverage for internal person’s time off
• Enterprise-grade tooling without separate licensing
• Vendor management for MSP-managed tooling

Difference: co-managed saves $65K in year one AND delivers broader coverage than the additional hire would.

Scenario: When the second-hire math actually works

Co-managed is not always the right answer. The second-hire math wins when:

• The business is large enough to fully use two internal people ($200+ employees, usually)
• The work is heavily user-facing and context-dependent (internal people outperform MSPs for high-context work)
• Compliance or data sensitivity requires work to happen in-house (defense contractors, some healthcare, some legal matters)
• The business wants the IT function to be wholly owned and controlled internally for strategic reasons

In these cases, hire. In most SMB cases with 50 to 200 employees and a single overwhelmed IT person, co-managed produces better outcomes for less money. For the broader comparison framework, see MSP vs in-house IT.

Common co-managed failure modes

Even when co-managed is the right model, the execution can go wrong. Watch for these patterns.

Shadow work from the internal IT person. They keep doing things they were supposed to hand off, either because they do not trust the MSP or because they feel threatened. The business pays for both teams to do the same work. Fix by giving the internal person a clear elevated role (IT manager, IT director, strategic IT lead) that does not require them to also be tier 1.

MSP doing minimum-viable under the contract. The internal person delivers heroic effort, the MSP delivers exactly what the SOW requires and nothing more. Over time the internal person burns out while the MSP looks satisfactory on paper. Fix by tracking outcomes against service quality, not just SLA compliance, in quarterly business reviews.

Users confused about who to call. Users go to internal for one kind of problem and MSP for another, then the categories get blurred, then they just call whoever they reached last time. Fix with a single front door for user tickets and let the internal/MSP split happen behind the scenes.

Documentation drift. Internal keeps their own documentation. MSP keeps their own documentation. Neither is complete. When something breaks, nobody can find the answer quickly. Fix by putting everything in one system (usually the MSP’s documentation platform, shared with internal read and limited write access).

Unclear ownership of new tooling or projects. A new line-of-business app needs to be rolled out. Who deploys it? Who supports it? Who patches it? Fix by adding new scope to the matrix explicitly at rollout, not after the fact.

Internal IT single point of failure. Internal person leaves. The MSP only knows their slice. Critical context walks out the door with the internal person. Fix by requiring the internal person to document as they go and by having the MSP participate in periodic knowledge transfers.

Rising overlap as business grows. Work that started clearly split gets fuzzy as the business adds complexity. Fix by reviewing the scope matrix annually in QBRs and rewriting as needed.

Setting up a co-managed engagement

If you are considering co-managed, work through these steps before signing.

1. Decide internally whether co-managed is the right model. Have the conversation with your internal IT person first. Their buy-in is not optional. If they are resistant, either address it head-on (reframe the role, give them authority over the MSP, find the right internal role for them) or pick a different model.

2. Write the initial scope matrix yourself. Before talking to any MSP, write down what you want the split to look like. This forces you to think through what you actually need rather than letting the MSP frame it.

3. Evaluate MSPs on co-managed specifically. Most MSPs do fully managed. Fewer do co-managed well. The questions to ask:

• How much of your business is co-managed vs fully managed?
• Walk me through a co-managed engagement that has been running for 2+ years. What worked, what broke?
• How do you handle scope disputes with internal IT?
• What does your onboarding look like when the client has an internal IT team?
• How do you support, rather than undermine, an internal IT lead? (Full list of MSP evaluation questions here.)

4. Document the scope matrix with the incoming MSP. Your matrix meets their operational reality, and the two get reconciled into a signed scope document that is part of the MSA.

5. Plan for a 90-day stabilization period. Co-managed onboarding is like regular MSP onboarding with one additional wrinkle: getting the split to actually work in practice. Expect the first 90 days to involve several scope adjustments as edge cases surface. That is normal. The full MSP onboarding flow applies here too.

6. Track both efficiency and quality in the first QBR. How has the internal IT person’s workload changed? Are tickets being resolved faster? Is the internal person doing the strategic work the business hired them for? If the answer is no, revisit the scope matrix.

7. Review annually. Co-managed relationships drift. Scope that fit two years ago may not fit today. Make scope review a standing QBR topic.

Co-managed IT costs in context

For budgeting purposes:

Scenario	Typical monthly cost	Annual cost
50-user business, Model 1 (security + ops)	$3,500-$6,000	$42K-$72K
75-user business, Model 1	$5,000-$8,500	$60K-$102K
100-user business, Model 1	$6,500-$11,500	$78K-$138K
150-user business, Model 1	$9,500-$17,000	$114K-$204K
75-user business, Model 2 (after-hours only)	$2,500-$4,000	$30K-$48K
75-user business, Model 3 (security specialty)	$1,500-$3,000	$18K-$36K

The ranges are wide because co-managed scope varies significantly. For pricing model mechanics (per-user vs retainer), see how MSPs are paid. For how this fits into the full IT budget, see the small business IT budgeting guide.

How Sequentur approaches co-managed engagements

Sequentur is a security-first MSP / MSSP for small and mid-sized businesses across the 15-to-250-employee range, including both general SMBs and regulated industries like healthcare, legal, financial services, and defense contractors. Roughly a quarter of our ongoing engagements are co-managed rather than fully managed – businesses in the 50-to-200 employee range with one to three internal IT staff who want specialist depth, 24/7 coverage, and backup without expanding internal headcount.

Our co-managed engagements start with a written scope matrix as part of the MSA. We prefer Model 1 (MSP owns security and tooling, internal owns helpdesk and operations) because it is the cleanest split and plays to each side’s strengths, but we run Model 2, 3, and 4 as well depending on the fit. Tooling is ours under our licensing, operated by our team, with read access for the internal team. Documentation lives in our platform, shared with the internal IT lead. Ticket routing is defined at onboarding and documented for users.

We have a stated commitment to supporting rather than undermining internal IT leads. Scope disputes, when they happen, get escalated to your internal lead and our account manager for resolution in writing. We do not undermine the internal person to users or to leadership, and we expect internal leads to do the same with us. Co-managed is not a gradual replacement strategy on our side.

If you have an internal IT team and are thinking about whether co-managed makes sense, schedule a call. We will walk through your current split, your gap areas, and what the scope matrix would look like for your specific environment. If the better answer is hiring a second internal person, or fully managed, or staying as you are, we will tell you that too.