Softwareentwicklung für KRITIS: Anwendungen bauen, die der Prüfung standhalten

© Kzenon

Softwareentwicklung für KRITIS auf einen Blick

👉 Betroffen ist die einzelne Anwendung, nicht das Unternehmen als Ganzes
👉 Beim BSI sind 1.231 Betreiber registriert, reguliert sind rund 29.500 Einrichtungen
👉 Zonenschnitt und Rollenmodell sind KRITIS-Anforderungen an Software, keine Betriebsthemen
👉 Zwei der drei häufigsten Schadensursachen entstehen im Auslieferungszustand, nicht im Betrieb
👉 Der Sprung auf 99,99 Prozent Verfügbarkeit verlangt zwei Standorte und Dauerbesetzung
👉 Prüfungen scheitern an fehlenden Belegen, nicht an fehlender Sicherheit
👉 Der übliche Supportzeitraum von fünf Jahren deckt die Laufzeit einer Fachanwendung nicht

Was Softwareentwicklung für KRITIS von normalen Projekten unterscheidet

KRITIS steht für Einrichtungen, deren Ausfall nicht ein Unternehmen trifft, sondern die Versorgung einer ganzen Region: Stromnetze, Wasserwerke, Kliniken, Verkehrsleitstellen.

Softwareentwicklung für KRITIS bezeichnet den Bau und die Pflege von Anwendungen für Betreiber kritischer Infrastrukturen. Sie unterscheidet sich von gewöhnlicher Softwareentwicklung nicht durch die eingesetzte Technik, sondern durch das, was vor der ersten Zeile Code feststehen muss: die geforderte Verfügbarkeit, der Zuschnitt der Zugriffsrechte, eine auswertbare Protokollierung und die Belege, die die Anwendung später über ihre eigene Entstehung liefert.

Wie groß der regulierte Bestand tatsächlich ist

Die Zahl der Betreiber, die solche Belege tatsächlich beim Bundesamt für Sicherheit in der Informationstechnik einreichen, ist klein. Zum Stichtag 30. Juni 2026 waren dort 1.231 Betreiber mit 2.180 Anlagen registriert. Der Kreis der Einrichtungen, für die seit dem NIS-2-Umsetzungsgesetz vergleichbare Anforderungen gelten, liegt dagegen bei rund 29.500. Deren Fachanwendungen entstanden überwiegend zu einer Zeit, in der niemand Nachweise verlangte. Für einen Teil dieser Einrichtungen kommen seit dem KRITIS-Dachgesetz vom März 2026 Vorgaben zur physischen Widerstandsfähigkeit hinzu. Die KRITIS-Anforderungen an Software treffen damit den Bestand stärker als jedes neue Projekt.

Einzelfragen der Softwareentwicklung für kritische Infrastrukturen

Die folgenden Seiten behandeln die Einzelfragen, die sich dabei getrennt entscheiden lassen, von der Härtung einer Anwendung über die Bereitschaft im Störfall bis zur Ablösung eines Altverfahrens.

📎 IT-Wartung in KRITIS
Welcher Reifegrad wird im Nachweis erwartet?
📎 Anwendungshärtung
Wie schrumpft die Angriffsfläche einer Anwendung?
📎 24/7-Bereitschaft für KRITIS-Software
Wen erreicht ein Störfall um drei Uhr nachts?
📎 Software-Lebenszyklus in KRITIS
Wann ist der richtige Zeitpunkt für einen Versionswechsel?
📎 Software-Ablösung in KRITIS
Wie gelingt ein Wechsel ohne Versorgungslücke?
📎 Wiederanlaufplan für KRITIS-Software
Wie schnell läuft die Anwendung nach einem Ausfall wieder?
📎 Kritikalitätsanalyse von Software
Welche Anwendung verdient welches Schutzniveau?
📎 SBOM-Pflege für KRITIS
Woher stammt jede einzelne Komponente im System?
📎 B3S-konforme Softwareentwicklung
Was verlangt der Branchenstandard vom Quellcode?
📎 Regressionstests in der KRITIS-Wartung
Welche Tests laufen vor jedem Patch?

