Bert Kondruß, 31.08.2026
Auf einen Blick

GRC-Tools DACH

Der deutsche und DACH-Markt für GRC-Software umfasst internationale Enterprise-Plattformen wie ServiceNow, IBM OpenPages, Archer und MetricStream sowie regionale Anbieter wie ADOGRC, CRISAM, R2C, GRASP GRC und Fecton GRC. Hinzu kommen GRC-Tools mit starkem Schwerpunkt auf ISMS und BSI IT-Grundschutz wie HiScout, verinice oder TTS trax. Dabei befindet sich der Markt in einem Wandel von dokumentierender GRC-Software hin zu stärker automatisierten und kontinuierlich steuernden Plattformen.
Welches GRC-Tool geeignet ist, hängt vor allem von Unternehmensgröße, GRC-Scope, regulatorischen Anforderungen und Integrationsbedarf
Aber Achtung: Bei der Auswahl zählt nicht nur der heutige Funktionsumfang. Gerade durch AI wird Fit for Direction entscheidend: Passt die Plattform auch zu den Entwicklungen, die in den nächsten Jahren zu erwarten sind?

1 Tool-Auswahl in der DACH-Region

1.1 Ein vielfältiger und unübersichtlicher Markt

Wer eine GRC-Plattform sucht, trifft in der DACH-Region auf einen vielfältigen und schwer überschaubaren Markt: internationale Enterprise-Plattformen, regionale GRC-Spezialisten sowie zahlreiche Lösungen, die aus ISMS, BSI IT-Grundschutz oder Compliance heraus entstanden sind. Die KonBriefing Market Map 2026 hilft, diese Landschaft einzuordnen, relevante Anbieter und Zielgruppen zu verstehen und die wichtigsten Entwicklungslinien des Marktes zu erkennen. Vor allem zeigt sie, worauf Unternehmen bei der Auswahl achten sollten, damit die gewählte Plattform nicht nur heute passt, sondern auch morgen und übermorgen noch ausreichende Optionen, Integrationsfähigkeit und strategische Handlungsfreiheit bietet.

1.2 Welches ist das beste GRC-Tool?

Der Begriff GRC-Plattform suggeriert einen relativ einheitlichen Markt. Tatsächlich unterscheiden sich die Produkte jedoch erheblich. Eine Plattform kann aus dem klassischen Enterprise Risk Management stammen, eine andere aus Informationssicherheit, eine dritte aus Compliance. Einige Produkte wurden für internationale Konzerne mit komplexen GRC-Organisationen entwickelt. Andere richten sich an mittelständische Unternehmen, die zunächst ein ISMS aufbauen und später weitere Managementsysteme ergänzen möchten.
Deshalb:
 
Es gibt weiterhin nicht die eine beste GRC-Software.
Entscheidend ist:
 
Welche Plattform passt zur eigenen Organisation - heute, aber auch zu ihrer geplanten Entwicklung in den nächsten Jahren?
Das verändert auch die Vorgehensweise bei der Tool-Auswahl. Eine Feature-Liste bleibt wichtig. Sie sollte aber nicht isoliert betrachtet werden. Funktionen müssen mit Zielmarkt, Architektur, Integrationsfähigkeit, Datenmodell, Betriebsmodell und strategischer Entwicklungsrichtung des Produkts zusammengebracht werden.
Für Ihre Tool-Auswahl: Definieren Sie vor einer Ausschreibung nicht nur den heutigen Scope. Beschreiben Sie zusätzlich, welche GRC-Disziplinen, Organisationseinheiten und regulatorischen Anforderungen in den nächsten drei bis fünf Jahren hinzukommen könnten. Diese Perspektive gehört bereits in RFI und RFP.

1.3 Was ist GRC-Software? Welche Tools berücksichtigt diese Market Map?

GRC-Plattformen unterstützen Unternehmen dabei, mehrere Disziplinen der Governance, des Risikomanagements und der Compliance auf einer gemeinsamen technologischen Grundlage abzubilden. Typische Anwendungsbereiche sind:
  • Enterprise Risk Management
  • Internes Kontrollsystem
  • Compliance Management
  • Audit Management
  • Informationssicherheitsmanagement
  • Business Continuity Management
  • Datenschutz
  • Third-Party Risk Management
  • Operational Resilience
