Entitlement Catalogue Guide: Describe, Own and Risk Rate Every Access Right

Access reviews, request workflows and segregation of duties checks all fail in the same way when the entitlement behind them is a cryptic string with no owner and no risk rating. A reviewer cannot judge "GRP_FIN_AP_L3_RW", a requester cannot pick the right access, and a policy engine cannot route high-risk access to extra approval if nothing says it is high risk. This guide covers the metadata layer of identity governance: how to write business-friendly entitlement descriptions, how to assign and sustain entitlement ownership, how to rate risk and sensitivity with published criteria, and how to decide which entitlements carry a privileged flag. It is written for IGA engineers, identity governance leads and application owners. Connecting applications and building the first catalogue export is covered in the Entitlement Catalogue and Application Onboarding Guide; this page picks up once the raw entitlements are in the platform.

Key takeaways

• Metadata is the control. Review cadence, approval stages, SoD rules and privileged access monitoring all key off fields in the catalogue, so a missing risk rating is a missing control, not a cosmetic gap.
• Owners must be people with deputies. An entitlement owner approves, reviews and governs the access right; a team mailbox or a departed employee cannot do that, and ownership must move automatically when people leave or change role.
• Descriptions answer one question. "What can the holder do, to what data, and why would someone need it" in one plain sentence, written with the owner and checked by a reviewer who does not know the application.
• Rate risk with published criteria. Without a scoring rubric every owner calls their access medium. Score privilege, data sensitivity, financial impact, reach and external exposure, and take the highest factor as the floor.
• Flag privileged access by definition, not by name. NIST defines a privileged user as one authorised to perform security-relevant functions that ordinary users cannot; apply that test to every entitlement, including those held by service accounts and AI agents.

What the catalogue is for

An entitlement catalogue is the curated register of every grantable access right (application role, group, permission set, profile, licence or responsibility) with the business metadata governance processes need. The raw values come from connectors and aggregation; the catalogue adds meaning. Each field should exist because a process consumes it.

Platform terminology differs. In Microsoft Entra entitlement management, a catalog is a container of resources (groups and Teams, enterprise applications, SharePoint sites) and access packages, with its own owners, a name and description users see, and "Require attributes" questions requesters must answer. Other IGA platforms hold the catalogue at the level of individual entitlements, each with a primary owner, additional owners, a requestable flag and a privilege level. The fields above apply in either model; the Entra ID Entitlement Management and Access Packages Guide covers the Microsoft specifics.

Writing business-friendly entitlement descriptions

A description is good when a reviewer who has never used the application can decide whether a named person should keep the access. IDPro's guidance on recertification stresses that reviewers need context: purpose, risk level, recent usage and how peers are provisioned. The description is the part of that context the catalogue owns.

A description template

• Action: what the holder can do, as a verb ("approve", "create", "read", "export", "administer").
• Object and scope: what data or function, and how much of it ("supplier invoices up to 50,000 in the UK entity", "all customer records").
• Who normally needs it: the job or team ("accounts payable team leads").
• What it does not include: where confusion is likely ("does not include payment release").

• Write with the owner, not for them: run a short working session per application against the entitlement export; emailed templates come back blank or copied from the raw value.
• Keep the raw value visible: show the technical name alongside the business name for traceability and for auditors.
• Test it: give five descriptions to a reviewer outside the team and ask them to say what the holder can do. Rewrite any they get wrong.
• Do not let aggregation overwrite curated text: confirm how your platform handles refreshes. Some platforms fill blank descriptions from the source on later aggregations but do not overwrite text you have edited; others treat the source as master. Know which before investing in content.
• Collapse noise first: hide entitlements nobody holds and merge sub-permissions always granted together, so effort goes to entitlements that matter.

Assigning and sustaining entitlement ownership

Several owner roles are often confused. Separate them explicitly, because each one answers a different question.

• Name a person, plus a deputy or governance group: a single named owner gives accountability; a deputy or group prevents requests stalling during leave. Platforms commonly support a primary owner with additional owners or a governance group.
• Do not default ownership to IT: technical teams know how access works, not whether a sales manager should hold it. IT-owned business entitlements produce approvals without judgement.
• Tie ownership to the joiner-mover-leaver process: when an owner leaves or moves, raise an ownership transfer task automatically, with the manager or application owner as interim owner. See the Joiner-Mover-Leaver Guide.
• Owner attestations: once a year, have each owner confirm the description, risk rating and privileged flag for their entitlements, separate from user access reviews. This keeps the catalogue current without a central team chasing every change.
• Orphaned entitlements: treat an entitlement with no valid owner as a finding, block new requests for it until an owner is assigned, and report the count.

Risk and sensitivity rating

A risk rating is only useful if two owners would rate the same entitlement the same way. Publish the criteria, score each factor, and use the highest factor as the floor rather than averaging, so one severe factor is never diluted by four mild ones.

• Data sensitivity is separate from privilege: an entitlement can be non-administrative and still high risk. The Coinbase insider breach involved support agents using routine access to customer records, including government ID images, that they had been legitimately given; NHI Mgmt Group's analysis frames the gap as how much each identity could see. A catalogue that rates "view all customer records" as low because it is read-only misses exactly that risk.
• Use inheritance: where entitlements nest (a group that grants a role that grants a permission), the effective rating should be the highest of its own rating and anything it grants. Some IGA platforms compute this as an effective privilege level derived from parent entitlements. The Group Sprawl and Nested Groups guide covers effective access calculation.
• Accept machine suggestions, then review: platforms increasingly suggest privilege levels from permission analysis. Treat suggestions as a draft for the owner to approve, never as the rating.
• Drive cadence from the rating: IDPro suggests quarterly review for high-risk access, semi-annual for moderate and annual for low, with event-driven reviews on role change, termination or incident. See the Access Reviews Guide.

