KRITIS und Datensouveränität: Anforderungen an kritische Infrastruktur

1. Das KRI­TIS-Dach­ge­setz: Wer ist betrof­fen? #

Das KRI­TIS-Dach­ge­setz (KRI­TIS-DachG) ist seit 17. März 2026 in Kraft (Bun­des­ge­setz­blatt I Nr. 66 vom 16. März 2026). Es schafft erst­mals einen ein­heit­li­chen Rechts­rah­men für die phy­si­sche Resi­li­enz kri­ti­scher Infra­struk­tur in Deutsch­land, setzt die EU-CER-Richt­li­nie (2022÷2557) um und ergänzt das NIS2UmsuCG.

Die KRI­TIS-Sek­to­ren #

• Ener­gie: Strom, Gas, Fern­wär­me, Raffinerien
• Was­ser: Trink­was­ser­ver­sor­gung, Abwasserentsorgung
• Trans­port und Ver­kehr: Schie­ne, Luft­fahrt, See­hä­fen, Straße
• Gesund­heit: Kran­ken­häu­ser, Labo­re, Pharmahersteller
• Finanz- und Ver­si­che­rungs­we­sen: Kre­dit­in­sti­tu­te, Zah­lungs­in­fra­struk­tur, Börsen
• Ernäh­rung: Lebens­mit­tel­her­stel­lung, Verteilung
• Infor­ma­ti­ons­tech­nik und Tele­kom­mu­ni­ka­ti­on: Rechen­zen­tren, DNS-Resol­ver, Cloud-Anbieter
• Sied­lungs­ab­fall­ent­sor­gung: kom­mu­na­le Entsorgungsbetriebe
• Welt­raum: Satel­li­ten­be­trei­ber, Bodenstationen
• Öffent­li­che Ver­wal­tung: Bun­des­be­hör­den, kri­ti­sche Verwaltungsinfrastruktur

Schwel­len­wer­te #

Die Betrof­fen­heit rich­tet sich nach sek­tor­spe­zi­fi­schen Schwel­len­wer­ten, die per Rechts­ver­ord­nung fest­ge­legt wer­den. Ener­gie-Netz­be­trei­ber ab einer bestimm­ten Netz­ka­pa­zi­tät, Kran­ken­häu­ser ab einer defi­nier­ten Bet­ten­zahl oder Trink­was­ser­ver­sor­ger ab einem bestimm­ten Ver­sor­gungs­vo­lu­men fal­len in den Anwen­dungs­be­reich. Die aktu­el­len Schwel­len­wer­te publi­ziert das BSI.

---

2. Daten­sou­ve­rä­ni­täts­pflich­ten für KRI­TIS-Betrei­ber #

Was das Gesetz for­dert #

Das KRI­TIS-Dach­ge­setz schreibt vor, dass Betrei­ber kri­ti­scher Infra­struk­tur Maß­nah­men zur Resi­li­enz ihrer Anla­gen und Sys­te­me umset­zen, ein­schließ­lich der IT-Sys­te­me, die für den Betrieb not­wen­dig sind. Kon­kret bedeu­tet das für Datenspeicherung:

• Ver­füg­bar­keits­ga­ran­tien für betriebs­kri­ti­sche Daten auch im Störungsfall
• Schutz vor unbe­fug­tem Zugriff, Mani­pu­la­ti­on und Datenverlust
• Nach­weis gegen­über den Auf­sichts­be­hör­den im Rah­men von Prüfungen

Was das Gesetz impli­ziert, aber nicht immer expli­zit benennt: Daten­sou­ve­rä­ni­tät ist die Vor­aus­set­zung für ech­te Resi­li­enz. Wer sei­ne Daten in einer frem­den Infra­struk­tur spei­chert, kann Ver­füg­bar­keit, Inte­gri­tät und Kon­trol­le nur bedingt garantieren.

Daten­sou­ve­rä­ni­tät als Com­pli­ance-Begriff #

Daten­sou­ve­rä­ni­tät bedeu­tet für KRITIS-Betreiber:

• Rechts­ho­heit: Die Daten unter­lie­gen aus­schließ­lich deut­schem und euro­päi­schem Recht
• Zugriffs­ho­heit: Nur auto­ri­sier­te Per­so­nen und Sys­te­me des Betrei­bers haben Zugriff
• Spei­cher­ho­heit: Der Betrei­ber bestimmt, wo und wie Daten gespei­chert werden
• Lösch­ho­heit: Der Betrei­ber kann Daten nach eige­nem Ermes­sen löschen oder archivieren

Jede die­ser Dimen­sio­nen ist bei Cloud-Spei­che­rung poten­zi­ell eingeschränkt.

---

3. War­um Cloud-Abhän­gig­kei­ten für KRI­TIS struk­tu­rel­le Risi­ken schaf­fen #