Für diese Market Map werden Produkte berücksichtigt, die mehrere dieser Disziplinen abdecken oder eine Plattform bereitstellen, auf der unterschiedliche GRC-Anwendungsfälle gemeinsame Daten, Objekte und Workflows nutzen können. Reine Speziallösungen für einzelne Aufgaben wie Hinweisgebersysteme oder isoliertes Policy Management werden grundsätzlich nicht berücksichtigt.
Dabei sind die Grenzen bewusst nicht zu eng gezogen. Ein Produkt, das ursprünglich als ISMS-Lösung entstanden ist, kann sich inzwischen zu einer breiteren GRC-Plattform entwickelt haben. Umgekehrt kann eine Enterprise-GRC-Plattform heute umfangreiche Cyber-, Resilience- oder AI-Governance-Funktionen besitzen.
Für Ihre Software-Ausschreibung: Lassen Sie sich nicht zu stark von Produktkategorien und Modulnamen leiten. Fragen Sie Anbieter stattdessen, welche Daten tatsächlich gemeinsam genutzt werden. Wird beispielsweise ein Geschäftsprozess einmal angelegt und anschließend von ISMS, BCM, Datenschutz und Risikomanagement verwendet - oder existiert er in mehreren Modulen mehrfach?

1.4 Features sind wichtig - aber nicht alle Features sind gleich wichtig

Ein strukturierter Kriterienkatalog bleibt ein wesentlicher Bestandteil jeder Tool-Auswahl. Er erlaubt es, fachliche Anforderungen zu präzisieren und Produkte systematisch miteinander zu vergleichen.
Problematisch wird eine Feature-Matrix erst dann, wenn sie zur alleinigen Entscheidungsgrundlage wird. "Risikomanagement: Ja" kann bei zwei Produkten völlig unterschiedliche Fähigkeiten bedeuten. Das Gleiche gilt für Begriffe wie Workflow, AI Governance, Continuous Monitoring oder Third-Party Risk. Deshalb sollten Anforderungen möglichst als konkrete Fähigkeiten oder Use Cases formuliert werden.
 
Schwächer: Das System unterstützt Risikomanagement.
 
Besser: Risiken müssen mit Unternehmenszielen, Geschäftsprozessen, Assets, Kontrollen, Maßnahmen und externen Ereignissen verknüpft werden können.
Noch besser ist es, kritische Anforderungen im PoC tatsächlich vorführen zu lassen.
Für Ihre Tool-Auswahl: Lassen Sie sich in einem PoC nicht nur vorbereitete Herstellerszenarien zeigen. Geben Sie dem Anbieter einen realen Prozess, einige typische Daten und eine konkrete Änderung vor. Beobachten Sie, wie schnell diese ohne Herstellerentwicklung umgesetzt werden kann.

2 GRC-Software in Deutschland, der Schweiz und in Österreich

2.1 Vier Marktsegmente im Überblick

2.1.1 Internationale Enterprise-GRC-Plattformen

Im oberen Marktsegment stehen internationale Plattformen. Sie adressieren typischerweise große und komplexe Organisationen mit mehreren GRC-Funktionen, umfangreichen Integrationsanforderungen, internationalen Strukturen und hohen Anforderungen an Konfigurierbarkeit und Skalierbarkeit.
Die Stärke dieser Plattformen liegt häufig nicht allein in einzelnen GRC-Funktionen, sondern in der Fähigkeit, umfangreiche Prozesse, Organisationsmodelle, Workflows und Integrationen auf einer gemeinsamen Plattform abzubilden.
Das kann gleichzeitig zu höherer Komplexität führen. Eine Plattform, die für einen internationalen Konzern mit mehreren zehntausend Beschäftigten geeignet ist, ist deshalb nicht automatisch eine gute Wahl für ein Unternehmen mit 1.000 Beschäftigten und einem kleinen GRC-Team.
Typische Produkte: ServiceNow, IBM OpenPages, Archer, MetricStream, OneTrust, Diligent, Corporater
Typischer Zielmarkt: Großunternehmen und Konzerne.
Typische Stärke: breite Plattformabdeckung, Integration, Skalierbarkeit und komplexe organisationsübergreifende GRC-Prozesse.
Für Ihren RFI / RFP
Achten Sie besonders auf: Implementierungsaufwand, Administrationsbedarf, Total Cost of Ownership und die Frage, ob die Organisation die Möglichkeiten der Plattform tatsächlich nutzen kann.
Fragen Sie nicht nur nach Lizenzkosten. Ermitteln Sie die gesamte Betriebsbelastung:
  • Wie aufwendig ist die Einführung?
  • Wie viele interne Ressourcen werden dauerhaft benötigt?
  • Wie viel kann der Kunde selbst konfigurieren?
  • Wann wird externe Beratung benötigt?
  • Wie aufwendig sind Releases und Änderungen?
  • Wie schnell können neue Anforderungen umgesetzt werden?

2.1.2 Eine starke DACH-Anbieterlandschaft

