IT Risikomanagement Tool gesucht? Warum Governance Software nicht gleich technische Risikoanalyse ist

Was ein GRC Tool typischerweise leistet

GRC steht für Governance, Risk & Compliance. Klassische GRC-Tools sind darauf ausgelegt, Organisationen auf Management- und Prozessebene zu unterstützen, „Compliance“ herzustellen. Auf höchster Management-Ebene adressiert man Governance (Steuerung & Verantwortlichkeiten), Risikomanagement (Risiken erkennen, bewerten, steuern), Compliance (Einhaltung von gesetzlichen Anforderungen und Standards). Es ist das Management-Werkzeug, um sicherzustellen, dass aktuelle und neue Anforderungen im Unternehmen adressiert werden.

Themen können sein:

• Richtlinien, Kontrollen und Policies zentral verwalten
• Compliance-Anforderungen abbilden (ISO 27001, IT-Grundschutz, B3S Anforderungen, NIS2 etc.)
• Audits, Maßnahmen und Workflows koordinieren
• Risiken auf Organisations- und Prozessebene bewerten
• Reporting für Management, Revision und Zertifizierungen liefern

Kurz gesagt: GRC-Tools strukturieren Organisationen.

Sie sind hervorragend geeignet für:

• ISMS und Compliance-Management: Verwaltung von Auditberichten, Risikoregistern, Compliance-Katalogen wie ISO27001 und Grundschutz. Es kann also als Betriebsplattform für das ISMS betrachtet werden.
• Konzernweite Steuerung und Mandantenmodelle
• Auditvorbereitung und Reporting
• Governance-Fragen auf Unternehmens- und Prozessebene

Wo klassische GRC-Tools an Grenzen stoßen

Keine Systemmodellierung
GRC-Tools arbeiten in der Regel mit Risiko-Registern, Kontrollkatalogen und Maßnahmenlisten. Sie dokumentieren Risiken auf organisatorischer Ebene, modellieren jedoch keine technischen Systeme. Eine Abbildung von Komponenten, Datenflüssen oder Abhängigkeiten innerhalb eines konkreten Produkts oder einer OT-Architektur findet meist nicht statt.

Keine Abbildung der realen Architektur
In vielen GRC-Systemen existieren Risiken losgelöst von der tatsächlichen Systemstruktur. Die reale Architektur (also interne Module, Schnittstellen, Cloud-Anbindungen, externe Services oder Drittanbieter-Komponenten) wird nicht als technisches Gesamtmodell erfasst. Dadurch fehlt die direkte Verbindung zwischen Risiko und konkretem Systemelement.

Keine Bewertung der Erreichbarkeit und Ausnutzbarkeit von Schwachstellen
GRC-Tools erfassen häufig Schwachstellen als abstrakte Risiken oder Compliance-Feststellungen. Ob eine Schwachstelle im konkreten System tatsächlich erreichbar und unter realistischen Bedingungen ausnutzbar ist, wird in der Regel nicht technisch bewertet. Die Risikobewertung bleibt damit häufig generisch oder katalogbasiert.

Kein Kontextbezug zur typischen Betriebsumgebung des Produkts
Regulatorische Anforderungen wie der Cyber Resilience Act verlangen die Berücksichtigung der erwartbaren Betriebsumgebung. Klassische GRC-Ansätze fokussieren primär auf Unternehmens- oder Governance-Strukturen. Der konkrete Einsatzkontext eines Produkts – etwa Netzwerktopologie, Integrationsszenarien oder OT-Abhängigkeiten – wird meist nicht systematisch in die Risikoanalyse integriert.

Und was ist SECIRA?

SECIRA ist kein GRC-Tool. SECIRA ist eine Plattform, in der ich eine technische Risikoanalyse kontinuierlich durchführen kann, die Ergebnisse liefert, die dann im ISMS bzw. GRC-Lösungen bearbeitet werden: am Produkt, System und der realen Angriffsfläche.

SECIRA wurde für Unternehmen entwickelt, die:

• Komplexe Infrastrukturen betreiben und blinde Flecken auflösen wollen
• Kritische Infrastrukturen mit einem Systemmix betreiben, sodass sich unterschiedliche Bereiche unterschiedlich „verteidigen“ können, und dennoch eine konsistente, nachvollziehbare Sicherheitsbetrachtung über alle Bereiche hinweg benötigen.
• Produkte mit digitalen Elementen entwickeln, weiterentwickeln und über Jahre sicher pflegen
• in Software, Embedded, OT nahen Systemen oder Cloud Backends reale Angriffsflächen verantworten
• Risikoanalysen, Bedrohungsmodelle und Schwachstellen so aufbauen wollen, dass sie technisch nachvollziehbar sind und über den gesamten Lebenszyklus aktuell bleiben, zum Beispiel im Kontext von CRA oder IEC 62443

Der Fokus liegt nicht auf Policies, sondern auf Fragen wie:

Welche Schwachstellen sind erreichbar und ausnutzbar?
Wie verändern sich Risiken über den Produktlebenszyklus?
Welche Bedrohungen sind technisch realistisch und relevant?
Welche Maßnahmen haben den größten Effekt auf die tatsächliche Sicherheit?

Wann ein GRC Tool sinnvoll ist:

• Sie primär Organisations- und Compliance-Themen managen
• Audits, Policies und Kontrollen im Fokus stehen
• Risiken eher abstrakt oder prozessorientiert bewertet werden
• Sie ein zentrales Management- und Reporting-Werkzeug suchen

Wann SECIRA notwendig wird:

• Sie Produkte mit digitalen Elementen entwickeln oder betreiben
• CRA, IEC 62443 oder produktspezifische Sicherheitsnachweise relevant sind
• Sie Risiken technisch verstehen und priorisieren müssen
• Security-Entscheidungen nachvollziehbar begründet werden sollen
• Risiken über viele Jahre gepflegt und aktualisiert werden müssen
  

Beides existiert nebeneinander: GRC für Governance und Organisation, SECIRA für die technische Tiefe.