A business continuity plan designed to support NIS2 requirements cannot be treated as a standalone procedure maintained by the IT department. It should be driven by business impact and risk analysis, define process recovery priorities and be exercised regularly. Its effectiveness is demonstrated not by policy statements, but by the organisation’s ability to make timely decisions, activate workarounds, achieve a minimum acceptable level of operation and return safely to normal business.
Business continuity is a management decision
Business continuity planning does not begin with a procedure template or an inventory of IT systems. It starts with the services, products and processes whose disruption could jeopardise contractual commitments, safety, compliance obligations or the organisation’s financial stability. The scope of the plan should be based on a business impact analysis. This means determining how the consequences of disruption escalate over time, when they exceed management’s accepted tolerance and the order in which operational capabilities must be restored.
The maximum tolerable period of disruption and acceptable level of loss should not be determined by IT alone. These parameters require management approval, informed by process owners and by finance, compliance, security and technology functions. The process owner defines continuity requirements, while the plan owner coordinates the design and maintenance of the continuity arrangements. Without a shared decision-making mechanism, IT protects infrastructure, operations remains accountable for service delivery, and senior management receives no coherent view of recovery priorities or acceptable downtime.
In a manufacturing plant, restoring a planning or control system does not automatically mean that shipments can resume. Production may remain at a standstill because technical data is unavailable, authorised operators are absent, power or supplier-provided connectivity has failed, or no approved manual workaround exists. Operational resilience is achieved only when the plan covers the process’s full chain of dependencies, rather than just the assets controlled by IT.
It is also important to distinguish business continuity, IT disaster recovery, incident response and crisis management. Business continuity concerns maintaining or resuming processes; disaster recovery restores technology and data; incident response contains and manages an event; and crisis management provides direction and decision-making during major disruption. These mechanisms should use aligned scenarios, escalation thresholds and accountability rules, but they are not interchangeable.
Only once this operating model has been defined can it be aligned with obligations arising from NIS2 and the applicable national legislation concerning risk management, business continuity, incident handling and management accountability, taking account of whether and how the organisation falls within scope. For broader context, see NIS2 for manufacturing companies: who is in scope, what obligations apply and how to prepare the organisation without reducing the issue to IT alone.
Risk must lead to an actionable scenario
A risk register can drive business continuity planning only when it shows the relationship between threat, vulnerability, asset, process and business impact. A list of cyber threats alone does not explain how operations will be maintained. Scenarios should therefore be built around disruption outcomes, such as the unavailability of a control system, data loss, loss of connectivity, staff shortages or supplier unavailability. Different causes can produce the same operational state and require the same continuity strategy.
Business impact analysis and risk analysis have distinct but complementary purposes. The former establishes the significance of an interruption, the rate at which losses escalate and the point at which management’s accepted tolerance is exceeded. The latter identifies possible event sources, vulnerabilities and the effectiveness of existing controls. The chosen assessment method and scale should support meaningful comparison between scenarios and informed acceptance of residual risk in line with the organisation’s risk appetite.
The scenario set should be limited to distinct impacts that require different decisions, resources or recovery sequences. Analysing every technical variation separately rarely improves the plan’s usefulness and usually makes it harder to maintain and apply under pressure.
| Process and impact | Scenario | Continuity strategy | Decision owner | Activation criterion |
|---|---|---|---|---|
| Production: loss of line control | Control system unavailable, irrespective of cause | Safe shutdown, workaround activation and prioritised restoration of control capability | Operational manager designated in the plan | Expected unavailability exceeds the maximum acceptable interruption, or operations cannot continue safely |
| Order fulfilment: data unavailable | Loss or unavailability of transactional data | Switch to an agreed alternative recording method, verify integrity and restore data | Process owner together with the person authorised to approve restoration | Lack of access to reliable data prevents the organisation from meeting its commitments |
| Customer service: external service unavailable | Connectivity or supplier service disruption | Activate an alternative solution, initiate contractual escalation and restrict the scope of service | Service owner | No confirmed restoration time is available before the critical threshold will be reached |
Each scenario should define the maximum acceptable interruption, minimum operating level, required resources, recovery sequence and the role authorised to activate the plan. These parameters should be based on actual downtime and recovery performance recorded during incidents, failures and exercises, as well as contractual requirements for availability, delivery times and disruption reporting. This provides a basis for measuring the time required to make a decision, reach the minimum operating level and complete full recovery.
The analysis must reflect actual process dependencies on applications, data, infrastructure, locations, utilities, critical competencies, IT suppliers, integrators and subcontractors. Where the strategy relies on third-party support, the organisation should verify availability, response times, escalation routes and fallback arrangements rather than relying solely on contractual wording. This subject is developed further in NIS2 and supply chain security: how to assess IT suppliers, integrators and subcontractors.
The plan must guide the organisation through disruption
An effective business continuity plan does not attempt to describe every possible event. It guides accountable people through a sequence of decisions. It should identify who assesses the situation, who declares continuity mode, which processes must be maintained at the minimum acceptable level, the order in which capabilities should be restored, how crisis communications will be managed and the criteria for ending emergency arrangements.
The level of detail is appropriate when the plan reduces the need for interpretation under pressure without duplicating technical and process work instructions. In a larger organisation, a practical structure is an overarching plan that defines command, escalation and coordination arrangements, supported by process-specific continuity plans.
Activation requires measurable criteria. Wording such as “in the event of a serious failure” postpones the debate over what “serious” means until the worst possible moment. A trigger may be based on exceeding the maximum acceptable interruption, loss of confidence in data integrity, inability to work safely, unavailability of critical personnel or an anticipated fall below the minimum operating level approved by the process owner. Every deviation should be linked to an action, an authorised decision-maker, an escalation deadline and a required record. Similar logic, although at a different operational level, is explained in Reaction plans within control plans: how to define actions when a process moves outside its limits.
Roles should be assigned to functions rather than only to named individuals. The responsibility matrix should cover deputies, limits of authority, availability, and primary and emergency communication channels. A named contact list can be maintained as a controlled appendix, allowing personnel changes to be made without revising the entire plan.
Senior management should make decisions that exceed the approved operational mandate, including accepting material business risk, authorising exceptional expenditure or approving communications of strategic significance. By contrast, the decision to activate a pre-approved workaround should be made as close to the process as practicable.
Following the loss of an order management system, the duty role may confirm the outage and expected duration, the process owner may activate the alternative record, and the continuity coordinator may escalate the event once the defined threshold is reached. The plan must specify the limits of the workaround: capacity, maximum duration, data protection and integrity controls, required manual reconciliations and the method for subsequently entering records into the system.
Normal operations should resume only after the solution’s stability, data completeness and reconciliation of manually processed transactions have been confirmed. The resulting records should support evaluation of the time taken to decide, achieve minimum operation and complete full recovery.
The greatest losses arise at the interfaces between plans
The scale of loss is not determined solely by the cause of an outage. Disruption is also prolonged by waiting for approval, ambiguous event classification, conflicting recovery priorities and poor visibility of dependencies between processes, systems and suppliers. The primary purpose of an incident response plan is to detect, assess, contain and manage an event. The business continuity plan is intended to maintain operations at an accepted level. Both mechanisms must define common handover points for information and decisions: who identifies a threat to continuity, who activates the workaround and who approves the return to normal operations.
The technical recovery sequence should be derived from process priorities, but it cannot simply replicate them. A system supporting the most critical process may depend on identity, network, database or integration services that must be restored first. Data integrity, the correct start-up sequence and security controls must also be maintained. Alignment between business and technical priorities should be tested by comparing required process availability with actual backup restoration results, tolerable data loss and infrastructure dependencies.
Operations may expect order intake to be restored before billing, while IT may plan to restore billing first because it contains the central customer master data. If this dependency has not been agreed in advance, the decision will be made under pressure and a manual workaround may generate records that cannot later be reconciled safely. Such cases should be assessed using actual detection, escalation, decision and recovery times, together with test results confirming data completeness and integrity.
A similar gap can arise at a supplier boundary. A contractual service availability commitment is no substitute for a role-based or named escalation route, agreed recovery parameters, access to information about the disruption or an obligation to participate in exercises. The requirements of critical processes should be compared with both the contract and the supplier’s demonstrated capability. Only then can the organisation make an informed decision on whether to maintain a backup solution, accept downtime, use internal resources or rely on an external service.
Budgets should address capability gaps rather than fund document production. Expenditure may be needed for additional redundancy, shorter decision paths, more frequent recovery tests, revised contractual terms or an alternative means of delivering the process. A structured approach to these costs is discussed in The cost of implementing NIS2 and the Polish National Cybersecurity System Act: how to budget for audits, documentation, training and controls without costly mistakes.
Exercises must test decisions, not just documents
A business continuity exercise should not be limited to reading the procedure or recording attendance. It should test a clearly stated hypothesis, for example whether the organisation can activate an alternative process without the primary system, retain control over data being entered and reconcile it safely after service restoration.
The exercise programme should develop progressively: from role reviews and tabletop exercises, through testing a selected procedure or recovery activity, to a technical and operational exercise involving business functions, IT, management and suppliers. The scope should increase in proportion to risk, process criticality and organisational readiness.
The scenario should require decisions under conditions that resemble a real disruption. These may include incomplete information, time pressure, conflicting priorities and the unavailability of a critical dependency, such as an approving manager, a supplier service or an up-to-date contact list. The exercise should not, however, be designed as a trap for participants. Its purpose is to assess the system—allocation of responsibilities, quality of information, practical feasibility of procedures and escalation capability—not to attribute personal blame.
Management participation is necessary where the scenario requires risk acceptance, reprioritisation or authorisation of a costly fallback solution. A supplier should be involved where its response is essential to process continuity.
For example, an exercise may begin with the unavailability of an order management system. The facilitator then introduces information that the data backup is incomplete and the service provider’s response is delayed. The team must decide whether to activate manual processing, which orders to accept and how to identify records so that duplication and loss of data integrity can be avoided after service restoration.
The exercise should measure the time required to identify the disruption, escalate it, activate continuity arrangements, reach the minimum operating level and restore operations. In parallel, the organisation should assess the quality of information flows and records, use of outdated contact details, failed escalations and plan steps that could not be completed. Actual performance should be compared with approved continuity objectives.
Exercise frequency and format should be based on risk, process changes, previous test results and the significance of dependencies—not solely on an annual schedule. Announced exercises are more effective for learning and agreeing roles. Unannounced exercises provide a better indication of actual readiness but require appropriate operational risk controls. Production systems should be used only where the scope, safeguards and ability to stop the exercise have been consciously approved; otherwise, a test environment is more appropriate.
Every exercise should result in actions with an assigned owner, completion date, effectiveness criterion and decision on retesting. The percentage of actions completed on time is a useful indicator, but a status of “completed” does not itself demonstrate improvement. The decisive evidence is the result of the repeat test. The approach described in How to build a library of quality templates: FMEA, Control Plan, 8D, audit, CAPA and KPI can help structure scenarios, records, corrective actions and measures.
Close the cycle with evidence and management review
A complete set of procedures does not demonstrate continuity capability. A credible evidence trail should connect approved risk and continuity assumptions, process-owner decisions, test records, exercise results, identified nonconformities, corrective actions and verification of effectiveness. The revision history for the business continuity plan should record not only the date and author of a change, but also the event, decision or analysis result that justified it.
The review frequency should reflect process criticality and the rate of change in risk. A periodic review date alone is not sufficient. Reviews should also be triggered by an incident, exercise or material change to a process, technology, location, supplier, organisational structure or risk profile. Exercise acceptance criteria should be established before the exercise begins so that the outcome is not reduced to a subjective conclusion that the organisation “managed adequately”.
Monthly monitoring may show that the exercise programme has been delivered on schedule, while one process has still failed to achieve its required recovery time and no fallback exists for a critical supplier service. This result should not be buried in a technical report. Senior management must receive information on processes that do not meet the required capability, unresolved and unaccepted gaps, risks that have been consciously accepted, and investments or organisational decisions that remain necessary. Management review should conclude with documented decisions rather than mere acknowledgement of the information presented.
Internal audit should test whether stated arrangements are reflected in practice: whether a process classified as critical actually participates in exercises, whether technical recovery objectives meet operational needs, and whether post-exercise actions have been completed and their effectiveness verified. Auditors or supervisory authorities should be presented with a traceable sequence of records showing the path from identified risk, through decision and testing, to verified improvement. Useful supporting indicators include completion of the approved exercise programme, timely closure of corrective actions and the number of unaccepted gaps between required and demonstrated continuity capability.
The final action plan can be incorporated into the broader schedule described in Implementing NIS2 after entry in the Polish National Cybersecurity System register: action plan to 3 April 2027. However, deadlines, the scope of obligations and appropriate measures should always be verified against the current legal position, the organisation’s status within the national cybersecurity system and its actual risk profile.
Masz pytania? Porozmawiajmy.
Bezpłatna konsultacja – bez zobowiązań.
