Your decision to change IT delivery is already made. The harder question is what to change to. Co-managed IT, fully managed IT, and internal IT each promise control, coverage, and accountability, but they distribute responsibility very differently. The right managed IT services model is not the cheapest option on a proposal. It is the one your internal team can genuinely own, given its bench strength, and the one your systems’ criticality and control requirements can tolerate. Choose poorly, and you recreate the same gaps, escalations, and outages you just paid to escape.
This comparison walks through the choice in practical terms. You will start with the change you already committed to, then clarify what co-managed, fully managed, and internal IT really mean. Next, you will see the responsibility split, a side-by-side comparison, and how to assess internal bench strength, tier systems by criticality, and evaluate contract, SLA, access, and escalation needs. You will also review buyer profiles, the cost trap, red flags, and where Orloff Phillips fits. By the end, you will know how to match the MSP delivery model to your internal capacity.
Start With the Change You Already Committed To
You have already made the hard decision: something about how your IT is delivered has to change. The question now is narrower and harder. It is not whether to outsource IT. It is which delivery model your team can actually own and sustain.
Three managed IT services delivery models exist. Co-managed IT splits responsibility between your staff and a provider. Fully managed IT hands the operational stack to a provider that owns outcomes under a defined service agreement. Internal IT keeps everything with your staff, with outside help brought in on demand for projects, audits, or overflow.
Orloff Phillips’ advisory view is that this choice is a fit problem, not a persuasion exercise. The model that works is a function of internal bench strength and system criticality, not the lowest quote. Budget sets the ceiling. Fit decides the model.
That distinction carries real weight, because choosing the wrong model reproduces the failure you just paid to escape. A co-managed contract with no internal owner for the remaining half leaves the same gaps in place. A fully managed contract over systems you refuse to hand over recreates the same stalemate. And handing a provider privileged access without matching your access requirements can reintroduce risks you had already mitigated, as federal guidance on MSP threats to customer environments makes clear.
Treat the rest of this piece as a worksheet rather than an argument. Score your bench. Tier your systems. Define your control needs. Then match yourself to a buyer profile and a model. If you are building the plan around this decision, the same discipline behind building an IT strategy without a full-time CIO applies here: define what you can genuinely own before you sign for what you cannot.
What Co-Managed, Fully Managed, and Internal IT Really Mean
Before you can match a model to your capacity, you need a working definition of each option. Three delivery models dominate the choices buyers make across Exton, Philadelphia, Wilmington, Cherry Hill, Lancaster, and Reading PA.
Fully managed IT. The provider takes ongoing, proactive responsibility for infrastructure, applications, endpoints, and security across on-premises, cloud, and hybrid environments under a defined service agreement. You buy outcomes, not hours.
Co-managed IT. Responsibility is split. Your team keeps named ownership of specific layers, such as identity or internal application support, while the provider owns monitoring, patching, escalation, and specialist functions. Co-managed now stands as a recognized category in its own right in analyst market listings, including co-managed security monitoring services, so it deserves its own definition rather than being treated as a discounted version of IT outsourcing.
Internal IT. Your staff own the stack end to end. Outside help is episodic: project work, audits, architectural review, or overflow capacity. It is not day-to-day operations. Businesses that need executive-level judgment without a full-time hire often fill part of that gap through fractional CIO services.
The label matters less than the split. Two providers can both call themselves fully managed and still leave very different work at your door. Ask for the responsibility matrix in writing, and treat that document, not the marketing language, as the definition of what you bought. Everything that follows depends on that split, which is why the next step is mapping who owns each layer.
The Responsibility Split: Who Owns What in Each Model
The label on the contract is not the model. The model is which of nine layers each side actually owns: endpoints, servers, network, identity and access, backup and recovery, security monitoring, application support, vendor management, and reporting.
Build a two-column matrix and mark each layer with one of three states: provider-owned, jointly owned with a named internal owner, or internally owned with no provider involvement. That completed matrix is the delivery model, not the marketing language wrapped around it.
Co-managed. Every jointly owned layer needs a specific person on your payroll attached to it. “The team handles that” is not an owner, and it never survives a real incident. Nobody is accountable at 2 a.m., and the provider’s escalation stalls on your side of the split. This is a recurring source of shared responsibility confusion and where IT leaders get burned.
Fully managed. The provider owns the outcome and the evidence: documentation, runbooks, and reporting you can audit. If you cannot inspect it, you cannot rely on it, the same accountability principle that governs every outsourced layer.
Internal IT. You also own the consequences: after-hours coverage, patch cadence, documentation, and the succession problem when a key person leaves. Accountability does not transfer with the title.
Write the split down before you compare models. The next section turns that completed matrix into a side-by-side fit test.
Co-Managed vs Fully Managed vs Internal IT: A Side-by-Side Comparison
The responsibility matrix defines the shape of each model. Three variables decide which shape your organization can actually hold: bench strength required, system criticality, and control.
Bench Strength
Internal IT demands the most. Every layer needs a named owner, after-hours coverage, and documentation that survives turnover. Fully managed demands the least, because the provider staffs the work. Co-managed sits in the middle, and that middle is where agreements fail: revisit the responsibility matrix before signing. Where the gap is leadership rather than hands-on capacity, compare what a fractional CIO actually costs against the model change you are weighing.
System Criticality
Fully managed suits high-criticality, standardized stacks, where consistency and coverage beat customization. Internal IT suits environments where deep institutional knowledge of a proprietary or legacy system is the real asset. Co-managed suits mixed portfolios with a few specialist gaps, such as security monitoring or cloud architecture.
Control and Visibility
Internal IT gives total control with total accountability. Fully managed trades control for consistency and coverage, but you retain accountability (see CISA guidance). Co-managed lets you keep the high-stakes layers and hand over the rest.
Read this as a fit test, not a ranking. No model wins every row, and the winner changes as your bench and your systems change.
Assess Internal Bench Strength Before You Sign Anything
The table tells you which model fits. The next question is whether your team can actually staff its side of it. Here, count named people, not headcount.
How many staff can own a system end to end: documentation, vendor contact, escalation, patching? Of those, how many are single points of failure? A team of six with one person who understands identity is a team of one.
Test depth with three questions. Can they cover after-hours incidents? Can they patch and test without a vendor walking them through it? Can they tell a business leader no on technical grounds? A no on any of the three means the capability is partial, and a partial capability still lands on your payroll during an outage.
Then map skills against your actual stack: identity, network, endpoint, cloud, data, and security. List the layers where nobody holds real depth. Goodwill does not close those gaps, and neither does an escalation contact.
Attrition and hiring decide the rest. ISC2’s 2025 workforce study (16,029 respondents) found that skills needs are “no longer solved just by adding people,” and that under-resourced teams carry rising risk and burnout. As a rule of thumb, a role you could not backfill within 60 days is not a capability you genuinely own, it is a dependency you carry.
Write the answer down and date it, because memory rewrites this conversation within a month. The same discipline sits behind benchmarking your MSP before you decide to fix or replace them: scoring on paper converts a feeling into evidence. Orloff Phillips’ advisory experience is that failed MSP engagements usually trace back to an internal capacity claim that was never tested on paper.
That score rules out the models you cannot staff. Next, the systems themselves set the bar.
Tier Your Systems by Criticality, Not by Convenience
Your bench score tells you what your team can genuinely own. Your system tiers tell you which systems must be owned with no gaps. Assign every system to one of three tiers before you talk to any provider.
Tier 1. Failure stops revenue or breaches a legal or contractual obligation. Billing, payment processing, core ERP or clinical systems, and the identity platform everything else depends on. These need the strongest accountability and the shortest escalation path you can contract, in any delivery model. If a model cannot deliver that, the system does not belong in it.
Tier 2. Failure degrades operations, but a documented workaround exists. Shared responsibility works here only when the workaround and its named internal owner are both written down before signature. An unwritten workaround is not a workaround; it is an outage with extra steps.
Tier 3. Convenience and productivity systems. Lighter coverage is defensible, and this is where co-managed or internal ownership holds up best.
Score each tier on three dimensions: recovery time and recovery point objectives, regulatory exposure, and the blast radius if credentials are compromised. For a practical frame on understanding tier classifications and what they really mean, tie each tier to a business impact statement rather than a server list. Criticality is a business judgment, not a technical one. Finance and legal should agree on Tier 1 before your IT staff rank anything.
The model then follows the tier, not the vendor’s product bundle. A provider selling one flavor of coverage across all three tiers is describing how it is organized, not what you need. Let the tier set the accountability level, then choose the delivery model that meets it.
Control Needs: Contracts, SLAs, Access Control, and Escalation
Criticality tiers set the standard; the contract has to enforce it. Write SLA targets per tier in business terms: response and resolution windows, patch windows, reporting cadence, and the remedy when targets are missed. An SLA without a remedy is a statement of intent, not an agreement.
Decide access control before day one. Name which provider roles receive privileged access, how that access is granted and revoked, and what gets logged and reviewed. A 2022 joint advisory from CISA, NSA, and international cybersecurity agencies warns that MSP privileged access creates cascading risk, because one compromised provider account can reach multiple customer networks. Require MFA on every provider account touching your environment, disable stale accounts, and review authentication logs on a fixed cadence.
Write the escalation path with names and timescales. Who at your organization is woken at 2 a.m., and who at the provider answers the call? A shared inbox is not an escalation path.
Lock in knowledge transfer: documentation ownership, runbook update frequency, and exit assistance. If leaving a provider means rebuilding your environment, you are not a customer, you are a hostage. This is where aligning scope, accountability, and contract terms pays off.
Match governance weight to the model. Fully managed needs the tightest outcome reporting. Co-managed needs the tightest interface definition, because the seam between provider and internal team is where failures hide. Internal IT needs the strongest internal change control, because no provider exists to catch your mistakes.
Matching the Model to Your Capacity: Buyer Profiles
With governance terms settled, the last question is candid: what can your team actually staff? Most buyers evaluating managed IT services land in one of four profiles.
No dedicated IT staff. A small team with no internal IT function should run fully managed IT outsourcing across the operational stack. Add independent advisory oversight so the provider stays honest and the roadmap stays yours.
One or two capable staff. When you have real capability but specialist gaps, co-managed IT fits best. Your team owns identity, endpoint standards, and vendor relationships; the provider owns monitoring, patching, and escalation. Every shared layer still needs a named internal owner.
Strong internal team under pressure. Compliance deadlines or rapid growth strain even good teams. Keep internal IT with periodic external review, or use co-managed for the narrow layers your staff genuinely do not want to carry. A fractional CISO engagement often covers the compliance review without rebuilding the team.
Multi-site or regulated. Assign coverage per system or per site rather than signing one blanket agreement. A Tier 1 system may need fully managed accountability while Tier 3 stays internal.
For MSP for small business buyers across Greater Philadelphia, Exton, Wilmington, Cherry Hill, Lancaster, and Reading, weigh the local factor last. Proximity does not fix a responsibility split that no one internally can staff.
The Cost Trap: Why Price Should Not Pick Your Model
Buyer profiles tell you which model fits on paper. The next question is what it costs, and that is where most selections go wrong, because the quotes you receive will not be describing the same job.
A low fully managed bid and a high co-managed bid frequently cover identical work at different accountability levels. One price reflects a provider that owns patching, monitoring, and after-hours response; the other assumes your team handles them. Until you normalize every quote against a single responsibility matrix, layer by layer, you are comparing each provider’s assumptions about your staff, not its capability. Build the matrix first, then place the numbers beside it.
The real cost driver is the work your team cannot absorb. Understaffed co-managed agreements hide that cost until the first major incident, when the invoice arrives as downtime, overtime, and stalled projects. A quote that looks 20% cheaper is not cheaper if it quietly shifts 30% of the operational load back onto people who are already at capacity.
Orloff Phillips’ advisory view is that budget sets the ceiling, not the model. Fit against internal capacity and system criticality decides which delivery model you can run well and keep running.
Internal IT carries its own false economy. Salaries look fixed and predictable, which makes them easy to compare against a monthly managed services fee. Coverage gaps, attrition, and deferred projects never appear on a line item, yet they carry the same operational consequences as an unpaid invoice. Price is a constraint. It is not a selection criterion.
Where Orloff Phillips Fits in This Decision
If the cost trap shows that price cannot pick your model, the next question is who can. Orloff Phillips is an IT consulting and advisory firm, not a reseller. There is no seat count or product bundle to sell, which matters when the recommendation itself is what you are buying.
A typical engagement runs in four moves: score internal bench strength against your actual stack, tier systems by criticality, define the responsibility matrix and governance terms, then select or renegotiate the delivery model that fits. The deliverable is a document you can hold a provider to, not a proposal you are asked to sign.
For small and mid-sized businesses in Exton, Philadelphia, Wilmington, Cherry Hill, Lancaster, and Reading PA, that means an independent read on whether a proposed co-managed or fully managed structure is staffable by the team you actually have, not the team on a hiring plan. That read is where MSP relationships get cleaned up and aligned, because an unstaffable split is the failure that survives a provider change.
Where an existing provider is not the problem, advisory support also strengthens internal IT operations and unifies systems, so the model you choose stays sustainable through growth and turnover. With fit defined in writing, the warning signs of a mismatched model become far easier to spot.
Red Flags That You Chose the Wrong Model
Once you have scored your bench and tiered your systems, run the model you are considering against these five failure patterns. If any apply, the model was chosen on price or habit, not fit. Unwind the choice before the first major incident does it for you.
- Co-managed with a phantom owner. If the internal half of the split has no named owner, or the owner changes every quarter, you have bought a fully managed deal without the accountability. Name one person per jointly owned layer. If you cannot, the split does not exist.
- Fully managed, fully undefined. Unlimited scope language with no responsibility matrix covers everything in theory and nothing in practice. “We handle that” is not a definition. Ask which team, which ticket queue, and which SLA.
- Internal IT running on heroics. Key-person dependency, undocumented runbooks, and no after-hours coverage are not normal operating conditions; they are an outage with a scheduled date. If Tier 1 systems depend on one person’s memory, you do not own internal IT. You are borrowing it.
- Governance theater. Escalation paths in a managed IT services or MSP outsourcing agreement that end at a shared inbox, SLAs with no remedy, and reports delivered after the review has closed are the same tell. No one is accountable when systems go down.
- The same failure, new contract. Each flag above is a symptom of price- or habit-driven selection. Fix the fit.
Matching the MSP Delivery Model to Your Internal Capacity
The fix is sequence, not selection. Score before you shop.
Score your bench first, named owners, after-hours coverage, recovery-ready documentation, before you read a single proposal. That score, not a quote, eliminates the models you cannot run.
Then map each system to its tier and let the tier set the escalation standard, the definitions are already in place. Assign accountability per tier and let the tier pick the model for that system.
Only then compare providers. Build the responsibility matrix layer by layer, define SLAs with remedies attached for the tiers that need them, and put access control and escalation paths in writing, including who answers at 2 a.m. The joint advisory AA22-131A from CISA, NSA, and international partners recommends that MSP contracts explicitly identify ownership of security roles and responsibilities, and that customers verify contractual terms match their own security requirements. Treat that as a floor, not a finish line.
One rule closes the loop: if the internal side of a co-managed split has no owner, choose fully managed or shrink the scope until it does. A model you cannot staff is the failure you already paid to escape.
Conclusion
Choosing between co-managed, fully managed, and internal IT is not a shopping decision. It is a staffing and risk decision. The sequence is fixed: bench score, criticality tier, responsibility matrix, then provider selection. If no internal owner can staff the co-managed split, choose fully managed or shrink the scope. Ready to stop guessing? Run the score, build the matrix, and map each tier to the right delivery model. Orloff Phillips can help you turn that framework into a practical plan. Your systems deserve coverage you can actually run.
Leave a Reply