The Entitlement Catalog: Inventorying and Classifying Access

“Finance Access”

A manager opens her quarterly access review and finds, next to the name of one of her analysts, an entry called “Finance Access.” She has no idea what it grants. It could be read access to a shared folder of reports. It could be the ability to approve payments. She approves it, as she approves the other forty entries on the list, because rejecting something she doesn’t understand might stop her analyst from working, and the review is due on Friday. Three weeks later, during an unrelated investigation, it turns out “Finance Access” included the ability to change the bank details on supplier records.

That entry, and the review that couldn’t catch it, is the problem this article is about. The previous article built the governance around joiner, mover, and leaver events and kept talking about “the standard bundle for this job” and “the access tied to the old job” as if those bundles were well defined. In most organizations they aren’t. Nobody can say exactly what’s inside them, the names mean nothing outside the system that created them, and half of what they contain has no owner. The entitlement catalog is where a program fixes that: what’s actually being granted, what it should be called, and who answers for it.

Everything earlier in this module acts on entitlements: birthright grants, the mover’s removal and grant, the leaver’s full removal. Everything later depends on them too. Separation-of-duties rules, access reviews, and role design are only as trustworthy as the catalog underneath them.

Permission, entitlement, role

Ask almost any organization what access someone has and you’ll hear a mix of words used as if they meant the same thing: permissions, entitlements, roles, rights, access. IGA needs them to mean different things, because policy, reviews, and automation all depend on knowing which layer they’re working at.

A permission is the raw technical grant a system enforces: SELECT on the invoices table, a specific OAuth scope, a checkbox in an admin console, membership in an Active Directory group. Permissions are what the system knows about. They rarely mean anything to people outside the team that built the system’s authorization model.

An entitlement is the business layer built on top of one or more permissions, and it’s the unit IGA actually governs. “Approve purchase orders up to $10,000” is an entitlement. Underneath it might sit a role assignment in the ERP, a permission in the workflow engine, and a subscription in the notification system: three technical grants a business person never needs to see. An entitlement is defined so that a reviewer, a manager, or an auditor can read its name and description and form a real opinion about whether a particular person should have it.

A role, in this sense, is a named bundle of several entitlements assigned together to everyone in a defined population. It’s the “standard bundle” from the JML article, made explicit. A role exists so that onboarding a new hire or reconciling a mover’s access is one governed action instead of a dozen separate requests.

flowchart BT
  accTitle: Permissions compose into entitlements, which bundle into roles
  accDescr: Several technical permissions from different systems combine into one business entitlement, approve purchase orders up to ten thousand dollars. That entitlement, together with viewing vendor master data and submitting payment batches, is bundled into the Accounts Payable Clerk role. Reviews and access requests work mainly at the entitlement layer.
  P1[ERP role assignment<br/>permission] --> E1[Approve purchase orders<br/>up to $10,000<br/>entitlement]
  P2[Workflow engine permission] --> E1
  P3[Notification subscription] --> E1
  E1 --> R1[Accounts Payable Clerk<br/>role]
  E2[View vendor master data<br/>entitlement] --> R1
  E3[Submit payment batch<br/>entitlement] --> R1

The distinction matters in practice because each layer changes for different reasons, at a different pace, under a different owner. Permissions change whenever an administrator reconfigures an application: often, technically, mostly invisible to governance. Entitlements change when the business meaning of a function changes: occasionally, and deliberately. Roles change when the organization redefines what a job needs: least often of the three, and the subject of the role engineering article later in this domain.

Getting the granularity right

Once the layers are clear, building a catalog comes down to one recurring judgment: how fine should each entitlement be? Getting it wrong in either direction undermines the governance the catalog is supposed to support.

Too fine, and the catalog simply re-exposes the raw permission model under a thin translation: hundreds of nearly identical entries per application, each a small variation on the last. A reviewer facing that list doesn’t review it. They scroll, because nobody can hold two hundred near-duplicates in their head long enough to judge each one. It’s the same fatigue the data model article described for duplicate identities: enough noise, and a reviewer stops reading and starts approving.

Too coarse, and the entitlement hides distinctions a reviewer would want to see. Bundling “view invoices” and “approve invoices” into a single “invoice access” means whoever reviews it can’t tell whether the person can only look at invoices or can approve them too. That difference matters enormously for separation of duties, and the catalog just erased it. “Finance Access” is the extreme version.

