KRITIS-Dachgesetz 2026:
Was jetzt auf Betreiber zukommt
– und wie Atlassian bei Nachweisen, Workflows und Resilienz hilft
Kritische Einrichtungen sollen in Deutschland einheitlicher und ganzheitlicher geschützt werden – nicht nur digital, sondern auch physisch und organisatorisch. Genau dafür schafft das KRITIS-Dachgesetz einen sektorübergreifenden Rahmen zur Umsetzung der EU-CER-Richtlinie (EU 2022/2557).
Kurz gesagt: Es geht um Risiken erkennen, Resilienzmaßnahmen steuern, Vorfälle melden und Nachweise sauber dokumentieren – auditfähig und wiederholbar.
Hinweis zum Stand (05.02.2026): Der Bundestag hat das KRITIS-Dachgesetz am 29.01.2026 beschlossen; Details zur Konkretisierung (z. B. Mindestanforderungen/Schwellen) werden teils über nachgelagerte Regelungen präzisiert.
Was Sie erwartet:
Was ist das KRITIS-Dachgesetz?
Das KRITIS-Dachgesetz schafft erstmals einen bundesweit einheitlichen Rahmen für die Resilienz kritischer Anlagen und Einrichtungen. Es setzt die EU-CER-Richtlinie um und erweitert den Fokus deutlich über klassische IT-Security hinaus: Im Zentrum stehen physischer Schutz, Organisation & Verantwortlichkeiten, Krisenfähigkeit sowie Governance und belastbare Nachweisführung.
Kurz: Resilienz wird vom „Konzeptpapier“ zum Betriebsmodell – mit klaren Anforderungen, die im Alltag wiederholbar umgesetzt und bei Bedarf belegt werden müssen.
Warum jetzt handeln? Wer ist betroffen?
Warum Unternehmen jetzt aktiv werden müssen
Resilienz ist kein Projekt, sondern ein Betriebsmodell. Wenn Risikoanalyse, Maßnahmen, Nachweise und Incident-Meldungen nicht zusammenpassen, wird’s in Prüfungen teuer – vor allem zeitlich.
Nachweise entstehen im Alltag – oder gar nicht. Wer erst kurz vor Audit/Behördenanfrage „Dokumentation baut“, verliert Wochen.
Abhängigkeiten wachsen. Kritische Services hängen voneinander ab (Dienstleister, Standorte, IT/OT, Logistik). Ohne zentrales Steuerungsmodell werden Lücken normal.
Bußgelder & Anordnungen sind realistische Risiken. Der Gesetzesrahmen sieht Ordnungswidrigkeiten oder Bußgelder vor.
Welche Unternehmen sind betroffen?
Betroffen sind Betreiber kritischer Anlagen/Einrichtungen in Sektoren wie z. B.
- Energie & Wasser,
- Gesundheit
- Transport
- IT/TK
- Finanz/Versicherung
- öffentliche/weitere essenzielle Dienste
Wichtig:
Ob eine Organisation konkret unter die Pflichten fällt, hängt von Definitionen und Schwellenwerten ab, die sektorspezifisch präzisiert werden (in der Praxis ist genau das oft der Knackpunkt in der Einordnung).
Was ändert sich konkret?
Die 4 größten Veränderungen durch das KRITIS-Dachgesetz
1) Pflicht zur Registrierung + behördliche Zuordnung (und laufende Aktualisierung)
Neu ist vor allem: Es gibt eine zentrale, formale „Onboarding“-Pflicht ins Regime – inkl. definierter Stammdaten, Kontaktstelle und späterer Behördenzuständigkeit.
Was konkret verlangt wird:
- Betreiber müssen ihre kritischen Anlagen über eine gemeinsame Registrierungsmöglichkeit von BSI & BBK registrieren.
- In der Registrierung stecken u. a.: Betreiber-Identität, Kontaktdaten, Sektor/Branche, kritische Dienstleistung, Standort/Versorgungsgebiet, ggf. EU-Bezug und eine erreichbare Kontaktstelle.
- Fristenlogik: spätestens 3 Monate nach Einstufung, frühestens jedoch bis einschließlich 17. Juli 2026.
- Änderungen müssen gepflegt werden (teils jährlich, teils „unverzüglich“ innerhalb von 2 Wochen).
- Wenn Betreiber nicht registrieren, kann das BBK nach Anhörung die Registrierung selbst vornehmen.
Warum das in der Praxis ein großer Shift ist
Ohne saubere Stammdaten/Ownership (24/7-Kontakt, klare Verantwortlichkeit je Anlage, konsistente Anlagen-Grenzen) kommt ihr in den Folgepflichten sofort ins Straucheln.
Das ist der perfekte Punkt, um Governance in Tools zu „verankern“ (Owner, Rollen, RACI, Nachweisstruktur).
2) Regelmäßige Risikoanalyse nach All-Gefahren-Ansatz (inkl. Interdependenzen)
Der Kernwechsel: Nicht „nur Cyber“ und nicht „nur punktuelle BCM-Dokumente“, sondern wiederkehrende, nachvollziehbare Risikoanalyse für physische, technische und menschliche Ursachen – plus Abhängigkeiten zu anderen Sektoren/Anbietern.
Was konkret verlangt wird:
- Betreiber müssen mindestens alle vier Jahre eine Risikoanalyse und Risikobewertung durchführen – auf Basis nationaler Risikoanalysen/Risikobewertungen und weiterer vertrauenswürdiger Quellen.
Die Analyse muss explizit Risiken und Abhängigkeiten berücksichtigen:
- Abhängigkeit des Betreibers von kritischen Dienstleistungen anderer Betreiber (auch sektorenübergreifend, auch EU/Drittstaaten).
- Abhängigkeit anderer Sektoren von der eigenen kritischen Dienstleistung (ebenfalls EU/Drittstaaten).
Praktische Konsequenzen (die viele unterschätzen):
Ihr braucht ein einheitliches Modell: Asset/Anlage → kritische Dienstleistung → Szenario → Eintrittswahrscheinlichkeit/Impact → Maßnahmen → Rest-Risiko.
Interdependenzen sind der „Audit-Killer“: Lieferketten, Single Points of Failure, zentrale Standorte, Personalengpässe, externe Dienstleister, Strom/Telekom-Abhängigkeiten – das muss strukturiert rein, nicht als Fließtext.
3) Verbindliche Resilienz-Ziele + Maßnahmenpaket (physisch, organisatorisch, technisch) – dokumentiert im Resilienzplan
Das ist der Paradigmenwechsel: Das Gesetz beschreibt sehr klar, welche Resilienz-Ziele erreicht werden müssen – und nennt typische Maßnahmen, die darunterfallen.
Die vier Resilienz-Ziele :
Betreibe müssen Maßnahmen treffen um:
Vorfälle zu verhindern,
angemessenen physischen Schutz von Liegenschaften & Anlagen sicherzustellen,
auf Vorfälle zu reagieren/abzuwehren und Auswirkungen zu begrenzen,
Wiederherstellung der kritischen Dienstleistung zügig zu gewährleisten.
explizit adressierte Maßnahmen (Beispiele aus dem Gesetzestext):
- Objekt-/Perimeterschutz und organisatorischer Schutz (z. B. bauliche/technische Sicherung)
- Überwachung der Umgebung, Detektion und Zugangskontrollen
- Risiko- und Krisenmanagementverfahren, Alarmabläufe
Wichtig: „verhältnismäßig“ – aber nicht beliebig: Maßnahmen müssen auf den Risikoanalysen basieren und verhältnismäßig sein („Zweck-Mittel-Relation“, Stand der Technik, wirtschaftliche Aspekte).
Praktische Konsequenzen (die viele unterschätzen):
Viele Organisationen haben „irgendwo“ Sicherheitskonzepte, Zutrittsprozesse, BCM-Pläne – aber nicht als geschlossenes, versioniertes, auditierbares System, das direkt auf Risiken einzahlt.
Genau hier entsteht der Bedarf nach Workflows + Wissensbasis + Nachweislogik (statt Dokument-Friedhof).
4) Meldewesen für Vorfälle: 24h-Erstmeldung + Folgebericht + standardisierte Inhalte (über gemeinsame Meldestelle)
Neu ist vor allem: Ein einheitlicher, fristgebundener Meldeprozess für relevante Vorfälle im KRITIS-Kontext (nicht nur IT-Incidents).
Was konkret verlangt wird:
Vorfälle müssen dem BBK unverzüglich, spätestens 24 Stunden nach Kenntnis gemeldet werden – über die gemeinsame Meldestelle (BBK/BSI).
Bei andauernden Vorfällen muss die Erstmeldung aktualisiert werden.
Spätestens einen Monat nach Kenntnis ist ein ausführlicher Bericht zu übermitteln.
Die Meldung soll bereits in der Erstmeldung strukturierte Kerndaten enthalten (z. B. Umfang der Betroffenheit, (voraussichtliche) Dauer, geografisches Gebiet).
Warum das ein echter Implementierungsblock ist:
Ohne sauberes Ticketing/Eskalation/Audit-Trail wird die 24h-Frist schnell sportlich – vor allem, wenn mehrere Stellen (Betrieb, Security, BCM, Standortschutz, Legal/Comms) koordiniert werden müssen.
„Nachweisfähigkeit“ ist hier nicht Kür, sondern Teil des Designs: Wer wusste wann was? Welche Entscheidungen? Welche Maßnahmen? Welche Kommunikation?
Die Lösung: Wie Atlassian-Tools KRITIS-Unternehmen bei der Umsetzung helfen
Die Anforderungen des KRITIS-Dachgesetzes sind stark prozess-, dokumentations- und governance-getrieben: Risiken müssen strukturiert bewertet, Maßnahmen gesteuert, Vorfälle nachvollziehbar bearbeitet und Nachweise konsistent dokumentiert werden. Genau hier spielt der Atlassian-Stack seine Stärken aus – als durchgängiges System aus Workflows (Jira), Wissens- und Nachweisführung (Confluence) und Incident-/Meldeprozessen (Jira Service Management).
Jira – workflow-getriebenes Risiko- und Maßnahmenmanagement
Mit Jira lassen sich Resilienz- und Governance-Prozesse operativ abbilden:
Risikoregister als strukturierte Tickets (Owner, Bewertung, Kritikalität, Review-Datum)
Verantwortlichkeiten, Deadlines und Abhängigkeiten sauber zuweisen
Maßnahmen/Controls als Tasks oder Epics steuern und Fortschritt nachverfolgen
Wiederkehrende Reviews über Automationen und Erinnerungen unterstützen
Beispiel-Workflow:
✔ Risiko identifizieren → bewerten → Maßnahmen planen → Umsetzung tracken → Review / Wirksamkeit dokumentieren
Ergebnis: Ein auditfähiger Prozess, der nicht in Excel endet, sondern im Alltag gelebt wird.
+ Jira Dashboards & Automatisierung – Governance „auf Knopfdruck“
KRITIS-Umsetzung scheitert oft nicht an Maßnahmen, sondern an Transparenz. Mit Jira-Dashboards und Automationen lassen sich u. a. abbilden:
Status von Top-Risiken, überfälligen Maßnahmen, offenen Reviews
Incident-Trends und Nachbereitung (Root Cause / Maßnahmentracking)
Standardisierte Reports für Management, Audits und interne Gremien
Confluence – zentrale Wissens- und Nachweisplattform
Confluence dient als zentrale Ebene für alles, was im Audit zählt:
Risiko- und Resilienzberichte (inkl. Begründungen, Entscheidungen, Freigaben)
Resilienzplan / Krisenhandbuch, Notfall- und Kommunikationspläne
SOPs, Betriebsanweisungen, Rollen & Zuständigkeiten (RACI, Kontaktketten)
Verlinkung auf Jira-Tickets als „lebende Evidenz“ (Nachweis direkt am Prozess)
Ergebnis: Dokumentation ist versioniert, auffindbar und nachvollziehbar – und eng mit der Umsetzung verknüpft.
Jira Service Management – Incident- & Meldemanagement mit Nachvollziehbarkeit
Wenn Vorfälle erfasst, eskaliert und ggf. gemeldet werden müssen, unterstützt Jira Service Management durch:
Standardisierten Incident-Intake (Portal/E-Mail/Integrationen) inkl. Klassifizierung
Eskalationen und klare Verantwortlichkeiten (je nach Setup auch On-Call/Bereitschaft)
Audit-Trail & Timeline: wer wusste wann was, welche Maßnahmen wurden ergriffen
Post-Incident Reviews inkl. Lessons Learned und Maßnahmenableitung in Jira
Hinweis zu Opsgenie: Falls Opsgenie bei euch im Einsatz ist, kann es als Bestandslösung/Übergang in das Setup integriert werden – strategisch setzen viele Organisationen künftig auf JSM-basierte Prozesse.
Wie wir KRITIS-Unternehmen unterstützen
Wir helfen Unternehmen dabei, die KRITIS-Anforderungen technisch und organisatorisch im Atlassian-Stack umzusetzen:
✅ Einordnung der Pflichten & Scope im Kontext eurer Organisation
✅ Auditfähige Jira-Workflows für Risiko- & Maßnahmenmanagement
✅ Confluence-Strukturen + Templates für Nachweise, Resilienzplan, Krisenhandbuch
✅ Jira Service Management Prozesse für Incident/Meldung inkl. Eskalation & Review
✅ Tool-Integration, Automatisierung, Dashboards, Enablement & Schulungen
JL.Digital GmbH.
KRITIS-Resilienz mit Atlassian umsetzen !
Das KRITIS-Dachgesetz fordert wiederkehrende Risikoanalysen, Resilienzmaßnahmen, Meldeprozesse und Nachweisführung.
Wir übersetzen diese Anforderungen in konkrete Workflows in Jira, saubere Nachweise in Confluence und Incident-Prozesse in Jira Service Management – inkl. Templates, Dashboards und Governance.
Startet mit einem KRITIS-Atlassian-Check und bekommt eine umsetzbare Roadmap.