Betroffen ist die Anwendung, nicht das Unternehmen

Die Aufsicht knüpft an der Anlage und ihrer Dienstleistung an. Innerhalb desselben Hauses gelten deshalb sehr unterschiedliche Maßstäbe nebeneinander. Das Leitsystem eines Wasserwerks trägt die volle Nachweislast, die Zeiterfassung derselben Belegschaft trägt keine. Mittelständische Versorger und Zulieferer, die seit Dezember 2025 erstmals unter Aufsicht stehen, ziehen deshalb oft entweder alles oder nichts in den regulierten Bereich. Die Pflichten selbst, von der Registrierung bis zu den Meldefristen, regelt das NIS-2-Umsetzungsgesetz und nicht die Software. Für die Softwareentwicklung zählt allein die saubere Abgrenzung, weil sie über Architektur und Aufwand entscheidet.

Warum die KRITIS-Sektoren unterschiedliche Software erzwingen

Sektorübergreifend gelten dieselben Sicherheitsanforderungen, bei den fachlichen hört die Gemeinsamkeit auf. Jeder Sektor zwingt der Anwendung eine Eigenschaft auf, die anderswo keine Rolle spielt und den Zuschnitt stärker prägt als jede Vorschrift. Die folgende Übersicht ordnet den Sektoren nach BSI-KritisV deshalb nicht ihre Pflichten zu, sondern die KRITIS-Anforderung an Software, an der ein Projekt scheitert, wenn sie zu spät erkannt wird. Ob eine Anwendung sie erfüllt, muss sich später belegen lassen, und welche Unterlagen dafür verlangt werden, klärt der Abschnitt zur Nachweisfähigkeit.

Welche Sicherheitsanforderungen müssen in der Architektur einer KRITIS-Anwendung stecken?

Sicherheit lässt sich einer Anwendung nachträglich hinzufügen, ihre Sicherheitsarchitektur nicht. Darin liegt der Unterschied zwischen einer Maßnahme und einer Architekturentscheidung. Eine Firewall lässt sich am Montag konfigurieren, ein Rollenmodell, das im Kern der Datenhaltung falsch geschnitten ist, kostet Monate. In der Softwareentwicklung für kritische Infrastrukturen fallen deshalb vier Entscheidungen früh, und sie fallen gemeinsam, weil jede die übrigen begrenzt. Absichern lassen sich die einzelnen Ebenen später mit Prüfungen und Härtungsmaßnahmen aus dem Bereich Cybersecurity, nachholen lässt sich die Reihenfolge dieser vier Entscheidungen damit aber nicht.

Zonen und Segmentierung in Software für kritische Infrastrukturen

Ein Zonenmodell teilt eine Anwendung in Bereiche mit unterschiedlichem Schutzbedarf und legt fest, welche Verbindung zwischen ihnen überhaupt bestehen darf. In der Praxis scheitert das selten an der Technik, sondern an der Frage, wo die Grenze verläuft. Eine Anwendung, die Messwerte aus der Fernwirktechnik entgegennimmt und sie zugleich einem Auswertungsportal bereitstellt, verbindet zwei Zonen mit sehr verschiedenem Risiko. Wird diese Grenze erst im Betrieb gezogen, liegt sie fast immer falsch, weil dann die Netztopologie darüber entscheidet und nicht der Datenfluss. Die Netzwerksegmentierung setzt die Grenze später technisch um, erfinden kann sie sie nicht.

Die Entscheidung fällt auf mehreren Ebenen gleichzeitig, und keine davon lässt sich isoliert treffen:

• Datenhaltung, also welche Zone welche Tabellen und Ablagen überhaupt sieht
• Kommunikation, also welche Seite eine Verbindung aufbauen darf und welche nur antwortet
• Authentifizierung, also ob eine Zone einer Identität aus einer anderen Zone vertraut
• Betriebsführung, also wer Konfiguration und Auslieferung in welcher Zone auslöst
• Notfall, also welche Verbindung im Störfall bewusst getrennt wird

Zugriffsrechte werden geschnitten, nicht vergeben

In der Softwareentwicklung für KRITIS entscheidet dieser Unterschied über den Prüfungsausgang, so akademisch er klingt. Rechte vergeben heißt, vorhandenen Rollen Berechtigungen zuzuordnen. Rechte schneiden heißt, die Rollen aus den Aufgaben abzuleiten, die im regulierten Betrieb tatsächlich anfallen, und erst danach zu berechtigen. In größeren Organisationen mit mehreren Standorten kommt hinzu, dass dieselbe Rolle je Standort andere Anlagen sehen darf. Fehlt diese Dimension von Beginn an, entstehen Sammelrollen, die in der Prüfung als unzureichende Trennung auffallen und sich nur mit einem Umbau der Datenhaltung auflösen lassen.

Protokollierung, die im Audit trägt

Protokolliert wird fast überall, auswertbar ist selten etwas. Brauchbar wird ein Protokoll erst, wenn es je Ereignis den Auslöser, den Zeitpunkt, die betroffene Anlage und die verantwortliche Identität festhält und diese Angaben über Systemgrenzen hinweg zusammenpassen. Es scheitert an Kleinigkeiten mit großer Wirkung. Verschiedene Komponenten schreiben unterschiedliche Zeitzonen, technische Dienstkonten erscheinen als handelnde Person, und Ereignisse aus dem Batchbetrieb tragen keinen Auslöser. Die zentrale Auswertung solcher Ereignisse ist eine eigene Disziplin. Für die Anwendung selbst zählt vorher, dass sie überhaupt vergleichbare Daten liefert.

IEC 62443 als Ordnungsrahmen für leittechniknahe Anwendungen

Sobald eine Anwendung an Leit- oder Fernwirktechnik grenzt, greift neben den Managementnormen eine zweite Normenreihe. IEC 62443 beschreibt Sicherheit für industrielle Automatisierungssysteme und denkt in Zonen und den Verbindungen zwischen ihnen, nicht in Organisationsprozessen. Sie ordnet jeder Zone ein Schutzniveau zu und leitet daraus ab, was eine Verbindung über die Zonengrenze hinweg leisten muss. Für ein Projekt bedeutet das eine doppelte Ableitung. ISO 27001 liefert das Managementsystem, IEC 62443 die technischen Anforderungen an der Schnittstelle zur Anlage.

KRITIS-Anforderungen an Software im Entwicklungsprozess verankern

Bitkom hat 2026 erhoben, wo Schäden in deutschen Unternehmen tatsächlich entstehen. Als häufigste Ursachen nennen die Befragten unzureichende Erkennung, Fehlkonfigurationen und schwaches Identitätsmanagement mit 59, 57 und 55 Prozent. Zwei dieser drei Ursachen entstehen nicht im Betrieb, sondern im Auslieferungszustand einer Anwendung. Eine Fehlkonfiguration ist eine Voreinstellung, die jemand beim Bauen getroffen hat, und ein schwaches Identitätsmanagement ist ein Rollenmodell, das jemand entworfen hat. Härtung im laufenden Betrieb arbeitet damit an der kleineren Hälfte des Problems. Die KRITIS-Anforderungen an Software greifen deshalb im Entwicklungsprozess und nicht erst in der Betriebsanweisung.

Softwareentwicklung für KRITIS beginnt bei den Anforderungen

