An IT director in a company of several hundred people rarely arrives at outsourcing through strategic reflection. They arrive through arithmetic: two people have left, a third has taken on the on-call duty, and the list of systems to maintain has not grown any shorter. The question “should we outsource?” then shows up as a question about the survival of a team rather than about an operating model. Which is precisely why it tends to be framed badly.
Because outsourcing IT services is not a binary decision. It is a decision about where the line of responsibility runs — and that line moves to a different place under each delivery model, while never disappearing. What stays on the company’s side stays there no matter how comprehensive a contract you sign: ownership of the data, decisions on accepting risk, and oversight of whether the provider is doing what you are paying for. This article is about drawing that line deliberately, before somebody’s contract template draws it for you.
What is IT services outsourcing, and what will we not call by that name?
The definition of the term — its scope, its variants, the dictionary distinctions — is set out in our entry on IT services outsourcing. Here we need only one distinction, because everything else depends on it: outsourcing a service transfers responsibility for a result, not for an activity.
A company that buys the time of three administrators still answers for the outcome of their work, because it is the company that assigns their tasks, sets priorities and decides what comes first. A company that buys a maintenance service with a defined availability level buys a result: the provider decides how many people and which tools to use, and is settled against whether the result occurred.
The difference is contractual, not technical. The same people can perform the same activities under either arrangement, and the only thing that changes is who bears the consequences when something fails. Many disputes with providers begin here: the contract describes one model while both parties’ expectations describe the other.
Which delivery models do you realistically have to choose from?
In practice, mid-sized companies choose between three models, which can still be mixed. The table below shows not so much differences in the service as differences in how responsibility is distributed — because that is the axis that matters.
| Model | Who answers for the result | Who manages the people | Settlement | When it makes sense |
|---|---|---|---|---|
| Hourly support (body leasing) | the buying company | the provider formally, the buyer operationally | for time | known scope, missing hands, project work |
| Managed services (service with an SLA) | the provider | the provider | for the service and the parameters met | repeatable maintenance, a need for measurability |
| Full IT outsourcing | the provider | the provider | a retainer for a defined scope | no in-house team, stable and documented scope |
These are not three levels of maturity but three answers to three different situations. Hourly support is the cheapest to start and the most expensive in terms of discipline, because the burden of planning stays with you. Full outsourcing removes the most operational work but demands a scope described precisely enough to settle disputes about it. Managed services is the market’s centre of gravity precisely because it forces measurability without requiring you to hand over everything.
The choice is rarely permanent: companies move from hours to a service once the scope stabilises, and return to hours for projects nobody yet knows how to describe as a service.
What stays on your side even under full outsourcing?
Three things always stay, and it is worth writing them into the contract explicitly rather than assuming they are obvious.
The first is ownership of the data, together with the right to access it at any time, in a format usable outside the provider’s infrastructure. The second is decisions about risk: a provider may recommend disabling an obsolete protocol, but you decide whether you accept the risk of leaving it in place, because you carry the business consequences. The third is oversight of the provider, that is, checking whether the service is delivered as agreed.
The third item is lost most often, because it looks like a technical activity and is not one. Oversight is not glancing at the provider’s dashboard once a quarter; it is maintaining your own independent picture of what is happening in your environment.
How do you split security duties so that nothing falls between the parties?
The most effective method is to break duties down into specific, assignable activities and give each of them an owner. A good scaffold here is the CIS Controls set published by the Center for Internet Security — version 8.1 covers eighteen controls broken down into individual safeguards (page checked on 10 September 2026). A separate, fifteenth control is named Service Provider Management and requires, in so many words, a process for evaluating service providers that hold sensitive data or are responsible for critical IT platforms and processes.
Note the direction of that requirement: it does not say “pick a good provider”, it says “have an evaluation process”. The process stays on your side even when you outsource the evaluation itself.
In practice the split is written into a table with four columns: activity, who performs, who approves, who verifies. Dull — and effective, because the empty cells in the “verifies” column are exactly the places where, after an incident, nobody can explain why nobody noticed. Asset inventory, vulnerability management, backups and their restore tests, and access reviews are the four areas where the line blurs most often.
Why is provider oversight a governance function rather than an administrator’s task?
Because that is its character in every serious frame of reference. The NIST Cybersecurity Framework 2.0 places supply chain risk management — the category labelled GV.SC — inside the GOVERN function, the one that describes organisational governance rather than day-to-day technical work. The category is named “Cybersecurity Supply Chain Risk Management” and breaks down into ten detailed outcomes.
Several of them read like a list of things companies usually do not do. GV.SC-02 expects security duties to be assigned and communicated across the whole relationship — not only inside your own organisation, but also towards the provider and any partner further down the chain. GV.SC-04 says suppliers are to be known and prioritised by criticality; that sentence assumes a supplier register, which many organisations simply do not have. GV.SC-08 requires relevant suppliers to be included in incident response planning — that is, deciding whom you wake at three in the morning before you have to do it.
Placing this inside GOVERN has an organisational consequence: if oversight of a provider slides down to a single administrator who “has a contact in their support team”, that is not oversight but a working relationship — useful, and insufficient as a control mechanism.
How do you assess a provider before you sign?
NIST CSF 2.0 devotes a separate outcome to this: GV.SC-06 covers planning and due diligence before entering a formal supplier relationship, precisely in order to reduce risk before it materialises. It sounds like a truism until you set it against the fact that due diligence on an IT provider is often reduced in practice to checking references and a company registry entry.
The context worth reading this in comes from the European Union Agency for Cybersecurity. The ENISA Threat Landscape 2025 report, published on 1 October 2025, analyses incidents recorded between 1 July 2024 and 30 June 2025 and describes the threat landscape the EU faces — and the security of supplier relationships is a permanent rather than seasonal theme within it. In European practice the same thread has a regulatory counterpart: the NIS2 Directive lists supply chain security among risk-management measures, together with aspects concerning relationships with direct suppliers and service providers. If your company is an essential or important entity, assessing a provider stops being good practice and becomes an obligation — something we cover in more depth in our article on the supply chain security audit under NIS2.
The practical minimum before signing is five questions: who exactly will operate your environment, and are they the provider’s employees or subcontractors; how their privileged access management process works; what the provider logs and for how long it retains those logs; what their own response plan looks like for an incident affecting many clients at once; and whether they will show the results of an independent audit, and if not, why not.
Which contract clauses settle a dispute before it happens?
An outsourcing contract is a document read most carefully at the worst possible moment, once something has already gone wrong. It is worth writing for that reader.
NIST CSF 2.0 puts this as GV.SC-05: requirements addressing supply chain cybersecurity risks are to be established, prioritised and written into contracts with suppliers and other relevant third parties. That is the heart of it — a statement in a sales deck is not an obligation until it becomes a clause.
Four clauses carry the most practical value. First, an obligation to report an incident within a specific deadline counted from detection, through a named channel — without it you learn about your provider’s incident from the media. Second, a right to audit or, as the realistic variant, an obligation to present an independent audit report on an agreed cycle. Third, explicit consent for subcontractors together with a list of them; outsourcing without that clause is often a longer chain than you assume. Fourth, rules for access to data and logs — including after the relationship ends.
How should you read an SLA so that it measures what matters to you?
A service level agreement always measures something specific, just not always the thing you care about. The classic mismatch concerns response time versus resolution time: a commitment to respond quickly to a ticket says only when somebody will acknowledge the case, not when the system will be working again.
So when reading an SLA it is worth checking four things. How availability is defined and from which vantage point it is measured — from the user’s perspective or from the management interface. What is excluded from measurement: maintenance windows, connectivity failures, faults on the cloud provider’s side. How time is counted during business hours and how outside them. And finally, who supplies the data used for settlement, because if the only source of measurement is the provider’s system, the provider is grading its own work.
That last point is not suspicion towards a particular company but measurement hygiene. Your own source of data, however simple, turns a conversation about SLA compliance from a discussion of interpretations into a discussion of numbers.
How do you tell that two offers are comparable?
The most common mistake in comparing offers is not bad arithmetic but comparing two different services. Before you line up the prices, line up the scopes: the same list of systems, the same number of users and devices, the same service hours, the same exclusions.
The second step is calculating the total cost rather than the monthly rate. On top of the retainer come one-off implementation and service transition, work billed outside the retainer, licences for the provider’s tooling, the cost of maintaining competencies on your side, and the cost of exit. Two offers differing by a dozen or so percent on the retainer can swap places once those items are added.
The third step is often skipped: check how much of the offered scope covers things you do not do at all today. If a provider proposes access reviews and backup restore tests while you do neither, that is not a more expensive offer — it is a different offer.
How do you plan service transition and exit from the contract?
Exit is best discussed before entry, while both parties are still happy. NIST CSF 2.0 states this plainly in GV.SC-10: supply chain risk management plans are to include provisions for activities that occur after a partnership or service agreement concludes.
In practice an exit plan is a short document answering four questions. What exactly you receive at termination — environment documentation, data in an agreed format, passwords and keys, configurations. Within what deadline and at what cost. Who transfers the knowledge, and over how many days. And how you confirm that your data has been deleted on the provider’s side.
Service transition at the start follows the same logic in reverse. It is worth planning a period of parallel running in which the outgoing team and the new provider work side by side, and setting an explicit criterion for ending that period. Without such a criterion, transition “continues” until somebody runs out of patience.
Which criteria should you put in a single table to make the decision?
The table below is a tool to fill in, not to read. Score each criterion from 0 to 2 for every option under consideration, and treat the result as a starting point for the conversation with your board — not as a verdict.
| Criterion | What you look at | Warning sign |
|---|---|---|
| Scope and exclusions | whether the list of systems and exclusions is closed | ”everything you need” with no annex |
| Split of duties | a table: performs / approves / verifies | empty cells in the “verifies” column |
| SLA measurement | definition, data source, exclusions | the provider is the only source of measurement |
| Incident reporting | deadline from detection, channel, addressee | no deadline, or a deadline of “promptly” |
| Subcontractors | list, consent, liability | the contract is silent on the matter |
| Access to data and logs | format, frequency, period after termination | data available only inside the provider’s tool |
| Exit plan | what, when, at what cost, who transfers knowledge | ”we will agree it if needed” |
| Total cost | retainer plus implementation, extra work, exit | comparison on the monthly rate alone |
Worth remembering: a good outsourcing contract is testable. If, having read it, you cannot say who checks the delivery of each item and where they get the data to check it, you do not yet have a contract — you have a description of an intention.
When does each model make sense, and when is outsourcing not worth it?
Hourly support works when the scope is known and only hands are missing — during a migration with a fixed deadline, for example. It stops making sense as a permanent model, because the whole burden of prioritisation returns to your team, which is exactly where things were tight.
Managed services makes sense when the scope is repeatable and measurable and you value predictable cost and quality. In return it requires maturity on both sides: the provider has to be able to report, and you have to be able to read the reports and act on what they show. That is how we deliver Managed IT Services — with a documented split of duties and measurement you can verify on your side, not only on ours.
Full outsourcing can be the right answer when there is effectively no in-house IT and no plan to build it. There is one hard condition: somebody on your side must retain oversight, even at part-time capacity or in the role of an external adviser. A company without that role is not buying calm; it is trading technical risk for contractual risk that nobody is watching.
And when is outsourcing not worth it? When the process is undocumented and its shape changes every month. Outsourcing entrenches what it finds — if it finds chaos, you will get chaos with an invoice and a measurement attached. The cheaper first step is then to tidy up the scope and take even a rough inventory of the environment, and only afterwards discuss the model. The same conclusion applies when you cannot name the result you expect. The contract will not name it for you.
Sources:
- Center for Internet Security, The 18 CIS Critical Security Controls (CIS Controls v8.1) — Control 15: Service Provider Management; page checked on 10 September 2026.
- NIST, Cybersecurity Framework (CSF) 2.0 — the GOVERN function, the Cybersecurity Supply Chain Risk Management category (GV.SC), subcategories GV.SC-02, GV.SC-04, GV.SC-05, GV.SC-06, GV.SC-08, GV.SC-10; resource checked on 10 September 2026.
- ENISA, ENISA Threat Landscape 2025, publication date 1 October 2025 (version 1.2 of 9 January 2026) — analysis of incidents from 1 July 2024 to 30 June 2025.
- Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2) — Article 21(2)(d) on supply chain security.
