8 min read<\/p>\n
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\u2014without 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.<\/strong><\/p>\n 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.<\/p>\n Related<\/span>BYOD in the German Enterprise 2026<\/a> \/<\/span> SAP Sovereign Cloud France<\/a><\/p>\n What is BSI-KRITIS compliance for cloud usage?<\/strong> 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.<\/p>\n 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\u2014or perilously close.<\/p>\n 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.<\/p>\n 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 \u201cwe have C5\u201d statement will be dismantled in a 2026 KRITIS audit. Auditors now demand service-level granularity, not just a hyperscaler-wide snapshot.<\/p>\n 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\u2019s desk during audit.<\/p>\n Treating KRITIS, NIS2 and C5 as separate tracks creates three parallel audit universes. That\u2019s expensive and unnecessary. In practice, about two-thirds of the requirements overlap. It\u2019s the remaining thirty percent that must be understood\u2014otherwise, you\u2019ll face findings.<\/p>\n Source: BSI-Kritisverordnung, NIS2UmsuCG draft, BSI C5 2020.<\/p>\n<\/div>\n 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\u2019t set up, they receive an incident alert from the hyperscaler but can\u2019t process it organizationally.<\/p>\n 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\u2019t established an internal assessment and escalation path, you\u2019ll burn most of those 24 hours on organizational clarification.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n If you already operate a central cloud platform for inventory and drift detection, Week 3 can be shortened. If you\u2019re 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.<\/p>\n In the clash between architectural idealism and audit reality, it\u2019s decided whether a setup survives scrutiny. The patterns below have frequently led to findings\u2014or just as often, avoided them\u2014over the past two years.<\/p>\n What breaks<\/p>\n What holds up<\/p>\n More often than not, failure stems not from technology but from organization. Cloud architectures at most critical-infrastructure operators are technically sound. What\u2019s missing are documented interfaces between IT security, compliance, and line-of-business teams. If you haven\u2019t walked through your reporting path once a quarter, you don\u2019t truly know it.<\/p>\n A second common stumbling block is the SaaS shadow layer. Marketing tools, HR systems, legal platforms\u2014all 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.<\/p>\n Three architectural building blocks have an outsized impact. They\u2019re not new, but by 2026 they\u2019re no longer optional.<\/p>\n First: Identity federation with a central audit backbone.<\/strong> 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\u2019t drop linearly\u2014it falls off a cliff\u2014because incident forensics follows a single path.<\/p>\n Second: Customer-managed keys, at minimum for data classes \u201chigh\u201d and \u201cvery high.\u201d<\/strong> Provider-managed keys are convenient and sufficient for \u201cnormal.\u201d When KRITIS-relevant data classes are involved, the discussion about key sovereignty is one the auditor reads and scores. An in-house key infrastructure\u2014whether external key manager or dedicated HSM attachment\u2014earns points in the report and buys maneuvering room during an incident.<\/p>\n Third: Configuration evidence as a first-class citizen.<\/strong> 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\u2019s question \u201cwhen did you know?\u201d can only be answered with a log entry, not an assumption.<\/p>\n A C5 attestation in the folder does not replace the audit trail inside the tenant. That\u2019s the lesson from every serious KRITIS report of the last two years. <\/p>\n<\/blockquote>\n 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.<\/p>\n 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.<\/p>\n 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\u2019s the prerequisite for a NIS2 audit without obvious findings.<\/p>\n From conversations with auditors\u2014without revealing details of individual reports\u2014a pattern emerges. Three areas receive disproportionate attention in 2026.<\/p>\n The first area is the completeness of the inventory. If you inventory cloud services by provider instead of by service, you\u2019re 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\u2019t on the list is a direct finding.<\/p>\n The second area is the effectiveness of the incident reporting chain. NIS2 demands 24-hour early warning. Auditors don\u2019t ask for the process; they ask for the last exercise. A quarterly drill with substitute rules and fallback communication usually suffices.<\/p>\n 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.<\/p>\n No. A C5 Type 2 attestation documents provider controls over a defined period, but it does not replace the operator\u2019s own risk assessment or the tenant-level audit trail. The operator must independently document its cloud configuration, key management, and access controls.<\/p>\n<\/details>\n With a centralized evidence layer. Cloud Security Posture Management\u2014or a custom build using provider APIs\u2014aggregates configuration, identity, and encryption events from all hyperscalers into a single source. Auditors examine this single source, not three separate dashboards.<\/p>\n<\/details>\n 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.<\/p>\n<\/details>\n 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.<\/p>\n<\/details>\n For data classified as \u201chigh\u201d 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.<\/p>\n<\/details>\nKey Takeaways<\/h2>\n
\n
What\u2019s really new in 2026<\/h2>\n
The Three Frameworks and Where They Clash<\/h2>\n
\n\n
\n \nAspect<\/th>\n BSI-KRITIS<\/th>\n NIS2 (national)<\/th>\n BSI C5<\/th>\n<\/tr>\n<\/thead>\n \n Target audience<\/strong><\/td>\n Operators of critical infrastructure<\/td>\n Essential and important entities<\/td>\n Cloud providers<\/td>\n<\/tr>\n \n Evidence<\/strong><\/td>\n Audit every two years<\/td>\n Self-declaration plus oversight<\/td>\n Type 1 or Type 2 attestation<\/td>\n<\/tr>\n \n Incident reporting<\/strong><\/td>\n To BSI, deadline varies by sector<\/td>\n 24-hour early warning<\/td>\n To provider\u2019s customers<\/td>\n<\/tr>\n \n Cloud relevance<\/strong><\/td>\n Indirect via outsourcing<\/td>\n Supply-chain obligations directly<\/td>\n Direct<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n From Framework to Setup: A Four-Week Path<\/h2>\n
What holds up, what breaks: Multi-cloud under scrutiny<\/h2>\n
\n
\n
Architecture decisions with compliance leverage<\/h2>\n
\n
Supply chains and the sub-processor knot<\/h2>\n
What auditors will really look for in 2026<\/h2>\n
Frequently Asked Questions<\/h2>\n
Is a C5 Type 2 attestation sufficient for KRITIS compliance?<\/strong><\/summary>\n
How do you demonstrate uniform compliance in a multi-cloud setup?<\/strong><\/summary>\n
Which cloud services fall under the NIS2 supply-chain obligations?<\/strong><\/summary>\n
What does the 24-hour deadline mean across multiple cloud providers in concrete terms?<\/strong><\/summary>\n
Is an external key manager worth it for KRITIS workloads?<\/strong><\/summary>\n