8 min read

By 2026, BSI-KRITIS, NIS2 and C5 will no longer sit side-by-side but stack vertically. Organisations embedding cloud services into critical infrastructure must satisfy all three frameworks simultaneously—without letting compliance become a box-ticking exercise that delivers no real protection. This practical audit reveals where the frameworks actually collide and how a multi-cloud setup can still pass inspection.

Bottom line: compliance hinges on the interplay of service selection, tenant configuration, evidence collection and incident-reporting workflows. The provider supplies only one piece of the puzzle.

Key Takeaways

• The regulated circle keeps expanding: With NIS2 transposed via the NIS2UmsuCG and the KRITIS umbrella law, far more companies now face cybersecurity and resilience obligations. Not every organisation will qualify as a KRITIS operator in the strict sense, yet NIS2/BSIG duties and KRITIS-style audit chains now reach deeper into the market than before.
• C5 is a proof framework, not a finish line: The auditor’s attestation folder covers the provider. Tenant configuration, key management, access control and logging must still be demonstrable by the operator.
• Multi-cloud creates multiple audit trails per workload: Provider attestation, tenant evidence, supply-chain and sub-processor proofs sit in separate silos unless a central evidence layer ties them together. The compliance workload rises sharply.

RelatedBYOD in the German Enterprise 2026  /  SAP Sovereign Cloud France

What’s really new in 2026

What is BSI-KRITIS compliance for cloud usage? Operators of critical infrastructures are now required to demonstrate, for every cloud service used in production, the data class, location, provider attestation (typically BSI C5 Type 2), their own tenant configuration evidence, and a documented incident reporting chain including 24-hour early-warning under NIS2. Generic provider attestations are no longer sufficient as of 2026.

The debate around KRITIS and cloud has been ongoing for years, but 2026 marks a turning point. The second ordinance amending the BSI-Kritisverordnung lowers thresholds in several sectors. At the same time, the draft KRITIS umbrella law for the first time links physical and digital resilience. In parallel, the NIS2 implementation in the NIS2UmsuCG significantly expands the circle of entities subject to obligations. Any company that previously hovered just below the KRITIS threshold is now inside—or perilously close.

For accurate classification, remember: for cloud setups, NIS2/BSIG is the more immediate cybersecurity lever. The KRITIS umbrella law adds further pressure on resilience and evidence requirements for operators of critical assets, though some details still need to be fleshed out in subordinate regulations. Keeping the regimes separate helps plan more precisely.

The impact on cloud strategies is anything but subtle. Every cloud service used in production must be evidenced individually: category, data class, location, provider attestation, and your own tenant configuration evidence. What three years ago passed as a blanket “we have C5” statement will be dismantled in a 2026 KRITIS audit. Auditors now demand service-level granularity, not just a hyperscaler-wide snapshot.

C5 remains an important attestation framework for cloud providers. For operators, however, it is only one piece of the puzzle: tenant configuration, access control, key management, and logging must each be verifiable. This separation was long glossed over and now lands squarely on the operator’s desk during audit.

The Three Frameworks and Where They Clash

Treating KRITIS, NIS2 and C5 as separate tracks creates three parallel audit universes. That’s expensive and unnecessary. In practice, about two-thirds of the requirements overlap. It’s the remaining thirty percent that must be understood—otherwise, you’ll face findings.

The most critical conflict in practice: NIS2 demands a 24-hour early warning for reportable incidents. KRITIS sector rules are sometimes stricter, sometimes looser. C5, in turn, obliges the provider to inform its customers. The customer must handle escalation to the BSI themselves. If the interface isn’t set up, they receive an incident alert from the hyperscaler but can’t process it organizationally.

Important clarification on the deadline: the 24-hour clock starts as soon as the obligated entity becomes aware of a significant security incident and must trigger the reporting path. Provider alerts are just one possible trigger, not the only one. If you haven’t established an internal assessment and escalation path, you’ll burn most of those 24 hours on organizational clarification.

Second conflict: supplier security. NIS2 places supply-chain protection at the center. In a multi-cloud reality, every hyperscaler and every SaaS tier-2 provider is part of that chain. C5 only covers the first cloud provider, not its sub-processors. Running SaaS on Hyperscaler X means you have two supplier levels with different evidence obligations.

From Framework to Setup: A Four-Week Path

The following approach is distilled from compliance projects in utilities, KRITIS-adjacent industries, and insurers. The timeline fits an existing multi-cloud setup with two to three hyperscalers and a handful of SaaS tools with customer data access.

The urge to tackle everything in parallel is understandable, but inefficient. Without a clean inventory, every posture tool is redundant. Without protection requirement assessment, no one knows which configuration evidence is truly critical. This sequence has proven most reliable in practice.

If you already operate a central cloud platform for inventory and drift detection, Week 3 can be shortened. If you’re still tracking assets in Excel sheets per department, extend Week 1 instead of cutting corners. An incomplete inventory surfaces on page one of a KRITIS audit. Then the correction cycle begins under time pressure.

What holds up, what breaks: Multi-cloud under scrutiny

