Ownership-model reference
Someone answers for every one of them.
Who owns what in the operating model, what each owner decides, and what happens to that ownership when people, teams, and whole companies move.
This is the reference the book points to. It puts every kind of owner the model names in one place, says what each one is accountable for, and then covers the part most programs never write down: how ownership survives a transfer, a reorganization, an acquisition, and the owner who simply leaves.
None of this requires a particular org chart. It requires that the roles be named, written down, and known. An owner who does not know they are the owner is not an owner. They are a name in a diagram. The Modern Identity Operating Model, Chapter 6
In brief
- An owner is the person accountable for the outcome, not necessarily the one doing the work.
- Ten kinds of owner and what each one decides, plus the eight decision lines that get tangled most.
- How ownership survives joiners, movers, leavers, reorganizations, and acquisitions, and what to do with ownership that has gone quiet.
Test yourself with ten questionsAbout 16 minutes to read in full
This page extends Chapter 6, Pillar One: Governance, and Chapter 7, Pillar Two: Lifecycle of The Modern Identity Operating Model.
Before the list
What owning actually means
The responsible person does the work. The accountable person makes sure the right work happens and answers for the outcome. An owner, in this model, is the accountable one. An application owner does not have to know what every permission does. They have to be the person who can say, a year from now, why this access exists and who should have it, and who acts when that stops being true. Chapter 4 says it plainly:
Ownership does not mean doing all the work. Ownership means being accountable for how the work is done.
You can test ownership for three things. It is explicit: written down somewhere other than someone's memory. It is current: the name belongs to someone who still holds that job. It is actionable: the owner knows they are the owner, can see what is tied to their name, and has somewhere to escalate. Most environments have the first in places. Very few have all three.
The owners the model names
Ten kinds of owner, and what each one decides
In a small program one person may hold four of these. What cannot happen is for any of them to be unassigned, or for two of them to be quietly collapsed into one because it was convenient.
Owners of systems and access
Where the meaning of access lives, and who decides who gets it.
1Business owner
Answers for what a system is for: its purpose, value, risk, and who should be able to use it. Deciding who gets access is a business judgment, so the approval belongs here even when someone else carries it out. The business owner is also accountable for what the access means, the mapping from "make this person a lead auditor" to the permissions that implement it. They can lean on admins or the vendor for the details. The accountability stays with them.
Decides: access to the application and what its access roles contain. Watch for: the orphaned application whose owner left, and the rubber stamp on five hundred raw permissions nobody could read.
2Technical owner
Answers for how the system runs: configuration, integrations, reliability, day-to-day operation. Owns the application baseline and oversees the procedures operations follows.
Decides: the baseline, retiring a service account, rotating a production credential. Watch for: becoming the default approver because they sit closest to the system. They understand the configuration, not the business risk of the access.
3Entitlement and access role owner
If the business owner holds the purpose of the system, the entitlement owner holds the door to one room inside it. An access role owner answers for a bundle: what it includes, what it deliberately excludes, and whether it still matches the work. This is the owner over time, usually not the person who built it.
Decides: who gets a specific entitlement, and whether a role still makes sense at review. Watch for: groups with no owner and no description, which is access no one is accountable for and no one can explain.
4Manager
Not an owner of systems, but the other half of almost every access decision. The manager knows whether someone in this job needs this access. The owner knows whether the access is safe to hand out. A review that asks only the manager is half a review.
Decides: need, and triggers most of the events that should change access. Watch for: the accidental owner. When an owner leaves, their manager usually holds the role until it is backfilled, often without being told what that involves.
Owners of truth and of the identities themselves
Where an identity comes from, and who vouches for the ones nobody hired.
5Authoritative source and data owner
HR owns employee lifecycle truth. Procurement and vendor functions shape it for non-employees. CI/CD and platform engineering are often the source for workloads. The handful of attributes that drive identity behavior each need an owner, a definition, and a known source.
Decides: what the data says, and who fixes it upstream. Not what anyone may access: authoritative is a claim about identity data, not about access.
6Sponsor of a non-employee
A named person inside the organization who vouches for a contractor, consultant, vendor, or partner and is accountable for them. The sponsor is the reason an identity you did not create has an owner at all. Collaboration guests get a lighter version: an invitation owner and an expiration.
Decides: scope, extensions, and when the work has ended. Watch for: federated access that outlives the contract because procurement never told the access owners.
7Nonhuman identity owner
Every service account, workload identity, API client, bot, secret, and certificate has a human owner who answers for its purpose, credential handling, review, and retirement. Service accounts follow the application they serve, so this owner is usually tied to that application's owner.
Decides: when the work is done and the credential is revoked, not just paused. Watch for: the migration account still running years after the migration.
8AI agent sponsor
An agent cannot be held accountable for what it does, so accountability has to land on a person. The sponsor owns the agent's purpose, delegated boundaries, review cadence, and shutdown path, and is accountable for its behavior.
Decides: whether the agent should exist, what it may do on its own, and when its purpose has ended. Watch for: an owner on the agent and none on what the agent creates.
Owners of the model itself
Who holds everyone else to account, and who carries the risk nobody has fixed yet.
9The identity function, as trusted advisor
Identity has two jobs: governing, which means owning the standards, the model, and the process, and operating the identity systems. Sometimes those live in two teams, sometimes one. Either way identity does not become the owner of the systems and access it governs. It counsels the owners, and when an owner falls short it advises on remediation rather than taking it over. The enterprise IAM tools are themselves a system, with their own business and technical owner.
Decides: the standards and the shape of the model. Watch for: advising that hardens into ownership, where identity is made accountable for decisions that were always someone else's, with none of the authority.
10Risk owner, and the sponsor of the work
Every exception and accepted risk needs a named owner with authority to carry it and a closure condition. GRC usually owns the method: the register, the criteria, and who may accept what. Separately, change that sticks has an active sponsor, a leader who tends to track whoever owns the identities in scope.
Decides: which gaps the organization will live with, and for how long. Watch for: the exception with no expiration date. It is not an exception. It is a pet.
Decision rights
Eight lines that get tangled most
Figure 6.1 in the book is the short form of a decision-rights matrix for the eight activities every identity program has to assign. Here it is in words, accountable role first. Every organization draws these lines a little differently. The right version is the one yours writes down and agrees to.
- Define the IAM standards. The governance side of identity holds both.
- Approve access to an application. The business owner holds both.
- Approve a specific entitlement. The entitlement owner is accountable; the business owner is responsible. This is the line most often assigned wrongly.
- Own the application baseline. The technical owner holds both.
- Own the SOPs and procedures. The technical owner, with operations doing the work.
- Operate the application. The technical owner, with operations doing the work.
- Own the enterprise IAM tools. The governance side of identity is accountable; the operating side is responsible.
- Remediate when an owner falls short. The business owner is accountable; the technical owner is responsible. Identity advises.
The full-size figure is on the figures page. The last line is the one that protects the identity team. When an owner falls short, the fix still belongs to the owners, and the model says so before the first argument about it.
When people move
Ownership through joiner, mover, and leaver
Joiner, mover, leaver is usually told from the point of view of a person's own access. This is the other direction: what happens to the things a person owns. A model that tracks what someone holds, and never what they answer for, loses owners quietly every quarter.
Joiner
Ownership is assigned at creation, not discovered later. Worker type is the first required field, because it decides what else is required: a sponsor, scope, and end date for a contractor; an owner and expiration for a guest; an owner, purpose, and review path for a service account or agent.
Mover
Before the move takes effect, list every object tied to the person's name, the roles, groups, service accounts, agents, and sponsored contractors, and name who inherits each one. A role change is not always an authority change, so some ownership may rightly stay. That should be a decision, not a default.
Leaver
The departing owner's objects go to the named backup, or to their manager as acting owner with a date to name a real successor. Then reroute the reviews. An owner certification with no owner behind it has nowhere to go, and nothing in the system says why.
Name ownership as a role wherever you can, so it survives turnover, and let the workflow resolve that role to whoever holds it today. When names are typed into the workflow instead, it keeps routing to the old owner long after the reorganization, because nothing tells it not to.
When the org chart moves
Reorganizations, acquisitions, and divestitures
A single mover is a handful of objects. A reorganization is hundreds changing hands in one announcement, and nobody files a ticket for the ownership side. The lean team in the book's seventh case study held its rules steady through rapid growth, and ownership stayed explicit when the org chart shifted. Treat a reorg as a lifecycle event in its own right.
Reorganization
- Pull the Ownership Map for every team in scope before the announcement. Filtered by owner and backup, it is the list of what is about to move.
- Reassign by decision, not inheritance. Start with privileged and regulated objects.
- Check what the platform still believes. Platform logic never revisited after a merger or reorg is one of the book's named forms of technical debt.
Acquisition
- Map ownership twice, once per estate, before anyone merges anything.
- Capture what the acquired team knows while they are still there. That window closes.
- Give every system that crosses an owner, a lifecycle, and an end condition. The ones that get none settle into a third state, neither retired nor adopted.
- Decide each account no one can explain: keep it with an owner attached, or turn it off and watch what breaks.
Case Study 9, in Chapter 23, ends on the line to keep:
Retirement by coincidence is not lifecycle. An estate the model cannot end is an estate the model does not govern.
Divestiture
The question runs in reverse: can you separate one population's access from another's without leaving orphaned accounts in either direction. Any object whose owner, sponsor, or source sits on the other side of the line needs a decision before the separation date.
When there is no one to ask
What to do with orphaned ownership
Every environment has some: the service accounts where the room went quiet, the groups with no description, the application whose owner left two reorganizations ago. This is the order the book's own stories work in.
1Make them visible, then narrow the list
Reconciliation, posture tooling, the catalog, and the CMDB all surface ownerless objects. Verify the CMDB before trusting it; an unreconciled one names owners who left years ago. Then sort by reach. Four hundred ownerless groups is visibility. Ten with privileged access, stale membership, and no business owner is a finding.
2Start with your own
In the book's first-wave story, the team named owners for the groups it had access to before asking anyone else to account for theirs, then moved to partners who already trusted it.
3Find the right owner, then set them up
Follow the access to the work it supports, and the work to the business owner. Tell them they now decide who has access and answer when it needs a call. Then make sure they can see what is tied to their name and have somewhere to escalate.
If they refuse: listen to why. In the book, an owner who rejected accountability for a sprawl of ERP instances had a point: it had been assigned on paper and never built. Once the processes were documented and the gaps had somewhere to sit, they took it.
4Decide the ones no one will claim
Turn off what nothing depends on and watch. What cannot be turned off goes to the escalation path your matrix names for unresolved ownership gaps, and into the risk register with a risk owner and a date. Not to the identity team by default.
Done looks like: every object is owned, retired, or carried as a risk someone with authority accepted. Nothing is simply there.
The identities that do not have a manager
Nonhuman and AI ownership
Human identities follow employment. Non-employees follow sponsorship. Service accounts follow their application, workloads follow deployment, and agents follow delegated authority. What changes with nonhuman and AI identities is that nobody notices when they should have ended. A finished task starts nothing at all, so the owner has to be the one who notices.
Own the credential, not only the account
Secrets and certificates need owners of their own. Every identity an agent creates should carry an expiration or review date the moment it exists, because it was born unowned.
Make the sponsor feel it
When an agent's run-rate lands on a named owner's cost center, certifying its access stops being free. And the record has to tell sponsor and agent apart, or the person answers for actions they never took.
When someone else runs it
A provider can run the work. You still own the outcome.
Outsourcing becomes dangerous when ownership is outsourced instead of execution. In a healthy arrangement, ownership and the core knowledge of the model stay inside; execution can sit outside. Chapter 20 says it in two sentences:
You can outsource activity. You cannot outsource accountability.
Every owner on this page still exists when a managed service provider runs the systems. What changes is how they exercise it: lifecycle you would enforce yourself becomes lifecycle you contract for. The book's five questions for any provider are a fair test of whether your owners are owning: who has access right now, who reviews it and signs off, what happens within twenty-four hours of a termination, how individual action is tracked on shared or admin accounts, and what you get back if you leave. Case Study 8 is the shared provider account that could not be offboarded when one engineer left.
Write it down
How the Ownership Map and the Decision-Rights Matrix fit
The Ownership Map is about things: for each object, who owns it, who backs them up, what it is for, how often it is reviewed, and how sure you are. The Decision-Rights Matrix is about decisions: for each recurring call, who approves, where it escalates, and what evidence has to exist.
The map says who owns a given entitlement. The matrix says approving it is that owner's call. A request needs both to route correctly. Start with the map if you do not know who owns things. Start with the matrix if you do, and approvals still stall on "I thought someone else owned that."
An illustrative example
The three rows from Figure 24.1. Names and objects are invented.
svc-payroll-etl
Service account, owned by D. Reyes in Finance. Nightly payroll extract. Confidence high. If D. Reyes moves teams, the mover step names who inherits it first.
APP-CRM-ADMINS
Group, owner unassigned, purpose unclear, predates the migration. Confidence none. This is the row the map exists to produce. It is privileged, so it goes near the top of the orphan list.
agent-ticket-triage
AI agent, sponsored by K. Osei on the Service Desk. Routes inbound tickets. Confidence low. The matrix row for agent onboarding says who closes that gap and with what evidence.
Do not leave the confidence column blank. A low is not a failure. It tells you where to look next.
Ownership Map
One row per object: owner, backup, purpose, cadence, confidence.
Decision-Rights Matrix (RACI)
One row per decision: approvers, escalation, evidence.
Governance Exception Record
For ownership gaps you decide to carry, with an owner and an end date.
Stakeholder and Sponsor Map
Who shapes identity truth, who carries the change, and who sponsors it.
AI Identity Intake Form
An agent's sponsor, boundaries, and deactivation plan, before it acts.
System-level owners live in the Identity System Catalog. The rest of the pack is on the templates page.
Test it
Ten questions for your ownership model
- Can you list the identity objects that have no owner? Not estimate. List.
- Does every application have a named business owner and a named backup?
- Do approvals ask both questions, the manager on need and the owner on risk?
- Can an identity that holds privileged access be created with a blank owner?
- Does a transfer reassign what the person owned, not only what they held?
- When an owner leaves, does their review go somewhere, or silently skip?
- Does every non-employee have an inside sponsor?
- Does every agent have a sponsor who knows they answer for its behavior?
- Is the identity team the owner of anything it does not control?
- Has anyone told each owner that they are the owner?
For a pillar-by-pillar reading, the Predictability Assessment asks about ownership in more than one pillar. Terms are defined in the glossary.
From the book
The longer treatment
This page gathers ownership from across The Modern Identity Operating Model:
- Chapter 6, "Who Owns What, and Why It Has to Be Said Out Loud" and "When Advising Hardens Into Ownership." The owner types and the identity function as trusted advisor.
- Chapter 12, "Decision Rights Are the Spine of Governance." The minimum decision rights, and worker type as the first required field.
- Chapter 13. Authoritative sources, sponsors for external identities, and nonhuman and agent lifecycle.
- Chapter 14, "The Application Owner Is Accountable for What Access Means." Design, then ownership, then review.
- Chapter 20 and Case Study 8. Managed service providers, and why the outcome stays yours.
- Case Studies 2 and 9, and Templates 1 and 2 in Chapter 24. Acquisitions, and the two artifacts on this page.
Go deeper in the book
Chapter 6, Pillar One: Governance, and Chapter 7, Pillar Two: Lifecycle, cover why ownership drifts and how the pillars keep it in place.
Coming soon: get notified