Daneben verfügt die DACH-Region über eine bemerkenswert große Gruppe eigener GRC-Anbieter. Diese Produkte adressieren häufig Mittelstand, gehobenen Mittelstand und Großunternehmen und verbinden mehrere GRC- beziehungsweise Managementdisziplinen. Für Käufer können regionale Anbieter Vorteile bieten: Nähe zum Markt, deutschsprachige Beratung, Kenntnis lokaler regulatorischer Anforderungen und teilweise eine größere Bereitschaft, kundenspezifische Anforderungen aufzunehmen.
Die Größe eines Anbieters sollte allerdings weder automatisch als Vorteil noch als Nachteil interpretiert werden. Ein kleinerer Anbieter kann ein sehr passendes Produkt und hohe fachliche Kompetenz besitzen. Bei einer strategischen Plattformentscheidung sollten Kunden aber zusätzlich prüfen, wie Produktentwicklung, Support, Technologie und Partnerstrukturen langfristig abgesichert sind.
Typische Produkte: ADOGRC, CRISAM, R2C, antares RiMIS, GRASP GRC, Fecton GRC
Typischer Zielmarkt: gehobener Mittelstand bis Großunternehmen, teilweise Konzerne.
Typische Stärke: breite GRC-Abdeckung kombiniert mit regionaler Marktkenntnis und häufig enger Verbindung von Software und Fachberatung.
Für Ihre Tool-Auswahl
Achten Sie besonders auf: Technologische Offenheit, Integrationen, Automatisierungsmöglichkeiten und die langfristige Produktstrategie.
Fragen an Anbieter:
  • Wie groß ist das Produkt- und Entwicklungsteam?
  • Wie viele Kunden verwenden die Plattform produktiv?
  • Wie sieht die Roadmap für die nächsten zwei bis drei Jahre aus?
  • Welche Funktionen werden zentral vom Hersteller entwickelt?
  • Gibt es Implementierungs- und Technologiepartner?
  • Wie wird die Weiterentwicklung wichtiger regulatorischer Inhalte sichergestellt?
  • Wie schnell werden neue Standards und Anforderungen unterstützt?
Dabei sollte eine Roadmap nicht als Versprechen verstanden werden. Sie zeigt vielmehr, ob die Entwicklungsrichtung des Herstellers mit der eigenen Entwicklung übereinstimmt.

2.1.3 Die deutsche Besonderheit: BSI IT-Grundschutz und ISMS

Deutschland besitzt zusätzlich einen Softwaremarkt, der stark durch Informationssicherheitsmanagement und BSI IT-Grundschutz geprägt wurde. Das unterscheidet die Anbieterlandschaft zumindest teilweise von anderen Ländern.
Der IT-Grundschutz gibt für den Aufbau und Betrieb eines ISMS eine detaillierte Methodik vor. Der BSI-Standard 200-2 beschreibt unter anderem den Aufbau des Sicherheitsmanagements und die systematische Erarbeitung von Sicherheitskonzepten; der BSI-Standard 200-3 ergänzt die Risikoanalyse. Diese methodische Tiefe begünstigte früh den Einsatz spezialisierter Software.
Daraus entstand eine Gruppe von Produkten, deren fachliche DNA stärker durch Informationsverbünde, Assets, Schutzbedarfe, Sicherheitsanforderungen und Maßnahmen geprägt ist als durch klassisches Enterprise Risk Management. Zu diesem Umfeld gehören unter anderem:
Typische Produkte: HiScout, verinice, TTS trax, INDITOR, AKARION GRC Cloud, teilweise GRASP GRC
Typischer Zielmarkt: Mittelstand bis Großunternehmen, öffentliche Verwaltung, KRITIS und regulierte Organisationen.
Typische Stärke: detaillierte Abbildung von ISMS, Informationswerten, Assets, Schutzbedarfen, Risiken und Sicherheitsmaßnahmen.
Für Ihre Tool-Auswahl
Achten Sie besonders auf die Fähigkeit, aus dem ISMS heraus weitere Managementdisziplinen aufzubauen, ohne neue Datensilos zu erzeugen.

2.1.4 Mid-Market-GRC- und Compliance-Plattformen

Mid-Market-GRC- und Compliance-Plattformen richten sich an Organisationen, die mehrere GRC-Themen integrieren wollen, ohne die Komplexität klassischer Enterprise-GRC-Suiten zu übernehmen. Häufig ermöglichen sie einen schrittweisen Einstieg, etwa über ISMS, Compliance oder Risikomanagement, und lassen sich später um weitere Managementdisziplinen ergänzen.
Typische Produkte: AKARION GRC Cloud, HITGuard, otris compliance SUITE, teilweise GRASP GRC
Typischer Zielmarkt: KMU, Mittelstand und teilweise gehobener Mittelstand.
Typische Stärke: schnellerer Einstieg und geringerer Implementierungsaufwand.
Für Ihre Tool-Auswahl
Hier konkurriert die neue Plattform häufig weniger mit ServiceNow oder Archer als mit der vorhandenen Realität:
 
