Kritikalitätsanalyse-Software: Methodik für KRITIS-Vergabe und Investitionen

© lchumpitaz

Was ist eine Kritikalitätsanalyse-Software?

Eine Kritikalitätsanalyse von Software bewertet, wie stark der Geschäftsbetrieb von einer Anwendung abhängt. Sie ordnet Anwendungen in Kritikalitätsklassen ein und liefert eine priorisierte Liste, die Investitionen, Wartung und Härtungsmaßnahmen lenkt. Wie dringend dieser Blick gebraucht wird, zeigt der BSI-Lagebericht 2025: rund 48 Prozent der KRITIS-Betreiber verfügen nicht über ein wirksames Angriffserkennungssystem. Parallel zählt das BSI 950 Ransomware-Vorfälle innerhalb eines Jahres.

Ohne strukturierte Bewertung bleibt im Ernstfall offen, welcher Ausfall den Betrieb wirklich treffen würde. Eine Kritikalitätsanalyse schließt diese Lücke – sie ersetzt Bauchgefühl durch nachvollziehbare Kriterien.

Wodurch unterscheidet sich Kritikalitätsanalyse von der Schutzbedarfsfeststellung?

Die Schutzbedarfsfeststellung definiert das Mindestschutzniveau einer Anwendung – sie ist Pflicht im IT-Grundschutz. Eine Kritikalitätsanalyse für Software setzt davor an: sie ordnet, welche Anwendung überhaupt den Aufwand lohnt.

Eine geschäftskritische Software erhält dann ein höheres Schutzlevel, eine nachrangige Anwendung wird mit weniger Maßnahmen ausgerüstet. Kritikalitätsanalyse liefert die wirtschaftliche Sortierung, Schutzbedarfsfeststellung baut technisch um. In der Praxis fließt die Analyse der Software-Kritikalität direkt in die Roadmap der Softwareentwicklung für KRITIS ein.

Bewertungsdimensionen der Anwendungskritikalität

Vier Bewertungsdimensionen prägen die Anwendungskritikalität in regulierten Branchen. Sie bilden den Rahmen jeder Software-Kritikalitätsanalyse:

• Geschäftsfunktion: Welcher Wertschöpfungsschritt hängt an der Anwendung?
• Versorgungsrelevanz: Wirkt ein Ausfall auf Bürger, Patienten oder Lieferketten?
• Datensensitivität: Welche Schutzziele dominieren konkret?
• Regulatorische Pflicht: Greifen NIS-2, DORA, B3S-Vorgaben oder Branchenvorgaben?
• Wiederherstellbarkeit: Wie lange darf die Anwendung höchstens ausfallen?
• Lieferantenabhängigkeit: Bestehen Single-Source-Risiken?

Aus diesem Mehrebenen-Modell entsteht eine differenzierte Klassifikation jenseits binärer Logik. Die Klassen steuern später Vertragsdetails, etwa im EVB-IT-Vertrag, und bestimmen Wartungstiefe sowie Reaktionszeiten. Eignungs- und Zuschlagskriterien lassen sich daraus direkt ableiten. Auch die Investitionshöhe wird an der Klasse ausgerichtet. Erst auf dieser Grundlage entscheiden Sicherheitsteams sinnvoll, wo gezielte Anwendungshärtung den höchsten Mehrwert liefert.

Methoden zur Kritikalitätsbewertung von Software

Eine professionelle Kritikalitätsbewertung von Software stützt sich auf drei methodische Bausteine: FMECA als quantitatives Verfahren, Application Portfolio Management als strategischer Rahmen und die Kritikalitätsmatrix als Visualisierung.

Clevere KRITIS-Organisationen kombinieren beides – qualitativ für die Breite, quantitativ für die Top-Klasse. Eine Software-Kritikalitätsanalyse wird damit auf das Datenmaterial maßgeschneidert. Unser Beitrag IT-Wartung für KRITIS zeigt, wie aus der Kritikalitätsbewertung konkrete Wartungs-Roadmaps entstehen. Auch Patching-Frequenz und Audit-Tiefe leiten sich aus der Klasse ab. Reaktionszeiten skalieren mit dem Risiko. So wird klar, wo gezieltes Schwachstellenmanagement KRITIS den größten Hebel hat.

Analyse der Software-Kritikalität nach FMECA

Software-FMECA bewertet jede Anwendung anhand der Risikoprioritätszahl aus Bedeutung, Auftretenswahrscheinlichkeit und Entdeckungswahrscheinlichkeit. Die Methode stammt aus der Anlagenwartung und wurde an IT-Systeme angepasst – sie liefert vergleichbare Werte. Eine systematische Analyse der Software-Kritikalität nach FMECA durchläuft folgende Schritte:

