Als ik mensen vertel wat Anzen is (“een ITSM- en GRC-platform”), krijg ik vaak eerst een beleefde knik, gevolgd door “maar dat zijn toch twee verschillende dingen?”. Deze post is voor die reactie.

Twee werelden, één werkelijkheid

In de meeste organisaties wonen ITSM en GRC in aparte gebouwen.

De ITSM-kant draait op tickets. Change-tickets, incident-tickets, aanvragen. Het favoriete gereedschap is ServiceNow, Jira Service Management, of (vaker dan men toegeeft) een mailbox die door drie mensen wordt gelezen. Zij weten welke services draaien, wie ze eigenaar is, en wat er afgelopen dinsdag is gewijzigd en waarom.

De GRC-kant draait op spreadsheets. Risicoregisters, control-matrices, audit-bevindingen, policy-reviews. Het favoriete gereedschap is Excel, soms met een dun GRC-product erbovenop. Zij weten welke controls bestaan, welke dit kwartaal worden getoetst, en welke auditor er als volgende langskomt.

Beide kanten kijken naar dezelfde organisatie. Beide kanten houden dezelfde services bij, dezelfde assets, dezelfde mensen, dezelfde processen. Ze schrijven het alleen twee keer op, in verschillende schema’s, en besteden vervolgens elke audit-cyclus twee weken aan het matchen van die twee versies.

Daar lekt tijd, vertrouwen en geld weg.

Het echte verband

ITSM en GRC zijn met elkaar verbonden omdat ze dezelfde werkelijkheid vanuit twee hoeken beschrijven:

• Een change in ITSM is een control-event in GRC. Eén gebeurtenis, twee registraties.
• Een incident in ITSM is een gerealiseerd risico in GRC. Eén gebeurtenis, twee registraties.
• Een service in ITSM is een asset in scope voor GRC. Hetzelfde ding, twee registers.
• Een eigenaar in ITSM is een accountable party in GRC. Dezelfde persoon, twee contactlijsten.

Zodra je het zo ziet, verandert de vraag van “moeten we deze systemen koppelen?” naar “waarom hebben we ze ooit gesplitst?”.

Het eerlijke antwoord: de tooling dwong de splitsing af. Enterprise ITSM- en GRC-suites zijn los van elkaar gegroeid, werden door verschillende teams aan verschillende inkopers verkocht, en de integratie was altijd andermans probleem. De integratie eindigde dus als een persoon (vaak een junior consultant) die zaken van het ene tool naar het andere overtikt.

Wat Anzen probeert te doen

Anzen begint bij de aanname dat er één CMDB is, één procescatalogus, één risicoregister en één audit trail, voor beide kanten.

Daar volgt het volgende uit:

• Je CI’s krijgen een risicoscore, en die score reist mee waar de asset ook opduikt.
• Procesmodellen leggen zowel de service-flow als de control-punten vast. Je tekent het één keer.
• Bewijs voor audits is een bijproduct van het dagelijkse werk, geen kwartaalbrand.
• Changes, incidenten en toegangsverzoeken vullen automatisch de audit trail die je anders met de hand had moeten samenstellen.

Het is geen magie. Het is gewoon weigeren om te doen alsof de twee werelden verschillend zijn.

Wat levert dat een organisatie op

Voor de uitvoerder: minder dubbele boekhouding, minder “kun je dat nog even voor de auditor exporteren?”, en een actueel beeld van waar risico daadwerkelijk zit.

Voor de business: audit-voorbereiding van uren in plaats van weken, bewijs dat auditors zelf kunnen ophalen, en de mogelijkheid om je te gedragen als een volwassen organisatie zonder twee enterprise-platformen plus een systeemintegrator te kopen om ze aan elkaar te lijmen. Dat laatste telt vooral voor het MKB en scale-ups; voor hen heb ik dit gebouwd.

Voor de auditor: een verhaal dat klopt, omdat het hetzelfde verhaal is dat je operations-team al vertelt.

Verder

Het platform staat op anzenplatform.com. Als dit ergens raakt, of als je vindt dat ik er ergens naast zit, laat het weten; dat laatste vind ik eigenlijk interessanter dan het eerste.

Norbert