In der Praxis läuft die Reihenfolge fast immer umgekehrt. Zuerst entsteht das Fachkonzept, dann fragt jemand, was die Regulierung zusätzlich verlangt, und die Antwort trifft auf eine Architektur, die bereits festliegt. Am teuersten wird dieser Reihenfolgefehler beim Mandanten- und Rollenschnitt, weil er tief in der Datenhaltung sitzt und sich nicht durch eine zusätzliche Prüfschicht heilen lässt. Softwareentwicklung für KRITIS dreht diese Reihenfolge um, und das kostet in der Anforderungsphase wenige Tage. Sie beginnt mit der Frage, welche Datenklassen die Anwendung verarbeitet, führt über den Schutzbedarf je Klasse zum Zonen- und Rollenschnitt und erreicht das Fachkonzept erst danach.

Prüfpunkte im Entwicklungsprozess von Software für kritische Infrastrukturen

Ein sicherer Entwicklungsprozess, im Fachjargon Secure SDLC, unterscheidet sich in der Softwareentwicklung für kritische Infrastrukturen vom üblichen Vorgehen weniger durch zusätzliche Werkzeuge als durch feste Stellen, an denen etwas belegt wird. Das BSI hat solche Stellen in der Technischen Richtlinie TR-03185 für Softwarehersteller beschrieben, in Teil 1 für proprietäre und in Teil 2 für quelloffene Entwicklung. Entscheidend ist nicht die Zahl der Prüfungen, sondern ihre Verankerung in der Auslieferungskette. Eine Prüfung, die jemand von Hand anstößt, fällt unter Projektdruck zuerst aus.

➤ Bedrohungsmodell zum Entwurf, aktualisiert bei jeder Architekturänderung
➤ Abhängigkeiten mit Herkunft und Version, maschinenlesbar gepflegt
➤ Statische Codeanalyse als Bedingung für die Übernahme in den Hauptzweig
➤ Dynamische Prüfung gegen die laufende Anwendung vor jeder Freigabe
➤ Getrennte Umgebungen mit maskierten statt echten Testdaten
➤ Freigabeprotokoll mit benannter Person, Zeitpunkt und geprüftem Stand

Zwei Meldeketten, die niemand von selbst verbindet

Hersteller vernetzter Produkte müssen aktiv ausgenutzte Schwachstellen ab dem 11. September 2026 innerhalb von 24 Stunden an eine europäische Meldeplattform melden und die Einzelheiten binnen 72 Stunden nachreichen. Betreiber melden erhebliche Störungen parallel dazu an das BSI. Beide Ketten laufen nebeneinander und treffen sich an keiner Stelle von allein. Ohne vertraglich vereinbarten Meldeweg erfährt ein Versorger von einer Lücke in seiner eigenen Fachanwendung eher über die europäische Meldestelle als über den Hersteller. Dieser Meldeweg gehört deshalb in den Vertrag und nicht in die Betriebsdokumentation. Er ist dort einer von mehreren Punkten, die vor der Unterschrift feststehen müssen und die der Abschnitt zur Beschaffung von KRITIS-Software im Einzelnen behandelt.

Verfügbarkeit als KRITIS-Anforderung an Software, nicht als Vertragszeile

Unter allen KRITIS-Anforderungen an Software ist die Verfügbarkeit die teuerste, wenn sie zu spät festgelegt wird. In fast jedem Wartungsvertrag steht eine Zahl dazu, in der Architekturdokumentation dagegen selten. Genau in dieser Lücke entstehen die teuren Nachbesserungen. Die Zahl im Vertrag beschreibt ein Ergebnis, hergestellt wird sie durch Entscheidungen über Datenhaltung, Standorte und Betriebsorganisation, und die trifft niemand mehr, wenn die Anwendung fertig ist. Für die Berliner Feuerwehr entstand ein Notfallhandbuch zur koordinierten Gefahrenabwehr, das im Einsatzfall ohne Vorlauf bereitstehen muss. Die Nutzung solcher Anwendungen fällt genau dann zusammen, wenn ohnehin alles gleichzeitig passiert.