In the clash between architectural idealism and audit reality, it’s decided whether a setup survives scrutiny. The patterns below have frequently led to findings—or just as often, avoided them—over the past two years.

More often than not, failure stems not from technology but from organization. Cloud architectures at most critical-infrastructure operators are technically sound. What’s missing are documented interfaces between IT security, compliance, and line-of-business teams. If you haven’t walked through your reporting path once a quarter, you don’t truly know it.

A second common stumbling block is the SaaS shadow layer. Marketing tools, HR systems, legal platforms—all eventually creep into the critical-infrastructure orbit because they process data from critical assets or hold identities of operations staff. Any inventory gap here is an audit gap waiting to happen.

Architecture decisions with compliance leverage

Three architectural building blocks have an outsized impact. They’re not new, but by 2026 they’re no longer optional.

First: Identity federation with a central audit backbone. If you run Hyperscaler X, Y and three SaaS vendors with separate identity stacks, you have five audit logs. If you centralize on one identity provider with consistent federation, you have one. The audit effort doesn’t drop linearly—it falls off a cliff—because incident forensics follows a single path.

Second: Customer-managed keys, at minimum for data classes “high” and “very high.” Provider-managed keys are convenient and sufficient for “normal.” When KRITIS-relevant data classes are involved, the discussion about key sovereignty is one the auditor reads and scores. An in-house key infrastructure—whether external key manager or dedicated HSM attachment—earns points in the report and buys maneuvering room during an incident.

Third: Configuration evidence as a first-class citizen. Provider attestations are point-in-time snapshots. A live cloud changes daily. Without a drift detector that alerts on deviations from the desired state, you cannot prove control effectiveness between audit dates. The auditor’s question “when did you know?” can only be answered with a log entry, not an assumption.

A C5 attestation in the folder does not replace the audit trail inside the tenant. That’s the lesson from every serious KRITIS report of the last two years.

Supply chains and the sub-processor knot

NIS2 moved supply-chain security from the appendix to the front page. For multi-cloud setups this means: every sub-processor becomes visible. Hyperscaler X uses sub-processor A for logging, sub-processor B for threat intelligence, sub-processor C for hardware maintenance. That list must exist, stay current, and any change must be contractually notified.

In a multi-cloud setup the numbers multiply. Three hyperscalers with twelve to twenty sub-processors each add up to roughly fifty supply-chain entries. Without a central outsourcing register that maintains the list and timestamps every change, the NIS2 question on supply-chain risk management cannot be answered.

Practical step: keep the outsourcing register as CSV or database table, reconcile monthly with provider sub-processor lists, write a change-notice into the contract, and name a reviewer. Sounds bureaucratic, but it’s the prerequisite for a NIS2 audit without obvious findings.

What auditors will really look for in 2026

From conversations with auditors—without revealing details of individual reports—a pattern emerges. Three areas receive disproportionate attention in 2026.

The first area is the completeness of the inventory. If you inventory cloud services by provider instead of by service, you’re immediately flagged. Auditors ask for the asset list, inspect the service roster, and compare it with network telemetry. Any SaaS tool surfacing in traffic that isn’t on the list is a direct finding.

The second area is the effectiveness of the incident reporting chain. NIS2 demands 24-hour early warning. Auditors don’t ask for the process; they ask for the last exercise. A quarterly drill with substitute rules and fallback communication usually suffices.

The third area is the consistency of key and identity sovereignty across every cloud tenant. Here multi-cloud complexity hits hardest. A single view of rotated keys and critical identity events over the last 90 days is the bare minimum. Without it, an audit problem is guaranteed.

Frequently Asked Questions

Is a C5 Type 2 attestation sufficient for KRITIS compliance?

No. A C5 Type 2 attestation documents provider controls over a defined period, but it does not replace the operator’s own risk assessment or the tenant-level audit trail. The operator must independently document its cloud configuration, key management, and access controls.

How do you demonstrate uniform compliance in a multi-cloud setup?

With a centralized evidence layer. Cloud Security Posture Management—or a custom build using provider APIs—aggregates configuration, identity, and encryption events from all hyperscalers into a single source. Auditors examine this single source, not three separate dashboards.

Which cloud services fall under the NIS2 supply-chain obligations?

All services that are material to the operation of essential services. In practice: every cloud service that processes data or identities of the obligated entity. This includes SaaS tools even if they are not directly in the production path, but merely hold identities or configuration data.

What does the 24-hour deadline mean across multiple cloud providers in concrete terms?

The clock starts when the obligated entity becomes aware of the incident, not when the provider does. Providers notify their customers, the customer evaluates and then submits the report to the BSI. Organizations without an internal escalation path can burn most of the 24 hours on internal clarifications.

Is an external key manager worth it for KRITIS workloads?

For data classified as “high” in most cases, yes. Customer-managed keys with an external key manager give the operator full control over keys and an independent audit trail. In the audit report and in an actual incident, this makes a clear difference compared to provider-managed keys.

Photo: Eckhard Henkel / Wikimedia Commons (CC BY-SA 3.0 DE)

Image source: AI-generated (May 2026), C2PA certificate embedded in image