Critical Infrastructure and NIS2 in Crisis Preparedness: Separate Scope, Roles, and Training Evidence

Separate critical infrastructure and NIS2 cleanly in crisis preparedness

Crisis preparedness becomes confusing when teams force different concepts into one checklist. In Germany, critical infrastructure concerns services whose disruption can have wide effects. NIS2 is a European cybersecurity framework implemented nationally. Both subjects can touch the same organisation, yet they have different triggers, roles, evidence, and escalation routes. Making the differences visible early avoids a paper process and creates a dependable way of working for attack, outage, and recovery. See also: business defence preparedness.

This article is an operating guide, not advice on an individual legal case. The starting point is not which label seems to fit the organisation. It is the service that must continue during disruption, the information required to sustain it, and the person allowed to decide. Germany's Federal Office of Civil Protection and Disaster Assistance explains the critical-infrastructure context. The NIS2 Directive addresses cyber-risk management and oversight. Both sources help orientation, but neither replaces assessment of the actual scope. See also: Federal Office of Civil Protection and Disaster Assistance on critical infrastructure, NIS2 Directive (EU) 2022/2555.

Assess scope before planning training

A dependable inventory separates at least four questions. Which products or services are time-critical for customers, partners, or the public? Which digital systems, suppliers, and locations support that service? Which disruption scenarios are plausible? And which regulation may follow? Only after answering these questions separately can executive management decide whether formal analysis, technical depth, or an organisational measure is needed. A blanket statement that we are, or are not, critical infrastructure is not a reliable operating basis.

For crisis preparedness, the service chain is usually more useful than an industry label. Map one service from an incoming request to delivery. Mark people, applications, data, suppliers, building access, communications, and approvals. You can then prioritise points: what stops immediately, what can be bridged manually, and what may only be released after specialist review? This map is also useful raw material for role profiles, evidence requirements, and scenario exercises.

The workforce-risk perspective prevents cyber risk from becoming an IT-only subject. Disruption often arises from combinations: an application is unavailable, a key person is absent, and a supplier delivers late. The guide to business workforce risks provides a useful question sequence: which minimum service must remain available, which role may release it, and which deputy can actually use the required information? These questions should come before any technical procurement or training.

Translate NIS2 risks into an operating process

The NIS2 Directive requires in-scope entities to manage cyber risks appropriately and links this work to responsibility at management level. In practice, not every executive must configure technical controls personally. They do need to understand material services, risks, measures, open points, and decision limits. A management update without traceable facts is not effective oversight. Conversely, a technical report does not replace a clear decision on priority, budget, or residual risk. See also: NIS2 training for management and employees.

Create a short decision record for each material scenario. It need not be complicated. Useful fields are service or process, dependencies, protection need, observed weakness, current measure, owner, deputy, decision point, due date, and evidence. An entry such as improve security is too vague. It is more useful to state that access to a critical service will be reviewed by a date, technology will document the result, and the process owner will confirm the operational effect. This turns a general duty into a reviewable work item.

Reporting, assessment, and recovery are three different activities. A person who notices an anomaly must know how to preserve information and where it goes. The incident team assesses reach, factual position, and next technical steps. Management decides at defined thresholds on customer communication, contingency operation, external reporting, or additional resources. Germany's BSI notes that cyber threats can quickly impair communication, data exchange, and business processes across an organisation. That is why the workflow needs fixed handoffs rather than ad-hoc messages. See also: Germany's BSI on the cyber-security situation.

AI-generated

Design roles for the exception case

A crisis team does not need a long list of titles, but a small number of distinguishable decisions. Executive management sets priority and tolerated constraints. A process owner defines the minimum service. IT and information security examine technical facts and recovery options. HR or operations organises availability and deputies. Communications prepares aligned statements. Compliance or legal evaluates whether specialist or regulatory escalation is needed. In smaller organisations, people can wear several hats, but decisions and counter-checks must remain visible.

