Incident Response Plan 2025: How to Prepare a Company for a Cyberattack? - NIS2 Requirements, 24/72h Rule, and Tabletop Exercises
Let's start with a brutal truth: in the mid-2020s, the traditional concept of "security" as a state free from threats has become a work of fiction. In 2025, governed by the NIS2 directive and the amended National Cybersecurity System Act (KSC), a new paradigm rules: resilience.
This is not another post about which antivirus software to buy. This is a survival guide for when the systems go down and the CEO's phone starts ringing in the middle of the night. Based on the "Complete Guide to Building Organizational Resilience," I have prepared a roadmap to help you turn chaos into an organized defense.
1. Understand That the Board’s Head is on the Block
If your CEO thinks cybersecurity is just a problem for "the IT guys," you need to correct them—fast. The amendment to the KSC Act has revolutionized the scope of responsibility.
This is no longer just a matter of "best practice." In cases of serious negligence, the supervisory authority can impose a financial penalty directly on the person managing the entity—up to 600% of their salary. Furthermore, it is even possible to temporarily suspend them from their management duties.
Practical takeaway: Your Incident Response Plan (IRP) must be approved by the Board, and the C-level executives must know their role in the decision-making structure. Without delegating authority to the Incident Manager to make tough decisions (e.g., stopping production), paralysis will set in during a critical moment.
2. Appoint an Incident Manager (And Don't Make It a Techie)
In the heat of battle against a cyberattack, the worst thing you can do is let everyone rush to their keyboards. An effective team (CSIRT) needs structure.
The key role is the Incident Manager. This is a person who does not "touch the keyboard" but manages the chaos. They are the translator between the technical jargon of IT and the business language of the Board. They ensure the technical team doesn't fall into the trap of "tunnel vision" and make mistakes due to fatigue.
A team that is exhausted after 24 hours of fighting an incident makes mistakes that can cost more than the attack itself.
Remember prosaic but critical elements: staff rotation (shifts of max. 12h) and providing food.
3. Apply the "Don't Pull the Plug" Procedure
When a ransom note (Ransomware) appears on the screen, instinct tells us to cut the power as quickly as possible. This is a mistake that can make data recovery impossible.
Modern procedures (Playbooks) are clear:
- Do not turn off the power: You will lose evidence in the RAM and potentially the encryption keys.
- Isolate the network: Physically unplug the network cable or turn off Wi-Fi.
- Secure backups: This is the absolute priority—immediately disconnect backup systems from the main network before the virus reaches them.
Only after full isolation and evidence gathering (memory dumps, disk images) can you think about "cleaning" and restoring systems.
4. The Clock is Ticking: The 24/72 Hour Rule
Implementing NIS2 requirements means the time for reporting incidents has shrunk drastically. The procedure is no longer just an internal company matter.
You must be ready for a reporting "relay race":
- Early Warning: You have only 24 hours from detection to inform the appropriate CSIRT (NASK, GOV, or MON). This is not the time for full analysis; it’s a "we have a problem" signal.
- Incident Notification: Within 72 hours, you must provide an update with an assessment of severity and Indicators of Compromise (IoC).
If your procedure requires three director signatures to send an email, you have already lost. You must have a prepared "fast track" for reporting.
5. Test "Dry Runs" Because Paper Accepts Everything
The biggest lie in cybersecurity is the sentence: "We have procedures, so we are safe." An untested procedure is just a hypothesis.
The most effective verification tool is Tabletop Exercises (TTX). Gather the Board, PR, Legal, and IT in one room. Throw them a scenario: "It's Friday, 4:00 PM, hackers have encrypted the databases and are demanding 5 million dollars. What do you do?". Such exercises expose gaps in communication and decision-making faster than any technical audit. They allow you to build the organization's "muscle memory".
What Can You Do Today?
You don't have to implement a complex SIEM system right away. Start with a small step that could save the company: Create and print (offline!) a Contact List. When systems go down, you won't be able to access the corporate address book in Outlook. You must have a physical list of phone numbers for: the CSIRT, IT provider, cyber insurer, and lawyers.
Be smart before the damage is done. Or at least be prepared not to lose your head while the damage is happening.
Aleksander
Want to Prepare Your Company for a Cyberattack?
If you need help building an Incident Response Plan, training a CSIRT team, conducting Tabletop Exercises, or auditing current response procedures – contact us. We'll help prepare your organization for incidents in compliance 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 an internal incident response team (Incident Manager, Tier 1/2/3)
- Tabletop Exercises (TTX) - tabletop exercises testing procedures and management communication in simulated attack scenarios
- Ransomware Response Planning - dedicated ransomware response procedures including the "don't pull the plug" rule
- NIS2 procedure audit - verification of compliance with 24/72h reporting requirements and CSIRT contact
- 24/7 incident support - access to experts during an actual attack, assistance in communication with CSIRT/UODO
📧 Contact an Incident Response expert →
See Also - Related Topics
Cybersecurity and Compliance
- NIS2 in Poland - Complete Guide - Detailed incident reporting requirements, 24/72h deadlines, and board responsibility
- Security Operations Center (SOC): Comprehensive Guide for 2026 - How 24/7 SOC supports rapid incident detection and response
- Managed Security Services Provider (MSSP) - Selection Guide - Incident response outsourcing: how to choose a provider with 24/7 Incident Response
Technologies Supporting Incident Response
- SIEM vs XDR - Which Solution to Choose? - Incident detection technologies and MTTD/MTTR support
- SOAR - Security Operations Automation - How automation accelerates incident response (playbooks, orchestration)
- Threat Hunting - Advanced Guide - Proactive threat detection before they become incidents
FAQ - Frequently Asked Questions about Incident Response Plan
What is an Incident Response Plan (IRP) and why is it mandatory under NIS2?
Incident Response Plan (IRP) is a documented set of procedures defining 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 mandatorily have incident response procedures, including: (1) Designation of a CSIRT team (Computer Security Incident Response Team) with clear role division, (2) Procedures for detecting and reporting incidents within 24/72h timeframes to the appropriate national CSIRT, (3) Crisis management process with delegated decision-making authority, (4) Communication plan (internal, external, supervisory authorities, media), (5) Recovery procedures (backup, business continuity). No IRP = non-compliance with NIS2 = risk of financial penalties and personal board responsibility (up to 600% of salary).
What is the 24/72 hour reporting rule in NIS2?
The 24/72h rule is a two-stage incident reporting process required by NIS2: Stage 1 - Early Warning: 24 hours from the moment of detection (not occurrence!) of an incident, you must send a preliminary report to the appropriate CSIRT (NASK for most sectors, GOV CSIRT for administration, MON CSIRT for defense). This doesn't have to be a full analysis - just a "we have a problem" signal with basic information (incident type, affected systems, preliminary impact assessment). Stage 2 - Incident Notification: 72 hours - update the report with: severity assessment, Indicators of Compromise (IoC: IPs, malware hashes, C2 servers), preliminary cause assessment, information on remedial measures applied. Critical mistake: counting time from the attack, not from detection. The timer starts when you identified the incident, not when the hacker entered the system (which may be unknown). This requires an automated escalation process (without waiting for board signatures).
Who is an Incident Manager and why shouldn't they be technical?
Incident Manager (Incident Lead) is a person responsible for managing the entire response process, but not performing technical work. Why not a techie? Because simultaneously "fighting the fire" (fixing systems) and managing the process (team coordination, board communication, strategic decisions) leads to cognitive overload and mistakes. Key Incident Manager roles: (1) Team coordination - delegating tasks to analysts (Tier 1/2/3), shift rotation (max 12h to avoid burnout), (2) Board communication - translating technical jargon into business language, providing updates every 2-4h, (3) Resource management - ensuring meals, logistics, psychological support for an exhausted team, (4) Strategic decisions - whether to disconnect production server? Whether to pay ransom? Whether to inform customers?, (5) Documentation - maintaining incident timeline (who, what, when did) for later analysis and CSIRT reports. Ideal profile: person with business experience (ex-manager, PMO), not necessarily deep technical knowledge, but understanding cybersecurity basics.
Why shouldn't you "pull the plug" during a ransomware attack?
"Pulling the plug" (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 operational memory and disappear after power off. Forensics needs a memory dump before shutdown, (2) Missing decryption key - modern ransomware sometimes keeps the decryption key in memory before sending it to C2. Shutdown = loss of chance to recover data without paying ransom, (3) Destroyed timeline - no logs of what happened after the attack (which files were encrypted? In what order?), (4) Data corruption - abrupt process interruption can damage the database more than the ransomware itself. Correct procedure: (1) Network isolation (physical cable unplugging/Wi-Fi off) - stops spreading without losing evidence, (2) RAM memory dump to external device, (3) Backup securing - disconnecting backup systems from network (highest priority!), (4) Disk image for forensics, (5) Only then - controlled shutdown.
What are Tabletop Exercises (TTX) and how to conduct them?
Tabletop Exercises (TTX) are simulation tabletop exercises testing Incident Response procedures in a safe, controlled environment without touching production systems. Format: Meeting in a conference room (2-4 hours) with key stakeholders: board, IT, PR, legal, HR, operations. Moderator (external expert or Incident Manager) presents an attack scenario in real time: "It's Friday, 4:00 PM. Hackers encrypted production and demand $5M. What do you do in the first 15 minutes? Who informs the board? Do we disconnect systems? Who contacts CSIRT?". Participants discuss decisions, exposing process gaps (e.g., "we don't have lawyer's phone," "we don't know who signs CSIRT report"). Benefits: (1) Discovering procedure gaps without real incident costs, (2) Building organizational "muscle memory" - board knows what to do under stress, (3) Testing communication chain, (4) Identifying authority conflicts (who has authority to stop production?). How often: NIS2 recommends minimum once a year, but ideally quarterly with different scenarios (ransomware, DDoS, data breach, insider threat).
What's the difference between CSIRT and SOC?
CSIRT (Computer Security Incident Response Team) and SOC (Security Operations Center) are two different teams performing complementary roles: SOC - Detection and 24/7 Monitoring: Proactive team of analysts (Tier 1/2/3) monitoring SIEM/XDR in real time, detecting anomalies and potential threats, escalating alerts, conducting Threat Hunting. SOC operates non-stop, focuses on prevention and early detection. CSIRT - Incident Response: Reactive team activated after detecting a serious incident, manages the entire Incident Response cycle (containment, eradication, recovery), communicates with management and authorities (NASK CSIRT), conducts forensics and post-mortem analysis, documents lessons learned. CSIRT can be on-call (doesn't have to work 24/7). Cooperation example: SOC detects suspicious C2 connection at 3:00 AM → escalates to on-call Incident Manager (CSIRT) → CSIRT activates full team, manages containment, reports to NASK. In small companies: These roles may overlap (SOC analyst also serves as CSIRT Tier 1) or be fully outsourced to MSSP.
How much does not having an Incident Response Plan cost?
The cost of lacking an IRP manifests on three levels: 1. Direct incident costs (increased 3-5x without IRP): According to IBM Cost of Data Breach 2024, organizations with tested IRP save an average of $2.66M ($1.22M USD vs $3.88M USD incident cost). Why? Because: Longer detection and containment time (MTTD/MTTR) = higher dwell time = greater scope of damage, decision chaos = mistakes (e.g., pulling plug destroying evidence) = higher recovery costs, lack of offline backups = necessity to pay ransomware ransom. 2. Regulatory fines (NIS2/GDPR): Lack of IRP procedures = violation of NIS2 Article 8 = penalty up to €10M or 2% of global turnover (important entity) / €20M or 4% (essential entity). Reporting delay (exceeding 24/72h) = additional periodic penalties 100k PLN/day, personal board responsibility up to 600% of salary. 3. Indirect costs (long-term): Loss of reputation and customers (lack of professional crisis communication), stock value drop (public companies), increase in cyber insurance premiums (insurers require IRP), legal costs (customer/shareholder lawsuits). Bottom line: Cost of building professional IRP (with TTX, training) = 50-200k PLN. Cost of lacking IRP = potentially tens of millions PLN.
What should a good Incident Response Plan contain?
A good IRP compliant with NIST Incident Response Lifecycle (4 phases) and NIS2 requirements contains: 1. CSIRT team structure: Roles (Incident Manager, Lead Analyst, Forensics Specialist, Communications Lead, Legal Liaison), RACI matrix (who is responsible for what), contacts (phones, email, alternative communication channels - Signal, WhatsApp for when email doesn't work). 2. Detection and classification procedures: Incident definition (what is an incident? What is just an "event"?), Severity levels (Low/Medium/High/Critical) with clear criteria, Escalation procedures (who makes decisions at each level?), SOC/SIEM contact - automatic alerts. 3. Playbooks for common scenarios: Ransomware (isolation, don't shut down, secure backups, law enforcement contact), Data Breach (scope identification, GDPR 72h notification, UODO communication), DDoS Attack (mitigation, provider contact, backup infrastructure), Insider Threat (HR involvement, legal consideration, evidence preservation). 4. Communication: CSIRT report templates (Early Warning 24h, Incident Notification 72h), Internal communications (for employees), External communications (for customers, media, regulators), Cyber insurer contact procedures. 5. Recovery and lessons learned: System restoration procedures from backup, Business Continuity Plan (BCP) integration, Post-Incident Review (PIR) - what went well? What to improve?, IRP update based on experience.
How often should an Incident Response Plan be tested?
Minimum regulatory requirements (NIS2, ISO 27001) are once a year, but best practices are much more frequent depending on test type: 1. Tabletop Exercises (TTX) - quarterly (4x/year): Rotating scenarios: Q1 ransomware, Q2 data breach, Q3 DDoS, Q4 insider threat. Participant rotation - rotate board members so not only "the same" people are trained. 2. Simulation Exercises - semi-annually (2x/year): Simulation in test environment (not production) - e.g., Purple Team (Red Team attacks, Blue Team defends), technical procedure + communication test. 3. Full-Scale Exercise - annually: Comprehensive simulation with all stakeholder engagement, including communication with external partners (IT provider, insurer, CSIRT, media), most similar to real incident. 4. Desk Check - every infrastructure change: After any major IT change (cloud migration, new applications, mergers/acquisitions) - IRP review if it's current (contacts, systems, playbooks). 5. After real incident - immediately: Post-Incident Review (PIR) within 2 weeks of closing incident, IRP update based on lessons learned, team retraining if procedures changed. Success indicator: Organizations testing IRP >2x/year have 38% lower incident costs (IBM).
Who should be on the CSIRT team and what are their roles?
The CSIRT team (Computer Security Incident Response Team) consists of technical and business roles: 1. Incident Manager: Manages entire process (doesn't perform technical work), coordinates team, communicates with board, makes strategic decisions (whether to disconnect production?), maintains timeline documentation. Profile: Person with PM/business experience, not necessarily deep tech. 2. Lead Security Analyst: Leads technical team work (Tier 1/2/3), analyzes malware, IoC, SIEM/XDR logs, coordinates containment and eradication, 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 attack timeline (what did hacker do? When? How did they get in?), prepares law enforcement report. Profile: GCFE/EnCE certifications, malware analysis experience. 4. Communications Lead: Manages internal communication (employees), external (customers, media, regulators), prepares press releases and FAQs, coordinates with PR/Legal. Profile: Person from PR/crisis communication. 5. Legal/Compliance Liaison: Ensures regulatory compliance (GDPR 72h notification, NIS2 24/72h), advises on legal matters (whether to inform customers? Whether to pay ransom?), contacts authorities (UODO, NASK CSIRT, prosecutor's office). Profile: In-house counsel or external legal advisor. 6. Business Continuity Lead: Manages system restoration, coordinates with IT Ops (restore from backup), activates BCP/DRP, minimizes business impact. Profile: IT Operations Manager. Note: In small companies roles may overlap (e.g., Lead Analyst = Forensics), or be outsourced to MSSP.
What does the incident response process look like (NIST 4 phases)?
NIST Incident Response Lifecycle defines 4 main response phases that create a continuous improvement cycle: PHASE 1 - Preparation: IRP building, CSIRT designation, training and TTX, tool implementation (SIEM/XDR/SOAR), offline contact list and playbook preparation, backup tests (are they offline? Do they work?). PHASE 2 - Detection & Analysis: SOC 24/7 monitoring (SIEM/XDR alerts), incident identification (is it a real incident or false positive?), severity classification (Low/Medium/High/Critical), preliminary scope analysis (which systems affected? How serious?), escalation to Incident Manager. PHASE 3 - Containment, Eradication & Recovery: Containment: Infected system isolation (network/physical), backup securing, C2 IP/domain blocking, password and certificate changes, Early Warning communication to CSIRT (24h). Eradication: Malware removal, backdoor closure, exploited vulnerability patching, verification that intruder actually left (threat hunting). Recovery: System restoration from clean backups, enhanced monitoring (is attack returning?), gradual business operations restoration. PHASE 4 - Post-Incident Activity: Post-Incident Review (PIR) - analysis what went well, what poorly, lessons learned - what to improve in IRP/procedures/tools?, final report to CSIRT (NIS2), playbook update and team retraining. Key: This isn't a linear process - phases may overlap (e.g., containment and analysis simultaneously), and the entire cycle ends with entering Preparation for the next incident.
Do small companies need an Incident Response Plan?
Yes, even (or perhaps especially) small companies need IRP, because: 1. Regulatory requirements (NIS2) also apply to small companies: NIS2 covers entities ≥50 employees or ≥€10M turnover in 18 sectors (energy, transport, banking, health, ICT, food, etc.). Even if you're not subject to NIS2, you may be subject to GDPR (72h data breach notification) - also requires procedures. 2. Small companies are equally attractive targets: Ransomware-as-a-Service attacks everyone - small companies are often easier targets (weaker defenses, no SOC). Average ransom demanded from SMB: $50-200k - often more than annual profit. 3. Less resilience to incident: Large corporation will survive a 3-day IT outage. Small company may go bankrupt (no access to invoices, payments, CRM). 4. Lack of technical team: Typical IT admin in small company isn't a cybersecurity expert - needs step-by-step procedures. Solutions for small companies: "Lite" IRP - simplified version focused on basics (who to call? Where are backups? How to report to CSIRT?), MSSP outsourcing - many MSSPs offer "IRP-as-a-Service" with 24/7 hotline (cost $1-3k/month), Templates and playbooks - NIST/ENISA publish free IRP templates that can be adapted, Tabletop Exercise once a year - even without budget can conduct TTX internally (moderator = IT admin, internet scenario). Bottom line: IRP for small company isn't a luxury, it's an insurance policy.
Sources:
About the Author
Dyrektor ds. Technologii w SecurHub.pl
Doktorant z zakresu neuronauki poznawczej. Psycholog i ekspert IT specjalizujący się w cyberbezpieczeństwie.
Powiązane artykuły
Koniec ery "klikania w konsolę". Jak SOAR i Agentic AI ratują nas przed cyfrowym wypaleniem
Analitycy SOC toną w powodzi danych, marnując godziny na fałszywe alarmy. Czy rok 2025 i nadejście autonomicznych agentów AI to moment, w którym maszyny w końcu pozwolą ludziom przestać "gonić duchy" i zacząć myśleć strategicznie?
Security Operations Center (SOC): Kompleksowy Przewodnik na 2026 | Budowa i Wdrożenie
Poznaj wszystko o Security Operations Center (SOC) - od budowy zespołu, przez technologie SIEM/XDR/SOAR, wymogi NIS2, modele wdrożenia, aż po przyszłość z AI. Praktyczny przewodnik dla CISO i menedżerów IT.
MSSP 2025: 4 Pułapki Przy Wyborze Dostawcy Managed Security (I Dlaczego Własny SOC Kosztuje 5x Więcej)
Własny SOC 24/7 wymaga 5-6 analityków na etat i kosztuje 5x więcej niż myślisz. Odkryj 4 krytyczne błędy przy wyborze MSSP, różnicę MSP vs MSSP, prawdę o "15 minutach reakcji" i dlaczego outsourcing nie zwalnia zarządu z odpowiedzialności NIS2.
Komentarze
Ładowanie komentarzy...