Remote infrastructure management: what to outsource and what to keep in-house

Handing part of your infrastructure to a remote management provider can free your team from night shifts and routine work, but only if the line is drawn in the right place. This article sets out criteria for deciding what to outsource and what to keep, and how to structure the arrangement so you stay in control of your own network.

Start with the work, not the org chart

Before talking to providers, list what your team actually does in a typical month. Include scheduled work (patching, backups, certificate renewals, capacity checks), reactive work (alerts, incidents, user requests) and project work (migrations, new sites, redesigns).

For each item, note four things:

• Frequency: daily, weekly or occasional.
• Time sensitivity: does it need a response at 3 a.m., or can it wait until morning?
• Specialism: is it a skill your team uses often enough to stay sharp?
• Business context: does doing it well depend on knowing your customers, contracts or strategy?

Tasks that are frequent, time-sensitive and well defined are the strongest candidates for outsourcing. Tasks that depend on business context usually belong in-house.

What usually makes sense to outsource

Some work suits an external team because it is repetitive, procedural or needs round-the-clock cover that a small team cannot staff.

• Monitoring and first response: watching alerts, triaging, following runbooks and escalating. Covering every hour of the week with your own people takes several engineers once holidays and sickness are accounted for.
• Patching and lifecycle work: operating system and firmware updates within agreed maintenance windows, with testing and rollback steps.
• Backup operations: checking jobs, handling failures and running periodic restore tests.
• Routine changes: VLANs, firewall rules, DNS records and user accounts, raised through tickets and approved by you.
• Specialist tasks you rarely do: BGP policy changes, RPKI and route object maintenance, reverse DNS delegation or hardening reviews. Doing these twice a year in-house means relearning them each time.

What you should keep in-house

Outsourcing execution is different from outsourcing responsibility. Some things should stay with your own organisation however much else you hand over.

• Architecture and roadmap: the provider can advise, but decisions about design, vendors and budget belong to you.
• Ownership of accounts and resources: domain registrar accounts, cloud root accounts, RIPE NCC LIR portal access and the IP address space itself should be held by your organisation, with the provider given delegated, named access.
• Break-glass credentials: keep an emergency path into every critical system that does not depend on the provider.
• Security policy and risk acceptance: the provider implements controls; you decide what risk is acceptable.
• Customer communication: during an incident the provider supplies the facts, but your team speaks to customers.
• Design knowledge: someone internal should understand why things are built the way they are, well enough to challenge the provider.

A simple decision table

Question	Points towards outsourcing	Points towards keeping in-house
How often is it done?	Daily or weekly, repeatable	Rare, one-off or strategic
Does it need 24/7 cover?	Yes	No
Can it be written as a runbook?	Yes	Depends on judgement and context
Is the skill used regularly in-house?	No	Yes
What happens if the provider leaves?	Easy to hand back	Hard to rebuild

Use the table to structure a discussion, not as a scoring system. A single answer in the right-hand column, especially the last one, can outweigh all the others.

How to structure the arrangement

The contract and operating model matter as much as the split itself. Before signing, make sure the following are agreed in writing:

1. Scope: the systems and tasks covered, and what is explicitly excluded.
2. Response definitions: what counts as a priority-one incident, how quickly the provider acknowledges it and when it escalates to you.
3. Access model: personal accounts for each engineer, multi-factor authentication, session logging and the ability to revoke access immediately. Shared logins are a warning sign.
4. Change control: which changes need your approval, which are pre-approved, and how emergency changes are reported afterwards.
5. Documentation ownership: runbooks, diagrams and configuration backups produced by the provider belong to you and live in a system you control.
6. Reporting: a regular summary of incidents, changes, capacity trends and open risks.
7. Exit plan: how the service is handed back or moved, including a notice period and the return of all documentation and credentials.

Start with a limited scope, such as monitoring and patching, and run it for a few months. Extend it once the working relationship has proved itself and the reporting gives you confidence in what is happening.

How TACS can help

TACS provides remote Infrastructure management and monitoring, scoped to the tasks you choose to hand over, while your organisation keeps ownership of its accounts and resources. If you first want an independent view of where to draw the line, our Consulting team can review your environment and help you decide.