Cybersecurity incident response plan: 5 steps for the first 24 hours

A cybersecurity incident response plan serves one specific purpose: when something fails, the team does not have to decide from scratch, under pressure, who does what. Knowing what to do after a cyberattack starts long before the attack. Finding out whether it has already happened is a first step, covered in our article on how to tell if your company has been hacked. Here we focus on what is prepared beforehand and on the first 24 hours of a security incident.

Picture a fictional situation: on a Tuesday morning, several people cannot open their files and a message appears on a screen. One person switches off their computer, another forwards a screenshot to a chat group, and nobody knows who should be told. The technical problem is already serious; the lack of order makes it worse.

1. Assign owners before you need the cybersecurity incident response plan

The first content of a cybersecurity incident response plan is not technical: it is a list of people. It should say who coordinates, who makes the decisions that affect the business, who acts on the systems and who speaks to third parties.

Keep these contacts somewhere that can be reached even if email or servers are down, and name a deputy for each role. A plan that depends on a single person stops working the day that person is unavailable.

2. Classify the incident in the first hour

With the plan already defined, the first hour is for understanding the scope, not for fixing everything. Note the time of the alert, who reported it, what is observed and which systems, accounts or data may be involved.

It helps to distinguish between a suspicious email nobody opened, an account with unusual activity and a computer with inaccessible files. Each case calls for a different response. A simple classification in levels, such as low, medium and critical, helps decide who is told and how urgently.

A good ransomware response starts with recognizing its signs: files that will not open, names or extensions that have changed, or a note demanding payment. Record the facts as they are observed, without assigning a cause yet. A record with specific times and observations is far more useful than a memory reconstructed the next day.

3. Contain the incident without destroying evidence

Containing means limiting the spread: disconnecting suspicious computers from the network, suspending compromised accounts or restricting remote access. The cybersecurity incident response plan should state who can order these actions and which ones need prior approval.

Before reinstalling a computer, restoring a system or deleting files, decide what information should be kept: received messages, screenshots, activity logs and a description of what was observed. That information helps understand the origin of the problem and review afterwards what failed. If the incident may have legal consequences, consult the right people first.

In a ransomware response, limiting the spread as soon as possible matters, but the decision about a possible ransom should not be improvised: it should be set out in the plan and discussed with legal advisers and technical specialists. This article does not replace a technical analysis: every environment requires its own decisions, and a fast but poorly chosen action can erase traces or widen the damage.

4. Communicate with care in your cybersecurity incident response plan

This kind of plan should anticipate how each group is informed. Knowing what to do after a cyberattack includes knowing what to say and to whom. Staff need clear instructions, such as what not to open, which channel to use and whom to send questions to. Customers and suppliers need accurate information, not assumptions.

If the incident affects personal data, there may be obligations to notify authorities and affected people, with their own deadlines. Do not assume or calculate them yourself: check the current rules with legal advisers or the data protection officer, and list that contact in the plan.

Use alternative channels when the usual ones may be compromised, and avoid spreading technical details or speculation in large groups. A short, consistent message reviewed by the person in charge reduces noise and mistakes.

5. Recover, close and learn from the incident

Recovery depends on backups. If you are not sure about yours, review the 3-2-1 rule and the tests to verify that your backups work. A copy that has never been restored does not guarantee that recovery is possible, and this matters a great deal when the incident is ransomware.

Restore by priority: first the services essential to the business, then the rest. Before reconnecting a computer or an account, check that access has been reviewed, affected credentials changed and, as far as possible, the cause of the incident corrected. Reconnecting without that review can reopen the problem.

Close the incident with a review afterwards: what happened, what worked, what was delayed and what the cybersecurity incident response plan needs to change. Document pending actions with an owner and a date. Rehearse it periodically with a simple exercise: a plan that has never been tested tends to fail when it is needed most.

Example timeline for the first 24 hours of a security incident

This fictional example shows how the plan can order the first hours. The time frames are indicative: every company should adjust them to its size and systems.