Most incident response plans stay closed during the incident itself. They are rarely missing. But they were written as IT documents, and an incident asks business questions: may IT shut down the ERP if that stops shipping? Who calls the biggest customer? Who decides whether the police secure evidence before the systems are rebuilt? An incident response plan for an SME is therefore above all a collection of decisions taken calmly in advance, so that nobody has to improvise them under pressure.
An incident response plan is a business document, not an IT manual. It records who may decide what during an incident, who informs whom and which reporting duties apply. The technology is the smallest part. A short plan that everyone knows and that has been rehearsed once beats any unread 60-page document. And most of it costs working time, not licences.
Why the plan is a business document
The technical questions of an incident have technical answers, and your IT team or your provider usually knows them better than any document: disconnect systems, check backups, preserve evidence. BACS, the Swiss Federal Office for Cybersecurity, publishes checklists for the first response that cover this part solidly.
The expensive questions are different ones. Do we shut down production even though the suspicion is not yet confirmed? An hour of standstill has a price, an encrypted ERP has one too, and only the management team knows both. Do we inform customers proactively or wait until we know more? Do we hold off rebuilding until the police have secured evidence, or does speed matter more to us? These are trade-offs between money, liability and reputation. None of them is an IT decision, and none of them can be made cleanly for the first time at three in the morning.
The most uncomfortable question belongs in this category as well: what if a ransom is demanded? Whether a company enters into contact with extortionists at all, who involves the insurer and who speaks to the authorities is a question for the management team and the board. Discussing it for the first time while the extortionists' countdown page is running is the most expensive conceivable way to do it.
That is what the plan is for. It is the record of the decisions the company has taken in advance: from which threshold the emergency applies, who may declare it, who may shut down, who speaks externally. Once those questions are settled, the rest is craft.
What belongs in an incident response plan for an SME?
Six things: criteria for when an event counts as an incident. Roles with real decision rights, including deputies. Contact details that work at the weekend too. Communication channels inside and outside the company. Reporting duties with clear ownership. And recovery priorities from a business point of view. All of it fits on a few pages, and that is exactly where it belongs.
Even the alarm criteria are a business decision. Declare every phishing attempt an emergency and the organisation goes numb. Escalate too late and you give away the hours in which an incident can still be contained. Setting the threshold deliberately matters more than setting it perfectly.
The part most often missing in practice is the decision rights. "The head of IT may disconnect any system immediately, including the ERP, without asking" is a sentence that looks banal in the document and saves hours in an emergency. The same goes for deputies: a plan that only works when the managing director is reachable is not a plan, it is a hope.
Communication channels also means: a channel that still works when mail and chat are encrypted or compromised. A printed contact list in the meeting room looks old-fashioned, until the day it is the only directory you can still trust.
Recovery priorities sound technical but are business strategy. What has to run again first, payroll or the webshop? The answer depends on the business model and sometimes plainly on the date, not on the server list. In our experience IT has an opinion on this, but rarely the basis for the decision. IT knows what depends on what technically. What a day of standstill costs the company, the management team knows.
A Friday evening without a plan
What this looks like without settled roles, an anonymised example from our practice. A trading company, around 120 employees, ransomware on a Friday evening. The head of IT spots it early and wants to disconnect the systems, including the ERP. Except: without the ERP, shipping stops on Monday, and the biggest customer has contractual penalties. The managing director is on a plane. A deputy was never defined. So a WhatsApp group spends four hours debating a question that a single sentence in the plan would have answered, while the malware keeps working. In the end the head of IT disconnects the systems on their own responsibility. It was the right decision. But it was theirs, and it should never have been.
The aftermath was just as typical. The company did not produce a thicker binder afterwards. It agreed a handful of sentences: who declares the emergency, who may shut down, who calls the biggest customer, who reports. At the next suspected incident the same situation ran without the WhatsApp debate. The technology was the same. The decision had already been taken.
We see this pattern again and again in variations: the damage does not come from nobody knowing what to do. It comes from nobody knowing who may decide it.
When does an SME have to report a cyber incident?
There are three layers. Under the revised Swiss Data Protection Act (nDSG) you report data security breaches that are likely to pose a high risk to the people affected to the FDPIC, the Swiss data protection authority, as soon as possible. Operators of critical infrastructure have reported cyberattacks to BACS within 24 hours since 1 April 2025. And customer contracts increasingly carry their own reporting deadlines, which apply regardless of any law.
For the nDSG report the FDPIC provides a guide and a reporting portal. For many SMEs between 50 and 500 employees, however, the third layer is the most relevant one: even companies outside the scope of the ISG, the Swiss Information Security Act, often have the 24-hour logic in their customer contracts already, because NIS2 migrates into Swiss contracts through the supply chain. What the ISG itself requires by the end of 2026, we have written up separately.
The plan therefore assigns each reporting deadline a responsible role with a deputy. During an incident there is no time to sort out ownership or search contract folders for deadlines. The clocks start at discovery, not at the moment somebody feels responsible.
What does incident readiness cost an SME?
Less than most budget rounds assume. The plan itself costs working time: a few days to develop it with the management team, then a few hours a year for rehearsal and upkeep. It needs no licences. Incident readiness only gets expensive when it is treated as a procurement project: forensics retainers, 24/7 monitoring and new tool categories before the basic questions are settled.
What an incident costs, conversely, cannot be stated seriously as an average figure; the ranges in public studies are so wide that they carry no decision. The more honest calculation is company-specific: what does a day without your ERP cost you? The management team usually knows that number by heart, and it is enough to put the few days of work on the plan into proportion.
Incident readiness is the clearest case of: more protection, fewer tools, lower cost. The most effective measure is a short document with settled decision rights and one exercise a year. Both cost the management team attention, not budget for new tooling.
There are situations where a SOC or a forensics retainer is the right answer, for instance when customer contracts demand guaranteed response times. But that is the second step, not the first. In an ongoing mandate, incident readiness is part of the basic equipment: in the CISO retainer it is a fixed component, alongside the monthly steering meeting and board reporting.
Why one exercise is worth more than twenty pages of plan
Ninety minutes at a table, one scenario, the management team takes part. A first exercise needs no more than that, and it reliably surfaces things no review of the document finds: the former IT manager's phone number in the contact list. The cyber insurance policy with an incident hotline whose number nobody knows. Backups that exist without anyone being able to say how long a restore takes.
The reason this works is unspectacular: people remember decisions they made themselves, not chapter 7.3. Whoever has once decided at the table whether the ERP comes off the network decides it faster and more calmly in a real incident. The exercise exposes the gap between paper and operations before the incident does. And the plan usually gets shorter afterwards, not longer.
One exercise a year is enough to start with. More important than the frequency is who sits at the table: without the management team it remains an IT exercise, and that answers only the technical questions again, which are already answered.
Frequently asked questions
Is our IT provider's emergency plan not enough?
It governs your provider's technology, not your decisions. Whether the ERP gets shut down, who informs the biggest customer and who reports to the FDPIC is written in no MSP contract. The two plans complement each other: theirs answers the how, yours the who and the from-when.
How long should an incident response plan be?
Short enough that it actually gets read during an incident. A few pages plus a current contact list are enough for most SMEs. Everything that is reference material belongs in the appendix.
Do we need a forensics retainer?
Only once the basic decisions are in place. A prepaid forensics team is of little use if nobody internally may decide whether to call it. For many SMEs, cyber insurance with an incident hotline is the more pragmatic first step, provided somebody knows the number.
If you could not say off the top of your head who at your company may shut down the ERP: those are exactly the questions we settle in a mandate, before somebody has to answer them at night.