Excel + SharePoint + Fachanwendungen + E-Mail.
Für Tool-Suchende ist deshalb besonders wichtig, ob die Plattform genügend fachliche Breite für die nächsten Entwicklungsschritte bietet, ohne gleichzeitig unnötige Komplexität einzuführen. Entscheidend ist der Spagat zwischen einfacher Einführung heute und ausreichender Erweiterbarkeit für morgen.

2.2 Zwei Entwicklungspfade - ein zunehmend konvergierender Markt

Die beschriebenen Marktsegmente haben unterschiedliche historische Wurzeln. Vereinfacht lassen sich in der DACH-Region zwei wichtige Entwicklungspfade erkennen, die heute zunehmend zusammenwachsen:
 
Corporate GRC: Risk Management → IKS → Compliance → Audit → weitere GRC-Disziplinen
 
Information Security GRC: ISMS → IT-/Cyber-Risk → Datenschutz → BCM → Compliance → weitere GRC-Disziplinen
Viele heutige Plattformen lassen sich nicht mehr eindeutig nur einem dieser Pfade zuordnen. Klassische GRC-Anbieter erweitern ihre Lösungen um Cyber Risk, ISMS und Operational Resilience, während ursprünglich sicherheitszentrierte Produkte zunehmend Compliance, BCM, Audit oder Enterprise Risk Management integrieren.
Für Ihre Tool-Auswahl:
Klären Sie, von welchem Ausgangspunkt Ihre Organisation kommt - aber bleiben Sie dort gedanklich nicht stehen. Wenn Sie heute ein ISMS-Tool suchen, überlegen Sie und prüfen Sie die Möglichkeiten mit dem Anbieter:
  • Soll später BCM hinzukommen?
  • Datenschutz?
  • Third-Party Risk Management?
  • Enterprise Risk Management?
  • Compliance?
  • AI Governance?
Umgekehrt sollte ein Unternehmen mit klassischem Enterprise GRC prüfen, wie tief die Plattform inzwischen Informationssicherheit, Cyber Risk und Operational Resilience unterstützt.
Der relevante Auswahlmaßstab lautet damit nicht nur Fit for Today, sondern auch Fit for Direction.

3 Die nächste Entwicklungsphase von GRC-Plattformen

Die Anbieterlandschaft beschreibt, woher die Produkte kommen. Für Käufer ist mindestens genauso wichtig, wohin sich der Markt bewegt. Vier Entwicklungen sollten deshalb bereits heute bei einer Plattformentscheidung berücksichtigt werden.

3.1 Von manuellen Prozessen zu Compliance Automation

Viele GRC-Plattformen sind historisch Systeme zur strukturierten Verwaltung von Informationen - heute oft noch manuell:
  • Risiken erfassen
  • Kontrollen dokumentieren
  • Assessments durchführen
  • Evidenzen hinterlegen
  • Maßnahmen verfolgen
  • Reports erstellen
Die nächste Entwicklungsstufe besteht darin, operative Systeme stärker einzubeziehen. Informationen aus beispielsweise Identity Management, ERP, Cloud-Infrastruktur, Asset Management, HR-Systemen oder Security Tools können automatisch übernommen werden. Damit verschiebt sich GRC schrittweise von
 
von: Dokumentieren, ob Compliance gegeben sein sollte
 
zu: automatisiert feststellen, ob sie tatsächlich gegeben ist.
Für Deutschland zeigt sich hier noch erhebliches Entwicklungspotenzial. Das bedeutet jedoch nicht, dass ein regionaler GRC-Anbieter bereits 2026 eine perfekte End-to-End-Automation bereitstellen muss. Wichtiger ist die Entwicklungsfähigkeit.
Fragen Sie Anbieter:
  • Welche externen Systeme können angebunden werden?
  • Können Evidenzen automatisiert übernommen werden?
  • Gibt es APIs?
  • Können Kunden selbst Integrationen erstellen?
  • Können Regeln oder Kontrolltests automatisiert ausgeführt werden?
  • Welche Erweiterungen sind dafür auf der Roadmap?
Ein wichtiges Auswahlkriterium lautet deshalb: Wie viel GRC-Arbeit muss der Anwender heute manuell erledigen - und wie viel davon kann die Plattform künftig automatisieren?

3.2 Von periodischen Kontrollen zu Continuous Controls Monitoring

