Co-Managed IT Support for Distributed and Remote Teams
Extend the person you have. Do not replace them.
Co-managed IT support is the arrangement for a business that already has someone competent and simply has no hours left. It is not a stepping stone to full outsourcing, and it should not be sold as one — the whole point is that your person keeps the mandate.
We work this way remotely with businesses in South Africa, the UK and Europe — including distributed teams with no single office to be near — and on site across the Helderberg and Cape Town, where we are based.
What co-managed IT support actually means
The internal team keeps ownership of the environment. We supplement them in specific, agreed places. They do not report to us, and we do 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. That sounds like a philosophical point and it is not — it decides who gets told when something changes, who signs off a purchase, and whose judgement wins when the two of us disagree.
Three shapes work. We have written them up at length in our piece on the three co-managed models and how they fail, but in short: an escalation partner for the hard things, project capacity for work with a beginning and an end, or the strategy and governance layer alongside an internal person who is technically strong and has no time to plan.
Managed IT services, outsourced IT, co-managed: the words are used loosely
Worth being precise, because the terms get used interchangeably by people selling quite different things.
- Managed IT services normally means a provider takes responsibility for an agreed scope for a monthly fee. It can be excellent. The risk is that the scope is described in the marketing and not in the contract.
- Outsourced IT usually means the provider becomes the IT function. Appropriate when there is no internal capability and none is wanted.
- Co-managed IT support keeps an internal owner and adds depth or capacity around them.
The failure mode is buying one and managing it like another. An arrangement bought as co-managed but run as outsourcing drifts: everything routes through the partner because it is easier, and you end up outsourcing at co-managed pricing without ever having decided to.
What we do not do
Said plainly, because it saves everyone a meeting. This is not break-fix IT support. There is no number to call to have a printer reset, no per-incident pricing, and no first-line desk.
If that is what you need, it is a completely legitimate thing to want and there are good providers who do it well. What we do is the layer above: the problems your internal person cannot solve at 02:00, the projects that would otherwise consume them entirely, and the planning nobody has time for.
Where an escalation partner earns its money
The narrow band of problems that need depth rather than hours:
- An identity or access architecture question where the wrong answer is expensive to reverse — the reasoning is in our IT architecture work.
- A security incident, or the suspicion of one, where the first hour of decisions matters and nobody wants to be improvising. See cybersecurity risk management.
- A failed restore, which is the worst possible moment to discover the backup was never tested — see disaster recovery.
- A migration or platform change with a vendor deadline attached, where the sequencing is the hard part.
- A client security questionnaire or insurance renewal asking structural questions the estate cannot currently answer.
The test for whether this shape is right: is the gap knowledge, or is it hours? If your internal person could solve these given a week they do not have, you need capacity. If they genuinely have not done it before, you need depth. Those are different purchases and they price differently.
Protecting the internal person
This is the part that decides whether the arrangement lasts, and it is the part most often got wrong.
If a partner reports over the internal person’s head, contradicts them in front of the business, or is introduced as a remedy 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.
Practically that means: they choose what gets delegated, they are in the room for anything that changes their environment, and any finding about the estate goes to them first rather than to their manager. A partner unwilling to work that way is optimising for replacing them.
What we insist on in writing
- A responsibility matrix. Every significant function with a single named owner. Not “shared” — where it genuinely is, split it further until it is not. “Backup” is ambiguous; “backup configuration” and “backup restore testing” can sit with different people without confusion.
- Your documentation stays yours, exportable in a form you can actually use. If the only record of your environment lives in a partner’s tenant, leaving is expensive by design.
- Your tenancy and licences stay registered to you, not to us. This is the single most common form of lock-in in this industry and it is entirely avoidable at the start.
- 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 anyone expects to use it, but because an arrangement you can leave is one both sides keep earning.
The compliance part nobody enjoys
If we touch systems holding personal information — and co-managed IT support always does — we are an operator in POPIA terms and the relationship must be governed by a written contract. That is a statutory requirement, not best practice, and it runs in both directions.
Practically: an operator agreement, clarity on which country data is processed in, and an obligation on us to notify you of a security compromise promptly enough that you can meet your own duties under section 22. The technical controls behind that are in our POPIA compliance checklist, and the Information Regulator publishes its own guidance on the Information Regulator’s website.
The same applies to our own access. Named individual logins rather than a shared partner account, multi-factor authentication with no exemptions, access scoped to what the arrangement actually requires, and removal the day a person leaves. If any provider resists those on their own access, that tells you something about their internal practices.
How it is priced
Three shapes, and which one suits depends entirely on whether the gap is depth or capacity.
Blocked hours drawn down as needed suits the escalation shape. Ask what happens to unused hours and whether the rate changes out of business hours — the answers vary a lot.
Fixed-scope project pricing suits the capacity shape. The scope has edges, which makes it the easiest to price honestly and the easiest to verify afterwards.
A monthly retainer suits the strategy layer, and is the same commercial structure as a virtual CIO engagement — often literally the same work, run alongside your team rather than instead of one.
What moves the number: 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, which is usually the argument for starting with an assessment.
Starting without committing to anything
The first engagement is a bounded assessment: a documented estate, a prioritised risk list and a responsibility matrix drafted against your current reality. You keep all three whatever you decide next, including deciding that your internal person needs a second pair of hands rather than us.
That is a legitimate outcome and we would rather say it early. A good co-managed IT support arrangement is one where the partner is comfortable saying “you do not need us for that” — and if a prospective provider never says it, they are optimising for something other than your outcome.