A test that usually settles it: could two people holding this entitlement need different answers to “should this be removed”? If one person’s access is clearly justified and another’s clearly isn’t, but the catalog only has one entry covering both, it’s too coarse. If a reviewer would never realistically decide differently between two adjacent entries, they’re probably one entitlement wearing two names, and it’s too fine.

Discovery, then curation

A catalog isn’t designed on a blank page. It’s built from what already exists, in two passes that are easy to blur together and shouldn’t be.

Discovery is mechanical. You connect to each target system and list its raw permissions: every AD group, every database role, every SaaS permission set and API scope. It’s largely automatable, using the same connectors that provisioning uses. Discovery answers what technically exists, and in an organization of any size the honest answer is usually alarming: thousands of groups, many unused, many overlapping, many named by whoever created them years ago in a way that made sense only to them.

Curation is the judgment discovery can’t make. It decides which of those thousands of permissions deserve to become a smaller number of named, owned, business-meaningful entitlements, and which are noise, duplication, or dead access nobody should be governing because nobody should have it. Curation is where the granularity test gets applied, one entitlement at a time, and it’s a human effort, led by application owners who know what each permission really does rather than what it’s called in the admin console.

A worked curation example

A regional insurer’s claims system has been running for eleven years and has 340 permission groups in its admin console, the product of more than a decade of one-off requests, each granted as its own group because that was the quickest way to satisfy one person’s ask. Nobody at the company can explain half of them, and several differ from each other by a single character.

The claims operations owner and IAM engineering curate them together. They start with usage: which groups have any active members at all. About 40% have none and are dropped. Interviews with the claims operations owner then show that the remaining groups map to a handful of real business distinctions: viewing a claim, adjusting a claim’s reserve, approving a payout below a threshold, approving one above it, and closing a claim file. Five entitlements, clearly named, each owned by the claims operations owner, replace 340 groups nobody could explain. More importantly, the five correspond to genuinely different levels of risk and authority, which the 340 groups had obscured rather than clarified.

A second case starts from a different place. A fast-growing SaaS company’s CRM was configured by three administrators over four years, none of whom talked to the others, leaving 28 custom permission sets with names like “Team A Access” and “New Sales Perms.” Usage shows all 28 are assigned to someone, so there’s no dead weight to remove. But they reduce to four real distinctions: viewing pipeline data, editing your own opportunities, editing any teammate’s opportunities, and exporting contact data. The curated catalog ends up smaller than the raw list not because access was excessive, but because the same four capabilities had been reinvented under different names by people who never compared notes. The fourth one, exporting contact data, also turns out to be the one entitlement that needs a higher risk tier and a narrower set of holders, something nobody could have seen while it was spread across six differently named permission sets.

Where to start curating

No program curates every permission in every system at once, and trying to is a good way to stall for a year. A sensible order puts the systems that carry the most risk first: those in scope for regulations such as SOX or PCI DSS, those holding customer or patient data, and those with financial authority. Inside each system, the permissions held by the most people come before the long tail, because they affect the most reviews and the most requests.

A useful rule of thumb is that a small fraction of permissions usually accounts for most assignments. Curating that fraction first gives reviewers readable entitlements for the bulk of what they see, while the long tail waits, flagged as uncurated, for a later pass. Labeling uncurated permissions honestly in the meantime, instead of letting them masquerade as entitlements, keeps reviewers from assuming more has been cleaned up than really has.

What each entitlement records

An entry in the catalog is more than a name. A catalog that only stores names forces every downstream process to rediscover everything else, so most mature catalogs settle on a common set of fields for each entitlement.

There’s the technical mapping: which permissions in which system the entitlement stands for, kept current as the system changes. There’s the structured name and the plain-language display name, with a short description of what it allows and who typically needs it. There’s the owner and a backup owner. There’s the risk tier and the reason for it, and the populations eligible to hold it. There’s whether it can be requested at all, or only assigned through a role or a policy. There’s the review cadence its tier implies. There are tags that separation-of-duties rules can refer to, such as “creates vendors” or “approves payments,” so conflict rules can be written once against tags instead of against every individual entitlement. And there’s its lifecycle state.

Keeping these fields in the catalog, rather than scattered across spreadsheets and the memories of application owners, is what lets an access request, a review, and a conflict check all read the same answer. Not every field has to be filled on day one. Owner, risk tier, and description are the ones reviews and requests depend on most, so they come first; the rest can follow as the catalog matures.

