Headless GRC: Warum Compliance ihre Oberfläche verliert und dabei gewinnt

Warum GRC einen neuen Ansatz braucht

GRC-Software wird headless: Daten, Logik und Workflows wandern in einen API-first-Kern, die Oberfläche wird austauschbar. Genau diesen Schritt hat der CRM-Markt bereits hinter sich.

Klassische GRC-Tools sind Monolithen. Risikoregister, Kontrollen, Nachweise, Audits und Richtlinien stecken in einer Anwendung mit fest verdrahteter Oberfläche. Wer dort arbeiten will, muss sich einloggen, Menüs lernen und Daten von Hand pflegen.

Das Ergebnis kennt jeder ISB: Compliance läuft parallel zum eigentlichen Geschäft statt darin. Fachbereiche öffnen das Tool einmal im Quartal, Nachweise kommen per Mail, und das Dashboard zeigt, was der Hersteller für wichtig hält. Was die Geschäftsführung wissen will, zeigt es nicht.

Die Analogie: Headless CRM

Headless CRM trennt die Kundendaten vom Bildschirm, auf dem sie angezeigt werden. Headless GRC macht dasselbe mit Risiken, Kontrollen und Nachweisen.

Im klassischen CRM arbeitete der Vertrieb in der Oberfläche des Herstellers. Headless CRM dreht das um: Das CRM ist eine Datenbank mit Geschäftslogik, erreichbar über APIs. Vertriebler sehen Kundendaten in Slack, im E-Mail-Client, in einem eigenen Sales-Cockpit oder im Webshop. Das CRM selbst sieht kaum noch jemand: Es ist das System of Record im Hintergrund.

Übertragen auf GRC heißt das: Das Risikoregister lebt nicht mehr nur in einer Maske, sondern dort, wo Entscheidungen fallen. Ein Entwickler sieht die relevante Kontrolle im Pull Request, der Einkauf die Lieferantenbewertung im Bestellprozess, der Vorstand sein Risikobild im Board-Report.

Key Characteristics von Headless GRC

Sechs Merkmale unterscheiden Headless GRC von einem klassischen Tool mit nachträglich angebauter Schnittstelle.

1. Entkoppelte Präsentationsschicht. Daten und Logik sind vollständig von der Oberfläche getrennt. Eine mitgelieferte UI ist eine von vielen möglichen Ansichten, nicht die einzige.
2. API-first statt API-auch. Jede Funktion, die die eigene Oberfläche nutzt, ist auch über die API verfügbar. Es gibt keine Aktion, die nur per Klick geht.
3. Strukturiertes Datenmodell. Risiken, Assets, Kontrollen, Anforderungen und Nachweise sind sauber modellierte, verknüpfte Objekte. Erst diese Struktur macht Daten für andere Systeme und für KI nutzbar.
4. Framework-Logik im Kern. Mappings zwischen ISO 27001, NIS2, DORA oder BSI-Grundschutz liegen im Backend. Jede Oberfläche erbt sie, statt sie nachzubauen.
5. Event- und Integrationsfähigkeit. Änderungen lösen Events aus, Nachweise kommen automatisch aus Cloud, Identity-Provider oder Ticketsystem. Compliance wird zum Datenstrom statt zur Stichtagsübung.
6. Feingranulare Berechtigungen und Nachvollziehbarkeit. Wenn viele Oberflächen und Agenten auf dieselben Daten zugreifen, müssen Rechte, Versionen und Audit-Trail im Kern sitzen. Revisionssicherheit darf nicht von der jeweiligen UI abhängen.

Die Zukunft: Custom Dashboards statt Standardansichten

Das Standard-Dashboard des Herstellers verliert an Bedeutung. Jede Organisation baut sich die Sichten, die zu ihren Fragen passen.

Ein Vorstand will wissen, ob das Unternehmen NIS2-fähig ist und wo das größte Restrisiko liegt. Ein Auditor will Nachweise pro Anforderung. Ein Teamlead will nur die drei Kontrollen sehen, für die sein Team verantwortlich ist. Ein einziges Dashboard bedient keinen dieser Menschen richtig.

