Co-Managed IT: 3 Proven Models That Avoid Costly Mistakes

The usual framing is a binary: keep IT in-house, or outsource it. That framing is wrong often enough to be expensive. The more common reality is a competent internal person or small team who are entirely consumed by day-to-day work, and a business that needs capability they do not have time to build.

Co-managed IT is the arrangement for that situation. It is also frequently sold as a stepping stone to full outsourcing, which is a different thing with different incentives — so it is worth being precise about what you are buying.

What co-managed actually means

In a co-managed arrangement the internal team keeps ownership of the environment. An external partner supplements them in specific, agreed places. The internal team does not report to the partner, and the partner does not become the route through which all work flows.

The distinction from full outsourcing is not the amount of external help. It is who holds the mandate. In co-managed IT, the business's own person remains accountable for the environment and decides what gets delegated. That is the whole point, and it is the thing that quietly erodes in badly-structured arrangements.

The three co-managed IT shapes that work

Escalation partner

The internal team handles everything day to day and escalates the narrow band of problems that need depth they do not have — a failing database, an identity architecture question, an incident at 02:00. The partner is on call for hard things rather than routine things.

This works when the internal team is genuinely capable and the gap is specialist knowledge, not capacity. It fails when it is used to paper over an understaffed team, because everything becomes an escalation and the cost model breaks.

Capacity for projects

The internal team runs operations. The partner runs the migration, the rollout, the office move — work with a beginning and an end that would otherwise consume the internal team entirely and stop everything else.

This is the most straightforward version and the easiest to price honestly, because the scope has edges. It works when the project genuinely ends. It fails when "the project" quietly becomes a permanent second team.

Strategy and governance

The internal team executes. The partner provides the planning layer they have no time for: the roadmap, the risk register, the vendor reviews, the budget cycle. This is the virtual CIO pattern applied alongside an existing team rather than instead of one.

It works when the internal person is technically strong and wants the strategic cover. It fails badly when it is imposed over their head, because it reads as a vote of no confidence — and the person who knows your environment best is now updating their CV.

When to add a partner instead of hiring

Adding a partner tends to be the better answer when:

• The gap is breadth, not hours. You need someone who has done identity, networking, backup architecture and security — occasionally. Hiring that person full time is expensive and they will be bored.
• You need cover, not headcount. One internal person means leave, illness and resignation are all single points of failure. A partner who already knows the environment is continuity insurance.
• The work is genuinely lumpy. A migration this quarter and nothing comparable for eighteen months does not justify a permanent hire.
• You need independence. Vendor review and risk assessment are hard to do objectively when the reviewer also implemented the thing.

Hiring tends to be the better answer when:

• The need is sustained volume of routine work. Partners are poor value for predictable, high-volume, low-complexity tasks.
• Deep institutional context matters more than technical breadth — bespoke systems, unusual processes, long-tenured relationships.
• You are large enough that the specialist would be fully occupied.

How these arrangements go wrong

Three failure modes, all avoidable, all common:

Ambiguous boundaries. If it is not written down who handles what, two things happen: work falls through the gap because each side assumed the other had it, and the same work gets done twice. Both erode trust quickly. The fix is unglamorous — a written responsibility matrix, reviewed when things change.

The partner becomes the bottleneck. Arrangements that start as escalation drift into everything routing through the partner, usually because it is easier. At that point you are outsourcing, at co-managed pricing, without having decided to. Watch the trend in what gets escalated.

The internal person is undermined. This is the one that does real damage. If the partner reports over the internal person's head, contradicts them in front of the business, or is introduced as a fix for their perceived shortcomings, you will lose them — and they are the only one who knows why that odd exception exists in the finance system.

What to insist on in a co-managed IT agreement

• A responsibility matrix. Every significant function, with an owner. Not "shared" — a name.
• Your documentation stays yours. If the partner's knowledge base is the only record of your environment and it lives in their tenant, leaving is expensive by design. Insist on an export you can actually use.
• Your credentials and tenancy stay yours. Licences and domains registered to you, not to the partner. This is the single most common lock-in.
• Defined escalation paths in both directions, including who can declare an incident and who talks to the business during one.
• An exit clause with a handover obligation. Not because you expect to use it, but because an arrangement you can leave is one both sides keep earning.