Welche Verfügbarkeit muss Software für kritische Infrastrukturen erreichen?

Die ehrliche Antwort hängt nicht am Sektor, sondern an der Frage, was während der Ausfallzeit passiert. Ein Abrechnungssystem darf einen Arbeitstag stillstehen, ein Leitsystem nicht einmal eine Schicht. Software für kritische Infrastrukturen braucht deshalb keine pauschal hohe Verfügbarkeit, sondern eine begründete. Die üblichen Prozentwerte verdecken diesen Unterschied, weil sie klein aussehen und große Sprünge im Aufbau bedeuten. Die folgende Staffel übersetzt sie in das, was sie technisch und organisatorisch tatsächlich verlangen.

Redundanz, Failover und die Grenze der Automatisierung

Jede Stufe dieser Staffel kostet nicht nur Geld, sondern auch Verhalten. Ein automatischer Schwenk zwischen zwei Standorten setzt voraus, dass die Anwendung an beiden Orten denselben Datenstand hat, und dieser Gleichstand ist bei schreibintensiven Fachverfahren der eigentliche Engpass. Lässt er sich nicht sicher herstellen, bleibt der Schwenk eine Entscheidung von Menschen. Dann bestimmt die Erreichbarkeit dieser Menschen die tatsächliche Verfügbarkeit und nicht die Technik. Ein Schwenk, der nur auf dem Papier existiert, funktioniert im Ernstfall selten. Geübt gehört er mindestens einmal jährlich, und zwar mit dem Personal, das nachts tatsächlich Dienst hat. Eine Anwendung ist nie verfügbarer als die Organisation, die sie im Störfall bedient.

Was vor der Festlegung der Verfügbarkeitsklasse geklärt sein muss

Die Klasse gehört in die Anforderungsphase und nicht in die Vertragsverhandlung. Vier Fragen entscheiden über sie, und alle vier lassen sich beantworten, bevor eine Zeile Code entsteht.

• Welcher Schaden entsteht je Stunde Stillstand, und welche Stelle trägt ihn?
• Gibt es ein Ausweichverfahren auf Papier oder in einem Zweitsystem?
• Wie weit darf der Datenstand nach einer Wiederherstellung zurückliegen?
• Welche Rolle darf einen Schwenk auslösen, und ist sie nachts besetzt?

© KI-generiert (TenMedia)

Nachweisfähigkeit: was im Audit tatsächlich verlangt wird

Prüfungen scheitern selten an fehlender Sicherheit und oft an fehlenden Belegen. Für Betroffene ist dieser Unterschied schwer zu ertragen, weil eine gut gebaute Anwendung durchfallen kann, während eine mittelmäßige mit vollständiger Dokumentation besteht. Aus Sicht der prüfenden Stelle ist das folgerichtig, denn geprüft wird nicht der Zustand an einem Stichtag, sondern die Fähigkeit, ihn über Jahre nachzuweisen. Eine Anwendung ohne belastbare Historie kann heute sicher sein und morgen unbemerkt unsicher werden, ohne dass jemand den Übergang benennen könnte. Diese Fähigkeit entsteht während der Softwareentwicklung für KRITIS oder gar nicht.

Welche Nachweise über die Softwareentwicklung verlangt ein KRITIS-Audit?

Von allen KRITIS-Anforderungen an Software ist die Nachweisführung am leichtesten zu erfüllen, weil die Unterlagen bei ordentlicher Arbeit ohnehin entstehen. Der Aufwand liegt nicht im Erzeugen, sondern darin, sie über die gesamte Laufzeit einer Anwendung auffindbar zu halten. Sieben Artefakte decken den überwiegenden Teil der Fragen ab.