The privileged flag

The privileged flag is a yes or no field on top of the risk rating, because privileged access triggers specific controls: PAM vaulting or just-in-time elevation, more frequent reviews, session monitoring and stricter approval. NIST SP 800-53 Rev. 5 AC-2(7) requires organisations to administer privileged accounts under a defined scheme, monitor privileged role or attribute assignments and revoke them when no longer appropriate, and AC-6(7) requires periodic review of user privileges. Those controls only work if you know which entitlements are privileged.

Flag an entitlement as privileged when it can

1. Create, modify or delete accounts, or grant or revoke access for others (including group and role management).
2. Change security configuration, logging, authentication or policy settings.
3. Read or change secrets, keys, certificates or credentials.
4. Run arbitrary code or queries in production, or change infrastructure.
5. Bypass application-level controls, such as "act as" or impersonation rights, or approval overrides.
6. Export or delete data in bulk outside normal business workflows.

• Look beyond names: privilege hides in entitlements called "power user", "support plus" or a custom role. Assess permissions, not labels.
• Include non-human holders: service accounts, workload identities and AI agents hold entitlements too, and are often granted administrative roles for convenience. The Identity Governance for AI Agents Guide covers how to bring them into the same reviews.
• Feed PAM: every flagged entitlement should be either brokered through PAM or have a documented exception. Reconcile the two lists monthly.

Building and maintaining the catalogue

1. Prioritise: start with applications that hold regulated data, move money or administer infrastructure, and with the entitlements held by the most people.
2. Publish the standards: description template, risk rubric, privileged criteria and owner role definitions, approved by the governance board.
3. Pre-classify: use permission analysis, naming patterns and platform suggestions to propose ratings and flags, so owners confirm rather than start from nothing.
4. Owner sessions: walk each owner through their entitlements; capture description, rating, flag, requestable status, prerequisites and maximum duration. Use bulk edit or CSV import for volume.
5. Quality gate: before an application is marked "governed", require 100 percent owner coverage and descriptions for every entitlement with at least one holder.
6. New-entitlement intake: alert when aggregation finds a new entitlement, hold it as non-requestable and unrated, and route it to the application owner within a set time.
7. Drift checks: when an entitlement's underlying permissions change, reopen its rating. Re-attest the catalogue annually.

Small organisations can start with a spreadsheet of the top twenty applications using the same fields, then load it into an IGA platform later. Large enterprises should treat catalogue quality as a measured service with its own owner, because thousands of applications produce constant change.

Measuring catalogue quality

• Owner coverage: percentage of entitlements with at least one holder that have a valid, active owner (target 100 percent for high-risk).
• Description coverage and quality: percentage with a business description, plus a sampled quality score from the reviewer test.
• Rating coverage: percentage of entitlements with a risk rating and privileged decision, and the number still unrated after the intake window.
• Privileged reconciliation: flagged entitlements not brokered through PAM and without an exception.
• Review outcome signal: revocation rate per campaign; a near-zero rate on high-risk entitlements often means reviewers cannot understand what they are approving.
• Orphaned entitlements: count and age of entitlements with no valid owner.

Framework mapping

Common failure patterns

• Raw values in front of reviewers: certifications built on technical names produce approval rates near 100 percent and no real assurance.
• IT as universal owner: the platform team ends up approving business access it cannot judge, and becomes the bottleneck for every request.
• Everything rated medium: no published rubric, so ratings carry no information and cannot drive cadence or approval stages.
• Read-only treated as safe: bulk read access to customer or employee data rated low because it cannot change anything, as the Coinbase case shows.
• Owners who have left: no link between the leaver process and catalogue ownership, so requests route to disabled accounts or fall back to administrators.
• Curated text overwritten: a refresh from the source system replaces business descriptions, and months of owner work disappear.

Practitioner checklist

• Publish a description template, a five-factor risk rubric and written privileged criteria, approved by the governance board.
• Assign a named primary owner and a deputy or governance group to every entitlement that has holders.
• Automate ownership transfer tasks from the joiner-mover-leaver process.
• Rate data sensitivity separately from privilege and take the highest factor as the floor.
• Compute effective ratings through nesting so inherited privilege is not missed.
• Reconcile privileged-flagged entitlements against PAM monthly.
• Hold newly discovered entitlements as non-requestable until an owner rates and describes them.
• Confirm how aggregation treats curated descriptions before bulk editing.
• Drive review frequency from the risk rating and run an annual owner attestation of the catalogue.
• Report owner coverage, description coverage, unrated entitlements and orphaned entitlements monthly.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
• NIST CSRC Glossary: Privileged user
• NIST: Cybersecurity Framework 2.0
• IDPro Body of Knowledge: Optimizing Access Recertifications
• Microsoft Learn: Create and manage a catalog of resources in entitlement management
• SailPoint Documentation: Entitlements

Related NHI Mgmt Group resources: Entitlement Catalogue and Application Onboarding Guide · Access Reviews Guide · Role Mining and Role Design Guide · Segregation of Duties Guide · Least Privilege Techniques Guide