An entitlement has a lifecycle too

Treating curation as a one-time project misses the fact that entitlements age, just as individual access does. A catalog needs a few defined states and a process for moving entitlements between them, or it becomes the kind of stale artifact the JML article warned about for birthright bundles: correct on the day it was built and quietly wrong two reorganizations later.

stateDiagram-v2
    accTitle: The lifecycle of an entitlement in the catalog
    accDescr: A proposed entitlement becomes active once it has an owner, a risk tier, and a final name, and can then be assigned to people. An active entitlement can be revised, changing its name or definition while keeping its identity, or deprecated when a system change or reorganization makes it inaccurate. A deprecated entitlement has its assignments moved or removed and is then retired, staying in the catalog as a record but no longer assignable.
    [*] --> Proposed: Discovery and curation identify a candidate
    Proposed --> Active: Owner assigned, risk tier set, name final
    Active --> Active: Revised
    Active --> Deprecated: No longer accurate
    Deprecated --> Retired: Assignments moved or removed
    Retired --> [*]

The state most catalogs skip is “deprecated” as a distinct, tracked step rather than silent abandonment. An application changes its permission model, and an entitlement that used to map cleanly onto it now describes something slightly different, or nothing at all. Without a deprecation step, the entitlement keeps existing, keeps being assigned to new hires through whatever role includes it, and keeps appearing in reviews that people approve because the name still sounds plausible. Deprecation forces the question: does this still describe something real, and if not, where does everyone who holds it need to move?

A naming scheme that survives a dozen systems

A catalog spanning dozens of applications fails quietly if each application names its entitlements in its own local style. “AP_Approve_10K,” “Invoice-Approval-Tier2,” and “FinanceApprover3” might all describe the same authority, and without a consistent pattern nobody, not a reviewer, not an auditor, not a search, can tell.

A pattern most mature catalogs settle on is System.Function.Level: the application, the business function, and where relevant a level or threshold that sets it apart from neighbors in the same function. Applied consistently, ERP.PurchaseOrderApproval.Under10K and ERP.PurchaseOrderApproval.Over10K sit next to each other in any sorted list, visibly related and visibly different, in a way “AP_Approve_10K” and “AP_Approve_Senior” never would.

The naming doesn’t change what any of these grant. It changes whether a person looking at the catalog can tell, without opening four admin consoles, that the first two rows are two tiers of the same authority and the last two belong to a completely different function. That legibility is what makes a catalog usable in a review rather than merely complete.

The technical name isn’t the only one that matters. People requesting access need a plain-language display name and a one-sentence description (“Approve purchase orders up to $10,000; usually needed by AP supervisors”), and the access request article covers how that presentation layer shapes what people ask for. The structured name serves reviewers and auditors; the display name serves everyone else. A good catalog keeps both.

Every entitlement needs an owner

Every entitlement in the catalog needs a named owner, usually the application or business owner accountable for that system or function. The reason is the same one the data model article gave for why every account needs an owning identity: an entitlement without an owner has nobody who can say whether a person should have it, and why, with real business context. It accumulates the same way an orphaned account does. Nobody notices when it’s wrong, because noticing isn’t anyone’s problem.

Ownership isn’t a label attached once. It’s an ongoing responsibility with two concrete jobs. The owner is the approver of record when someone requests the entitlement, the person a workflow routes to. And the owner is the person a review campaign asks to confirm that the entitlement’s assignments are still correct, and who should periodically check the entitlement itself: whether it still describes something real, whether the threshold in Over10K still matches the actual approval policy, whether it should be split, merged, or retired.

Ownership also needs a successor, which is easy to forget until the owner leaves. An entitlement whose only owner just went through their own leaver event is back to ownerless until someone deliberately reassigns it. The catalog should be part of what a leaver’s manager or HR handover checks, alongside the more familiar job of transferring the departing person’s reports and open work.

Classifying entitlements by risk

Not every entitlement deserves the same scrutiny, and a catalog that treats them all alike wastes effort on the low-risk majority while under-reviewing the few that matter. A small number of risk tiers, set for every entitlement during curation, lets the rest of the program, approval routing, review frequency, separation-of-duties policy, treat entitlements differently without arguing about risk every time.

The JML article talked about sizing approvals and escalation windows by risk; this is what that assumed. A tier can’t drive an approval workflow or a review cadence until every entitlement has been explicitly given one, and that’s a curation decision, not something a workflow engine can work out on its own.

