A cyberattack leaves no time to think. It arrives on a Friday evening or a Monday morning, it hits the people who know what to do, and it puts everyone in a state where decisions are made poorly.
This is a well-known and perfectly normal phenomenon: under stress, attention narrows, memory for detail fades, and people forget obvious things like their own provider’s phone number. The response plan exists for exactly this reason. It does not make your company smarter during the crisis; it spares the company from having to be.
What does a written plan actually change?
An incident response plan is a document that describes, in advance, who does what once an attack is discovered. Nothing more.
Its value does not come from its technical content, which is often modest, but from the moment it was written. The same questions asked on a calm Tuesday afternoon and on a Sunday evening in the middle of an attack do not get the same answers. In calm conditions, you take the time to call the insurer to check what the policy covers. Under pressure, you pay a ransom because no one knows where the backups are.
The plan therefore turns a series of difficult decisions into a series of simple actions. On the day it matters, the question is no longer “what should we do?” but “where are we on the list?”.
Typical scenario: a twelve-person construction company discovers on a Saturday that its files are encrypted. The owner is away, the employee who "handles IT" does not know whether they are allowed to shut down the server, and the provider's contract is locked in a cabinet. Three hours pass before the first useful call. None of those three hours were lost due to lack of skill: they were lost due to the absence of a written decision.
One to two pages, no more
This is the point that separates a usable plan from a document for show, and it deserves to be said plainly: if your plan is longer than two pages, it will not be read on the day of the incident.
Long documents feel serious. They reassure people in meetings. But a fifty-page binder assumes that someone, in the middle of a crisis, will flip through it to find the right section. That never happens. What happens is that people search for a number in their e-mails, call someone at random, and the binder stays on the shelf.
A two-page plan fits on the table. It reads in three minutes. It can be photocopied and handed to four people. This is not a concession to the small size of your company; it is the condition for the plan to actually be used.
The short plan does not replace your provider’s detailed technical procedures, which are their responsibility. It sets the decision structure and the first actions. Everything else can be improvised, provided these points have already been settled.
What should the plan contain, section by section?
Here is the content to reuse as is. Each line corresponds to a block of a few sentences in your document.
| Section | What it contains | Common pitfall |
|---|---|---|
| Who decides | The name and mobile number of the person who decides, plus their deputy and the delay after which the deputy takes over | Listing only one person |
| Contacts | IT provider, insurer and policy number, lawyer, bank, NCSC, cantonal police | Switchboard numbers instead of direct lines |
| First actions | Isolate from the network without shutting down, do not reformat anything, do not restore right away, log the time of every action | Wording them too technically |
| Backups | Where they are, on which medium, who has access, how to launch a restore | Writing “on the NAS” with no further detail |
| Communication | Template messages for employees, customers and partners, and who sends them | Drafting the messages during the crisis |
| What not to do | Do not pay in the first hours, do not talk to the press without approval, do not erase traces | Skipping this section, the shortest and most useful one |
Two clarifications about contacts. Note down direct mobile numbers, not switchboards: a switchboard does not answer on a Sunday. And check with your provider what its actual intervention hours are, as well as its contractual response time, two pieces of information many managers discover at the worst possible moment.
For the technical side, the first actions are detailed in our article on the first 24 hours of a cyberattack, and the list of Swiss contacts in who to contact in case of an incident.
The plan must be printed
This is the most important point in this article, and the one most often missed.
A response plan saved on the company server will be encrypted along with the rest of the files. A plan stored in an online space whose password sits in the password manager, itself on an unreachable computer, suffers the same fate. The document meant to help you when everything is locked cannot depend on what is locked.
Print the plan in several copies and store them outside your IT systems: with management, with the person responsible for IT, possibly at the manager's home. The same rule applies to emergency credentials: administrator access to the server, the firewall and the backup space must exist on paper, in a sealed envelope or a safe, with a record of who opens it and when.
The test is simple. Imagine that all your systems are unreachable, on a Sunday, with your premises closed. If you can still get your hands on the plan and the emergency credentials, your storage arrangement holds. If not, it needs to be revisited.
Assign roles, not just names
An effective plan assigns three distinct functions.
The one who decides. They make the hard calls: whether to stop production, whether to warn customers, whether to commit expenses. This is usually the manager, and they absolutely need a named deputy.
The one who handles the technical side. They liaise with the provider, carry out the first actions, and keep a time-stamped log of actions. They do not need to be an engineer; they need to know who to call and what to record.
The one who speaks. To employees first, then to customers and partners. A single voice, to avoid contradictory versions that damage trust more than the incident itself.
In an eight-person company, the same person often combines two of these roles. That is normal and not a problem. What is a problem is not having written it down: an unformalised combination of roles produces either tasks no one takes on, or two people calling the same provider with conflicting instructions.
Also think about availability. A role assigned to a single person who takes three weeks of holiday a year leaves a three-week gap in your setup.
How do you test the plan once a year?
A plan that has never been tested is a hypothesis, not preparation. The exercise suited to an SME is called a tabletop exercise, and it fits into one hour.
Bring together the people named in the plan, around a table, without touching any system. Read a scenario aloud, for example: Monday, 7 a.m., the files on the server are encrypted and a ransom note appears. Each person then explains, in turn, what they do in the first thirty minutes, who they call, and with what number. You then introduce a complication: the person who decides does not answer, or the provider announces a four-hour delay.
One person takes notes, and only on the blockers: missing information, an outdated number, a decision no one feels authorised to make. These notes become the list of corrections to make to the plan in the following days, each with an owner and a deadline.
During the session, ask the person responsible for backups to restore a random file, live, and time it. You immediately measure the reliability of your backup strategy and how realistic your plan is.
The schedule matters as much as the exercise itself. The plan must be reviewed whenever a provider, an insurer, or a person holding a role changes. Contacts are the most perishable part of the document, and a plan with outdated numbers is worse than no plan at all: it creates the illusion of being ready.
Where what you can do alone stops
Writing this plan is within reach of any SME. The outline above is enough, no budget is required, and half a day of work puts you in a noticeably better position than most companies your size.
What is not within your reach is knowing whether this plan will hold up against a real attack. Almost every plan ever confronted with a serious scenario contains at least one false assumption, and it is rarely where you would expect: an administrator account that no one holds anymore since an employee left, an off-site backup whose restore takes four days rather than four hours, an insurer that requires notification before any intervention or else refuses coverage, a provider whose contract does not cover weekends.
These blind spots are not found by re-reading your own document, because you re-read what you believed to be true when you wrote it. They surface when someone from outside, who has already seen incidents unfold, asks the questions you would not think to ask. That is the difference between a plan that exists and a plan that works.
This document is therefore a solid foundation; it does not replace a review of your actual situation. To gauge your overall level of preparedness, the cyber check-up includes several questions on incident response, and the other crisis reflexes are gathered in the Responding to an incident pillar.