Sin­gle Point of Fail­ure #

Wenn ein KRI­TIS-Betrei­ber sei­ne betriebs­kri­ti­schen Daten aus­schließ­lich bei einem Cloud-Anbie­ter spei­chert, ent­steht ein Sin­gle Point of Fail­ure außer­halb der eige­nen Kon­trol­le. Die Aus­fall­his­to­rie gro­ßer Cloud-Anbie­ter zeigt: Regio­na­le Aus­fäl­le, die stun­den­lang dau­ern, sind kei­ne theo­re­ti­schen Szenarien.

Für einen Ener­gie­ver­sor­ger, einen Was­ser­auf­be­rei­ter oder ein Kran­ken­haus kann ein mehr­stün­di­ger Daten­zu­griffs­ver­lust kri­ti­sche Kon­se­quen­zen haben, für den Betrieb und für die Compliance.

Aus­län­di­scher Rechts­rah­men #

Alle drei gro­ßen Hypers­ca­ler (AWS, Micro­soft Azu­re, Goog­le Cloud) sind US-Kon­zer­ne. Der US CLOUD Act ver­pflich­tet sie, US-Behör­den auf rich­ter­li­che Anord­nung Zugriff auf Kun­den­da­ten zu gewäh­ren, auch wenn die­se phy­sisch in euro­päi­schen Rechen­zen­tren lie­gen. Für KRI­TIS-Betrei­ber, die mit staats­re­le­van­ten Daten arbei­ten, ist das kein abs­trak­tes Risiko.

Ein Betrei­ber, der nicht aus­schlie­ßen kann, dass Drit­te ohne sein Wis­sen auf sei­ne Betriebs­da­ten zugrei­fen, erfüllt die Anfor­de­run­gen an Daten­sou­ve­rä­ni­tät nicht vollständig.

Aus­fall des Anbie­ters als Sze­na­rio #

KRI­TIS-Betrei­ber müs­sen im Rah­men des KRI­TIS-Dach­ge­set­zes Not­fall­sze­na­ri­en durch­den­ken und doku­men­tie­ren. Der Aus­fall des Cloud-Spei­cher­an­bie­ters ist eines die­ser Sze­na­ri­en. Wer kei­ne On-Pre­mi­ses-Fall­back-Infra­struk­tur betreibt, kann die­ses Sze­na­rio nicht beherrschen.

---

4. BSI-Anfor­de­run­gen an Daten­spei­che­rung für KRI­TIS-Betrei­ber #

Das BSI kon­kre­ti­siert die Anfor­de­run­gen des NIS2UmsuCG im IT-Grund­schutz; das KRI­TIS-Dach­ge­setz ergänzt die phy­si­sche Dimen­si­on. Für Daten­spei­che­rung und Back­up gel­ten fol­gen­de Kernprinzipien:

Off­line-Back­up-Pflicht #

Das BSI emp­fiehlt aus­drück­lich die 3 – 2‑1 – 1‑0-Regel: min­des­tens eine Siche­rungs­ko­pie off­line und vom Netz getrennt. Für KRI­TIS-Betrei­ber ist die­se Emp­feh­lung fak­tisch ein Gebot, da Ran­som­wa­re-Resi­li­enz zu den gefor­der­ten Schutz­maß­nah­men zählt.

Unver­än­der­lich­keit (Immu­ta­bi­li­ty) #

Für Pro­to­koll­da­ten, Betriebs­auf­zeich­nun­gen und Audit-Logs for­dert das BSI Mani­pu­la­ti­ons­schutz. WORM-Spei­cher (Wri­te Once Read Many) erfüllt die­se Anfor­de­rung durch tech­ni­sche Unver­än­der­lich­keit, unab­hän­gig von Benut­zer­rech­ten oder admi­nis­tra­ti­vem Zugriff.

Nach­voll­zieh­bar­keit und Pro­to­kol­lie­rung #

KRI­TIS-Betrei­ber müs­sen Zugrif­fe auf kri­ti­sche Sys­te­me pro­to­kol­lie­ren und die­se Pro­to­kol­le revi­si­ons­si­cher auf­be­wah­ren. Das schließt Pro­to­kol­le aus IT-Betriebs­sys­te­men, Leit­sys­te­men (SCA­DA) und Sicher­heits­lö­sun­gen ein.

Regel­mä­ßi­ge Prü­fun­gen #

KRI­TIS-Betrei­ber müs­sen die Umset­zung ihrer Sicher­heits­maß­nah­men regel­mä­ßig gegen­über dem BSI nach­wei­sen; das BSI kann zusätz­lich Prü­fun­gen anord­nen. Daten­spei­cher und Back­up-Sys­te­me wer­den dabei auf Kon­for­mi­tät mit den BSI-Vor­ga­ben geprüft. Feh­len­de Res­to­re-Tests, kei­ne Off­line-Kopien oder unge­si­cher­te Pro­to­koll­spei­cher füh­ren zu Beanstandungen.

