Softwareentwicklung für KRITIS und regulierte Branchen: Was Betreiber kritischer Infrastrukturen 2026 wirklich brauchen

Software, die in einem Online-Shop läuft, darf abstürzen. Das ist ärgerlich, aber reparierbar. Software, die eine Netzleitstelle steuert, eine Klinikplattform betreibt oder Finanztransaktionen verarbeitet, hat keine vergleichbare Fehlertoleranz. Ausfälle in kritischen Infrastrukturen sind nicht nur teuer, sie können Versorgungssicherheit, Gesundheit oder öffentliche Sicherheit gefährden. Genau deshalb gelten für diese Systeme andere Maßstäbe als im allgemeinen Unternehmensumfeld.

Der Unterschied beginnt bereits bei der Frage, was Sicherheit überhaupt bedeutet. Im klassischen Softwareprojekt wird Sicherheit oft als nachgelagertes Qualitätsmerkmal behandelt: Man entwickelt, testet und überprüft am Ende, ob alles sicher ist. In KRITIS-Projekten und in NIS2-regulierten Umgebungen ist dieser Ansatz schlicht nicht mehr zulässig. Security by Design ist keine Empfehlung, sondern eine Voraussetzung.

Das NIS2-Umsetzungsgesetz verpflichtet besonders wichtige und wichtige Einrichtungen zu umfassenden Maßnahmen des Risikomanagements, zu Meldepflichten bei Sicherheitsvorfällen innerhalb von 24 Stunden und zu nachweisbarer Compliance. KRITIS-Betreiber, also die rund 1.800 Unternehmen, die eine Versorgungsschwelle überschreiten, erfüllen darüber hinaus noch strengere Pflichten: Sie müssen Systeme zur Angriffserkennung betreiben, die Cyberangriffe in Echtzeit identifizieren, und sich seit dem 17. Juli 2026 auch beim Bundesamt für Bevölkerungsschutz und Katastrophenhilfe für den physischen Schutz registrieren.

Was viele Unternehmen unterschätzen: Diese Anforderungen treffen nicht nur die Betreiber selbst, sondern auch deren Lieferkette. Wer als Softwaredienstleister für einen KRITIS-Betreiber entwickelt, wird Teil der regulatorischen Verantwortungskette. NIS2 verpflichtet betroffene Einrichtungen ausdrücklich dazu, die Sicherheitsstandards ihrer Lieferanten und Dienstleister vertraglich abzusichern und zu überprüfen. Ein Softwarepartner, der keine nachvollziehbaren Entwicklungsprozesse, keine Dokumentation und keine definierten Sicherheitsmaßnahmen vorweisen kann, wird damit selbst zum Compliance-Risiko für seinen Kunden.

Hinzu kommt der Cyber Resilience Act, der für Softwarehersteller ab 2027 verbindlich wird und bereits jetzt in der Projektvorbereitung mitgedacht werden muss. Er schreibt Security by Design, aktives Schwachstellenmanagement und eine vollständige Software Bill of Materials vor, also eine dokumentierte Liste aller verwendeten Bibliotheken und Komponenten.

Der Begriff klingt nach einer Selbstverständlichkeit, aber sein konkreter Inhalt wird in Projekten immer noch häufig zu spät eingeführt. Security by Design bedeutet, dass Sicherheitsanforderungen genauso wie funktionale Anforderungen bereits in der Anforderungsanalyse erhoben werden. Welche Daten verarbeitet die Software? Welche regulatorischen Vorgaben gelten im konkreten Branchenkontext? Welche Angriffsvektoren sind realistisch? Diese Fragen bestimmen die Architekturentscheidungen, nicht umgekehrt.

Im Architekturentwurf folgt dann das Threat Modeling, die strukturierte Analyse potenzieller Bedrohungen und Angriffsflächen. Methoden wie STRIDE helfen dabei, systematisch zu erfassen, wo Daten über Vertrauensgrenzen fließen, wo privilegierte Zugänge bestehen und wo Eingaben manipulierbar sind. Die Ergebnisse fließen direkt in die Wahl von Authentifizierungsverfahren, Verschlüsselungsstrategien und Zugriffskontrollen ein.

Im Entwicklungsprozess bedeutet das in der Praxis automatisierte SAST- und DAST-Tests in der CI/CD-Pipeline, Security Gates, die kritische Schwachstellen vor dem Merge blockieren, und ein konsequentes Dependency Scanning, das Open-Source-Komponenten auf bekannte Schwachstellen prüft. OWASP-Standards bilden dabei den Mindestrahmen, ergänzt durch branchenspezifische Vorgaben, ob IEC 62443 in der Energiebranche, ISO 27001 als übergreifende Basis oder DSGVO- und HIPAA-Anforderungen im Gesundheitsbereich.

Genauso wichtig ist, was nach dem Go-live passiert. KRITIS-Software muss oft zehn, fünfzehn oder zwanzig Jahre stabil laufen. Robuste Architekturen, geplante Wartungszyklen und ein strukturiertes Patch Management sind keine nachrangigen Überlegungen, sondern von Anfang an Teil des Architekturentwurfs.

Ein Aspekt, der in der öffentlichen Diskussion oft zu wenig Aufmerksamkeit bekommt, ist die Auditierbarkeit von Software. Das BSI kann jederzeit Nachweise verlangen. Software, deren Entwicklungsprozesse nicht dokumentiert sind, deren Änderungshistorie nicht nachvollziehbar ist oder die keine Logging- und Monitoring-Funktionen mitbringt, macht die Einhaltung regulatorischer Fristen praktisch unmöglich. Wenn ein Sicherheitsvorfall eintritt und innerhalb von 24 Stunden eine Erstmeldung abgegeben werden muss, ist das kein Zeitrahmen für manuelle Recherchen. Die technische Infrastruktur muss Vorfälle automatisch erkennen, protokollieren und klassifizieren können.

