Business continuity and cybersecurity: How to plan for uninterrupted operations

A 2024 survey showed that companies without a documented Business Continuity Plan (BCP) take on average 3,5× longer to return to normal operations after a cyber incident than organisations with a BCP. Yet creating a BCP is not necessarily a complex and expensive project, even a basic version can cover the greatest risks in a smaller company.

This article explains key concepts, NIS2 requirements and the practical steps for creating an effective business continuity plan with a focus on cyber threats.

BCP vs. DRP: What is the difference and why does it matter?

Two basic terms are often confused or conflated:

Business Continuity Plan (BCP)

BCP is a strategic document describing how an organisation will operate under disrupted conditions. It answers the question: How will we run our business if our usual ways of operating fail?

BCP includes:

• Identification of critical business processes and their prioritisation.
• Alternative methods for performing critical processes (manually, using another system, or at a different workplace).
• Communication plan: who contacts whom and through which channels.
• Roles and responsibilities of the crisis team.

Disaster Recovery Plan (DRP)

DRP is a technical document describing how to restore IT infrastructure and systems after an outage. It answers the question: How we restore IT systems to operation?

DRP includes:

• Recovery procedures for every critical system.
• Backup strategies and data recovery.
• Failover procedures (switching to backup systems).
• Test procedures.

Simply put: the BCP states what the company will do; the DRP explains how technicians will restore systems. Both are essential: a DRP without a BCP leads to a situation where IT restores systems but the company does not know how to operate in the interim. A BCP without a DRP results in the company knowing what it wants to do but lacking the tools for restoration.

RTO and RPO: Key metrics for cyber scenarios

Two key metrics for operational continuity:

RTO (Recovery Time Objective)

RTO is the maximum acceptable downtime for a system or process, i.e., how long it must take to restore the system to avoid unacceptable business losses.

Examples:

• E-shop: RTO for payment system = 2 hours (each hour of downtime = direct loss of revenue).
• Manufacturer: RTO for ERP system = 24 hours (production may temporarily operate manually).
• Hospitals: RTO for medical IT systems = 30 minutes (patient safety).

RPO (Recovery Point Objective)

RPO is the maximum acceptable data loss, i.e., how old the data we are willing to restore from a backup can be without causing unacceptable problems.

Examples:

• E-shop: RPO for the order system = 1 hour (loss of orders exceeding one hour is unacceptable).
• Accounting: RPO = 24 hours (a daily advance payment is sufficient).
• Financial transactions: RPO = 0 (no data loss: synchronous replication required).

How to determine RTO and RPO

Correctly determining RTO and RPO requires a Business Impact Analysis (BIA): an assessment of the impact of downtime on business processes.

1. Identify critical business processes and their dependencies on IT systems.
2. Quantify the impact of an outage over time (financial loss per hour, regulatory risk, reputational damage).
3. Determine the maximum acceptable impact: this defines the RTO and RPO.
4. Verify whether existing backup and recovery capacities meet RTO and RPO requirements. If not, invest in improvements or consciously accept the risk.

NIS2 and requirements for operational continuity

NIS2 Directive Article 21 explicitly requires the implementation of measures including operational continuity and crisis management. Specifically, this includes:

• Backups and data recoverydocumented backup policy with defined RTO and RPO, regular data recovery testing.
• Crisis managementdefined procedures for managing cyber incidents with a clear escalation path and decision-making authority.
• Redundancyappropriate redundancy" of critical systems and communication means.
• Supply chainBCP must include scenarios for the failure of key suppliers (cloud provider, MSP, critical software).

Key point: NIS2 does not demand perfect plans; it requires proportionate and documented plans matching the organisation's risk profile. The absence of any documented approach constitutes a direct breach of requirements.

Cybersecurity scenarios and how to plan for them

Scenario 1: Ransomware attack

The most common and most destructive cyber scenario. BCP/DRP must cover:

• Isolation of affected systems from the network (and who will carry this out and with what tools).
• Switch to backup communication channels (the company email may be compromised).
• Recovery procedure from deposits: the correct sequence and duration (you must know this in advance, not guess during an incident).
• Alternative methods for performing critical processes during recovery (paper records, alternative systems).
• NÚKIB notifications and GDPR notices (with ready-made templates).

Scenario 2: DDoS attack on critical services

A DDoS attack can make websites, online shops or customer portals inaccessible. The plan must include:

• Contact and procedure for activating DDoS mitigation services (Cloudflare, Akamai, Radware): a pre-negotiated contract, not searching for contacts in the middle of an attack.
• Customer communication regarding an outage (prepared template for social media and email).
• Alternative order acceptance methods (telephone, email) during outages.

Scenario 3: Outage of a key cloud provider

Azure, AWS or Google Cloud experience outages despite high availability. If you rely on a single cloud, your RTO depends on the cloud provider, not on you.

• Multi-cloud or hybrid strategy for critical systems.
• Offline copies of key data for the most critical scenarios.
• Knowledge of the cloud provider's SLA and their communication channels during an incident.
• Alternative approaches to data (local copies of the most critical data).

Testing Plans: Why This Is the Most Critical Step

An untested BCP/DRP is merely a document that does not guarantee a successful recovery. Practice has shown that plans never tried out fail in real situations for predictable reasons: outdated contacts, obsolete procedures, and assumptions that are untrue.

Types of tests (from simplest to most demanding)

1. Tabletop exercise. Discussion of the scenario in the conference room. The team goes through the plan step by step, identifying gaps and questions. Low cost, can be done quarterly.
2. Walkthrough test. Each team member describes their actions during an incident, verifying that everyone knows their role. This reveals gaps in knowledge and responsibilities.
3. Simulation testsimulation of an incident in a test environment, with no impact on production. Technicians actually carry out recovery steps, but using test data and systems.
4. Full interruption testactual switchover to backup systems. The most realistic test, but also the highest risk and cost. Suitable for critical infrastructure at least once a year.

What to test as a priority

• Restoring data from backups: actually attempt to restore the backup and verify that the data is complete and consistent. Many companies only discover that their backups are corrupted or incomplete when they need them.
• Communication plan: verify that you have valid contact details for key persons (NÚKIB, insurance company, IR firm, lawyer) outside of corporate systems.
• Handover of responsibilities: what happens if a key person is unavailable (holiday, illness)?

Communication during an incident: Who says what to whom

Communication during a cyber incident is critical and cannot be improvised. Poor communication can cause reputational damage greater than the incident itself.

Prepare templates in advance for:

• Internal employeeswhat happened, what they should (or should not) do, and when they will receive further information.
• Customers. Sincere and factual communication without exaggeration or downplaying.
• Regulators (NÚKIB, ÚOOÚ)formal notification in accordance with legal requirements, with ready-made templates.
• Mediaconsistent, concise reporting: media relations are always handled by one designated person, not IT.
• Business partnersinformation on potential impact to their systems or data.

SecureOn.cz provides comprehensive support in developing BCP and DRP for cyber scenarios: from Business Impact Analysis through plan creation to testing and regular updates. We are happy to help you meet NIS2 requirements for business continuity while creating plans that actually work, not just exist on paper.

Conclusion: A plan gathering dust in a drawer will not save you.

Business continuity planning is not a bureaucratic exercise to satisfy an audit. It is an investment in organisational resilience that pays off during the first serious incident. Key message: the plan must be tested, updated and known to those who will need it in a crisis.

Start where you are: even a simple, one-page procedure for a ransomware scenario with contacts, isolation steps and a recovery process from backup is better than no plan at all. Gradually expand it. Test it. And hope you never need it, but be glad to have it if the worst happens.