Reifegradmodell

Ein Reifegradmodell (engl. Maturity Model) ist ein strukturiertes Rahmenwerk, mit dem Organisationen den aktuellen Zustand ihrer Prozesse anhand vordefinierter Stufen bewerten. Statt einer reinen Ja/Nein-Frage ("haben wir einen Prozess?") beschreibt es, wie ausgereift, wiederholbar und gesteuert ein Prozess tatsächlich ist. Im Compliance- und Informationssicherheitsumfeld dient ein Reifegradmodell vor allem dazu, eine ehrliche Standortbestimmung vorzunehmen, Lücken sichtbar zu machen und eine priorisierte Roadmap zur Verbesserung abzuleiten. Ursprünglich aus der Software- und Prozessverbesserung stammend, werden Reifegradmodelle heute branchenübergreifend eingesetzt — von der IT-Sicherheit über das Projektmanagement und die Qualitätssicherung bis hin zur Datenschutz- und GRC-Organisation. Der gemeinsame Nenner ist immer derselbe: Reife wird nicht als Zustand, sondern als Entwicklungsstufe verstanden, die man bewusst und schrittweise erhöhen kann.

Die meisten Reifegradmodelle arbeiten mit fünf bis sechs Stufen. Ein typisches GRC-Modell unterscheidet:

Stufe 0 — Nicht vorhanden / Reaktiv: Es gibt keinen definierten Prozess; gehandelt wird nur anlassbezogen, etwa nach einem Vorfall oder kurz vor einem Audit.

Stufe 1 — Initial / Ad hoc: Erste Aktivitäten existieren, sind aber personenabhängig, nicht dokumentiert und nicht wiederholbar. Das Ergebnis hängt davon ab, wer die Aufgabe übernimmt.

Stufe 2 — Wiederholbar / Strukturiert: Prozesse sind dokumentiert, es gibt definierte Verantwortlichkeiten und SLAs. Die Aktivitäten werden in regelmäßigen Abständen durchgeführt, jedoch noch überwiegend manuell.

Stufe 3 — Definiert / Standardisiert: Prozesse sind organisationsweit standardisiert, in Tools abgebildet und in den Regelbetrieb integriert. Dies ist für regulierte Unternehmen (NIS2, DORA) heute der Mindeststandard.

Stufe 4 — Gesteuert / Risikobasiert: Prozesse werden anhand von Kennzahlen (KPIs) gemessen und gesteuert; Entscheidungen erfolgen risikobasiert und datengestützt.

Stufe 5 — Optimierend / Prädiktiv: Kontinuierliche Verbesserung ist institutionalisiert; Automatisierung und KI-gestützte Triage ermöglichen vorausschauendes Handeln. Diese Stufe erreichen in Deutschland meist nur Konzerne mit reifen SOCs, Banken oder Telekommunikationsanbieter.

Reifegradmodell-Beispiele und ihre Abgrenzung: Es gibt mehrere etablierte Modelle, die je nach Zielsetzung unterschiedliche Schwerpunkte setzen.

CMMI (Capability Maturity Model Integration) stammt ursprünglich aus der Softwareentwicklung und Prozessverbesserung. Es ist generisch und prozessorientiert und definiert die klassischen fünf Stufen (Initial, Managed, Defined, Quantitatively Managed, Optimizing). CMMI eignet sich gut, um die grundsätzliche Prozessdisziplin einer Organisation zu beschreiben, sagt aber für sich genommen nichts über konkrete Sicherheitskontrollen aus.

ISO 27001 ist kein Reifegradmodell im engeren Sinne, sondern ein Zertifizierungsstandard mit konkreten Anforderungen (ISMS-Hauptteil und 93 Annex-A-Controls in der Version 2022). ISO 27001 fragt primär: "Ist die Control vorhanden und wirksam?" Der zugehörige Reifegedanke steckt im PDCA-Zyklus (Plan-Do-Check-Act) und in der geforderten kontinuierlichen Verbesserung. In der Praxis kombinieren viele Organisationen ISO 27001 mit einem Reifegradraster, um nicht nur "erfüllt/nicht erfüllt", sondern auch die Qualität der Umsetzung zu bewerten.

NIST CSF (Cybersecurity Framework) verwendet sogenannte Implementation Tiers (Tier 1 Partial, Tier 2 Risk Informed, Tier 3 Repeatable, Tier 4 Adaptive). Diese Tiers ähneln Reifegradstufen, beschreiben jedoch ausdrücklich, wie stark das Risikomanagement in Entscheidungen und Kultur verankert ist — weniger die formale Prozessdokumentation. NIST CSF ist daher besonders nützlich, um die risikobasierte Steuerung (Stufe 4) zu beschreiben.

Kurz gesagt: CMMI bewertet Prozessdisziplin generisch, ISO 27001 prüft konkrete Sicherheitskontrollen gegen einen Standard, und NIST CSF beschreibt die Reife des Risikomanagements. Reife Organisationen nutzen die drei nicht alternativ, sondern komplementär: ISO 27001 als Kontroll-Baseline, NIST CSF zur risikobasierten Priorisierung und ein CMMI-ähnliches Stufenraster für die interne Standortbestimmung.