Das bedeutet für die Softwareentwicklung: Logging ist kein optionales Feature, Dokumentation ist kein Bürokratieprojekt und nachvollziehbare Entwicklungsprozesse sind kein Nice-to-have. Sie sind die Grundlage dafür, dass Software in regulierten Umgebungen überhaupt eingesetzt werden darf.

Viele KRITIS-Betreiber und stark regulierte Unternehmen stehen vor der Frage, wie sie die Vorteile moderner Cloud-Infrastrukturen nutzen können, ohne die Kontrolle über kritische Daten zu verlieren. Die Antwort liegt in der Regel in hybriden Modellen: Besonders sensible Systeme und Daten bleiben in der Private Cloud oder On-Premises, während weniger kritische Workloads flexibel in der Public Cloud betrieben werden.

Diese Architekturentscheidung muss von Beginn an in das Systemdesign einfließen. Zero-Trust-Architekturen sind dabei der heute übliche Rahmen: Das Prinzip „Never trust, always verify“ ersetzt implizites Vertrauen durch konsequente Zugangsprüfung für jeden Nutzer, jedes Gerät und jeden Prozess, unabhängig davon, ob der Zugriff von innen oder außen kommt. Für KRITIS-Betreiber ist dieser Ansatz nicht nur sinnvoll, er ist in vielen Fällen regulatorisch gefordert.

Die Wahl des richtigen Entwicklungspartners ist in regulierten Umgebungen strategisch. Neben technischer Kompetenz spielen mehrere Faktoren eine entscheidende Rolle, die in normalen IT-Projekten oft weniger Gewicht haben.

Prozessreife und Nachweisfähigkeit stehen an erster Stelle. Ein Partner, der keine dokumentierten Entwicklungsprozesse vorweisen kann, lässt seinen Kunden bei der Lieferketten-Compliance allein. Das BSI erwartet, dass betroffene Unternehmen die Sicherheitspraktiken ihrer Dienstleister überprüfen und vertraglich absichern. Ein Dienstleister ohne nachvollziehbare Prozesse ist damit ein regulatorisches Problem.

Erfahrung mit branchenspezifischen Standards ist nicht delegierbar. Wer KRITIS-Software für die Energiebranche entwickelt, muss IEC 62443 nicht lernen, während das Projekt läuft. Wer Softwarelösungen für das Gesundheitswesen entwickelt, muss DSGVO, HIPAA und, bei Medizinprodukten, MDR und IEC 62304 von Beginn an konsequent anwenden. Regulatorische Kompetenz und technische Kompetenz müssen im selben Team zusammenkommen.

Langfristige Partnerschaften sind in regulierten Umgebungen besonders wertvoll, weil Software hier nicht deployed und vergessen wird. Patch Management, Sicherheitsmonitoring, Incident Response und die Anpassung an neue regulatorische Anforderungen erfordern einen Partner, der das System kennt und langfristig begleitet.

BAYOOTEC entwickelt seit über 20 Jahren individuelle Softwarelösungen für Unternehmen, bei denen Verlässlichkeit, Datenschutz und Compliance nicht optional sind. Als Teil der BAYOONET Group arbeiten wir in einem Ökosystem, das regulierte Umgebungen aus unterschiedlichen Perspektiven kennt: BAYOOSOFT bringt tiefes Know-how in IT-Security und Zugriffsverwaltung für KRITIS-relevante Infrastrukturen mit, BAYOOMED verfügt über mehr als zehn Jahre Erfahrung in der Entwicklung von Medizinsoftware nach IEC 62304 und MDR, und BAYOOCARE begleitet Unternehmen durch regulatorische Prozesse im Medizinproduktebereich.

Für unsere Kunden bedeutet das: Wenn ein Energieversorger eine Plattform für die Netzkontrolle entwickeln lässt, oder wenn ein Krankenhaus eine Cloud-Lösung für die Patientendatenverwaltung braucht, arbeiten wir nicht als externer Lieferant, sondern als Partner, der die regulatorischen Rahmenbedingungen von Anfang an mitdenkt. Security by Design, auditierbare Prozesse, hybride Architekturansätze und die Integration branchenspezifischer Standards sind für uns keine Sonderleistungen, sondern Teil unseres Entwicklungsansatzes für regulierte Umgebungen.

Wir führen regelmäßige Penetrationstests durch, entwickeln mit Privacy by Design als Grundprinzip und unterstützen unsere Kunden auch bei der Vorbereitung auf Zertifizierungen wie ISO 27001. Transparenz über den Entwicklungsstand und enge, kontinuierliche Abstimmung sind dabei kein Beiwerk, sondern das, was in KRITIS-Projekten den Unterschied zwischen einem Projekt, das im Audit besteht, und einem, das nachgebessert werden muss, ausmacht.

Wenn Du wissen möchtest, wie BAYOOTEC Deinen konkreten Anwendungsfall in einer regulierten Umgebung angehen würde, vereinbare gerne einen ersten unverbindlichen Kennenlerntermin. Wir schauen uns an, was Du brauchst, bewerten bestehende Systeme und entwickeln einen konkreten Plan, ohne endlose Präsentationen, aber mit technischer Substanz.