Veza and ServiceNow: Building a Continuous Identity Governance Programme

By Iconica Editorial, Iconica

9 min read · Updated August 2026

Table of contents

Summary

ServiceNow's acquisition of Veza puts continuous identity governance natively inside the platform for the first time, rather than bolted on through a third-party integration. That's a meaningful architectural shift — but turning on a capability and operationalizing it as a governed, continuous programme are two different projects, and the gap between them is where most identity governance initiatives stall.

Identity governance has moved from a compliance checkbox to a board-level concern faster than almost any other security discipline in the past two years. The reason is straightforward: as agentic AI takes on more operational work inside the enterprise, the question of who — or what — can access which data and take which action stops being an IT hygiene issue and becomes a question about the organisation's actual risk surface. A dormant service account with excessive privileges was always a problem. A dormant service account with excessive privileges that an AI agent can now discover and use is a materially different one.

ServiceNow's acquisition of Veza, which closed in March 2026, is a direct response to that shift. It's worth being precise about what changed, because the architectural implications are different depending on whether Veza is understood as a bolt-on integration or as a newly native capability.

‍

What Actually Changed When ServiceNow Acquired Veza

Before the acquisition, Veza operated as an independent identity security platform — its Access Graph mapped permissions and entitlements across cloud, SaaS, on-premises, and custom systems, and organisations that wanted that visibility inside their ServiceNow workflows did so through integration. That's no longer the architecture. Veza is now part of ServiceNow's Security and Risk portfolio, which means identity governance capability — visibility into who can take what action on what data, across human, machine, and AI identities — sits inside the platform rather than alongside it.

For a platform owner, this is a genuinely different starting position than "which identity governance tool should we integrate." The question becomes: how do we operationalize a native capability that now exists inside the platform we already run, and how do we build the governance discipline around it so that it delivers continuous value rather than a one-time visibility exercise.

That distinction — activation versus operationalization — is where this article is really aimed, because it's where most identity governance programmes quietly fail.

‍

Why Identity Governance Became a Board-Level Issue

Traditional identity governance and administration tools were built around a directory-centric model: track users, track groups, track role assignments, run periodic access reviews. That model was already straining under cloud sprawl and SaaS proliferation. It breaks down further once non-human identities — service accounts, automations, and now autonomous AI agents — start outnumbering human users inside the environment, often by a wide margin.

The result is a familiar pattern across large enterprises: access reviews that technically happen on schedule but rubber-stamp entitlements nobody has actually verified, dormant accounts that were never deprovisioned, and permission sprawl that accumulates quietly until an audit, a breach, or a board question forces a reckoning. Boards are asking that question now because the cost of getting it wrong has changed shape. It's no longer just a compliance fine. It's an AI agent with more access than anyone intended, acting at machine speed, inside systems the organisation depends on to run.

This is exactly the gap that a native identity capability inside ServiceNow is positioned to close — provided the organisation treats it as a governance programme and not a feature switch.

‍

The Difference Between Turning It On and Governing It

Here is where architecture matters more than most organisations expect. Enabling a native identity governance capability gives you visibility. It does not, on its own, give you a programme.

A genuine continuous identity governance programme requires several things that don't come pre-built with any platform capability, no matter how well designed:

Ownership that is actually assigned. Someone — a named role, not a committee — has to own the accuracy of entitlement data, the cadence of access reviews, and the escalation path when a review surfaces a risk. Without a named owner, visibility data accumulates and nobody acts on it.

Baselines defined before drift is measured. You can't know whether access has drifted from what's appropriate unless "appropriate" was defined first, for each system, each role, and each class of identity — human and non-human alike.

Integration into existing governance cycles, not a parallel process. Identity risk needs to show up in the same architectural and platform health reviews that already govern the rest of the ServiceNow estate, not live in a separate security team's dashboard that platform architects never see.

A plan for non-human and AI identity specifically. This is the fastest-growing risk category and the one legacy processes were never built to catch. Service accounts and AI agents don't self-report when their access no longer matches their function — someone has to design the review process that catches it.

None of this is a Veza-specific requirement. It's the same architectural discipline that determines whether any powerful platform capability becomes a lasting operational advantage or an expensive dashboard nobody consults after the first quarter.

‍

Why This Is an Architectural Problem, Not a Security Team Problem

The instinct in most organisations is to hand identity governance to the security team and consider the platform team's job done once the capability is switched on. That instinct is understandable and usually wrong.

Identity governance touches the same architectural decisions that govern everything else on the platform: how roles are structured, how entitlements are inherited, how new modules and integrations get provisioned, how technical debt in access design compounds over time if nobody is accountable for catching it early. An architect who is only in the room for functional delivery — and absent from identity governance design — is missing the piece of the platform most likely to become the next compliance finding or the next headline breach.

This is precisely the failure mode of the fragmented delivery model, where the team that designs the platform's workflows and the team that governs its access controls have never spoken to each other, let alone shared a roadmap. Architectural governance that's embedded in every delivery decision — not bolted on as a separate security workstream — is what closes that gap. It means access design gets the same architecture decision record treatment as any other significant platform choice, and it means platform health reviews catch identity risk before it becomes remediation cost, not after.

‍

What a Continuous Programme Looks Like in Practice

A continuous identity governance programme, done properly, follows the same discipline Iconica applies to outcome measurement more broadly: define what's being measured and who owns it, instrument the platform to surface it, track it on a regular cadence, steer when it drifts, and report it in terms the board actually understands.

Applied to identity, that means access reviews that are risk-weighted rather than blanket exercises that treat every entitlement the same. It means dormant accounts and excessive privileges get surfaced automatically and reviewed on a defined schedule, not discovered during an incident response. It means non-human and AI identities are brought into the same governance loop as human users, with an owner accountable for each. And it means identity risk posture becomes a standing item in governance reviews, not a once-a-year audit response.

None of that happens because a capability exists inside the platform. It happens because someone designed the programme around it — the same way a strategic roadmap has to be designed around a platform vision, not assumed to follow automatically from good intentions.

‍

The Real Question for Platform Owners

The acquisition puts a genuinely capable identity governance engine natively inside the platform most enterprises already depend on. That's a real architectural advantage over a fragmented, multi-vendor identity stack — but only for organisations that treat it as the start of a governance programme rather than the end of a procurement decision.

The question worth asking isn't whether the capability exists. It's who owns it, what it's measured against, and whether it's reviewed with the same rigour as every other architectural decision on the platform. Those are the questions an architect-led rollout answers before go-live — not the questions that get asked for the first time after an audit finds the gap.

‍