---

5. Lie­fer­ket­ten­si­cher­heit: War­um die Her­kunft von Sto­rage-Hard­ware eine Com­pli­ance-Fra­ge ist #

Sup­p­ly Chain Secu­ri­ty unter KRI­TIS #

Das KRI­TIS-Dach­ge­setz und NIS2 ver­pflich­ten Betrei­ber, die Sicher­heit ihrer Lie­fer­ket­te zu bewer­ten. Das schließt die Hard­ware ein, auf der kri­ti­sche Daten gespei­chert werden.

Sto­rage-Hard­ware aus Hoch­ri­si­ko­län­dern oder von Her­stel­lern ohne Trans­pa­renz über ihre Pro­duk­ti­ons­ket­te stellt ein Risi­ko dar: Mani­pu­lier­te Firm­ware, ein­ge­bet­te­te Back­doors oder schwa­che kryp­to­gra­fi­sche Imple­men­tie­run­gen kön­nen die gesam­te Daten­si­cher­heits­stra­te­gie untergraben.

Made in Ger­ma­ny als Com­pli­ance-Argu­ment #

Für KRI­TIS-Betrei­ber ist die Her­kunft der Spei­cher­hard­ware ein nach­weis­ba­rer Fak­tor in der Risi­ko­be­wer­tung. Hard­ware, die in Deutsch­land ent­wi­ckelt und gefer­tigt wird, unter­liegt deut­schem Recht und ist gegen­über dem BSI nach­voll­zieh­bar dokumentierbar.

FAST LTA ent­wi­ckelt und fer­tigt sei­ne Sto­rage-Sys­te­me in Mün­chen. Das schließt Silent Cubes für Lang­zeit­ar­chi­vie­rung und das Silent Brick Sys­tem für Air-Gap-Back­up ein. Für KRI­TIS-Betrei­ber ist das ein über­prüf­ba­res Argu­ment in der Lieferkettendokumentation.

---

6. On-Pre­mi­ses als Daten­sou­ve­rä­ni­täts­stra­te­gie für KRI­TIS #

Air Gap: Schutz auch bei Netz­werk­kom­pro­mit­tie­rung #

Ein Air Gap trennt Back­up-Sys­te­me phy­sisch oder gal­va­nisch vom Pro­duk­ti­ons­netz. Wenn Angrei­fer das Pro­duk­ti­ons­netz­werk eines KRI­TIS-Betrei­bers kom­pro­mit­tie­ren, errei­chen sie air-gap­ped Back­ups nicht.

Das Silent Brick Sys­tem bie­tet zwei Varianten:

• Silent Brick Pro: Phy­sisch aus dem Con­trol­ler X ent­nehm­bar. Die Brick-Ein­heit kann in einem Tre­sor oder einem sepa­ra­ten Sicher­heits­be­reich gela­gert wer­den, das ergibt maxi­ma­len phy­si­schen Schutz.
• Silent Brick Max Air: Gal­va­ni­sche Tren­nung ohne phy­si­sches Ent­neh­men. Geeig­net für auto­ma­ti­sier­te Back­up-Pro­zes­se mit hohem Daten­durch­satz und gleich­zei­ti­ger Netzwerktrennung.

WORM für unver­än­der­li­che Archi­vie­rung #

Silent Cubes sind Hard­ware-WORM-Sys­te­me. Daten, die auf Silent Cubes geschrie­ben wer­den, las­sen sich nicht über­schrei­ben oder löschen: nicht durch Soft­ware, nicht durch Admi­nis­tra­tor-Berech­ti­gun­gen, nicht durch Ran­som­wa­re. Für KRI­TIS-Betrei­ber, die Betriebs­pro­to­kol­le, Audit-Logs und regu­la­to­ri­sche Auf­zeich­nun­gen revi­si­ons­si­cher archi­vie­ren müs­sen, ist Hard­ware-WORM die tech­nisch sichers­te Lösung.

Phy­si­sche Kon­trol­le als Resi­li­en­z­merk­mal #

On-Pre­mi­ses-Infra­struk­tur bleibt im Angriffs­fall zugäng­lich, auch wenn Netz­werk­ver­bin­dun­gen aus­ge­fal­len sind. Für KRI­TIS-Betrei­ber, bei denen Netz­aus­fall ein rea­lis­ti­sches Angriffs­sze­na­rio ist, ist das ein struk­tu­rel­ler Vor­teil gegen­über Cloud-only-Strategien.

---

7. Sek­tor­spe­zi­fi­sche Anfor­de­run­gen: Ener­gie, Gesund­heit, Was­ser im Ver­gleich #

Ener­gie