Worked Example — Reifegradbewertung im GRC-Kontext: Ein mittelständischer Finanzdienstleister bewertet sein Schwachstellenmanagement. Heute werden Scans nur jährlich vor dem Audit durchgeführt, die Ergebnisse landen in einer Excel-Liste, SLAs gibt es nicht — das entspricht Stufe 1. Die Gap-Analyse zeigt: Für die DORA-Konformität wird mindestens Stufe 3 benötigt. Die abgeleitete Roadmap sieht vor, zunächst wöchentliche authentifizierte Scans und ein Ticketing-Tool einzuführen (Weg zu Stufe 2-3), anschließend KPIs wie MTTR und Asset-Coverage zu etablieren (Stufe 4). Das Reifegradmodell liefert hier sowohl die ehrliche Ist-Bewertung als auch die priorisierte Verbesserungsreihenfolge und macht den Fortschritt gegenüber dem Management messbar. Im nächsten Reporting kann die Geschäftsleitung schwarz auf weiß sehen, dass das Schwachstellenmanagement von Stufe 1 auf Stufe 3 angehoben wurde — und welcher Restaufwand bis zur risikobasierten Steuerung auf Stufe 4 noch offen ist. Genau diese Übersetzung von technischem Fortschritt in eine für das Management verständliche Stufenlogik ist der eigentliche Mehrwert eines Reifegradmodells.

Reifegradmodelle sind damit ein zentrales Werkzeug der Compliance-Steuerung: Sie übersetzen abstrakte regulatorische Erwartungen in eine nachvollziehbare Entwicklungslinie und helfen, Investitionen dort zu konzentrieren, wo der größte Reifegradsprung mit dem geringsten Aufwand erreichbar ist.

So führen Sie eine Reifegradbewertung durch: Eine belastbare Bewertung folgt typischerweise fünf Schritten. Erstens wird der Scope festgelegt — welche Prozesse oder Domänen (z. B. Schwachstellenmanagement, Incident Response, Drittparteienrisiko) sollen bewertet werden? Zweitens wird ein Referenzmodell ausgewählt (CMMI-ähnliches Stufenraster, ISO-27001-Controls oder NIST-CSF-Tiers). Drittens erfolgt die Datenerhebung durch Interviews, Dokumentenprüfung und Nachweise (Evidence), nicht durch Selbsteinschätzung allein — denn Selbstauskünfte überschätzen die Reife systematisch. Viertens wird je Prozess eine Ist-Stufe vergeben und gegen die regulatorisch oder strategisch geforderte Soll-Stufe gestellt (Gap-Analyse). Fünftens entsteht daraus eine priorisierte Roadmap mit konkreten Maßnahmen, Verantwortlichen und Zeithorizonten.

Reifegrad und Zielstufe: Nicht jede Organisation muss Stufe 5 anstreben. Die sinnvolle Zielstufe ergibt sich aus Regulierung, Risikoappetit und Branche. Für ein NIS2- oder DORA-pflichtiges Unternehmen ist Stufe 3 (standardisiert, in den Regelbetrieb integriert) in der Regel der Mindeststandard; Stufe 4 (KPI-gesteuert, risikobasiert) ist das realistische Ziel für eine reife Sicherheitsorganisation. Eine durchgängige Stufe 5 über alle Domänen hinweg ist teuer und nur dort wirtschaftlich, wo das Risiko es rechtfertigt. Wichtig ist außerdem, dass die Reifegrade über die Zeit konsistent gemessen werden, damit Fortschritt und Rückschritt erkennbar bleiben.

Häufige Fehler bei Reifegradmodellen: Erstens die Verwechslung von Reifegrad und Compliance — eine erfüllte ISO-27001-Control kann unreif umgesetzt sein (vorhanden, aber nicht gesteuert). Zweitens die Bewertung per Selbsteinschätzung ohne Nachweise, was zu geschönten Ergebnissen führt. Drittens das Streben nach der höchsten Stufe als Selbstzweck statt nach der risikoangemessenen Stufe. Viertens eine einmalige Bewertung ohne Wiederholung — ein Reifegradmodell entfaltet seinen Wert erst als wiederkehrendes Steuerungsinstrument, etwa im jährlichen Management-Review.

In der Praxis bilden viele Organisationen die Reifegradbewertung direkt auf ihre regulatorischen Anforderungen ab: Die für NIS2 (Art. 21), DORA und ISO 27001:2022 geforderten Maßnahmen werden je Domäne einer Reifegradstufe zugeordnet, sodass das Management auf einen Blick erkennt, wo die Organisation die regulatorische Mindestreife bereits erreicht und wo noch Handlungsbedarf besteht. Damit wird das Reifegradmodell zur gemeinsamen Sprache zwischen IT-Sicherheit, interner Revision und Geschäftsleitung.