Mit einem headless Kern entstehen solche Sichten schnell und ohne Herstellerprojekt: als BI-Report, als Seite im Intranet, als Widget im Ticketsystem oder als Board-Präsentation, die sich selbst aktualisiert. Die Daten bleiben eine Quelle, die Darstellung wird pro Zielgruppe gebaut.

Generative UI: Oberflächen entstehen bei Bedarf

Der nächste Schritt nach Custom Dashboards ist Generative UI: Die Oberfläche wird nicht mehr gebaut, sondern im Moment der Frage von einer KI erzeugt.

Statt durch Menüs zu navigieren, fragt die Geschäftsführerin: „Welche kritischen Lieferanten haben keine aktuelle Bewertung, und welche Risiken hängen daran?“ Ein KI-Agent holt die Daten über die API und erzeugt dafür eine passende Ansicht: eine Tabelle, ein Diagramm oder eine Abhängigkeitskarte. Morgen sieht dieselbe Frage vielleicht anders aus, weil sich die Daten geändert haben.

Damit verschiebt sich, was ein GRC-Anbieter eigentlich liefert. Die Oberfläche wird zur Momentaufnahme. Was bleibt und wertvoll ist, sind:

• ein verlässliches, strukturiertes Datenmodell,
• korrekte Framework- und Bewertungslogik,
• saubere Berechtigungen, damit die KI nur zeigt, was der Fragende sehen darf,
• ein lückenloser Audit-Trail, auch wenn ein Agent statt eines Menschen schreibt.

Protokolle wie das Model Context Protocol (MCP) machen genau das heute schon möglich: KI-Assistenten greifen strukturiert auf GRC-Daten zu, lesen Risiken und legen Maßnahmen an, ohne dass jemand die klassische Oberfläche öffnet.

API-first ist die einzige echte Voraussetzung

Wenn Oberflächen generiert werden, braucht ein GRC-System im Kern nur noch eines: eine vollständige, gut dokumentierte API.

Das klingt nach Vereinfachung, ist aber ein hoher Anspruch. Eine API, die nachträglich an ein Tool angeschraubt wurde, deckt meist nur Lesezugriffe oder einzelne Objekte ab. API-first heißt dagegen, dass die eigene Oberfläche des Anbieters selbst nur ein Client dieser API ist. Was dort geht, geht auch für jedes Dashboard, jede Integration und jeden KI-Agenten.

Für Käufer von GRC-Software ergeben sich daraus klare Prüffragen. Sie ergänzen die sieben Fragen zur Auswahl von GRC-Software:

• Ist jede Funktion der Oberfläche auch per API verfügbar, inklusive Schreibzugriff?
• Ist das Datenmodell offen dokumentiert und stabil versioniert?
• Gelten Rollen und Rechte bei API-Zugriffen genauso wie in der UI?
• Werden Änderungen über die API revisionssicher protokolliert?
• Gibt es eine Anbindung für KI-Assistenten, etwa über MCP?

Wer diese Fragen mit Ja beantworten kann, ist für Custom Dashboards und Generative UI vorbereitet. Wer nicht, kauft ein Tool, dessen Oberfläche in wenigen Jahren niemand mehr öffnen will.

Fazit

GRC folgt dem Weg, den CRM vorgezeichnet hat: vom Arbeitsplatz zum System of Record. Die Oberfläche wird erst individuell, dann generiert, und am Ende zählt nur noch der Kern.

Für Anbieter heißt das, in Datenmodell, Logik und API zu investieren statt in immer neue Masken. Für Anwender heißt es, Compliance dorthin zu bringen, wo gearbeitet wird, und GRC-Tools danach auszuwählen, wie gut sie sich unsichtbar machen lassen.

Wie sich diese Entwicklung in Michael Rasmussens Generationenmodell einordnet, beschreiben wir in GRC 7.0: Was Michael Rasmussens GRC Orchestrate für Unternehmen bedeutet. Wohin sie langfristig führen kann, zeigt unsere Prognose GRC 9.0: Embedded GRC.