📋 Bedrohungsmodell mit Datum und Bezug zur geprüften Version
📋 Architekturdokumentation, die Zonen und Datenflüsse sichtbar macht
📋 Rollen- und Berechtigungskonzept mit Änderungshistorie
📋 Abhängigkeitsliste mit Herkunft, Version und Prüfstand
📋 Testberichte je Freigabe, nicht nur zum letzten Stand
📋 Freigabeprotokolle mit Person, Zeitpunkt und Prüfergebnis
📋 Nachweis der Umgebungstrennung samt Umgang mit Testdaten

Warum Nachweise nachträglich teuer werden

Ein Beleg, der zum Zeitpunkt der Entscheidung entsteht, kostet Minuten. Derselbe Beleg zwei Jahre später kostet Tage, weil zuerst rekonstruiert werden muss, wer was warum entschieden hat, und weil die beteiligten Personen oft nicht mehr im Projekt sind. Bei einer Anwendung mit zehn Jahren Laufzeit summiert sich diese Differenz zu einem eigenen Budgetposten. Hinzu kommt ein zweites Risiko. Eine nachträglich zusammengestellte Dokumentation beschreibt, was jemand für richtig hält, nicht zwingend das, was tatsächlich passiert ist. Fällt diese Abweichung in einer Prüfung auf, steht nicht mehr die einzelne Lücke zur Debatte, sondern die Glaubwürdigkeit der gesamten Unterlagen.

Die Nachweiskaskade in der Lieferkette

Am Ende jeder Lieferantenabfrage steht dieselbe Frage nach Artefakten aus der Entwicklung. Betreiber müssen belegen, dass ihre Dienstleister belegen können, und in Organisationen mit mehreren Standorten und zentraler Sicherheitsorganisation wird daraus ein eigener Prozess mit eigenem Personal. Die Prüfkosten des Auftraggebers entscheiden sich daran, an welcher Stelle diese Unterlagen entstehen. Ein Dienstleister, der sie erst auf Anfrage zusammenstellt, verlagert seinen eigenen Aufwand in das Prüffenster des Betreibers. Wer die Unterlagen dagegen laufend führt, liefert sie als Auszug statt als Projekt.

KRITIS-Software beschaffen und in den Betrieb übergeben

Beim Beschaffen von Software für kritische Infrastrukturen sind zu Beginn des Vergabeverfahrens die Weichen für die spätere Nachweisfähigkeit noch stellbar. Beschaffung entscheidet dann über deutlich mehr als den Preis. Sie legt fest, welche Seite im Prüfungsfall Unterlagen liefert, wie lange Sicherheitsupdates kommen und was geschieht, wenn ein Anbieter sein Produkt einstellt. Die letzte Frage wird am häufigsten übergangen und trägt das größte Risiko. Ein eingestelltes Produkt lässt sich weder patchen noch belegen, und der Wechsel fällt in einen Zeitpunkt, den nicht der Betreiber bestimmt. Diese Bindung ist messbar, das Raster dafür steht im Leitfaden zur digitalen Souveränität. Diese drei KRITIS-Anforderungen an Software lassen sich vor der Unterschrift klären, und dort kosten sie nichts.

Eignungsnachweise und Präqualifikation im Vergabeverfahren

Öffentliche Auftraggeber und Sozialversicherungsträger prüfen die Eignung eines Anbieters formal, bevor sie sein Angebot inhaltlich bewerten. Verlangt werden Zertifizierungen, Referenzen aus vergleichbaren Umgebungen und der Nachweis, dass die Abläufe hinter der Entwicklung dokumentiert sind. Entscheidend ist dabei der Geltungsbereich dieser Zertifikate. Eine Eintragung im Amtlichen Verzeichnis präqualifizierter Unternehmen nimmt einen Teil dieser Nachweise vorweg, sodass er nicht in jedem Verfahren neu erbracht werden muss. Für Vergabestellen verkürzt das die Prüfung, für Anbieter senkt es die Hürde zur Teilnahme.

Lässt sich bestehende Standardsoftware nachträglich KRITIS-tauglich machen?

