NIS2 Emergency Planning: A Complete Guide to Building Business Continuity That Actually Works
When ransomware locks your systems at 2 AM on a Friday, your emergency plan either saves the company or reveals itself as fiction. There's no middle ground. The document sitting in SharePoint, unread, becomes worthless the moment you actually need it.
Article 21(2)(c) of the NIS2 Directive requires "business continuity, such as backup management and disaster recovery, and crisis management." These aren't suggestions. They're legal requirements with penalties reaching €10 million or 2% of global turnover for essential entities. But beyond the regulatory pressure lies a more fundamental truth: a properly built emergency plan is the difference between a disruption that costs hours and one that threatens your company's survival.
This guide walks through every step of creating an emergency plan that satisfies NIS2 requirements and actually functions under pressure. No theoretical frameworks. No checkbox exercises. Practical steps that thousands of European companies have used to build real resilience.
Understanding What NIS2 Actually Requires
The NIS2 Directive doesn't ask for vague "preparedness." It demands specific capabilities across three distinct domains that work together during incidents.
Backup management ensures critical data can be restored when primary systems fail or become compromised. This includes not just having backups, but verifying they work and protecting them from the same threats affecting production systems.
Disaster recovery covers the technical restoration of systems and services. When your database server fails or ransomware encrypts your infrastructure, DR procedures bring systems back online in a defined sequence with verified functionality.
Crisis management coordinates the human response. While technical teams restore systems, someone must make decisions, communicate with stakeholders, fulfill the 24-hour regulatory notification requirement, and ensure the business continues operating through alternate means if necessary.
The Implementing Regulation (EU) 2024/2690 adds specific evidence requirements: documented plans, business impact analysis, backup policies with restoration procedures, records of testing, and crisis communication templates. Regulators expect to see not just that you planned, but that you tested, documented the results, and improved based on findings.
Step 1: Business Impact Analysis — Finding What Actually Matters
You cannot protect everything equally. Attempting to do so wastes resources and creates confusion during actual incidents. Business Impact Analysis (BIA) identifies what matters most and establishes the recovery requirements that drive all subsequent planning.
Identifying Critical Business Functions
Start with what the business does, not what IT systems exist. Ask: if this function stopped entirely, what would happen in one hour? One day? One week?
Consider a mid-sized manufacturing company as an example. Their critical functions might include customer order processing, production scheduling, quality management systems, and financial transactions. Notice these are business activities, not applications. The ERP system matters because it supports these functions, not as an end in itself.
For each function, document who depends on it, what regulatory obligations attach to it, and what happens operationally when it fails. A customer portal outage for a SaaS company damages revenue and reputation immediately. An internal HR system outage is annoying but survivable for days.
Defining Recovery Requirements
Every critical function needs two specific metrics defined by business stakeholders, not IT alone.
Recovery Time Objective (RTO) answers: how quickly must this function be restored before unacceptable harm occurs? The answer varies dramatically by function. A hospital's patient records system might need a 15-minute RTO. A marketing analytics dashboard might tolerate 72 hours.
Recovery Point Objective (RPO) answers: how much data loss is acceptable? If you backup daily at midnight and an incident occurs at 11 PM, you could lose nearly 24 hours of data. For transaction systems, this might be catastrophic. For configuration files that rarely change, daily backups may be sufficient.
In general, RTO and RPO can only be determined if the so called MTPD (Maximum Tolerable Period of Disruption) has been determined. If we know, for instance, that we can survive a downtime of, let's say, 3 days.
Once the MTPD has been calculated, we know that our RTO must be smaller than or equal to out MTPD, as otherwise the organization would not survive the outage. This is typically determined before RTO and RPO.
Here's a practical example of how this looks documented:
These numbers drive everything else. If customer transactions require 15-minute RPO, you need near-continuous replication or very frequent backups. If financial reporting tolerates a 72-hour RTO, you have flexibility in how you approach its recovery.
Mapping Dependencies
Every function depends on systems, data, people, and third parties. Document these dependencies explicitly because during a crisis, missing a single dependency means a failed recovery.
For customer transactions, the dependency chain might look like this: the payment gateway requires internet connectivity and credentials stored in a specific vault. The CRM requires a database server, an application server, and integration with an email service. Order processing requires ERP connection and inventory system access. Each link in this chain must be recoverable within the function's RTO.
Step 2: Building Your Backup Management System
Backups represent your last line of defense. When ransomware encrypts production and attackers have deleted online backups, your offline copies determine whether you recover or pay.
The 3-2-1-1-0 Backup Strategy
Modern backup strategy extends the classic 3-2-1 rule:
Maintain three copies of critical data: production plus two backups. Use two different media types, because a bug affecting your primary backup system shouldn't compromise your secondary. Keep one copy offsite, geographically separated from your primary location. Add one copy offline or immutable, completely disconnected from any network that an attacker could reach. Verify zero errors through regular restoration testing.
The offline or immutable copy deserves emphasis. Sophisticated ransomware attacks specifically target backup systems. They compromise backup credentials, delete backup catalogs, and encrypt backup data alongside production. An air-gapped copy that physically cannot be reached through your network is your insurance against this scenario.
Backup Configuration by System Type
Different systems require different approaches based on their RPO requirements.
For systems requiring near-zero RPO, implement synchronous replication to a secondary site or continuous data protection that captures every change. Transaction databases and critical business applications typically fall here.
For systems with 1-24 hour RPO, daily or more frequent scheduled backups suffice. Verify they complete successfully and test restoration quarterly. Most business applications fit this category.
For systems with multi-day RPO, weekly backups with longer retention may be appropriate. Documentation, static configurations, and development environments often fall here.
Backup Documentation Requirements
For NIS2 compliance, document your backup strategy comprehensively. This documentation should cover what data is backed up and at what frequency, where backups are stored physically and logically, how long backups are retained, who can access backup systems and with what credentials, how backups are protected including encryption and access controls, and the procedures for restoration, including step-by-step instructions.
Step 3: Disaster Recovery Procedures
Backups without restoration procedures are just storage costs. DR procedures translate backup capability into actual recovery.
Creating Recovery Procedures That Work
Each critical system needs documented recovery procedures detailed enough that someone unfamiliar with the system could execute them. This isn't an insult to your team; it's recognition that during a 2 AM crisis, your primary expert might be unavailable.
A recovery procedure for a database server might include these elements:
Pre-recovery assessment: Check what caused the failure. Verify backup integrity before beginning restoration. Confirm network connectivity to the restoration target. Estimate total recovery time and communicate to stakeholders.
Recovery execution: Start with the detailed steps. Connect to backup management console using credentials from the password vault (location specified). Navigate to the backup catalog and select the most recent verified backup. Initiate restoration to the designated recovery server. This typically takes 2-4 hours for a database of this size. Monitor progress and address any errors that appear.
Verification: Once restored, run database integrity check using the specified command. Verify application connectivity by testing the designated URL. Confirm data currency by checking the timestamp of the last transaction. Execute test transactions through the application.
Completion: Notify the technical lead that the database is restored and verified. Update the incident log with restoration details. Schedule post-incident review within 48 hours.
Notice the specificity. Not "restore the backup" but exactly how, where to find credentials, what commands to run, how long each step takes, and how to verify success.
Recovery Sequence Planning
Systems have dependencies. You cannot restore your web application before the database it depends on is running. Document the recovery sequence based on these dependencies.
A typical sequence might be: First, restore core infrastructure, including network, DNS, and authentication. Second, restore database systems. Third, restore application servers. Fourth, restore integration and middleware. Fifth, restore user-facing systems.
Within each phase, specify the order of individual system restoration.
Alternative Operations
Sometimes, full recovery takes longer than business can tolerate. Document workarounds that allow critical functions to continue during extended outages.
If your order management system is down for 24 hours, can customer service take orders via phone and enter them manually later? If email is unavailable, do you have an alternate communication channel? If your primary data center is completely lost, can you operate from a secondary location?
These alternatives aren't preferred, but they provide continuity options while technical recovery proceeds.
Step 4: Crisis Management Team and Procedures
Technical recovery alone isn't sufficient. Someone must coordinate the overall response, make decisions, and manage communications.
Defining the Crisis Management Team
Your crisis management team needs clear roles with defined responsibilities and pre-authorized decision-making authority.
Executive sponsor holds ultimate authority for major decisions, including resource allocation, external communication approval, and business impact tradeoffs. This person can commit company resources without waiting for additional approvals.
Crisis coordinator manages the overall response, ensures all workstreams are progressing, identifies blockers, and maintains the incident timeline. This person doesn't do technical work; they ensure technical work happens.
Technical lead directs IT recovery efforts, coordinates technical teams, and provides status updates to the crisis coordinator. They make technical decisions about recovery approach and sequence.
Communications lead handles internal employee communications, external customer notifications, media inquiries, if applicable, and coordinates with marketing and PR. They ensure consistent messaging and timely updates.
Legal and compliance contact addresses regulatory notification requirements, including the NIS2 24-hour requirement, assesses liability implications, and advises on communication content.
Each role needs a primary and a backup person assigned. Document contact information and escalation procedures.
Pre-Authorized Decision Authority
During crises, waiting for approvals costs critical time. Define in advance what decisions each team member can make without escalation.
The technical lead might be authorized to spend up to €50,000 on emergency vendor support, bring in contractors, and make system configuration changes. The communications lead might be authorized to send internal updates and standard customer notifications. The executive sponsor might need to approve external media statements, expenditures above the threshold, and decisions affecting customer contracts.
Document these authorities explicitly so nobody hesitates during an actual incident.
Crisis Communication Templates
When an incident occurs, you don't have time to craft communications from scratch. Prepare templates in advance.
For internal employee notification: "We are currently experiencing a technology incident affecting [systems]. Our teams are working to restore service. [Work from home/come to office] instructions. Updates will follow every [timeframe]. Questions to [contact]."
For customer notification: "We are aware of an issue affecting [services]. Our technical teams are actively working on a resolution. We expect [estimated impact/timeline]. We will provide updates as we have more information. We apologize for any inconvenience."
For regulatory notification, NIS2 requires a 24-hour early warning to your national CSIRT or competent authority. This template should include entity identification, description of the incident and affected systems, initial assessment of impact, preliminary indication of whether the incident was caused by unlawful or malicious acts, and contact information for follow-up.
Having these templates reviewed by legal and approved in advance eliminates delay when you need to communicate under pressure.
Step 5: Testing Your Emergency Plan
An emergency plan that has never been tested is an assumption about what would happen, not a demonstrated capability. Testing reveals gaps, builds team muscle memory, and validates that recovery actually works.
Types of Testing
Tabletop exercises gather the crisis management team to walk through a scenario verbally. No systems are touched. The goal is testing decision-making, communication flows, and identifying gaps in procedures. Run these semi-annually.
A tabletop scenario might be: "It's 7 AM Monday. Overnight, ransomware encrypted 70% of your servers, including all domain controllers. The attackers demand €500,000 in Bitcoin. Your CISO is on vacation in a location without reliable phone service. Go."
Walk through: Who gets notified first? What decisions need to be made immediately? How do you communicate with employees who can't access email? When and how do you notify regulators? What's your negotiation position on ransom? Each question reveals whether your procedures address real scenarios.
Functional tests verify that specific technical capabilities work. Can you actually restore from backup? How long does it take? Test backup restoration quarterly for critical systems.
Full-scale exercises simulate actual crisis conditions as closely as possible without affecting production. Activate response procedures, use communication channels, and work through recovery steps. Run these annually or every 18 months for the full scope, with smaller functional tests throughout the year.
Documenting Test Results
For NIS2 compliance, testing must be documented. Record what was tested, including the date, scenario, and participants. Note what worked and what didn't work. Capture specific issues identified and the remediation actions planned with assigned owners and target dates. Document how remediation was verified.
This documentation demonstrates to regulators that you maintain and improve your capabilities over time.
Improving Based on Results
Every test reveals improvement opportunities. Maybe restoration took 6 hours instead of the planned 4. Maybe the backup for a critical system hadn't run successfully for two weeks. Maybe the crisis coordinator didn't know how to reach the executive sponsor.
Each finding needs an owner and a deadline. Track remediation to completion. The next test should verify that the fix worked.
Putting It All Together: Your NIS2 Emergency Plan Documentation
Your complete emergency plan should include these documented components:
Business Impact Analysis covering methodology, critical function identification, RTO, and RPO for each function, dependency mapping, and management approval.
Business Continuity Plan covering scope and objectives, roles and responsibilities, continuity procedures for each critical function, communication procedures, and alternative operations.
Disaster Recovery Plan covering system recovery procedures with step-by-step detail, recovery sequence, resource requirements, contact information for vendors and support, and alternative arrangements.
Backup Management Documentation covering backup policy, backup schedules and coverage, retention periods, security controls, and restoration procedures.
Crisis Management Documentation covering team composition with contact details, activation criteria, response procedures, communication templates, and escalation paths.
Testing Records covering test schedule, results of each test, issues identified, remediation actions and verification.
This documentation serves dual purposes: it guides actual response during incidents, and it demonstrates compliance to regulators.
The Reality Check
Building a complete emergency plan takes effort. For a mid-sized company starting from minimal documentation, expect 2-4 months of focused work to establish the foundation, with ongoing maintenance thereafter.
But the alternative is worse. When an incident occurs without preparation, you're making critical decisions under pressure without information, trying to restore systems without documented procedures, and discovering dependencies through trial and error. The cost in extended downtime, regulatory penalties, and reputation damage far exceeds the investment in proper planning.
NIS2 compliance isn't just about avoiding fines. It's about building the capabilities that let your company survive incidents that are increasingly common and increasingly severe.
Kertos helps companies build and maintain emergency plans that work. Our platform includes integrated BCP and DRP documentation, backup verification tracking, testing management, and the evidence trails regulators expect. We've helped hundreds of European companies build resilience that passes both audits and real incidents.
Start your automated NIS2 assessment
