Operational network resilience starts in operations, not in IT

Why operators of critical infrastructure need to reassess their operational capability
Operational network resilience is often primarily associated with technical measures. This typically involves stable infrastructure assets, IT networks, redundancies, monitoring, and services for rapid recovery after disruptions. While all of these are important, they are not enough.

For network operators, municipal utilities, telecommunications providers and regulated utility companies operating critical infrastructure (KRITIS), the decisive question in the event of a serious incident is not only whether individual systems are available. What matters is whether they can continue to provide business-critical services.

This is precisely the distinction between technical availability and genuine operational network resilience. KRITIS assets and networks can be formally stable while central processes stall. Conversely, if processes, responsibilities and recovery paths have been thoroughly prepared, a technical disruption can remain manageable.

This article is the opening instalment in a blog series on operational network resilience for KRITIS operators. It demonstrates that resilience does not end with stable IT systems, but must be proven in live operations.

The pressure to act is increasing. The KRITIS Act and the NIS2 Implementation Act mean that significantly more companies are now subject to stricter requirements regarding asset security, organisational security, cybersecurity, reporting obligations, risk management and evidence. The Federal Government describes the objective of national implementation as strengthening important entities and the European internal market. Companies providing basic services, particularly in healthcare, energy and infrastructure, are expected to comply with stricter IT security rules.¹ According to the Federal Government, around 30,000 companies in 18 sectors will be directly affected.²

In many organisations, resilience is primarily assessed at system level. The focus tends to be on servers, network components, applications and monitoring tools. This approach is understandable because technical systems can be measured. Metrics such as availability, downtime and recovery time can be comparatively easily captured.

However, for operational reality, this perspective is not enough. Business-critical services do not depend on a single system. They arise from the interaction of processes, technical dependencies, external services and operational decisions.

For example, a KRITIS network operator with redundant infrastructure may still encounter difficulties during an incident if it is unclear who makes decisions, which service provider to contact, which customers to inform and which processes to prioritise. While the technical foundation may be in place, operational capability remains vulnerable.

The Federal Network Agency (BNetzA) also clarifies that operational network resilience is not purely an internal IT issue, particularly for KRITIS sectors. Its strategy paper on the resilience of telecommunications networks focuses on ensuring telecommunications in incidents and crises of exceptional scale. The paper is primarily aimed at operators of telecommunications networks and providers of telecommunications services.³ The statements and recommendations it contains align with the KRITIS resilience, sovereignty and defence strategy of the EU and the Federal Government, including funding opportunities.

This is precisely why operational network resilience needs to be considered more strongly from the perspective of business operations. The central question is not ‘Which critical services must continue to function even in the event of disruption?’

A common mistake starts with the terminology itself. Technical and operational network resilience are often treated as equivalent, even though they describe different things. In KRITIS environments in particular, this would be negligent.

Technical network resilience primarily refers to the technical robustness of IT and communications networks. It focuses on stable connections, redundancies, segmentation, monitoring, performance, and recovery after technical disruptions. The key question is whether the network can continue to run.

Operational network resilience goes further. As well as considering the technical infrastructure, it also considers the operator’s organisational ability to maintain business-critical services during disruptions. To achieve this, technical measures must be combined with robust processes and clear operational decisions. The key question is: can operations continue to deliver?

This distinction is crucial in the KRITIS environment. A network may be technically available, yet a critical business process may still fail due to unclear responsibilities or ineffective recovery processes.

Technical network resilience is therefore an important prerequisite. Operational network resilience, on the other hand, describes the overarching ability to ensure operational capability under real conditions.

For operators of critical infrastructure and digital services, operational network resilience encompasses more than just protection against cyberattacks. It forms part of broader operational resilience, which is defined as the ability to maintain critical services in a controlled manner during disruptions, or to restore them quickly.

This requires a clear view of:

Operational network resilience emerges where technical stability is translated into reliable organisational operational capability.

This is highly relevant, particularly in view of NIS2, KRITIS requirements and rising expectations regarding the ability to provide evidence. However, regulation requires not only that measures exist, but also that they are implemented effectively and that the associated risks are understood.

In practice, similar patterns often emerge. While many companies, including direct KRITIS operators and their suppliers, are familiar with their technical assets, they do not always understand their significance for specific business processes. While it is documented which systems exist, it is less clear which services would fail if a particular system, service provider or interface were to become unavailable.

Responsibility often becomes critical when it is distributed across several areas without clear rules on who leads during an incident. IT, network operations, information security, compliance, procurement, business units and external service providers often have different perspectives on resilience. In normal operations, this usually works. During an incident, however, it wastes time: information must first be gathered, decisions are delayed, and no one has an immediate complete picture of the situation.

In addition, although emergency and recovery plans may exist, they are not always tested regularly. On paper, the organisation appears prepared. However, under real conditions, it becomes clear whether escalation chains work, whether contacts are reachable, and whether technical, organisational, and communication measures interact.

It is precisely at this point that it becomes clear whether the operational network resilience of KRITIS operators is robust or merely theoretical.

Operators need to understand that operational network resilience is not demonstrated by how convincingly concepts are documented. What matters is whether critical services remain operational during an incident and whether the planned processes work as intended.

For operators, this means that operational network resilience must be tested wherever critical services are created. This involves not only the infrastructure, but also the processes, dependencies and decisions that keep operations running during an incident. Only once these interconnections are visible can the necessary measures be identified.

A purely IT-centred view is insufficient for this purpose. For network operators, municipal utilities and regulated utility companies, it is important to understand how robust operations remain when systems fail, external dependencies become critical, or rehearsed processes no longer work.

The guiding question for operators is therefore: ‘Which critical services must remain available even during disruptions, and how robust are the necessary processes?’

The next articles will address the central fields of action for operators, including: NIS2, providing evidence, external dependencies during an incident, investment priorities, leadership responsibility, and customer expectations.

The focus will be on the practical implementation of these areas in operations. What requirements must be met? Which processes must be in place? What evidence must be available in the event of a serious incident?

How strong is your operational network resilience? Using a structured approach, we evaluate critical processes, key dependencies and relevant regulatory requirements, including NIS2, critical infrastructure requirements, ISO 27001 and other sector-specific requirements.

This highlights where action is needed and which measures should be prioritised. Request a check to obtain a technically sound assessment of your operational network resilience.