Incident Response Plan: What to Prepare Before an Attack

The question is not “if”, but “when”. Sooner or later, every organization faces an incident - ransomware, data leak, account takeover, server compromise. How much such an incident costs depends greatly on one thing: whether there was a plan, or whether it was written while the systems were already on fire. Improvising during a crisis is the most expensive way of working that exists. This article shows you what to prepare in advance.

Why the plan is created before and not during

During an incident, people act under pressure, lack full information and often outside working hours. This is the worst possible moment to make decisions such as “who has the right to disconnect production?”, “do we notify the supervisory authority?”, “where is the lawyer’s number?”. The Incident Response Plan moves these decisions to a quiet time - before the clock starts ticking.

The recognized framework is the NIST cycle of six phases. Let’s go through them, pointing out what is worth preparing in each.

Phase 1: Preparation

This is the only phase that happens entirely before the incident - and the most important. Includes:

• Team and roles. Who is in charge (Incident Commander), who is responsible for technology, who is responsible for communication, and who is responsible for the legal side. Roles, not names - people go on vacation.
• Contact details - for the team, management, lawyer, insurer, DFIR service provider, and supervisory authority. Kept outside of the main system because it may be unavailable.
• Playbooks - ready-made procedures for the most common scenarios (more on them below).
• **Restore-tested, offline, and ransomware-resistant backups - without it, the rest of your plan is useless. We describe this in backup strategy 3-2-1.
• Logs and visibility - if you don’t collect logs, you won’t be able to recreate what happened after the incident. Security monitoring is a condition for effective response.

Phase 2: Detection and Analysis

The most dangerous incident is the one you don’t know about. This phase involves detecting the signal and assessing whether it is a real incident, how serious it is, and what it involves. Key elements:

• Signal sources - alerts from systems, user reports, external information (e.g. that your data was leaked).
• Triage - The level of criticality determines who to engage and how quickly.
• Scoping - Which systems, accounts and data are affected. It’s difficult and time-consuming, so the logs collected earlier are invaluable.

Important rule: do not destroy evidence. A hasty wipe or restart of the machine may remove traces needed to understand the attack and take action. If possible, protect your system image before you start cleaning.

Phase 3: Containment

The goal: stop the spread without making the situation worse. A distinction is made between:

• Short-term restriction - quick containment actions (isolation of the infected machine from the network, blocking the account, cutting off traffic). Buys time.
• Long-term limitation - more permanent changes that allow you to regain function without the risk of relapse.

This brings back the decision prepared in phase 1: who has the authority to disconnect the production system? During an attack, there is no time to look for the decision-maker.

Phase 4: Elimination (eradication)

Removing the cause: deleting the malware, closing the exploited vulnerability, removing the access used by the attacker. It is crucial to understand how the attacker entered - otherwise he will return the same way. If the cause was a vulnerability, patching it belongs to this phase, and the closing process is described in vulnerability management.

Phase 5: Recovery

Controlled recovery: restoration of systems from clean copies, restoration of services, increased monitoring for recurrence. Don’t restore everything at once - do it in stages, watching for the attacker to return. Define the “system is trusted again” criteria in advance so that you don’t silently restore the same backdoor.

Phase 6: Lessons learned

This is the phase most often skipped, yet one of the most valuable. Within one or two weeks of closing the incident, gather the team and answer honestly: what worked, what did not, where data was missing and what should improve in the plan. The goal is learning, not a blame game - a blame culture makes it more likely that the next incident will be hidden rather than reported. The conclusions feed back into phase 1 and complete the cycle.

Playbooks: procedures for specific scenarios

It is worth supplementing the overall plan with playbooks - short, specific step-by-step procedures for the most common types of incidents. Minimum to start with:

• Ransomware - isolation, scope assessment, decision to restore from a copy, communication. Don’t improvise ransom payments - this is a strategic and legal decision. Details in the article Ransomware: how to defend yourself.
• Data leak - determining the scope, reporting obligations (below), communication with data subjects. Step by step in Data leak: first 72 hours.
• Account takeover / phishing - reset credentials, invalidate sessions and tokens, check what the attacker has already done.
• Server compromise - isolation, evidence preservation, input analysis, reconstruction from a clean image.

The playbook should fit on one or two pages. It is meant to be used at three in the morning, not read like a textbook.

Legal Obligations: The clock is ticking faster than you think

Reacting is not just about technique. Depending on the nature of the incident, reporting deadlines apply:

• GDPR - a personal data protection breach is reported to the supervisory authority (UODO in Poland) usually within 72 hours of being discovered.
• NIS2 - Covered entities are required to provide early warning within 24 hours and fuller notification within 72 hours. We explain who this applies to in NIS2 in Poland: obligations of companies.
• Sectoral - Finance (DORA) and other industries have their own regimes.

Therefore, contacting a lawyer and knowing who is reporting and when must be part of the plan - not something to be determined after the fact.

Summary

An incident response plan is the best loss minimization investment you can make before an attack occurs. NIST’s six phases—Preparation, Detection, Mitigation, Elimination, Recovery, Conclusion—provide a proven framework. The greatest value lies in the first phase: prepared roles, contacts, playbooks and, above all, tested backups. A plan that has never been practiced is a document, not a skill - so it’s worth doing at least one dry exercise.

If you want to prepare or test a response plan, or need support during an ongoing incident, contact us - incident response and consulting is one of the areas of our work.

Frequently asked questions (FAQ)

Does a small business really need a response plan? Yes - the smaller the team, the worse it is at improvising in a crisis. A small business plan doesn’t have to be thick: just a list of contacts, a few playbooks for the most common scenarios and tested backups. These are a few sites that save you hours of chaos and real money on the day of the incident.

What to do in the first hour after detecting an incident? Don’t panic and don’t destroy evidence. Launch the team as planned, pre-classify the incident, secure traces (images, logs) and limit spread by isolating affected systems. In parallel, start the legal path - the clock for filing deadlines may have already started.

Should we pay ransom for ransomware? This is a strategic, legal and business decision, not a technical one - and should not be made under the pressure of the moment. Payment does not guarantee data recovery, finances crime and may be legally problematic. The best alternative is tested, offline backups that allow you to restore systems without negotiation. This decision is worth discussing in your plan before it is needed.

How often should you test your response plan? At least once a year, in the form of a tabletop exercise - the team discusses a realistic scenario and checks whether the plan works, where there are gaps and whether contacts are up to date. This test is cheap, and it detects problems you won’t see in the document: outdated roles, missing permissions, copies that no one has ever restored.