When I tell people what Anzen is (“an ITSM and GRC platform”), the first reaction is usually a polite nod, sometimes followed by “but those are two different things, right?”. This post is for that reaction.

Two worlds, one reality

In most organisations, ITSM and GRC live in separate buildings.

The ITSM side runs on tickets. Change tickets, incident tickets, request tickets. Their tool of choice is something like ServiceNow, Jira Service Management, or (more often than people admit) email and a shared inbox. They know which services are running, who owns them, and what changed last Tuesday and why.

The GRC side runs on spreadsheets. Risk registers, control matrices, audit findings, policy reviews. Their tool of choice is Excel, sometimes with a thin GRC product layered on top. They know which controls exist, which ones are being assessed this quarter, and which auditor is coming next.

Both sides are looking at the same business. Both sides are tracking the same services, the same assets, the same people, the same processes. They just write it all down twice, in different schemas, and then spend two weeks every audit cycle trying to reconcile the two views.

That reconciliation is where time, funds and trust leak away.

The real link

ITSM and GRC are linked because they describe the same reality from two angles:

• A change in ITSM is a control event in GRC. Same event, two records.
• An incident in ITSM is a risk realisation in GRC. Same event, two records.
• A service in ITSM is an asset in scope for GRC. Same thing, two registers.
• An owner in ITSM is an accountable party in GRC. Same person, two contact lists.

Once you see it that way, the question stops being “should we link these systems?” and becomes “why on earth did we ever split them?”.

The honest answer is that the tooling forced the split. Enterprise ITSM and GRC suites grew up separately, were sold by separate teams to separate buyers, and the integration was always somebody else’s problem. So the integration ended up being a person (often a junior consultant) copying things from one tool to another.

What Anzen tries to do

Anzen starts from the assumption that there is one CMDB, one process catalogue, one risk register, and one audit trail, serving both sides.

A few things fall out of that:

• Your CIs are scored for risk, and the risk score follows the asset wherever it appears.
• Process models capture both the service flow and the control points. You draw it once.
• Evidence for audits is a byproduct of running the service, not a quarterly fire drill.
• Changes, incidents, and access requests automatically populate the audit trail you would otherwise have had to assemble manually.

It isn’t magic. It is just refusing to pretend the two worlds are different.

What’s in it for businesses

For the practitioner: less double bookkeeping, fewer “can you re-export that for the auditor?” requests, and a real-time picture of where risk actually sits.

For the business: audit prep that takes hours instead of weeks, control evidence that auditors can self-serve, and the ability to act like a mature organisation without buying two enterprise platforms and a systems integrator to glue them together. That last point matters disproportionately for SMEs and scale-ups, which is who I had in mind when I started this.

For the auditor: a story that holds together, because it is the same story your operations team is already telling.

More

The platform lives at anzenplatform.com. If any of this resonates, or you think I’m wrong about something, let me know; the second case is more interesting than the first.

Norbert