Incident Response Plan 2025: How to Prepare Your Business for a Cyberattack – NIS2 Requirements, the 24/72-Hour Rule and Tabletop Exercises

Let's start with a hard truth: halfway through the 2020s, the traditional idea of "security" as a state free from threats has become fiction. In 2025, under the NIS2 Directive and the amended National Cybersecurity System Act (KSC), a new paradigm applies: resilience.

This isn't another article about which antivirus to buy. It's a guide to surviving when your systems go down and the CEO's phone starts ringing in the middle of the night. Drawing on "The Complete Guide to Building Organizational Resilience," I've put together a roadmap to help you turn chaos into an organized defense.

1. Understand That the Board's Neck Is on the Line

If your CEO thinks cybersecurity is a problem for "the IT people," you need to set them straight, and fast. The amendment to the KSC Act changed the rules on accountability completely.

This is no longer a matter of "good practice." In cases of serious negligence, the supervisory authority can impose a fine directly on the person managing the organization: up to 600% of their salary. They can even be temporarily suspended from their management role.

The practical takeaway: Your Incident Response Plan (IRP) must be approved by the Board, and C-level executives must know their role in the decision-making structure. If the Incident Manager isn't given the authority to make tough calls (such as shutting down production), the organization will freeze at the critical moment.

2. Appoint an Incident Manager (and Don't Make It a Technician)

In the heat of a cyberattack, the worst thing you can do is let everyone rush to their keyboards. An effective response team (CSIRT) needs structure.

The key role is the Incident Manager. This person doesn't "touch the keyboard." Their job is to manage the chaos. They translate between technical IT jargon and the business language of the Board. They make sure the technical team doesn't fall into tunnel vision or make mistakes out of exhaustion.

A team worn out after 24 hours of fighting an incident makes mistakes that can cost more than the attack itself.

Don't forget the mundane but critical details: staff rotation (shifts of no more than 12 hours) and making sure people get fed.

3. Follow the "Don't Pull the Plug" Procedure

When a ransom note appears on the screen, instinct tells us to cut the power as fast as possible. That's a mistake that can make data recovery impossible.

Modern procedures (playbooks) are clear:

• Don't cut the power: You'll lose evidence stored in RAM and potentially the encryption keys.
• Isolate from the network: Physically unplug the network cable or turn off Wi-Fi.
• Secure your backups: This is the top priority. Immediately disconnect backup systems from the main network before the malware reaches them.

Only after full isolation and evidence collection (memory dumps, disk images) should you think about cleanup and restoring systems.

4. The Clock Is Ticking: The 24/72-Hour Rule

NIS2 has dramatically shortened the time you have to report incidents. Incident handling is no longer just an internal company matter.

You need to be ready for a reporting "relay race":

1. Early Warning: You have just 24 hours from detection to notify the relevant CSIRT (CSIRT NASK, CSIRT GOV or CSIRT MON). This isn't the time for a full analysis. It's a signal that says "we have a problem."
2. Incident Notification: Within 72 hours, you must submit an update with a severity assessment and indicators of compromise (IoCs).

If your procedure needs three directors to sign off before anyone can send an email, you've already lost. You need a prepared "fast track" for reporting.

5. Run Dry Runs, Because Paper Never Says No

The biggest lie in cybersecurity is "We have procedures, so we're safe." An untested procedure is just a hypothesis.

The most effective way to test it is with Tabletop Exercises (TTX). Get the Board, PR, Legal and IT in one room. Hand them a scenario: "It's Friday, 4:00 p.m. Hackers have encrypted your databases and are demanding $5 million. What do you do?" Exercises like this expose communication and decision-making gaps faster than any technical audit. They help the organization build "muscle memory."

Want to Prepare Your Business for a Cyberattack?

If you need help building an Incident Response Plan, training your CSIRT team, running Tabletop Exercises or auditing your current response procedures, get in touch with us. We'll help prepare your organization for incidents in line with NIS2, GDPR and ISO 27001 requirements.

What We Offer

• Incident Response Plan (IRP) development - comprehensive response procedures tailored to your infrastructure and regulatory requirements
• CSIRT team training - preparing your in-house incident response team (Incident Manager, Tier 1/2/3)
• Tabletop Exercises (TTX) - exercises that test procedures and executive communication in simulated attack scenarios
• Ransomware Response Planning - dedicated ransomware response procedures, including the "don't pull the plug" rule
• NIS2 procedure audit - verifying compliance with the 24/72h reporting requirements and CSIRT contact procedures
• 24/7 support during an incident - access to experts during a live attack, plus help communicating with CSIRT and the Personal Data Protection Office (UODO)

📧 Talk to an Incident Response expert →

See Also - Related Topics

Cybersecurity and Compliance

• NIS2 in Poland - The Complete Guide - Detailed incident reporting requirements, the 24/72h deadlines and management liability
• Security Operations Center (SOC): The Complete Guide for 2026 - How a 24/7 SOC supports fast incident detection and response
• Managed Security Services Provider (MSSP) - A Buyer's Guide - Outsourcing incident response: how to choose a provider with 24/7 Incident Response

Technologies That Support Incident Response

• SIEM vs XDR - Which Should You Choose? - Incident detection technologies and their impact on MTTD/MTTR
• SOAR - Security Operations Automation - How automation speeds up incident response (playbooks, orchestration)
• Threat Hunting - An Advanced Guide - Proactively detecting threats before they become incidents

What Can You Do Today?

You don't need to roll out a complex SIEM system right away. Start with one small step that could save your company: Create and print (offline!) a Contact List. When your systems go down, you won't be able to get into the company address book in Outlook. You need a physical list of phone numbers for: your CSIRT, your IT provider, your cyber insurer and your lawyers.

Plan ahead before disaster strikes. Or at least be prepared enough not to lose your head when it does.

Aleksander

Sources:

• National Cybersecurity System Act (KSC)
• NIST Incident Response: 4-Step Life Cycle
• Ransomware Response Checklist
• Personal Data Breach Notification - Personal Data Protection Office (UODO)

FAQ

What is an Incident Response Plan (IRP), and why is it mandatory under NIS2?

An Incident Response Plan (IRP) is a documented set of procedures that defines how an organization detects, responds to, contains, recovers from and learns from cybersecurity incidents. The NIS2 Directive (Article 8 of the KSC Act) requires essential and important entities to have incident response procedures in place, including: (1) Appointing a CSIRT (Computer Security Incident Response Team) with clearly defined roles, (2) Procedures for detecting incidents and reporting them to the relevant national CSIRT within the 24/72h deadlines, (3) A crisis management process with delegated decision-making authority, (4) A communication plan (internal, external, supervisory authorities, media), (5) Recovery procedures (backup, business continuity). No IRP = no NIS2 compliance = risk of financial penalties and personal liability for management (up to 600% of salary).

What is the NIS2 24/72-hour reporting rule?

The 24/72h rule is the two-stage incident reporting process required by NIS2: Stage 1 - Early Warning: 24 hours from the moment the incident is detected (not when it occurred!), you must send an initial report to the relevant CSIRT (CSIRT NASK for most sectors, CSIRT GOV for public administration, CSIRT MON for defense). It doesn't need to be a full analysis. A "we have a problem" signal with basic information is enough (incident type, affected systems, initial impact assessment). Stage 2 - Incident Notification: 72 hours - an update to the report that includes a severity assessment, Indicators of Compromise (IoCs: IP addresses, malware hashes, C2 servers), a preliminary root cause assessment and information on the remediation measures taken. A critical mistake: counting time from the attack rather than from detection. The clock starts when you identify the incident, not when the attacker got into your systems (which may be unknown). This requires an automated escalation process that doesn't wait for Board signatures.

Who is the Incident Manager, and why shouldn't they be a technical person?

The Incident Manager is the person responsible for managing the entire response process, but not for doing the technical work. Why not a technician? Because "fighting the fire" (fixing systems) while also managing the process (coordinating the team, communicating with the Board, making strategic decisions) leads to cognitive overload and mistakes. Key Incident Manager responsibilities: (1) Team coordination - assigning tasks to analysts (Tier 1/2/3) and rotating shifts (max. 12 hours, to avoid burnout), (2) Communication with the Board - translating technical jargon into business language and providing updates every 2-4 hours, (3) Resource management - arranging meals, logistics and psychological support for an exhausted team, (4) Strategic decisions - Should we disconnect the production server? Should we pay the ransom? Should we notify customers?, (5) Documentation - maintaining the incident timeline (who did what, and when) for later analysis and reports to the CSIRT. Ideal profile: someone with business experience (former manager, PMO), not necessarily deep technical expertise, but with an understanding of cybersecurity fundamentals.

Why shouldn't you "pull the plug" during a ransomware attack?

"Pulling the plug" (a hard shutdown) during a ransomware attack is an instinctive but destructive reaction. Why is it a mistake? (1) Loss of evidence in RAM - key digital artifacts (malware processes, encryption keys, C2 network connections) exist only in memory and disappear when the power is cut. Forensics needs a memory dump before shutdown, (2) Losing the decryption key - modern ransomware sometimes keeps the decryption key in memory before sending it to the C2 server. Shutting down = losing the chance to recover data without paying the ransom, (3) Destroying the timeline - no logs of what happened after the attack (Which files were encrypted? In what order?), (4) Data corruption - abruptly killing processes can damage a database more than the ransomware itself. The correct procedure: (1) Network isolation (physically unplugging the cable or turning off Wi-Fi) - stops the spread without losing evidence, (2) RAM dump (memory dump) to an external device, (3) Securing backups - disconnecting backup systems from the network (top priority!), (4) Disk image for forensics, (5) Only then - a controlled shutdown.

What are Tabletop Exercises (TTX), and how do you run them?

Tabletop Exercises (TTX) are discussion-based simulation exercises that test Incident Response procedures in a safe, controlled setting without touching production systems. Format: A meeting in a conference room (2-4 hours) with key stakeholders: the Board, IT, PR, Legal, HR and Operations. A facilitator (an outside expert or the Incident Manager) walks through an attack scenario in real time: "It's Friday, 4:00 p.m. Hackers have encrypted production and are demanding USD 5 million. What do you do in the first 15 minutes? Who informs the Board? Do we disconnect systems? Who contacts the CSIRT?" Participants discuss their decisions, exposing gaps in the process (e.g., "we don't have a phone number for our lawyer," "we don't know who signs the CSIRT report"). Benefits: (1) Uncovering gaps in procedures without the real cost of an incident, (2) Building organizational "muscle memory" - the Board knows what to do under stress, (3) Testing the communication chain, (4) Identifying conflicts of authority (who has the authority to stop production?). How often: NIS2 recommends at least once a year, but ideally every quarter with different scenarios (ransomware, DDoS, data breach, insider threat).

What is the difference between a CSIRT and a SOC?

A CSIRT (Computer Security Incident Response Team) and a SOC (Security Operations Center) are two different teams with complementary roles: SOC - 24/7 Detection and Monitoring: A proactive team of analysts (Tier 1/2/3) that monitors SIEM/XDR in real time, detects anomalies and potential threats, escalates alerts and conducts Threat Hunting. The SOC operates around the clock and focuses on prevention and early detection. CSIRT - Incident Response: A reactive team activated after a serious incident is detected. It manages the entire Incident Response lifecycle (containment, eradication, recovery), communicates with the Board and authorities (CSIRT NASK), conducts forensics and post-mortem analysis, and documents lessons learned. A CSIRT can work on call (it doesn't need to operate 24/7). How they work together: The SOC detects a suspicious C2 connection at 3:00 a.m. → escalates to the on-call Incident Manager (CSIRT) → the CSIRT activates the full team, manages containment and reports to NASK. In small companies: These roles may overlap (a SOC analyst also serves as CSIRT Tier 1) or be fully outsourced to an MSSP.

How much does not having an Incident Response Plan cost?

The cost of not having an IRP shows up on three levels: 1. Direct incident costs (3-5x higher without an IRP): According to IBM's Cost of a Data Breach 2024, organizations with a tested IRP save an average of $2.66 million (USD 1.22 million vs. USD 3.88 million per incident). Why? Because: longer detection and containment times (MTTD/MTTR) = longer dwell time = greater damage; decision-making chaos = mistakes (e.g., pulling the plug and destroying evidence) = higher recovery costs; no offline backups = having to pay the ransomware ransom. 2. Regulatory penalties (NIS2/GDPR): No IRP procedures = violation of Article 8 of NIS2 = fines of up to €10 million or 2% of global turnover (important entities) / €20 million or 4% (essential entities). Late reporting (missing the 24/72h deadlines) = additional periodic penalties of PLN 100,000 per day, plus personal liability for management of up to 600% of salary. 3. Indirect (long-term) costs: Loss of reputation and customers (due to a lack of professional crisis communication), falling share prices (for public companies), higher cyber insurance premiums (insurers require an IRP), legal costs (lawsuits from customers and shareholders). Bottom line: Building a professional IRP (with TTX and training) costs PLN 50,000-200,000. Not having one could cost tens of millions of PLN.

What should a good Incident Response Plan include?

A good IRP aligned with the NIST Incident Response Lifecycle (4 phases) and NIS2 requirements includes: 1. CSIRT team structure: Roles (Incident Manager, Lead Analyst, Forensics Specialist, Communications Lead, Legal Liaison), a RACI matrix (who is responsible for what), contacts (phone numbers, email, alternative communication channels such as Signal or WhatsApp for when email is down). 2. Detection and classification procedures: A definition of an incident (What counts as an incident? What is just an "event"?), severity levels (Low/Medium/High/Critical) with clear criteria, escalation procedures (who makes decisions at each level?), integration with the SOC/SIEM - automated alerts. 3. Playbooks for common scenarios: Ransomware (isolate, don't shut down, secure backups, contact law enforcement), Data Breach (identify the scope, GDPR 72-hour notification, communication with UODO), DDoS Attack (mitigation, provider contact, backup infrastructure), Insider Threat (HR involvement, legal considerations, evidence preservation). 4. Communication: CSIRT report templates (24h Early Warning, 72h Incident Notification), internal messages (for employees), external messages (for customers, media and regulators), procedures for contacting your cyber insurer. 5. Recovery and lessons learned: Procedures for restoring systems from backup, Business Continuity Plan (BCP) integration, Post-Incident Review (PIR) - What went well? What needs to improve?, updating the IRP based on experience.

How often should you test an Incident Response Plan?

The minimum regulatory requirement (NIS2, ISO 27001) is once a year, but best practice is to test much more often, depending on the type of test: 1. Tabletop Exercises (TTX) - quarterly (4x/year): Rotating scenarios: Q1 ransomware, Q2 data breach, Q3 DDoS, Q4 insider threat. Change the participants - rotate Board members so it's not always "the same people" getting trained. 2. Simulation Exercises - every six months (2x/year): A simulation in a test (not production) environment - e.g., Purple Team (Red Team attacks, Blue Team defends), testing technical procedures plus communication. 3. Full-Scale Exercise - once a year: A comprehensive simulation involving all stakeholders, including communication with external partners (IT provider, insurer, CSIRT, media); the closest thing to a real incident. 4. Desk Check - after every infrastructure change: After any major IT change (cloud migration, new applications, mergers and acquisitions), review whether the IRP is still current (contacts, systems, playbooks). 5. After a real incident - immediately: A Post-Incident Review (PIR) within 2 weeks of closing the incident, updating the IRP based on lessons learned, and retraining the team if procedures have changed. Success metric: Organizations that test their IRP more than twice a year have 38% lower incident costs (IBM).

Who should be on a CSIRT team, and what are their roles?

A CSIRT (Computer Security Incident Response Team) combines technical and business roles: 1. Incident Manager: Manages the entire process (doesn't do technical work), coordinates the team, communicates with the Board, makes strategic decisions (should we take production offline?) and maintains the timeline documentation. Profile: Someone with PM or business experience, not necessarily a deep technical expert. 2. Lead Security Analyst: Directs the team's technical work (Tier 1/2/3), analyzes malware, IoCs and SIEM/XDR logs, coordinates containment and eradication, and recommends remediation. Profile: Senior SOC analyst with GCIH/GCIA/OSCP certifications. 3. Forensics Specialist: Collects and analyzes digital evidence (memory dumps, disk images, network captures), reconstructs the attack timeline (What did the attacker do? When? How did they get in?) and prepares the report for law enforcement. Profile: GCFE/EnCE certifications, malware analysis experience. 4. Communications Lead: Manages internal communication (employees) and external communication (customers, media, regulators), prepares press releases and FAQs, and coordinates with PR/Legal. Profile: Someone with a PR or crisis communications background. 5. Legal/Compliance Liaison: Ensures regulatory compliance (GDPR 72-hour notification, NIS2 24/72h), advises on legal questions (Should we notify customers? Should we pay the ransom?) and handles contact with authorities (UODO, CSIRT NASK, the public prosecutor's office). Profile: In-house counsel or an external legal advisor. 6. Business Continuity Lead: Manages system restoration, coordinates with IT Ops (restoring from backup), activates the BCP/DRP and minimizes business impact. Profile: IT Operations Manager. Note: In small companies, roles may overlap (e.g., Lead Analyst = Forensics) or be outsourced to an MSSP.

What does the incident response process look like (the 4 NIST phases)?

The NIST Incident Response Lifecycle defines 4 main response phases that form a cycle of continuous improvement: PHASE 1 - Preparation: Building the IRP, appointing the CSIRT, training and TTX, deploying tools (SIEM/XDR/SOAR), preparing an offline contact list and playbooks, testing backups (Are they offline? Do they work?). PHASE 2 - Detection & Analysis: 24/7 SOC monitoring (SIEM/XDR alerts), identifying the incident (is it a real incident or a false positive?), classifying severity (Low/Medium/High/Critical), initial scoping (Which systems are affected? How serious is it?), escalating to the Incident Manager. PHASE 3 - Containment, Eradication & Recovery: Containment: Isolating infected systems (network/physical), securing backups, blocking C2 IPs/domains, changing passwords and certificates, sending the Early Warning to the CSIRT (24h). Eradication: Removing malware, closing backdoors, patching exploited vulnerabilities, verifying that the intruder is actually gone (threat hunting). Recovery: Restoring systems from clean backups, heightened monitoring (is the attack coming back?), gradually restoring business operations. PHASE 4 - Post-Incident Activity: Post-Incident Review (PIR) - analyzing what went well and what didn't; lessons learned - what to improve in the IRP, procedures and tools; final report to the CSIRT (NIS2); updating playbooks and retraining the team. Key point: This isn't a linear process. Phases can overlap (e.g., containment and analysis at the same time), and the whole cycle ends by feeding back into Preparation for the next incident.

Do small businesses need an Incident Response Plan?

Yes. Small businesses need an IRP too, and arguably even more so, because: 1. Regulatory requirements (NIS2) apply to smaller companies as well: NIS2 covers entities with ≥50 employees or ≥ EUR 10 million in turnover across 18 sectors (energy, transport, banking, healthcare, ICT, food, etc.). Even if NIS2 doesn't apply to you, GDPR may (72-hour data breach notification), which also requires procedures. 2. Small businesses are just as attractive a target: Ransomware-as-a-Service attacks everyone, and small businesses are often easier targets (weaker defenses, no SOC). The average ransom demanded from SMBs is $50-200k, often more than their annual profit. 3. Lower resilience to incidents: A large corporation can survive a 3-day IT outage. A small business can go bankrupt (no access to invoices, payments or CRM). 4. No dedicated technical team: The typical IT admin at a small company isn't a cybersecurity expert and needs step-by-step procedures. Options for small businesses: A "lite" IRP - a simplified version focused on the basics (Who do we call? Where are the backups? How do we report to the CSIRT?), Outsourcing to an MSSP - many MSSPs offer "IRP-as-a-Service" with a 24/7 hotline (costing USD 1,000-3,000 per month), Templates and playbooks - NIST and ENISA publish free IRP templates you can adapt, A Tabletop Exercise once a year - even with no budget, you can run a TTX in-house (with the IT admin as facilitator and a scenario from the internet). Bottom line: For a small business, an IRP isn't a luxury. It's an insurance policy.