• Anwendungen und Schnittstellen vollständig erfassen
• Mögliche Fehlerarten je Anwendung katalogisieren
• Auswirkungen auf Geschäftsprozess und Versorgungsauftrag bewerten
• Auftretens- und Entdeckungswahrscheinlichkeit bestimmen
• Risikoprioritätszahl berechnen und Kritikalitätsklassen ableiten
• Maßnahmen priorisieren und Verantwortliche zuordnen

Die Tabelle wirkt aufwendig, zahlt sich aber aus: jede Bewertung lässt sich auditfest begründen und skaliert vom Einzelmodul bis zum Gesamtportfolio. Eine Kritikalitätsanalyse einer Anwendung als Beispiel läuft pragmatisch in zwei Workshops.

Application Portfolio und Kritikalitätsmatrix

Wer ein größeres Anwendungsportfolio bewerten muss, kombiniert Application Portfolio Bewertung mit der Kritikalitätsmatrix. Beide Methoden ergänzen FMECA um die strategische und kommunikative Sicht. Die Kombination liefert Daten für Vorstand, IT-Leitung und Compliance gleichermaßen – jede Gruppe findet ihre Sprache. Auch eine Bewertung der Software-Kritikalität jenseits einzelner Module wird damit überschaubar.

Application Portfolio Bewertung im Überblick

Application Portfolio Management ergänzt FMECA strategisch. Application Portfolio Bewertung fragt: passt die Anwendung zur Geschäftsstrategie, ist sie ablösereif, lebt sie wirtschaftlich? Vier Dimensionen prägen die Antwort: Geschäftswert, IT-Fit, Lebenszyklus und Kosten. Aus diesen Bewertungen entstehen Wartungs-Roadmaps und Ablöse-Empfehlungen. Liegen Anwendungen im roten Bereich, taugen Wartungspflaster nicht. Auch schrittweise Modernisierung wird oft zu teuer. Eine Kritikalitätsanalyse-Software erkennt diese Schwelle früh und führt zur geplanten Software-Ablösung in KRITIS.

Kritikalitätsmatrix in der Praxis

Die Kritikalitätsmatrix bringt qualitative und quantitative Bewertungen in eine zweidimensionale Übersicht. Auf einer Achse läuft die Auswirkung auf den Geschäftsbetrieb, auf der anderen die Eintrittswahrscheinlichkeit. Anwendungen verteilen sich in Quadranten – grün, gelb, orange, rot. Die Visualisierung dient als Diskussionsgrundlage in Lenkungskreisen, wo Vorstand, IT-Leitung und Compliance priorisieren. Praxis-Erfahrung zeigt: zwei bis drei Workshops genügen, um eine erste belastbare Matrix zu erzeugen. Damit liegt die Kritikalitätsbewertung von Software pragmatisch und auditfest vor.

Kritikalitätsanalyse von Software für Vergabe und Beschaffung

Bei Software-Vergaben in der öffentlichen Hand und in regulierten Branchen ist die Kritikalitätsklasse einer Anwendung längst keine Bürokratie-Pflicht mehr, sondern Eingangsgröße der Leistungsbeschreibung. Wer eine Kritikalitätsanalyse von Software professionell durchführt, schafft die Grundlage für klare Eignungs- und Zuschlagskriterien, belastbare SLAs und tragfähige Budgetansätze. In der Praxis fließt die Kritikalitätsklasse direkt in den Pflegerahmen ein – sie bestimmt, ob Pflege S, Pflege L oder ein individueller Rahmen vereinbart wird. Damit verändert sich das Vergabe-Risiko spürbar: nachrangige Software wird preisorientiert beschafft, geschäftskritische Software erhält längere Vergabeverfahren mit Sicherheits-Nachweisen.

Welche Rolle spielt die Kritikalitätsanalyse bei Software-Ausschreibungen der öffentlichen Hand?

Bei öffentlichen Software-Ausschreibungen liefert die Kritikalitätsanalyse die Begründung für jeden geforderten Sicherheits-Baustein im Lastenheft. Vergabestellen können nur das fordern, was sie objektiv begründen können – sonst droht die Rüge.