Compliance Automation führt zu Continuous Controls Monitoring, kurz CCM. Heute werden viele Kontrollen noch periodisch überprüft. Beispielsweise: Ist Multi-Faktor-Authentifizierung für privilegierte Benutzer aktiviert? Ein Owner beantwortet die Frage und liefert einen Nachweis.
Mit stärkerer Automation kann die Plattform den Nachweis selbst aus einem Identity-System beziehen.
Continuous Controls Monitoring geht einen Schritt weiter: Das System überwacht fortlaufend, ob die relevante Kontrolle weiterhin wirksam ist, erkennt Abweichungen und löst gegebenenfalls eine Reaktion aus.
Forrester bezeichnete CCM 2026 noch als das schwächste aktuelle Kriterium der untersuchten GRC-Plattformen. Viele Lösungen konzentrieren sich demnach noch auf die automatisierte Sammlung von Audit-Evidenz; das größere Potenzial liegt in der kontinuierlichen Messung der Control Effectiveness und der darauf aufbauenden Remediation. Das ist für die Bewertung regionaler Anbieter wichtig: CCM ist eine wichtige Entwicklungsrichtung, aber 2026 noch kein pauschales Ausschlusskriterium. Auch gute kleinere DACH-Plattformen müssen diese Fähigkeit nicht bereits vollständig umgesetzt haben. Sie sollten aber technologisch in diese Richtung zeigen.
Für Ihre Ausschreibung sollten Sie deshalb nicht nur fragen:
 
Unterstützt das Produkt Continuous Controls Monitoring: Ja/Nein?
Sondern:
  • Können externe Messwerte Controls zugeordnet werden?
  • Kann die Control Effectiveness automatisch aktualisiert werden?
  • Können Grenzwerte definiert werden?
  • Lassen sich bei Abweichungen Workflows auslösen?
  • Können eigene Datenquellen angebunden werden?
  • Ist die Architektur für kontinuierliche Datenströme ausgelegt?
So unterscheiden Sie zwischen heute vorhanden, technisch vorbereitet und strategisch erkennbar.

Agentic AI macht Continuous Governance noch wichtiger

CCM gewinnt zusätzlich an Bedeutung, wenn AI sich im Unternehmen von einer Assistenzfunktion zu einer neuen Form digitaler Workforce entwickelt. AI-Agenten können künftig in Fachbereichen selbständig Informationen abrufen, Systeme bedienen, Vorgänge bearbeiten, Kommunikation auslösen oder Transaktionen vorbereiten und durchführen. Damit verändern sich Governance und Kontrolle.
Bei einem AI-Agenten reicht es nicht, einmal im Jahr festzustellen, dass er ordnungsgemäß freigegeben wurde. Unternehmen müssen zunehmend wissen:
  • Welche Berechtigungen besitzt der Agent aktuell?
  • Auf welche Daten greift er zu?
  • Welche Aktionen führt er tatsächlich aus?
  • Welche Systeme verwendet er?
  • Welche Kosten verursacht er?
  • Welche Entscheidungen darf er selbst treffen?
  • Wann ist menschliche Freigabe erforderlich?
  • Verhält er sich weiterhin innerhalb der definierten Grenzen?
Damit wird Governance kontinuierlicher.
 
Je autonomer AI im Unternehmen handelt, desto weniger reicht periodische Governance.
Oder noch grundsätzlicher:
 
Agentic AI macht Governance zunehmend zu einem Echtzeitproblem.
Für Tool-Suchende bedeutet dies nicht, dass eine GRC-Plattform heute bereits sämtliche zukünftigen AI-Agenten überwachen können muss. Sie sollte aber zukünftig externe Betriebs- und Kontrollinformationen aufnehmen und mit Governance-Objekten verknüpfen können.

3.3 Von AI Compliance zu AI Governance

AI wirkt auf GRC in zwei Richtungen:

3.3.1 AI for GRC

AI unterstützt GRC-Fachleute beispielsweise bei:
  • Risikoidentifikation
  • Compliance-Analysen
  • Zusammenfassungen
  • Kontrollbeschreibungen
  • Assessments
  • Audit-Vorbereitung
  • Verarbeitung von Fragebögen

3.3.2 Governance von AI

Gleichzeitig müssen Unternehmen ihren eigenen AI-Einsatz kontrollieren. Hier beginnt AI Governance. Dazu gehören beispielsweise:
  • AI Inventory
  • AI Use Cases
  • Modelle
  • AI Provider
  • Verantwortlichkeiten
  • Risikoklassifizierung
  • Policies
  • Controls
  • Assessments
  • Human Oversight
  • Incidents
  • Evaluierungen
  • Monitoring
Für Käufer ist insbesondere eine längerfristige Perspektive wichtig:
 
Heute lautet die Frage vielleicht: "Kann die Plattform für den EU AI Act unsere AI-Systeme inventarisieren?"
 
Morgen könnte sie lauten: Wie kontrollieren wir 500 AI-Agenten, die als digitale Workforce über verschiedene Unternehmensbereiche verteilt sind?
Dann müssen nicht mehr nur Anwendungen verwaltet werden, sondern möglicherweise Agenten mit:
  • Identitäten
  • Rollen
  • Berechtigungen
  • Modellen
  • Datenzugriffen
  • Kostenbudgets
  • Aufgabenbereichen
  • Kontrollgrenzen
  • Eskalationsregeln