The honest summary

Co-managed IT is not a compromise between in-house and outsourced. It is the right structure when you have someone good who is out of hours in the day, and you would rather extend them than replace them.

The arrangements that last are the ones where the boundaries are written down, the internal person's authority is explicitly preserved, and the partner is comfortable saying "you do not need us for that." If a prospective partner never says that, they are optimising for something other than your outcome.

What co-managed IT costs, and how it is priced

As with any advisory arrangement, a number quoted without knowing the estate is marketing. The pricing shapes are worth understanding so you can compare proposals sensibly.

Per-user or per-device monthly. Common, predictable, and the model most likely to drift into full outsourcing — because once you are paying per seat, routing everything through the partner feels free. Watch the escalation trend.

Blocked hours, drawn down. A pool used as needed. Suits the escalation-partner shape well. Ask what happens to unused hours and whether the rate changes out of business hours.

Fixed-scope project. Right for the capacity shape. The scope has edges, which makes it the easiest to price honestly and the easiest to verify.

Retainer for the strategy layer. A fixed monthly scope for roadmap, risk and vendor review. This is the same commercial structure as a virtual CIO engagement, and often literally the same work.

The variables that move the price are the number of users and sites, how much documentation already exists, out-of-hours expectations, and regulatory exposure. An estate with a maintained inventory costs measurably less to support than one without.

The security questions co-managed IT raises

Adding a partner adds credentials, and credentials are now the dominant route into a business. Third-party access deserves the same discipline as employee access, and it frequently does not get it.

The specifics matter here. Partner accounts need multi-factor authentication with no exemptions, named individual logins rather than a shared partner account, access scoped to what the arrangement actually requires, and removal on the day a person leaves the partner — which requires the partner to tell you, which requires it to be in the contract.

This is not hypothetical caution. Identity-led intrusion has overtaken software exploitation as the leading cause of ransomware, and third-party accounts are a well-documented route in — the detail is in our analysis of the gaps MFA does not close.

If your partner resists individual named accounts or MFA on their own access, that is a meaningful signal about their internal practices.

Where co-managed IT meets compliance

If the partner touches systems holding personal information, they are an operator in POPIA terms, and the relationship must be governed by a written contract. That is a statutory requirement, not best practice.

Practically that means an operator agreement, clarity on which country data is processed in, and an obligation on the partner to notify you of a security compromise promptly enough that you can meet your own notification duties. The technical controls behind this are set out in our POPIA compliance checklist.

The same logic extends across borders. If delivery capacity comes from an offshore or outstaffed team, the obligations do not change — a point we cover in IT outsourcing to South Africa.

A responsibility matrix is the whole game

Almost every failed co-managed IT arrangement traces back to an ambiguous boundary. The remedy is unglamorous and takes an afternoon.

List every significant function — identity and access, endpoint management, patching, backup, network, telephony, licence management, vendor liaison, incident response, documentation — and against each put a single owner. Not "shared". A name.

Where genuinely shared, split it further until it is not. "Backup" is ambiguous; "backup configuration" and "backup restore testing" can sit with different owners without confusion.

A useful public reference point is the shared-responsibility model cloud providers publish, such as Microsoft's shared responsibility documentation — not because it maps to your arrangement, but because it demonstrates the level of specificity that actually prevents disputes.

Review it whenever something structural changes: a new system, a new site, a departure on either side.

Where the gap is the planning layer rather than the hours, the strategy half of a co-managed arrangement is the same work as a virtual CIO engagement — the roadmap, the risk register and the vendor reviews, run on a cycle alongside your internal team rather than over their head.

That leadership layer is bought in more than one shape, and the shapes are not interchangeable. Our piece on a fractional CIO versus a virtual CIO covers which one suits a co-managed IT arrangement, and the conflict of interest to check before signing either.