The tier deserves a written reason, not just a label, because two entitlements that look alike can end up in different tiers for reasons a later reviewer will need to understand. Approving purchase orders up to $10,000 and up to $500 are both purchase order approval, but the threshold alone can put one in “elevated” and leave the other in “standard.” That reasoning belongs in the entitlement’s definition, not in the memory of whoever set the tiers.

The catalog covers more than employees

The data model article separated employees, sourced from HR, from contractors, vendors, and service accounts, sourced elsewhere. The catalog has to reflect that split, because what someone should be allowed to hold isn’t the same across those groups even when the entitlement is technically identical.

A service account should almost never be eligible for anything above “standard” without an explicit, documented exception. A non-human identity with privileged, unreviewed access turns up disproportionately often in breach post-mortems, precisely because nobody gives it the scrutiny a human identity gets by default. Contractors are often eligible for less than employees by policy, not just by job: some organizations exclude non-employees from every “privileged / critical” entitlement regardless of the work, because a shorter, less certain engagement makes ongoing accountability harder.

The practical consequence is to record eligibility as an attribute on every entitlement: which of the employee, contractor, and service-account populations may hold it. Otherwise it gets discovered the first time a contractor receives something nobody meant to open to non-employees. Partner users who sign in through federation are worth naming as a fourth population so their exclusion is deliberate. Since this organization was never the authority on who they are, it generally shouldn’t assign its own entitlements to them through the same catalog that governs employees; their access is better modeled as a narrow, purpose-built integration.

Access that doesn’t live in a connected system

Discovery finds what connectors can see. Some access never shows up there, and a catalog that ignores it gives a false sense of completeness.

Shared credentials are the classic case: the login to a supplier’s portal that five people in purchasing know, the password to a social media account kept in a team vault, the token for a bank’s corporate website held by two people in treasury. Delegated access is another: someone with full access to their manager’s mailbox and calendar, granted years ago and never revisited. So are spreadsheets and scripts that hold embedded database credentials, giving anyone who can open the file a quiet way into a system that the catalog believes is tightly controlled.

Not all of this needs to become a formal entitlement on day one. But it should at least be inventoried, owned, and marked as outside automated provisioning, so that reviews and leaver processes know to ask about it. An honest catalog says which access it covers and which it doesn’t.

How catalog efforts go wrong

A few patterns recur often enough to name, because each produces a catalog that looks complete without being governable.

The first is cloning instead of curating. Under deadline pressure, someone takes one system’s existing group structure, relabels it, and calls it the catalog, skipping the work of testing each group against usage and business meaning. The result is as bloated and unmaintainable as the raw list it was meant to replace, with friendlier names.

The second is role explosion disguised as thoroughness. Modeling a slightly different combination for every variation in how a job is done, a senior AP clerk role for the east region, another for the west, another for remote staff, produces hundreds of nearly identical roles that nobody can tell apart or review meaningfully. It’s the role explosion problem the role engineering article deals with, and it starts here, at catalog design, when granularity discipline slips.

The third is treating the catalog as a one-time deliverable. A catalog built once, presented to a steering committee, and never revisited decays as fast as an unreviewed birthright bundle. New applications arrive without their entitlements entering the catalog, existing ones change their permission models without the catalog changing, and within eighteen months it describes a landscape that no longer exists. Someone has to own keeping the catalog itself current, separate from the individual entitlement owners. Most mature programs give that job to the same governance forum that owns separation-of-duties policy and review design.

What the rest of the domain builds on this

Two capabilities later in this domain depend on the catalog existing at the entitlement layer specifically.

Separation-of-duties policy has to name the entitlements that conflict, such as “approve purchase orders” and “create vendor records,” and that policy only means something if those names refer to stable, well-defined, well-sized entitlements. Written against raw permissions, an SoD rule would have to list every technical variant in every system, and would break the first time an application changed its model. Written only against roles, it can miss a real conflict inside a single role: two entitlements bundled into one role that should never have been combined, invisible to a check that compares only role names.

Access certification is only as good as what the reviewer is shown, and what they’re shown is entitlements. That’s why the granularity and naming work in this article decides whether a review is meaningful or a click-through. The data model article described reviews breaking quietly under duplicate identities; they break just as quietly under a badly designed catalog, where a reviewer approves something they can’t interpret, not because they’re careless, but because the catalog gave them “Finance Access.”