Für Ihre Tool-Auswahl: Lassen Sie sich deshalb nicht allein ein "EU AI Act Module" demonstrieren.
Fragen Sie:
  • Ist ein AI-System ein eigenes Governance-Objekt?
  • Können Modelle, Provider und Use Cases getrennt verwaltet werden?
  • Lassen sich Beziehungen zu Prozessen, Daten, Risiken und Controls modellieren?
  • Kann das Datenmodell zukünftig um AI-Agenten erweitert werden?
  • Können technische Monitoringinformationen eingebunden werden?
AI Governance ist damit auch ein Test für die Erweiterbarkeit des gesamten Plattformmodells.

3.4 Risikomanagement als Navigationsinstrument verstehen

Eine grundlegende Entwicklung betrifft das Risikomanagement. Viele GRC-Systeme unterstützen einen klassischen Zyklus: Risiko identifizieren → Wahrscheinlichkeit und Schadenshöhe bewerten → Maßnahmen definieren → Restrisiko bestimmen → Risikoregister aktualisieren → Bericht erstellen. Dieser Prozess bleibt notwendig.
Doch Unternehmen bewegen sich zunehmend durch ein Umfeld mit:
  • geopolitischen Veränderungen
  • Cyberrisiken
  • AI-Disruption
  • Lieferkettenstörungen
  • neuen regulatorischen Anforderungen
  • Energie- und Rohstoffrisiken
  • technologischen Abhängigkeiten
  • makroökonomischer Unsicherheit
In einer solchen Umwelt reicht die Frage "Welche Risiken haben wir?" nicht aus. Das Management benötigt zunehmend Antworten auf: Was verändert sich gerade, was bedeutet das für unsere Ziele - und welche Entscheidungen sollten wir deshalb treffen?
Risk Management entwickelt sich perspektivisch:
Risk Documentation → Risk Monitoring → Risk Intelligence → Decision Support
Gerade im DACH-Umfeld ist Risikomanagement traditionell stark durch methodische Ordnung, Nachweisbarkeit, Risikoinventare, Reporting und Auditierbarkeit geprägt. Das sind wichtige Stärken. Sie sollten jedoch nicht dazu führen, dass Risikomanagement primär als ordnungsgemäße Verwaltung von Risiken verstanden wird.
In stürmischen Zeiten ist ein gepflegtes Risikoregister allein noch kein Kompass.
Für Ihre Software-Auswahl:
Fragen Sie Anbieter deshalb nicht nur:
  • Können Risiken erfasst und bewertet werden?
Fragen Sie zusätzlich:
  • Können Risiken mit Unternehmenszielen verbunden werden?
  • Können Key Risk Indicators integriert werden?
  • Können externe Daten und Ereignisse eingebunden werden?
  • Unterstützt das System Szenarien?
  • Werden Veränderungen über die Zeit sichtbar?
  • Können unterschiedliche Zukunftsszenarien miteinander verglichen werden?
  • Kann das Management erkennen, welche Entscheidungen durch eine veränderte Risikolage betroffen sind?
Risikomanagement sollte nicht nur nachweisen, dass Risiken gemanagt werden. Es sollte dem Unternehmen helfen, durch unsichere Zeiten zu navigieren.

4 Niemand weiß, wie GRC und AI 2031 aussehen werden

4.1 Deshalb strategische Optionen für die Zukunft schaffen

Bei einer mehrjährigen Plattformentscheidung besteht eine Versuchung: Man versucht vorherzususehen, welche Funktionen in fünf Jahren benötigt werden. Gerade bei AI ist das kaum möglich.
Die bessere Strategie ist deshalb nicht, die Zukunft exakt vorherzusagen. Sie lautet stattdessen: Entscheidungsfreiheit erhalten.. Unternehmen sollten eine Plattform auswählen, die ihnen möglichst viele zukünftige Optionen offenhält. Das betrifft insbesondere AI.
Heute kann der GRC-Anbieter ein bestimmtes LLM integriert haben. Morgen kann Ihr Unternehmen jedoch aus Datenschutz-, Kosten-, Sicherheits- oder Vertragsgründen ein anderes Modell einsetzen wollen. Vielleicht existiert bereits ein konzernweiter Vertrag mit einem AI-Provider einschließlich Datenschutzregelungen, AVV, Security Assessment und ausgehandeltem Kostenmodell. Dann sollte die GRC-Plattform diesen Provider möglichst nutzen können.
Sinnvolle SOLL-Anforderungen für eine Ausschreibung können deshalb sein:
  • Unterstützung mehrerer AI-Provider
  • Möglichkeit zur Nutzung kundeneigener AI-Modelle
  • dokumentierte Schnittstellen zu AI-Diensten
  • Austauschbarkeit des AI-Providers
  • transparente Verbrauchs- und Kostenmessung
  • kundenseitige Kostenlimits
  • Datenexport über dokumentierte Formate
  • dokumentierte APIs
  • konfigurierbare Integrationen
  • möglichst geringe Abhängigkeit von proprietären AI-Diensten des GRC-Anbieters