Workforce planning becomes dependable only when every key role has clear information, approvals, and contacts for its deputy. The workforce emergency plan for a crisis offers a simple structure: minimum staffing, absence thresholds, deputy order, access rights, and secure contact paths. For cyber incidents, add the question of who translates a technical finding into an operational decision. Even the best analysis is of limited use if nobody knows whether a service may be stopped, restricted, or reopened.

Avoid treating a deputy as only a name in a spreadsheet. A deputy needs access to current work instructions, a short overview of open risks, and authority to act within a predefined framework. The deputy matrix for key personnel shows how knowledge, approvals, and absence fit together. Test not only whether the deputy can be reached. Test whether the person can decide a real case from the record and hand it over cleanly.

Tie training evidence to decisions

For crisis preparedness and NIS2, attendance confirmation alone is insufficient. Useful evidence connects audience, concrete capability, course version, scenario, result, repeat, and the underlying work instruction. A service owner might need to define minimum service and escalate an interruption. A helpdesk role might need to record an anomaly, preserve evidence, and use the defined channel. For executive management, the focus is priority, resources, and follow-through, not technical detail.

Plan a short scenario test for each role. Example: an external supplier reports unusual activity while the person holding the primary approval cannot be reached. The helpdesk gathers facts. IT assesses the finding. The process-owner deputy decides on safe contingency operation. Executive management receives a decision note with option, effect, and deadline. Assess not only the correct professional answer. Assess the completeness of the handoff, time to decision, and quality of the record.

In workforce processes, operational crisis situations can create additional uncertainty. The guide to the Labour Security Act at work is therefore useful as a separate learning module: responsibilities and reporting routes there are assessed differently from response to a cyber incident. Connect the subjects through shared scenarios, but keep the specialist questions separate. This prevents the team from treating a workforce measure as an IT approval or an IT report as an employment-law decision.

AI-generated

Build routine with measures and exercises

Measure a small set of indicators that trigger a real decision. Useful examples are the share of key roles with a tested deputy, the share of material services with a current dependency map, time to a complete initial report, overdue actions, and the share of learners who pass a scenario test. A poor number is not an end in itself. It should show where a work instruction is unclear, an interface is weak, or an approval is too slow. Add an owner and next date to every indicator.

A quarterly rhythm can start small. In the first month, the team updates the service chain and open actions. In the second, it conducts a 45-minute exercise with a deputy. In the third, executive management reviews results, decides on resources, and confirms priorities. The cycle then starts again. This sequence connects risk management, training, and improvement without making one annual large exercise the only evidence of preparedness.

When political or security situations increase pressure to act, operational decisions must not rely on assumed legal consequences. The guide to tension, state of defence, and alliance cases helps organise terms and employer questions. For a NIS2 or critical-infrastructure exercise, it is enough to document assumptions about staff, communication paths, and minimum operation. The legal assessment, regulatory report, or a specific obligation then belongs in the appropriate specialist review.

A six-week starting plan

Start in week one with one material service and its dependencies. In week two, clarify roles, deputies, and decision thresholds. Week three creates the short decision record and names missing evidence. Week four delivers role-based learning and a scenario test. Week five runs a realistic, time-limited scenario. In week six, leadership reviews open actions, results, and priorities. The scope stays manageable when you first master one chain cleanly and then transfer the approach.

Evidence should be easy to find without waiting for an audit or incident to trigger a search. The guide to audit-ready training records without spreadsheets shows the pattern: role, content, version, assignment, completion, and evidence are maintained together. Add the exercise record, decisions, and improvement evidence. The organisation can then show not only that people were trained, but which decision they are expected to make safely in the relevant workflow and when this was last tested.

The next practical step is small and clear: name an owner for one service, choose a plausible scenario, and agree the three pieces of information that must be complete before a decision. Then record who supplies them, who checks them, and who releases the decision. This clear chain separates critical-infrastructure context, NIS2 risk, workforce question, and technical measure without fragmenting collaboration. It creates preparedness that remains actionable during a real disruption.