Headless GRC: waarom compliance haar interface verliest en daar beter van wordt

Waarom GRC een nieuwe aanpak nodig heeft

GRC-software wordt headless: data, logica en workflows verhuizen naar een API-first-kern en de interface wordt uitwisselbaar. Precies die stap heeft de CRM-markt al achter de rug.

Klassieke GRC-tools zijn monolieten. Risicoregister, beheersmaatregelen, bewijs, audits en beleid zitten in één applicatie met een vast ingebouwde interface. Wie daar wil werken, moet inloggen, de menu's leren kennen en gegevens met de hand bijhouden.

Het resultaat kent elke CISO: compliance loopt naast de eigenlijke bedrijfsvoering in plaats van erin. Vakafdelingen openen de tool één keer per kwartaal, bewijs komt per e-mail binnen en het dashboard toont wat de leverancier belangrijk vindt. Wat de directie wil weten, toont het niet.

De analogie: Headless CRM

Headless CRM scheidt de klantgegevens van het scherm waarop ze worden getoond. Headless GRC doet hetzelfde met risico's, beheersmaatregelen en bewijs.

In het klassieke CRM werkte sales in de interface van de leverancier. Headless CRM draait dat om: het CRM is een database met bedrijfslogica, bereikbaar via API's. Verkopers zien klantgegevens in Slack, in hun e-mailclient, in een eigen salescockpit of in de webshop. Het CRM zelf ziet bijna niemand meer: het is het System of Record op de achtergrond.

Vertaald naar GRC betekent dit dat het risicoregister niet langer alleen in een invoerscherm leeft, maar daar waar beslissingen vallen. Een ontwikkelaar ziet de relevante beheersmaatregel in de pull request, inkoop ziet de leveranciersbeoordeling in het bestelproces en het bestuur ziet zijn risicobeeld in het bestuursrapport.

Kernkenmerken van Headless GRC

Zes kenmerken onderscheiden Headless GRC van een klassieke tool met een achteraf aangebouwde API.

1. Ontkoppelde presentatielaag. Data en logica zijn volledig gescheiden van de interface. Een meegeleverde UI is een van vele mogelijke weergaven, niet de enige.
2. API-first in plaats van API-ook. Elke functie die de eigen interface van de leverancier gebruikt, is ook via de API beschikbaar. Er bestaat geen actie die alleen met een klik werkt.
3. Gestructureerd datamodel. Risico's, assets, beheersmaatregelen, eisen en bewijs zijn zorgvuldig gemodelleerde, gekoppelde objecten. Pas die structuur maakt gegevens bruikbaar voor andere systemen en voor AI.
4. Frameworklogica in de kern. Mappings tussen ISO 27001, NIS2, DORA of BSI IT-Grundschutz staan in de backend. Elke interface erft ze, in plaats van ze na te bouwen.
5. Events en integraties. Wijzigingen zetten events in gang en bewijs komt automatisch binnen uit de cloud, de identity provider of het ticketsysteem. Compliance wordt een datastroom in plaats van een exercitie op een peildatum.
6. Fijnmazige rechten en herleidbaarheid. Als veel interfaces en agents dezelfde gegevens gebruiken, moeten rechten, versies en audit trail in de kern zitten. De controleerbaarheid van vastleggingen mag niet afhangen van de UI die toevallig wordt gebruikt.

De toekomst: Custom Dashboards in plaats van standaardweergaven

Het standaarddashboard van de leverancier verliest aan betekenis. Elke organisatie bouwt de weergaven die bij haar vragen passen.

Een bestuur wil weten of het bedrijf klaar is voor NIS2 en waar het grootste restrisico ligt. Een auditor wil bewijs per eis. Een teamlead wil alleen de drie beheersmaatregelen zien waarvoor zijn team verantwoordelijk is. Eén dashboard bedient geen van deze mensen goed.

Met een headless kern ontstaan zulke weergaven snel en zonder project bij de leverancier: als BI-rapport, als pagina op het intranet, als widget in het ticketsysteem of als bestuurspresentatie die zichzelf bijwerkt. De gegevens blijven één bron, de weergave wordt per doelgroep gebouwd.

Generative UI: interfaces ontstaan wanneer ze nodig zijn

De volgende stap na Custom Dashboards is Generative UI: de interface wordt niet meer gebouwd, maar op het moment van de vraag door een AI gegenereerd.

In plaats van door menu's te navigeren, vraagt de algemeen directeur: “Welke kritieke leveranciers hebben geen actuele beoordeling, en welke risico's hangen daarvan af?” Een AI-agent haalt de gegevens op via de API en maakt er een passende weergave voor: een tabel, een grafiek of een afhankelijkheidskaart. Morgen ziet dezelfde vraag er misschien anders uit, omdat de gegevens zijn veranderd.

Daarmee verschuift wat een GRC-leverancier eigenlijk levert. De interface wordt een momentopname. Wat blijft en waarde heeft, is:

• een betrouwbaar, gestructureerd datamodel,
• correcte framework- en beoordelingslogica,
• zuivere rechten, zodat de AI alleen toont wat de vragensteller mag zien,
• een sluitende audit trail, ook als een agent schrijft in plaats van een mens.

Protocollen zoals het Model Context Protocol (MCP) maken precies dat vandaag al mogelijk: AI-assistenten krijgen gestructureerd toegang tot GRC-gegevens, lezen risico's en leggen maatregelen aan, zonder dat iemand de klassieke interface opent.

API-first is de enige echte voorwaarde

Als interfaces worden gegenereerd, heeft een GRC-systeem in de kern nog maar één ding nodig: een volledige, goed gedocumenteerde API.

Dat klinkt als een vereenvoudiging, maar het is een hoge lat. Een API die achteraf aan een tool is vastgeschroefd, dekt meestal alleen leestoegang of afzonderlijke objecten af. API-first betekent daarentegen dat de eigen interface van de leverancier zelf slechts een client van deze API is. Wat daar kan, kan ook voor elk dashboard, elke integratie en elke AI-agent.

Voor kopers van GRC-software volgen daaruit duidelijke toetsvragen. Ze vullen de zeven vragen voor het kiezen van GRC-software aan:

• Is elke functie van de interface ook via de API beschikbaar, inclusief schrijftoegang?
• Is het datamodel openbaar gedocumenteerd en stabiel geversioneerd?
• Gelden rollen en rechten bij API-toegang op dezelfde manier als in de UI?
• Worden wijzigingen via de API controleerbaar en onveranderbaar vastgelegd?
• Is er een koppeling voor AI-assistenten, bijvoorbeeld via MCP?

Wie deze vragen met ja kan beantwoorden, is voorbereid op Custom Dashboards en Generative UI. Wie dat niet kan, koopt een tool waarvan over een paar jaar niemand de interface nog wil openen.

Conclusie

GRC volgt de weg die CRM heeft uitgestippeld: van werkplek naar System of Record. De interface wordt eerst individueel, dan gegenereerd, en uiteindelijk telt alleen nog de kern.

Voor leveranciers betekent dat investeren in datamodel, logica en API in plaats van in steeds nieuwe invoerschermen. Voor gebruikers betekent het compliance brengen naar de plek waar gewerkt wordt, en GRC-tools kiezen op basis van hoe goed ze zich onzichtbaar kunnen maken.

Hoe deze ontwikkeling past in het generatiemodel van Michael Rasmussen, beschrijven we in GRC 7.0: wat GRC Orchestrate van Michael Rasmussen betekent voor organisaties. Waar ze op lange termijn toe kan leiden, laat onze voorspelling GRC 9.0: Embedded GRC zien.