Nicht jede Plattform wird heute sämtliche Punkte erfüllen. Aber die Antworten zeigen Ihnen, wie stark Ihre zukünftige Wahlfreiheit eingeschränkt wird.

4.2 AI muss auch abschaltbar sein

Ein weiterer Punkt wird bei der Tool-Auswahl leicht übersehen: Softwarehersteller werden in den nächsten Jahren immer mehr AI-Funktionen in ihre Produkte integrieren. Für Kunden ist das grundsätzlich positiv.
Problematisch wird es, wenn neue AI-Funktionen automatisch aktiviert werden oder technisch nicht mehr sauber von klassischen Funktionen getrennt werden können.
Gerade regulierte Organisationen müssen selbst entscheiden können, wo AI eingesetzt werden darf.
Nehmen Sie deshalb Anforderungen zur AI-Steuerbarkeit in Ihre Ausschreibung auf.. Beispielsweise:
  • AI-Funktionen müssen administrativ deaktivierbar sein.
  • Die Aktivierung muss pro Mandant, Organisation oder Use Case steuerbar sein.
  • Berechtigte Benutzergruppen müssen festgelegt werden können.
  • Verwendete AI-Provider müssen transparent ausgewiesen werden.
  • Die für AI verwendeten Daten müssen nachvollziehbar sein.
  • Eine Nutzung von Kundendaten für Modelltraining muss steuerbar beziehungsweise ausschließbar sein.
  • Neue AI-Funktionen dürfen nicht automatisch ohne administrative Entscheidung aktiviert werden.
  • Kritische AI-Aktionen müssen protokolliert werden.
Ein scheinbar banales Auswahlkriterium kann deshalb strategisch wichtig werden: Kann der Kunde AI auch einfach auf "Off" stellen?

4.3 Integration wird wichtiger als die Zahl der Module

Die langfristige Bindung an eine GRC-Plattform entsteht nicht nur durch Funktionen. Sie entsteht vor allem durch Daten. Über Jahre sammeln sich:
  • Risiken
  • Controls
  • Assets
  • Prozesse
  • Lieferanten
  • Policies
  • Assessments
  • Evidenzen
  • Maßnahmen
  • Beziehungen zwischen diesen Objekten
Je wertvoller dieses Beziehungswissen wird, desto schwieriger wird ein späterer Plattformwechsel. Deshalb sollte Architektur bereits bei der Auswahl berücksichtigt werden.
Fragen für RFI und RFP:
  • Welche APIs stehen zur Verfügung?
  • Sind sämtliche relevanten Objekte darüber erreichbar?
  • Können Daten vollständig exportiert werden?
  • In welchen Formaten?
  • Können eigene Objekttypen ergänzt werden?
  • Können Beziehungen zwischen Objekten erweitert werden?
  • Gibt es Webhooks oder Event-Schnittstellen?
  • Können Integrationen kundenseitig gebaut werden?
  • Welche Low-Code-/No-Code-Funktionen existieren?
  • Welche Änderungen bleiben releasefähig?
Das Ziel ist nicht maximale technische Offenheit um jeden Preis. Das Ziel ist: ausreichende strategische Bewegungsfreiheit.

5 Was Tool-Suchende aus der Market Map mitnehmen sollten

5.1 Eine gute GRC-Auswahl verbindet drei Zeithorizonte

Heute: Passt die Plattform zu unseren aktuellen Anforderungen?

Hier bleibt eine detaillierte Feature-Liste wichtig.
Prüfen Sie die Prozesse, regulatorischen Anforderungen, Reports, Workflows, Rollenmodelle und Integrationen, die für den Produktivbetrieb benötigt werden.

Morgen: Passt die Plattform zu unserer organisatorischen Entwicklungsrichtung?

Fragen Sie sich:
  • Welche Managementsysteme sollen zusammenwachsen?
  • Wird aus ISMS später GRC?
  • Wird Third-Party Risk wichtiger?
  • Kommt AI Governance hinzu?
  • Soll Risikomanagement stärker strategisch eingesetzt werden?
  • Soll Compliance stärker automatisiert werden?

Übermorgen: Erhält uns die Plattform ausreichend Optionen?