Measuring whether the catalog is healthy

The measures worth watching here are about the catalog as an artifact, separate from the measures for the processes that use it.

The share of entitlements with a named, confirmed owner says how much of the catalog has real accountability behind it; an unowned entitlement is ungoverned however well named it is. The share of entitlements reviewed within their tier’s cadence says whether risk-based review is actually happening or only defined; a privileged entitlement last looked at two years ago is a finding waiting to be found. The average number of permissions per entitlement is a rough signal of granularity; a figure that keeps climbing suggests entitlements are absorbing new permissions without anyone asking whether they still belong together. And the number of deprecated entitlements still assigned to people says whether deprecation is driving any change or just relabeling things.

None of these matter much as a single reading. The trend is the signal. A catalog where ownership is rising and deprecated-but-assigned entitlements are falling is one the program is maintaining; the reverse, even from a good start, is a catalog drifting back into the unmanaged sprawl it was built to replace. A quarterly snapshot of these four, reported alongside the JML and data quality measures from earlier in this module, gives a steering committee an honest view of whether the foundation is holding.

Where this maps to standards

The permission, entitlement, and role layers aren’t a house invention. They echo work the industry has converged on:

• ANSI/INCITS 359, the RBAC standard, formalized role-based access control as a layer between users and permissions decades ago. The composition of permissions into roles described here traces back to that model, even though most real catalogs add the entitlement layer in between to keep roles from becoming unmanageably fine-grained.
• The IDPro Body of Knowledge covers entitlement curation, ownership, and naming as practitioner discipline.
• SCIM (RFC 7643), introduced in the data model article for identity attributes, also defines a schema for groups and entitlement-like objects, useful for programs that provision entitlement assignments over SCIM rather than through proprietary connectors.

Closing the loop this module has been building

The first article described IGA as a loop: administration provisions and removes, governance decides and verifies. Each article since has built part of what governance needs to do its half in practice. An authoritative source and matching to know who (article 2). A reconciled, auditable lifecycle to know when access changes and whether it really did (article 3). And now a curated, owned, risk-tiered catalog to know what is being granted, removed, reviewed, and checked for conflict. None of the governance activities in this domain has anything concrete to work on without it. It’s the least visible layer of an IGA program, and the one everything else assumes is right.

Recap

• A permission is the raw grant a system enforces; an entitlement is the business unit built on one or more permissions; a role bundles entitlements for a population. Governance works mostly at the entitlement layer.
• The central design problem is granularity: too fine buries reviewers in noise, too coarse hides distinctions that matter, especially for separation of duties.
• Entitlements come from discovery, which lists raw permissions mechanically, followed by curation, a human pass that names, groups, assigns owners, and discards dead weight.
• Curate the riskiest systems and the most widely held permissions first, and label the uncurated rest honestly.
• Each entitlement records more than a name: technical mapping, description, owner, risk tier, eligibility, requestability, review cadence, SoD tags, and state.
• Entitlements have a lifecycle, and “deprecated” needs to be a real, tracked step.
• Inventory and own the access no connector sees, such as shared credentials and delegated mailboxes, even before it becomes a formal entitlement.
• A consistent naming scheme, such as System.Function.Level, plus a plain-language display name, makes the catalog readable across dozens of systems.
• Every entitlement needs a named owner who approves requests and confirms reviews, and a successor when that owner leaves.
• Risk tiers, set during curation with a written reason, let approvals, reviews, and SoD policy treat entitlements differently. Eligibility by population belongs on every entitlement.

Three questions to test yourself

1. A review shows a manager an entitlement called “Finance Access.” What’s wrong with it from a granularity standpoint, and what would a better design look like?
2. Why does this article argue that separation-of-duties policy should be written against entitlements rather than roles? Describe a situation where a role-level check would miss a real conflict.
3. A legacy system has 200 permission groups and no documented owner for any of them. Using this article’s curation process, describe the first three steps you’d take before proposing a single new entitlement name.

Hands-on exercise

Choose one application you use regularly and can see some of the permissions of, or imagine one in detail.

1. List every permission or group you know of in it, even approximately.
2. Group them into three to six entitlements using the granularity test from this article, and name each with the System.Function.Level pattern and a plain-language display name.
3. Assign each entitlement a risk tier with a one-line reason, and decide which populations (employees, contractors, service accounts) may hold it.
4. Name who should own each entitlement, and who would take over if that person left.