Manchmal ja, und die Antwort hängt an vier Eigenschaften des Bestands. Fällt eine davon aus, hilft Nachrüsten nicht mehr weiter, weil sich ein fehlender Nachweis nicht rückwirkend erzeugen lässt.

• Herkunft: Ist für jede Komponente belegbar, woher sie stammt und in welcher Version sie läuft?
• Schnitt: Lassen sich Mandanten und Rollen trennen, ohne die Datenhaltung umzubauen?
• Abhängigkeiten: Werden die eingesetzten Bibliotheken vom Hersteller überhaupt noch gepflegt?
• Testbarkeit: Existiert eine Testabdeckung, die eine Änderung nachvollziehbar absichert?

Was der Vertrag über die Supportdauer regeln muss

Der Cyber Resilience Act verpflichtet Hersteller, während eines Supportzeitraums kostenlose Sicherheitsupdates bereitzustellen, und setzt dafür in der Regel fünf Jahre an. Fachanwendungen in Versorgungsbetrieben laufen deutlich länger, zehn bis fünfzehn Jahre sind keine Ausnahme. Die Differenz ist keine Rechtsfrage, sondern eine Beschaffungsentscheidung, und sie fällt außerhalb der eigentlichen Softwareentwicklung für KRITIS. Bleibt sie im Erstvertrag offen, taucht sie im sechsten Jahr als Verlängerungsverhandlung wieder auf, und dann verhandelt der Betreiber ohne Alternative. Die Supportdauer gehört deshalb in dieselbe Vertragsanlage wie der Meldeweg für Schwachstellen.

Individualsoftware für KRITIS-Betreiber mit TenMedia

Softwareentwicklung für KRITIS gehört bei TenMedia seit über 14 Jahren zum Geschäft, aus Berlin und für Auftraggeber in Behörden und bei Betreibern kritischer Infrastrukturen. Die beschriebene Reihenfolge aus Schutzbedarf, Zonenschnitt und Fachkonzept ist dabei keine Empfehlung an andere, sondern die eigene Arbeitsweise in der Softwareentwicklung für KRITIS.

Zertifizierungen und Nachweise

Die Zertifizierung nach ISO 27001 über den TÜV Süd umfasst Entwicklung und Wartung, nicht allein den Bürobetrieb. Für Auftraggeber ist dieser Geltungsbereich der entscheidende Punkt, weil er genau die Abläufe abdeckt, nach denen in einer Prüfung gefragt wird. Er umfasst damit auch Umgebungstrennung, Freigabewege und den Umgang mit Abhängigkeiten. Hinzu kommen die Zertifizierung nach ISO 9001 für das Qualitätsmanagement und die bereits genannte Eintragung im Amtlichen Verzeichnis präqualifizierter Unternehmen.

Softwareentwicklung für KRITIS: Leistungen im Überblick

Die Leistungen der Softwareentwicklung für KRITIS decken den gesamten Lebenszyklus einer Anwendung ab, von der Anforderungsaufnahme bis zum Betrieb nach dem Go-live. Der laufende Teil, also Pflege, Überwachung und Reaktion im Störfall, ist im Softwarebetrieb und in der Wartung im Einzelnen beschrieben.

• Anforderungsaufnahme mit Schutzbedarfsermittlung und Zonenschnitt
• Entwicklung nach dokumentiertem Prozess mit Prüfpunkten in der Auslieferungskette
• Ablösung und Migration von Altverfahren ohne Versorgungslücke
• Betrieb, Wartung und Bereitschaft nach vereinbarten Reaktionszeiten
• Aufbereitung der Nachweise für Prüfungen und Vergabeverfahren

Wo ein Vorhaben in dieser Kette einsetzt, ist offen. Softwareentwicklung für KRITIS beginnt in vielen Fällen nicht mit einem Neubau, sondern mit der Bestandsaufnahme einer Anwendung in kritischer Infrastruktur, die seit Jahren zuverlässig läuft und über die sich trotzdem nichts belegen lässt.