Hier geht es weniger um heutige Features.
Es geht um:
  • APIs
  • Erweiterbarkeit
  • Integrationsfähigkeit
  • Datenportabilität
  • AI-Provider-Wahl
  • Abschaltbarkeit von AI
  • Automatisierungsfähigkeit
  • Anschlussfähigkeit für Continuous Controls Monitoring
  • Erweiterbarkeit um neue Governance-Objekte
Für Ihren Anforderungskatalog: Teilen Sie Anforderungen in mindestens drei Gruppen:
Must-have heute:
Funktionen, ohne die die Plattform nicht produktiv eingesetzt werden kann.
Expected tomorrow:
Funktionen, die innerhalb der nächsten zwei bis drei Jahre wahrscheinlich benötigt werden.
Strategic Options:
Fähigkeiten, deren konkrete Ausprägung heute noch unsicher ist, für die aber technologische Offenheit erhalten bleiben soll.
Gerade die dritte Kategorie wird bei AI zunehmend wichtig.

5.2 Vier Entwicklungsachsen für GRC-Plattformen im Auge behalten

Auf dem Markt sind diese Richtungen erkennbar:
  • Compliance Automation
  • Continuous Control Monitoring
  • AI Governance
  • Risk Intelligence & Decision Support
Diese Entwicklungen bedeuten nicht, dass jeder Anbieter 2026 bereits die vollständige Plattform der Zukunft liefern muss. Gerade kleinere und regionale Anbieter können für viele Organisationen die bessere Wahl sein, wenn fachliche Tiefe, Zielmarkt, Implementierungsmodell und Kundenanforderungen gut zusammenpassen.
Zukunftsfähigkeit bedeutet deshalb nicht:
 
Alle Funktionen der Zukunft müssen heute vorhanden sein.
Sondern:
 
Die Plattform sollte technologisch und konzeptionell in eine Richtung entwickelt werden können, die dem Kunden zukünftige Optionen offenhält.

6 Fazit

Der Markt für GRC-Plattformen in der DACH-Region bietet eine große Auswahl - von internationalen Enterprise-Suiten über regionale GRC-Spezialisten bis zu stark ISMS- und BSI-geprägten Plattformen. Für Tool-Suchende ist deshalb weniger entscheidend, den vermeintlich "besten" Anbieter zu finden, als die Plattform auszuwählen, die zur eigenen Organisation und ihrer Entwicklungsrichtung passt.
Eine belastbare Auswahl muss drei Zeithorizonte zusammenbringen: die heutigen fachlichen Anforderungen, die absehbare Entwicklung der eigenen GRC-Organisation und genügend Offenheit für Anforderungen, die heute noch nicht vollständig vorhersehbar sind. Dazu gehören insbesondere mehr Automation, Continuous Controls Monitoring, AI Governance, die Governance einer möglichen agentischen Workforce sowie ein Risikomanagement, das stärker zur Orientierung und Entscheidungsunterstützung beiträgt.
Kleinere und regionale Anbieter müssen diese Zukunft nicht bereits vollständig umgesetzt haben. Entscheidend ist, ob Architektur, Integrationsfähigkeit, Datenmodell und Produktentwicklung erkennen lassen, dass die Plattform in diese Richtung wachsen kann.

7 Methodik

Marktabgrenzung
Berücksichtigt werden Softwareplattformen, die in Deutschland, Österreich oder der Schweiz verfügbar und für mehrere Governance-, Risk- & Compliance-Disziplinen einsetzbar sind.
Einbezogen werden
Produkte mit mehreren Anwendungsbereichen wie Enterprise Risk Management, IKS, Compliance Management, Audit, ISMS, BCM, Datenschutz oder Third-Party Risk Management sowie Produkte, die diese Bereiche über gemeinsame Daten, Objekte oder eine gemeinsame Plattform verbinden.
Nicht einbezogen werden
Reine Speziallösungen für einzelne Aufgaben, sofern diese nicht Bestandteil einer breiteren GRC-Plattform sind.
Geografische Definition
DACH-Relevanz setzt keinen Unternehmenssitz in Deutschland, Österreich oder der Schweiz voraus. Internationale Anbieter werden berücksichtigt, sofern ihre Produkte im DACH-Markt relevant verfügbar sind.
Segmentierung
Die Zuordnung beschreibt den primären Marktzugang und die typische Ausrichtung eines Produkts. Überschneidungen zwischen Segmenten sind ausdrücklich möglich.
Zielmarkt
Die Angaben zur Unternehmensgröße stellen eine analytische Einordnung der typischen Marktpositionierung und keine technischen Einsatzgrenzen dar.
Erstellung
Recherchen und die finale Ausformulierung wurden durch KI unterstützt.
Research-Stand: 2026
Die KonBriefing Market Map 2026 dient der strukturierten Orientierung bei der Auswahl von GRC-Plattformen und erhebt keinen Anspruch auf vollständige Erfassung aller im DACH-Markt verfügbaren Produkte.