Most Swiss SMEs have a risk register. Forty rows in Excel, traffic-light colours, a "measure" column that nobody has touched since the last audit. Then a customer auditor sits down at the table, points at a red row and asks: who decided that you carry this risk? And the room goes quiet.
This is where IT risk management in an SME almost always fails, at a point where nobody looks for it. The method is in place, the threats are known, the list exists. What is missing is a person who has been assigned a particular risk and is allowed to carry it. A register without an owner is a watch list, and a watch list has never moved a budget.
IT risk management in an SME holds up when every risk is described as a business event, carries a rough figure in francs or days of downtime, has a named owner from the business and a dated decision: accept, mitigate, transfer or avoid. Five maintained risks beat forty coloured ones. The expensive risk is rarely the one you overlooked. It is the one you accepted without anyone knowing they accepted it.
Why the risk register in an SME usually changes nothing
Because it was created as an audit artefact and never meant as a basis for decisions. Somebody built it ahead of a certification or a customer audit, it served its purpose, and after that it lived on as a file that gets refreshed once a year. Four patterns keep showing up.
The risks are written in IT language. "Outdated firmware on the perimeter firewall" is an observation for the engine room; for the management team there is no consequence attached that they could decide on. "The ordering process stops until the firewall is replaced" describes the same thing in a language somebody can act on.
Then the owner: in most registers, every row says IT. That is convenient and wrong. IT can describe, mitigate and monitor a technical risk. It cannot accept it, because it does not answer for the revenue attached to it. A register where the same department appears everywhere has not distributed responsibility, it has offloaded it.
Any figure is missing. Traffic-light colours are the substitute for the estimate nobody wanted to make. Red and amber say nothing about whether an incident costs a monthly budget or eats into equity. Without that order of magnitude a committee decides on gut feel, and gut feel follows the latest headline rather than your own business.
And nothing ever closes. Rows get added, none goes away. After three years there is a collection nobody can work through in a single meeting, and for exactly that reason nobody works through it any more. A register that only grows is an archive.
What belongs in an IT risk register that holds up in an SME?
Five entries per row: the business event that occurs; a rough order of magnitude in francs or days of downtime; a named owner from the business; the decision taken (accept, mitigate, transfer or avoid); and a date on which the row comes back to the table. If one of these is missing, the row is a note rather than a decision.
Each of the five blocks a particular excuse, and that is where their value sits. The business event keeps the conversation on consequences instead of technology. The order of magnitude stops every topic from looking equally urgent; it does not need to be precise, because telling annoying apart from expensive and from existence-threatening is enough for nearly every decision in an SME. The name prevents a risk from belonging to the organisation, and therefore to nobody. The decision ends conversations that would otherwise repeat every year. And the date records that a decision once taken has an expiry, because the business changes.
What is absent from that list is worth noting: a probability of occurrence in percent. In an SME with a handful of incidents in ten years, any percentage is guesswork, and guessed numbers inside a formula produce a precision that does not exist. In our experience an honest sense of how often this happens in your industry is enough to sort the list.
The most useful part of a risk register is not the list of measures. It is the list of things you deliberately do not do. Anyone who records in writing which risks they carry and why does not need to cover them with yet another tool that nobody evaluates anyway. More protection, fewer tools, lower cost starts right here, with the justified non-investment.
Who is allowed to accept an IT risk at all?
The person who also answers for the revenue attached to that risk. An IT manager can describe and mitigate a technical risk. Only someone who stands behind the affected part of the business can accept it: the division head, the management team, and for existence-threatening topics the board. Whoever accepts, signs with a name and a date.
That sounds like formalism until you have done it once. A signature changes the conversation, because it visibly moves the risk to where it already sat. The Federal Office for Cybersecurity BACS states in its recommendations on the ICT minimum standard that the fundamental responsibility for self-protection lies with the companies and organisations themselves. Neither the service provider nor the insurer takes it off your hands, and the IT department certainly does not.
The board holds overall direction and must be able to show that it knows and addresses the material risks of the company, including those from IT. A dated acceptance is exactly that evidence. It prevents no incident, but it answers the question that comes after one, and it answers it with a document rather than with recollections.
For one category, acceptance is not on the table anyway. Any operator of critical infrastructure covered by the ISG, the Swiss Information Security Act, must report cyberattacks to BACS within 24 hours of discovery; that obligation has applied since 1 April 2025. By 31.12.2026 an organisation subject to the ISG also needs a working ISMS. Points like these belong in the register like any other risk, only with less room to move: accepting is not an option here.
What this looks like in a Swiss industrial SME
A supplier with around 140 employees, two plants, an ERP hosted by a single external provider. The register had 38 rows. The ERP appeared twice, amber both times, both times with owner "IT" and the measure "review backup concept". IT had been asking for a tested recovery for two years and had twice failed to get it into the budget.
We merged the two rows into one and reworded it: "Order processing stops if the ERP host has an extended outage. Order of magnitude eight to ten working days until full operation, because recovery has never been tested. Owner: COO." That was all we did, no new analysis and no scoring matrix.
The COO did not want to sign. The figure was not new to him, but it stood next to his name for the first time. Three weeks later there was budget for a recovery test and a second site for the database. The register did not change the risk, it made visible the decision the company had been taking quietly for two years.
The second effect was unexpected. Of the 38 rows, eleven remained. The rest were observations from IT or points long since closed. Two of them still had a running subscription for a tool that was supposed to cover exactly this risk and had stopped sending alerts to anyone since the last staff change. Cancelling it was the easiest measure of the whole year.
How often does an SME need to look at its IT risks?
Four times a year is enough in most SMEs, provided there are also defined triggers that bring a row to the table immediately. Risks do not change on a quarterly cycle. The management team does talk about budget and priorities on that cycle anyway, and a meeting that rides along with an existing meeting survives the first hectic quarter.
In practice the triggers matter more than the calendar: a new major customer with security clauses in the contract, a new critical supplier, an incident at your company or at a partner, a regulation that starts to bite, a larger system change. Each of these events shifts either the consequence of a risk or the question of who is allowed to carry it. Which suppliers fall into that category at all is a separate exercise; we described it in which suppliers can stop your business.
A condensed version then goes up from the quarterly meeting. What lands there are the few rows with a decision attached. Which numbers actually arrive is a discipline of its own: see security KPI reporting for management and the board.
Common questions
Do we need risk management software for this?
In an SME, rarely. A spreadsheet or an intranet page carries a double-digit number of risks as long as it has an owner and is on the screen at the quarterly meeting. A tool becomes interesting when several departments maintain it in parallel and the history has to be traceable. It never solves the ownership problem: software cannot provide a signature.
How many risks are the right number?
As many as the management team can work through seriously in one meeting. In our experience that is five to ten at committee level, with a longer working list underneath that is maintained in operations. Once the committee starts leafing instead of reading, the list is too long and loses the effect it was built for.
What if we want neither to mitigate nor to carry a risk?
Then two options remain, and both are used too rarely in SMEs. Transferring means passing the risk on contractually or through insurance, where a contract does not prevent the outage but distributes the cost. Avoiding means giving up the service or the system the risk is attached to. Avoiding sounds like retreat and is often the most honest calculation.
A clean register does not come from a method. It comes from somebody asking the uncomfortable questions and writing down the answers. That is exactly where we start in mandates: the Cyber Assessment with a risk register and a 90-day roadmap ends with a list of the top topics, each of them carrying a name. The more interesting question then asks itself: which row in your current register would somebody from the management team sign if you asked them tomorrow?