The outage begins with physical damage. Remote-control links fail, while the on-call team cannot reach the site because the access road is closed. Three departments open three different incidents. Resilience tends to fail at exactly these handovers. Germany’s KRITIS Umbrella Act has been in force since 17 March 2026 and creates obligations for operators of critical installations. In operation, cyber, physical, workforce and supply-chain risk must be governed together without collapsing distinct legal regimes into one.
Note: General professional guidance; not legal advice or a certification or audit guarantee.
That requires an integrated operational resilience model combined with separate determinations of applicability and reporting duties. A company within the NIS2 or German BSI Act environment is not automatically an operator of a critical installation under the KRITIS Umbrella Act. A physical incident report must not simply be relabelled as a cyber notification either. Governance should connect the facts; legal classification must preserve the boundaries.
The statutory transitions do not follow one blanket calendar date. Under section 8(1), an operator must register no later than three months after its installation qualifies as critical. Section 8(7) makes the section 12 duties applicable for the first time nine months after registration; the duties under sections 13, 18 and 20 first apply ten months after registration. Planning and evidence therefore need to use the installation’s individual status and actual registration date. The official consolidated text does not support a blanket 17 July deadline.
The real bottleneck is not another risk assessment
Many organisations already maintain business continuity plans, information security risks, emergency manuals, physical protection concepts and supplier assessments. What they often lack is a shared view of which critical service depends on which resources and who decides when one event crosses several domains.
Consider a clearly hypothetical situation at a utility operator. A technical site loses normal power after severe weather. Standby power starts, but external communications remain unstable. At the same time, the specialist provider needed for an on-site inspection cannot arrive because the access road is closed. The continuity team focuses on outage duration, Information Security on disrupted connections, and Physical Security on site access. All three assessments may be professionally correct. Without a common service and dependency logic, however, nobody can show when the minimum service level is crossed or who decides to restrict operations.
The bottleneck is organisational rather than documentary. Departmental registers arrange risk by ownership. A real event observes no such structure. It uses shared resources, changes several assumptions at once, and creates decisions at handovers. An integrated model does not replace specialist registers. It gives them a connecting grammar so that several partial views can become one decision-ready operating picture.
The Act focuses on critical installations and services to the public. It defines resilience as the ability to prevent and resist incidents, limit their consequences, respond, recover and restore operations. Operators must perform risk analysis and evaluation at least every four years and when required. Measures derived from that analysis must be presented in an applied resilience plan, including the reasoning behind them.
That is not an invitation to create another isolated register. A spreadsheet row labelled “flood” does not make a pumping station resilient.
Each specialist function governs a different unit. Business Continuity thinks in processes and recovery times, Physical Security in sites and protection zones, Information Security in information, applications and threats, and Procurement in contracts and suppliers. Problems arise when the handovers remain unnamed. A measure may then be closed in one register although its related assumption was never tested in another. An extended supplier contract, for example, does not show whether the provider can make personnel available at the priority site during a widespread event.
A common management error is therefore to demand one universal risk score. Different scenarios are compressed into an aggregated colour or number until the dashboard looks comparable. In the process, time, cascades and thresholds disappear—the very information needed for an operational decision. A coupled failure with a low estimated likelihood may cross the minimum service level quickly once it occurs; a more frequent disruption may remain manageable because reserves are available. Management does not need mathematical uniformity at any price. It needs traceable statements about the service at risk, the uncertain assumption, the duration of reserves and the authority to decide the next operating state.
One model built around five connecting objects
From a governance perspective, the work can be organised around five objects. This is professional synthesis, not a statutory template.
1. Critical service and tolerable disruption
Start with the service whose significant impairment affects public supply, not with a building or server. Management needs a shared view of the minimum service level, tolerable interruption, recovery priority and affected population or customer groups.
This is not a purely technical metric. Hypothetically, a process may continue to run while its output remains available to only part of the intended recipient group. Conversely, one technical subsystem may fail without immediately taking the service below its agreed minimum. Management and operations therefore need to decide in advance which restriction remains manageable, when escalation begins, and which restoration takes priority. Otherwise, the crisis team negotiates terminology while the operational clock is already running.
2. Dependencies across domains
A dependency map connects installations, OT and IT, power, communications, people, premises, logistics and material third parties. It should expose common causes of failure: one technical room, service provider or identity platform can disable several processes that looked independent on paper.
The map is useful only when it changes a decision. A hypothetical operator might discover that two separately documented recovery procedures depend on the same external specialist. Each procedure is plausible on its own; together they cannot work when both need the person at once. Management can now prepare a second source, develop internal capability, or change recovery priorities explicitly. A line on a diagram then becomes the trigger for a resource decision rather than decoration.
Completeness is not a realistic first objective. Start with dependencies whose loss affects several services or whose replacement is particularly difficult. Extend the map through exercises, incidents and change activity. An architecture diagram with an owner and last-review date is more defensible than a static overview without maintenance responsibility.
3. Scenarios rather than departmental risks
A scenario should describe the cause, affected dependencies, potential cascade and impact on the critical service. “Ransomware”, “sabotage” and “extreme weather” are only headings. A scenario becomes governable when the organisation knows which service falls below which minimum level, when that happens and which assumptions support the conclusion.
The hypothetical utility case can be worked through as a timeline. In the first minutes, standby power takes over and the service remains above its minimum level. After an hour, unstable communications impair remote control while access remains blocked. Several hours later, fuel is not the only constraint. The combination of cooling, qualified operators and the missing on-site inspection becomes decisive. The scenario connects four specialist perspectives through one service and timeline. It does not predict events; it exposes the assumption on which an accountable decision depends.
The crisis team can now define thresholds in advance. While remote control and cooling remain demonstrably stable, operations continue. If either assumption fails, a named role considers a restricted operating state; if workforce reserves reach a defined internal threshold, priority relief is arranged. The actual values belong in the operator’s design, not in a generic template. What matters is the mechanism: observation, threshold, decision and consequence must be connected. Without that link, a scenario remains an illustrative story. With it, the scenario becomes an instrument for exercises, investment and escalation.
4. Measures with an objective and evidence
Every priority measure needs a resilience objective, owner, due date and expected evidence. A standby generator is not effective merely because it appears in the asset register. More persuasive evidence might include a realistic load-test record, confirmed fuel logistics, measured switching times and resolved deviations.
In a hypothetical exercise, the generator starts correctly but a dependent cooling system receives no power after the switch. The test has not simply “passed” or “failed” in the abstract. It has disproved a specific assumption. Operations and management must decide whether to change load distribution, provide an additional supply, or revise the tolerable operating period. Evidence here means not merely that a test record exists, but that the observed result produces an accountable follow-up decision.
This logic also protects against action catalogues that confuse activity with effect. Training, a contract or technical redundancy may be worthwhile. The measure becomes defensible through its connection to a scenario and intended service level. Without that link, the organisation may close many actions while retaining exactly the same disruption exposure. That is administratively tidy, but operationally limited comfort.
5. Decisions and residual uncertainty
Management must see which scenarios are accepted, treated or escalated, where dependencies remain uncertain and which investment reduces which disruption. A green status without documented thresholds is not defensible.
Separate reporting routes, connect the operating picture
The Act excludes events that are exclusively security incidents under the German BSI Act or Telecommunications Act from its definition of an incident. For incidents under the KRITIS Umbrella Act, section 18 provides for notification without undue delay and no later than 24 hours after awareness, followed in principle by a detailed report no later than one month after awareness. The classification of a real event and any parallel obligations still require case-specific assessment.
Incident management should therefore avoid one universal “report” button and use a shared triage process instead. The process records the actual event and affected critical service, classifies the matter as physical, cyber-related or coupled, and identifies the relevant legal entities, installations and regimes. It determines the authority, deadline, minimum information and approval separately for each reporting route. A controlled common fact base keeps the information consistent across those routes.
This keeps statutory reporting logic distinct while giving incident command and management one operating picture. It reduces contradictory timelines, duplicate root-cause analyses and approvals by the wrong role.
In practice, the common fact base should record event time, awareness time, affected services, observed impact, response actions and unresolved uncertainty. Legal assessments attach to those facts rather than becoming mixed into them. If a fact changes, the responsible roles can test which notification is affected without maintaining several competing versions of reality. A common operating picture is therefore not a common legal form.
Take a hypothetical coupled incident in which physical access fails while remote administration is also disrupted. Incident command needs one consistent timeline even if different specialists separately determine which reporting routes apply. A predefined triage records both assessments, their approvals and deadlines.
Reuse existing evidence without claiming automatic equivalence
Section 17 allows risk analyses, measures, documents and certificates created under other obligations or voluntarily to support evidence of compliance. It does not mean that an ISO 27001 certificate, business continuity exercise or BSI Act submission automatically satisfies every KRITIS requirement. Reuse requires a reasoned mapping of the finding, resilience objective, installation and period, together with the remaining gap.
An evidence register can record source, scope, period, responsible function, evidential value and last review. It reduces duplicate work without turning similarity into legal equivalence.
Reuse also has an organisational dimension. The ISMS may regard a piece of evidence as technically and methodologically sound while its operator scope or review period does not fit the resilience plan. Conversely, a continuity exercise may provide valuable observations on staffing and recovery but cannot support an untested physical protection measure. Each mapping therefore needs two confirmations: the specialist owner confirms what the evidence can substantiate, and the role accountable for the resilience objective confirms that it fits the specific scope. This is slightly more work than moving a PDF into another folder, but it avoids the later discovery that the same evidence was referenced everywhere and sufficient nowhere.
Management governs decisions rather than document volumes
An integrated model changes reporting to the executive team. Instead of presenting the number of completed actions or available plans in isolation, it shows residual disruption by priority scenario, assumptions tested with defensible evidence, and open decision deadlines. An overdue action does not automatically become the greatest risk. Its significance depends on the service level that relies on it, available compensation and the point at which the next threshold will be reached.
Investment conflicts also become more concrete. If the same mobile power unit is intended to protect two sites, management cannot simply assure both functions that “redundancy exists”. It has to weigh priority, transport time, staffing and alternative operating states. If the same external specialist appears in several recovery plans, the issue is not the completeness of the plans but the scarce capability. The integrated model translates such conflicts into decisions about resources, sequence and accepted residual uncertainty.
The management consequence is sober. Owners become accountable not for documents but for valid assumptions and timely escalation. Exercises show which assumptions were confirmed or disproved. A green status remains green only when its threshold, evidence period and next review are visible. Colour alone is not an operating reserve.
Review criteria for the next 90 days
- Entities and installations are assigned to a defensible scope separately from the NIS2 or BSI Act classification.
- Management has confirmed critical services, minimum levels and recovery priorities.
- A cross-domain map shows technical, physical, workforce and third-party dependencies.
- Common scenario IDs connect the risk assessment, resilience plan, BCM, ISMS and physical security work.
- Every priority measure has an objective, owner, due date, operating evidence and escalation threshold.
- Triage separates reporting routes, deadlines and approvals by legal regime.
- Exercises test coupled failures and decision handovers rather than isolated departmental routines.
- Management can see residual uncertainty, overdue measures and assumptions that have never been tested.
Conclusion and the A-R-C perspective
The KRITIS Umbrella Act should not be treated as a project to produce a resilience plan. The plan is the visible layer. What matters is the operating model underneath: critical service, dependency, scenario, measure, evidence and decision.
A-R-C helps organisations make information security and resilience governable, auditable and management-ready. A focused Resilience Governance Review is a practical starting point: scope hypotheses, existing registers, reporting routes and evidence are brought into one control picture, then the largest decision and evidence gaps are prioritised.
Scope and limitations
This article provides professional analysis on governance and implementation. It is not legal advice, an individual KRITIS or NIS2 applicability determination, or an audit, certification or resilience guarantee. Implementing regulations, authority decisions and sector-specific regimes require separate case-by-case review.
Primary sources
- German KRITIS Umbrella Act, official consolidated text, particularly sections 2, 4, 8, 12, 13, 16–18 and 20, accessed 2 August 2026: https://www.gesetze-im-internet.de/kritisdachg/BJNR0420B0026.html
- German Bundestag, “Bundestag beschließt Gesetz zur Stärkung kritischer Anlagen”, 29 January 2026, accessed 2 August 2026: https://www.bundestag.de/dokumente/textarchiv/2026/kw05-de-kritische-infrastruktur-1137002
- German Bundestag, Bundestagsdrucksache 21/3906, committee recommendation and report, accessed 2 August 2026: https://dserver.bundestag.de/btd/21/039/2103906.pdf
About the author
Andreas Rühl supports organizations as an interim CISO and ISMS/GRC advisor. His focus is making information security manageable, auditable and fit for management decisions.