The Target Operating Model (TOM) most IAM roadmaps skip

A roadmap isn't an operating model

We've written before about the four pillars a strategy needs and the phased roadmap that gets you there. Both answer "what, and in what order." Neither answers the question that actually determines whether any of it survives past go-live: who owns this once the programme team has moved on?

Without an explicit answer, the default answer is nobody — or worse, whoever's loudest in the room that quarter. Access certification campaigns quietly stop happening. Role definitions drift out of sync with how the business actually works. A platform that was architecturally sound at go-live degrades into exactly the kind of sprawl the programme was meant to fix, not because the design was wrong, but because nobody was accountable for keeping it right.

The governance structure, kept small on purpose

A TOM doesn't need a large org chart. It needs three things clearly defined, and clearly defined early — before the first phase ships, not after:

• A governance board. A small, multi-stakeholder group — security, IT, a real business sponsor — that steers direction, priorities, and risk trade-offs. Its job is deciding, not doing.
• An operations function. A centralised team accountable for strategy execution and day-to-day running: provisioning, reviews, exception handling. Distinct from the governance board, which shouldn't be approving individual access requests.
• A hybrid model, not a pure one. Fully centralised control doesn't scale to every application owner's actual context; fully delegated control loses consistency within a quarter. The model that holds is centralised IAM services with delegated business-unit accountability for what only the business unit actually knows — who needs access to what, and why.

Accountability has to have a name on it

"IT owns identity" isn't accountability — it's diffusion. What actually holds up:

• IAM Owner. Accountable for the strategy, the investment case, and compliance — the person a board asks when something goes wrong.
• IAM Operations. Runs provisioning, reviews, and onboarding/offboarding day to day. The team that keeps the lights on, not the team that decides policy.
• Application Owners. Define what access their own system actually needs, and complete the periodic reviews for it. Nobody else can credibly do this — they're the only ones who know.
• HR / Identity Source Owners. Own the authoritative data the whole lifecycle depends on. Where this role is undefined, identity data quality degrades by default — see our piece on directory hygiene.
• Security & Risk. Enforce policy and monitor for audit and compliance gaps, independent of the team running day-to-day operations.

Processes need a maturity goal, not just an owner

Naming an owner isn't the same as defining what "good" looks like for what they own. Every core IAM process needs both:

• Identity lifecycle. Fully automated, integrated with HR as the authoritative source — not a manual process with an owner attached to it.
• Access requests. A self-service portal with real workflow and approvals, not an inbox someone monitors.
• Role-based access. Defined roles with automated entitlement mapping, reviewed as the organisation changes — not a one-time role-mining exercise nobody revisits.
• Privileged access. Vaulted, session-monitored, moving toward Just-in-Time rather than standing privilege.
• Access reviews. Periodic and risk-based certification campaigns that actually change something — not a rubber-stamp exercise. See why most campaigns fail at this specifically.
• Identity governance. Segregation-of-duties enforcement and audit reporting that runs continuously, not something assembled from scratch every time an auditor asks.

Key takeaways

• A roadmap and a TOM answer different questions. Both need to be written down; neither substitutes for the other.
• Keep the governance structure small and clearly split: a board that decides, an operations function that runs, and delegated accountability where only the business unit actually has the context.
• Every process needs a named owner and an explicit maturity goal — an owner with no target just maintains the status quo.
• Agree this before the first phase ships. Retrofitting accountability onto a live programme is a much harder conversation than having it upfront.