• Pri­mä­re Regu­lie­rung: KRI­TIS-DachG, NIS2UmsuCG/​BSIG, EnWG
• Beson­de­re Daten­ka­te­go­rien: SCA­DA-Daten, Netztopologie
• WORM-Rele­vanz: Pro­to­koll­si­che­rung, Audit-Logs
• Air-Gap-Anfor­de­rung: hoch (kri­ti­sche Infrastruktur)
• Daten­spei­cher­ort: Deutsch­land empfohlen

Gesund­heit

• Pri­mä­re Regu­lie­rung: KRI­TIS-DachG, NIS2UmsuCG/​BSIG, §630f BGB, §203 StGB, DSGVO Art. 9
• Beson­de­re Daten­ka­te­go­rien: Pati­en­ten­da­ten (beson­ders geschützt)
• WORM-Rele­vanz: Pati­en­ten­ak­ten, Rönt­gen­bil­der, OP-Berichte
• Air-Gap-Anfor­de­rung: hoch (Ran­som­wa­re-Risi­ko im Gesundheitssektor)
• Daten­spei­cher­ort: Deutsch­land aus §203-StGB-Grün­den geboten

Was­ser

• Pri­mä­re Regu­lie­rung: KRI­TIS-DachG, NIS2UmsuCG/​BSIG, DVGW-Regelwerk
• Beson­de­re Daten­ka­te­go­rien: Ver­fah­rens­da­ten, Netzpläne
• WORM-Rele­vanz: Mess­da­ten, Betriebsprotokolle
• Air-Gap-Anfor­de­rung: hoch (Ver­sor­gungs­si­cher­heit)
• Daten­spei­cher­ort: Deutsch­land empfohlen

Beson­der­heit Gesund­heits­sek­tor #

Für Kran­ken­häu­ser und Kli­ni­ken kommt zu den KRI­TIS-Anfor­de­run­gen der beson­de­re Schutz von Pati­en­ten­da­ten nach Art. 9 DSGVO hin­zu. §203 StGB ver­bie­tet die unbe­fug­te Wei­ter­ga­be von Pati­en­ten­da­ten, auch an Cloud-Anbie­ter, deren Mit­ar­bei­ter Zugriff haben. Die Kom­bi­na­ti­on aus KRI­TIS-Pflich­ten und §203 StGB macht On-Pre­mi­ses-Spei­che­rung für Kli­ni­ken in vie­len Fäl­len zur rechts­si­chers­ten Lösung.

---

8. Zeit­plan: Was bis wann umge­setzt sein muss #

• KRI­TIS-Dach­ge­setz, Grund­pflich­ten: in Kraft seit 17. März 2026
• NIS2UmsuCG, Regis­trie­rungs­pflicht beim BSI: in Kraft seit 6. Dezem­ber 2025; BSI-Por­tal seit 6. Janu­ar 2026; Regis­trie­rungs­frist war der 6. März 2026
• NIS2UmsuCG, tech­ni­sche Sicher­heits­maß­nah­men: gel­ten seit 6. Dezem­ber 2025 ohne all­ge­mei­ne Über­gangs­frist; BSI-Prü­fun­gen laufen
• Umset­zungs­nach­weis beson­ders wich­ti­ger Ein­rich­tun­gen: bis Dezem­ber 2028 gegen­über dem BSI
• Lie­fer­ket­ten­si­cher­heit (Bewer­tung): lau­fen­de Pflicht seit Inkrafttreten
• Not­fall­ma­nage­ment-Nach­wei­se: lau­fen­de Pflicht, in Prü­fun­gen nachzuweisen

Hin­weis: KRI­TIS-Betrei­ber, die noch nicht voll­stän­dig kon­form sind, soll­ten die Bestands­auf­nah­me ihrer Spei­cher­in­fra­struk­tur prio­ri­sie­ren. BSI-Prü­fun­gen fin­den statt.

---

Wei­ter­füh­ren­de Res­sour­cen #

→ KRI­TIS-Dach­ge­setz: Was sich für Betrei­ber kri­ti­scher Infra­struk­tur ändert (/de/­b­log/­kri­tis-dach­ge­set­z/) → Was ist Daten­sou­ve­rä­ni­tät? (/de/­b­log/­was-ist-daten­sou­ve­rae­ni­tae­t/) → Logi­scher vs. phy­si­scher Air Gap: Tech­ni­scher Ver­gleich (/de/­b­log/­lo­gi­scher-vs-phy­si­scher-air-gap/) → Made in Ger­ma­ny: Siche­re IT-Infra­struk­tur aus Deutsch­land (/de/­b­log/­ma­de-in-ger­ma­ny-it-infra­struk­tur/) → US CLOUD Act: Was IT-Ent­schei­der wis­sen müs­sen (/de/­b­log/us-cloud-act-erklaer­t/)