In many Swiss SMEs with 50 to 500 employees, an external IT provider runs the entire IT function. That is usually a sensible decision. It gets uncomfortable on the day a customer, an auditor or an incident asks who is accountable for security. The management team points at the IT provider, the IT provider points at the contract, and in the contract "security" sits as a catch-all term in a list of services.
The gap is rarely technical. It sits between running something and being accountable for it, and it usually surfaces when there is no time left to close it calmly.
An IT provider runs your security, it does not carry the accountability. The Swiss Federal Office for Cyber Security (BACS) states that responsibility cannot be outsourced and that your company can end up at the end of the liability chain after an incident. What you outsource is the work. What stays in-house are the decisions: what gets protected, what an outage may cost, who pulls the plug in an emergency. That needs no new headcount, but it does need a counterpart who asks the questions.
Does our IT provider not already handle security?
It handles the part that was ordered as a service: patches, backups, firewall, endpoint protection, often monitoring too. What it does not do is decide. The Swiss Federal Office for Cyber Security writes in its recommendations for working with IT providers that responsibility cannot be outsourced or delegated, and that your own company stands at the end of the liability chain when an incident happens.
This is no accusation against the provider. It sells operations, and operations is a business of tickets, availability and response times. Security decisions are a business of trade-offs. Which outage is bearable and which is not? Who gets an exception from multi-factor sign-in, and for how long? How long may a server run unpatched because production would otherwise stop? An external party can prepare questions like these. The company has to answer them.
Running it is not leading it
The difference sounds academic until you walk through concrete tasks. Almost every security task has an operating part and a decision part. The operating part can be outsourced. The decision part cannot.
| Task | The provider runs | You decide |
|---|---|---|
| Patches | installs updates, reports exceptions | which system gets downtime when, and which risk stays open |
| Backup | jobs run, failures get reported | which data has to be back how fast for the business to keep going |
| Identities | creates accounts, configures sign-in | who gets access and who may justify an exception |
| Alerts | detects and reports | whether you shut down when in doubt, even with production running |
| Evidence | delivers logs, reports, configurations | what of it satisfies a customer or an auditor |
In our experience the damage rarely comes from the operating part. The jobs run. The damage happens when the decision part stays vacant and the provider quietly takes it over as well. It does so because somebody has to answer and nobody else is there.
Three decisions end up with the wrong party particularly often. The first is risk acceptance. A system cannot be patched because the vendor no longer ships anything, and somebody has to say that the company lives with that. This is a business statement, even when it sits inside a technical ticket. The second is prioritisation. When the budget covers three of eight measures, the business decides which three they are. The third is communication during an incident. Whether and when customers, insurers and authorities get informed is not something a provider can carry for you.
All three have the same thing in common: they cost money or trust, and both belong to the management team. Anyone who quietly hands them to operations is not delegating work but liability, and gets it back when it matters.
Why the next tool does not close the gap
When an accountability problem becomes visible, a quote often follows. A managed detection package or a second backup target. The provider means it seriously, it offers what it has. Only no product answers the question of who decides.
Most companies do not have a security problem, they have a sizing problem. Too many tools, too little overview, too much cost for too little real protection. Companies that first clarify who makes which decision often find that nobody has ever looked at half of the licences they pay for. More protection, fewer tools, lower cost.
That is the uncomfortable part of it. An accountability problem cannot be bought. It can only be decided.
What this looks like in practice
An industrial company with around 180 employees, IT with the same regional provider for twelve years. Good people, short paths, everyone on first-name terms. Then a major customer runs a supplier audit and asks for evidence that the backups can be restored. Not that they run. That they come back.
The contract said "backup including monitoring". Restore tests had never been ordered, so they never happened. Nobody had been sloppy, nobody had ever asked. The provider ran the first full restore test, it took considerably longer than anyone had expected, and the management team saw a number for the first time on the question of how long the business stands still without its ERP.
The revealing part was the reaction in the management team. The duration itself was the smaller issue. What weighed more was that nobody knew the number beforehand, so nobody had ever decided whether it was bearable. The provider had done nothing wrong. It had simply never been given a target to deliver against.
Nothing was bought afterwards. Two things were decided: how fast which system has to be back, and that the test happens twice a year, with a record. That was the entire difference between "we have backup" and "we know what backup means here".
What does the contract with your IT provider have to answer?
Three things: what exactly gets delivered, how that delivery is evidenced, and what happens in an emergency. Most SME contracts answer the first question properly, the second rarely and the third not at all. It surfaces in exactly that order during an audit or an incident.
The first question sounds banal and still gets answered poorly: which task is ordered and which is not? "Security" in a service list is not a task. Restore tests, checking configurations, reviewing permissions and log retention are either ordered, or they do not happen.
Evidence is about how you can tell, without asking, that something has taken place. The BACS names explicit restore tests, a data processing agreement with a clarified data location and periodic reviews by independent third parties, among others. Not every one of these points is proportionate for an SME. The question behind them is.
That leaves the emergency. Who calls whom, within what deadline, and what does a call-out outside office hours cost? This is the point where many standard contracts go quiet. Which decisions should be settled beforehand is covered in our article on the incident response plan for your SME.
Then there is liability. The BACS advises setting out contractually how liability is handled in the event of damage. In our experience it is usually capped at a multiple of the monthly fee. That is not unfair, it simply rarely matches what a production standstill costs. Anyone who knows that number decides differently about redundancy and insurance.
Your provider gets better when it has a counterpart
An IT provider without a competent counterpart optimises for what gets measured: tickets closed, availability held. That is rational. Security work that nobody asks about shows up in none of those figures.
As soon as somebody in-house asks the same three questions on a regular basis, the relationship shifts: what has changed about the risk, what is still open, what do you need from us? Working through tickets turns into a shared list. In our experience the best pointers then come from the provider itself. It has seen the legacy problems for years, it has simply never reported them to anyone able to decide something.
Day to day this is one fixed appointment a month, plus the preparation for it. Not much time, but it has to be binding. An appointment that gets dropped at the first bottleneck is no counterpart, it is a calendar entry. And whoever keeps the appointment notices after two or three rounds that the list gets shorter rather than longer.
This counterpart does not have to be full-time. It has to exist and be able to decide. Which other suppliers deserve the same attention is covered in our article on supplier risk in an SME.
What does it cost to bring security leadership in-house?
Less than most people assume, because leadership costs time and no licences. A full-time CISO in Switzerland sits between CHF 150'000 and 250'000 per year (salary data from jobs.ch), plus social contributions and several months of searching. For an SME with outsourced IT, that is the wrong order of magnitude.
Two variants are realistic. Either somebody in-house gets the role officially, with a time budget and backing from the management team. Or the role comes in on a mandate. Our packages and pricing page shows what that means: the CISO Retainer from CHF 4'900 per month with a six-month minimum term, CISO Sparring from CHF 2'400 per month for two days, when an IT lead is already in place and only the second opinion is missing.
The third variant does not work: giving the role to the provider that also runs operations. It could do it technically. Only then the same party both delivers and assesses the same service. That separation is the reason auditors ask about it.
Writing down the difference between running and leading once, properly, costs a few hours. The benefit shows up on the day a customer asks or something fails.
Frequently asked questions
Do we have to change IT provider?
Usually not. The most common finding is a contract from a time when nobody asked for evidence. The provider itself is rarely the problem. A change costs months and brings the same gap along as long as the accountability question stays open.
Can our IT provider run the ISMS as well?
Parts of it yes, such as documenting configurations and evidence from operations. The steering, no. An ISMS includes the assessment of your own providers, and nobody assesses themselves credibly. In a customer audit that is the question that reliably comes up.
Who reports an incident, we or the provider?
The affected company has to report. For operators of critical infrastructure, the obligation to report to the BACS within 24 hours of discovery has applied since 1 April 2025. The provider may spot the incident first. The deadline still runs against you, which is why the contract should state how fast it informs you.