Eine dokumentierte Kritikalitätsklasse ist deshalb der saubere Weg, um Härtungs-, Wartungs- und Reaktionspflichten in Vergabeverfahren rechtssicher zu verankern. Konkret heißt das: bei einer geschäftskritischen Software werden andere SLAs, Verfügbarkeitsklassen und Reaktionszeiten ausgeschrieben als bei einer einfachen Fachanwendung. Auch die Eignungsprüfung der Bieter wird differenziert – Referenzen mit ähnlicher Kritikalitätsklasse zählen mehr als generische Erfahrung. Damit wird die Analyse der Software-Kritikalität zum stillen Hebel jeder Vergabeentscheidung.

Drittparteienrisiko und Lieferkette

Die Kritikalitätsanalyse-Software endet nicht an der Unternehmensgrenze. Dienstleister, Cloud-Anbieter und Wartungspartner werden mit der Kritikalität der Anwendung bewertet, die sie betreuen. NIS-2 und DORA verlangen Drittparteien-Standards auf gleichem Niveau wie der Betreiber. Bei Drittparteien zählen besonders:

• Welche Anwendungen verarbeitet der Dienstleister direkt oder indirekt?
• Welche Schutzziele sind bei Auftragsverarbeitung berührt?
• Bestehen Sub-Lieferanten oder Konzentrationsrisiken?
• Wie reagiert der Anbieter im Notfall mit welcher Reaktionszeit?
• Welche Audit-Rechte sind vertraglich verankert?

Wer diese Fragen vor Beauftragung beantwortet, vermeidet Audit-Überraschungen und reduziert Konzentrationsrisiken im Lieferanten-Stack. Eine Kritikalitätsbewertung von Software macht diese Risiken systematisch sichtbar.

Trigger, Kosten und externe Beauftragung

Eine Kritikalitätsanalyse rentiert sich bei Investitions- oder Vergabeentscheidungen, die mehr als Bauchgefühl rechtfertigen müssen. Klassische Auslöser sind Modernisierungsprojekte, neue regulatorische Pflichten, anstehende Audits, Reorganisationen oder Mergers. Wer eine Kritikalitätsbewertung Software beauftragen will, sollte den Anlass klären – sonst droht eine Schubladen-Studie ohne Wirkung. Wer hingegen kurz vor einer Vergabe oder Migration analysiert, gewinnt unmittelbar nutzbare Entscheidungskriterien. Auch Kritikalitätsanalyse-Software-Kosten lassen sich so frühzeitig kalibrieren. Die Untersuchung der Software-Kritikalität wird damit zur Vorstufe jeder größeren IT-Investition.

Wann sollte eine Kritikalitätsanalyse für ein Software-Portfolio durchgeführt werden?

Sieben typische Auslöser haben gemeinsam, dass am Ende eine konkrete Entscheidung steht – Geld, Vertrag oder Architektur:

• Bevorstehende Software-Ausschreibung oder Vergabe
• Geplante Cloud- oder Plattform-Migration
• Neue regulatorische Pflicht (NIS-2, DORA, Branchen-Standards)
• Vorbereitung eines BSI- oder Branchen-Audits
• Reorganisation oder Mergers and Acquisitions
• Strategischer Wechsel des IT-Dienstleisters

Erfahrene Häuser planen die Analyse als Vorprojekt – drei bis sechs Monate vor dem Cutover. Damit fließt das Ergebnis direkt in Lastenheft und Risikobewertung. Die Kritikalitätsanalyse-Software-Kosten orientieren sich an Portfolio-Tiefe und Methodik – qualitative Workshops liegen im niedrigen fünfstelligen Bereich, quantitative FMECA-Bewertungen können sechsstellig werden.

Externe Analyse der Software-Kritikalität beauftragen

Eine Software-Kritikalitätsanalyse sollte beim externen Dienstleister beauftragt werden, wenn es an Methoden-Erfahrung mangelt oder Bedarf an einem unabhängigem Audit-Blick besteht. Geliefert werden eine Kritikalitätsmatrix, eine FMECA-Tabelle und eine Kritikalitätsanalyse mitsamt Vorlage. Auf Wunsch lässt sich daraus eine Kritikalitätsanalyse für Vergabeverfahren erstellen, die Vergabestellen direkt im Lastenheft nutzen.

Wer eine Kritikalitätsanalyse durchführen lassen möchte, startet mit einem strukturierten Vorgespräch, in dem Datenstand und Audit-Bezug abgesteckt werden. Eine Kritikalitätsbewertung von Software zu beauftragen heißt nicht, ein Werkzeug zu mieten – die Software-Kritikalitätsbewertung wird zur Entscheidungsgrundlage für Audit und Vergabe.