// Guide · Response
IT incident response: what counts in the first hours
An incident cannot be scheduled; how you handle one can. Which decisions have to be settled beforehand so that nobody has to improvise later.
// Starting point
The plan is written before the day, not during it
When an encryption attack is running or an account has been taken over, the things you need most are the first to go: time, an overview, and the calm to sort out who is responsible for what. An incident response plan therefore consists largely of decisions taken in advance — who may take a system off the network, who gets the call, what you restore from.
Such a plan does not have to be long. Two or three pages, printed and kept somewhere everyone knows, are worth more than a concept sitting on an encrypted file server. How continuous monitoring and orderly response work together in practice is described on our page about security monitoring and incident response.
This article follows the familiar sequence: prepare, detect, report, contain, investigate, recover, review. The order matters more than completeness — containing before reporting costs you traces, and sometimes your insurance cover.
// Preparation
What has to be ready before anything happens
These five decide whether the first hours run in order. All five must be available without access to the company network.
-
Contact list with deputies
Management, IT leads, your provider, the internet supplier, the data protection officer, the insurer. A second person per entry, for when the first cannot be reached.
-
Authority to disconnect
A named person is allowed to take systems off the network immediately, without asking. Granting that in advance saves the most critical minutes of all.
-
List of critical systems
Which applications keep the business running, in what order they have to come back, and which dependencies sit between them.
-
A second communication route
An agreed route for when email and the phone system are unavailable — named beforehand, not invented in the middle of the incident.
-
Access to the backups
Where the copy sits that an attacker could not reach, who can get to it, and how long a restore has taken in the past.
// First hours
From suspicion to containment
Four steps that happen in this order. Each one produces the result that makes the next one possible.
Take the suspicion seriously
Unusual sign-ins, files that suddenly will not open, a system that has become oddly slow: the suspicion gets reported rather than investigated first. False alarms are cheaper than lost hours.
Trigger the chain
One point of contact takes the report, informs the named people and starts a timeline with clock times. Those notes become the basis for every notification that follows.
Stop it spreading
Disconnect affected systems, lock suspicious accounts, close remote access. Do not power anything down — that destroys the traces the investigation depends on.
Find the way in
Secure and review the logs before anything is restored. While the entry point is unknown, every restart leads back into the same incident.
// Afterwards
Restart and review
The two phases after containment are the ones people cut short — which is exactly where the repeat incident comes from.
Back into operation
- Only start once the entry point is demonstrably closed
- Restore from a state that predates the incident
- Renew credentials and keys across the affected areas
- Bring systems up in order of criticality, not all at once
- Watch the first days more closely than usual
Learning from the incident
- Write up the timeline and the decisions taken
- Name what was missing — contacts, rights, backups, practice
- Give each action an owner and a date
- Rework the plan against what actually happened
- Report the outcome to management, not only within IT
// Outward
Notifying, informing, recording
A second track runs alongside the technical work, and it has deadlines of its own. These points belong in the plan so nobody forgets them under pressure.
- Where personal data is affected, the incident must be notified to the competent data protection authority within 72 hours of becoming aware of it
- The individuals concerned have to be informed where the risk to them is high
- A report to the police, particularly in cases of extortion or a demand for payment
- Notification to the insurer, often with a shorter deadline written into the policy
- Check contractual notification duties towards your clients
- An agreed form of words for staff, customers and suppliers
- Record every step with a time — none of it can be reconstructed afterwards
// Common questions
Questions about the response plan
01 What does an incident response plan have to contain as a minimum?
A list of the critical systems, a contact list with named deputies, clear authority to disconnect from the network, the reporting route inside and outside the company, and a description of how a restore runs. All of it on paper, or on a device that works without the company network.
02 Should we switch affected systems off immediately?
Disconnect them from the network, yes. Power them down, usually no. Shutting a machine down destroys traces in memory that matter for the investigation — and without that investigation you cannot know whether the way in is still open when you restart. Disconnecting stops the spread, which is enough for the moment.
03 Who outside the company has to be informed?
That depends on the incident. Where personal data is affected, the duty to notify the competent data protection authority within 72 hours of becoming aware applies. Depending on the situation, add law enforcement, your insurer, clients with contractual notification duties, and the individuals concerned.
04 How do we communicate when email is down?
That is exactly what a second route is for, defined and tested in advance: company mobile numbers on a printed list, a notice at an agreed place, or a fixed telephone chain. Improvised group chats on private devices create their own problems afterwards.
05 When may the business start up again?
Once the way in has been closed and the restored systems come from a state that predates the incident. Restarting on the same unexamined state can reproduce the same incident within days.
06 How often should the plan be rehearsed?
Once a year as a walk-through around a table is enough to begin with: everyone involved talks through a scenario and names their own steps. It reliably surfaces which contact details are out of date and which responsibility was only ever assumed.
Fits with this
All guides
Is there a list within reach when it matters?
We walk through a scenario with you, fix responsibilities and reporting routes in writing, and check whether your backups genuinely carry a restart.