A governed catalog is the approved menu of applications, entitlements, roles, or bundles that eligible users can request through self-service. It sits between the requester and the technical permission model, adding business context, ownership, approval logic, and auditability so access is understandable and controlled.
What an Access Request Catalog Actually Is
An access request catalog is the curated front door for access requests: the approved list of roles, entitlements, applications, or bundles that eligible users can request through self-service. It converts raw permission objects into something business-owned, reviewable, and auditable.
Its main value is not convenience alone. A catalog makes access requestable only when the organisation has already decided what should be requestable, who owns it, and what approval or policy logic must apply before access is granted.
Why the Catalog Matters for Access Governance
The catalog is where governance becomes visible to the requester. Instead of exposing every technical permission, it presents a controlled menu that reflects business context, entitlement ownership, and the intended audience for each item.
That structure helps separate access design from access consumption. A well-run catalog reduces confusion around roles versus entitlements, makes approvals easier to understand, and supports access reviews because the request path is tied to named business objects rather than ad hoc exceptions.
It also helps prevent permission sprawl. When users can only request preapproved items, teams are less likely to create one-off grants that are hard to interpret later or impossible to govern consistently.
What Belongs in the Catalog, and What Does Not
A good catalog usually includes requestable business roles, application access packages, group bundles, and other entitlement groupings that have a clear owner and review path. It should be organised around how the business thinks about access, not around every low-level technical permission.
That does not mean the catalog must hide technical detail forever. The requester may need enough context to choose correctly, but the underlying permission model should stay behind the scenes unless exposing it materially improves decision quality.
This is why catalog design is a governance problem as much as a user-experience problem. Poorly named or overly broad items can create role explosion, duplicate access paths, or bundles that look simple but contain excessive privilege.
How the Catalog Fits into the Request-to-Grant Flow
The catalog sits between intent and enforcement. The requester selects an approved item, policy evaluates eligibility, approvals may be routed to the right owner, and then the technical system provisions the underlying access.
That separation matters because the catalog is not the permission model itself. It is the controlled interface to it, and it should preserve auditability from request to approval to provisioning so the organisation can explain why access existed at a given time.
For that reason, many access programs treat the catalog as part of identity governance rather than a simple portal feature. The catalog is where business ownership, entitlement lifecycle, and request automation come together. IAM and IGA Basics is a useful reference for the broader governance model that this pattern sits inside.
Risk and Threat Considerations
An access request catalog becomes risky when it is stale, overbroad, or poorly governed. If requestable items no longer match current business need, users can obtain access that appears approved but is effectively excessive, ambiguous, or difficult to review later.
Failure mechanism: weak ownership, broad bundles, or outdated catalog items let requesters obtain more access than intended while approvals provide a false sense of control.
Impact: privilege creep, audit gaps, and reduced confidence that self-service requests actually reflect least-privilege intent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Access request catalogs govern which access items can be requested and approved. |
| AC-6 — Least Privilege | Catalogs should expose only requestable access that reflects least-privilege intent. | |
| AU-2 — Event Logging | Request, approval, and provisioning events need auditability for catalog-governed access. | |
| Recommendation — Define requestable access items under AC-2 and keep them owner-approved, current, and auditable. Limit catalog items to least-privilege bundles and remove broad or redundant access options. Log catalog requests and approvals so access decisions remain traceable end to end. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Catalogs are a mechanism for controlling how access is requested and granted. |
| Recommendation — Use access control management to keep the catalog approved, current, and role-aligned. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The catalog operationalises controlled access selection and approval. |
| A.5.18 — Access rights | Catalog items represent governed access rights that must be assigned and reviewed. | |
| Recommendation — Maintain access control rules that define which access items can appear in the catalog. Track access rights through the catalog and review them on a defined schedule. | ||
Practitioner Guidance
Governance implication: treat the catalog as a controlled product, not a static menu. Each item should have a clear owner, a business description, and a defined approval or policy path so requesters understand what they are asking for and reviewers know what they are approving.
What to watch for: if users frequently choose broad bundles, if catalog entries duplicate one another, or if reviewers routinely override the catalog’s intended approval path, the catalog is no longer shaping access behavior and needs redesign.
NIST SP 800-53 Rev 5 Security and Privacy Controls aligns with catalog governance because access request, approval, and audit processes map directly to controlled authorization and accountability practices. CIS Controls v8 is also relevant because it reinforces account management, least privilege, and access control hygiene around requestable access paths.
Related resources from NHI Mgmt Group
- How should organisations design an access request catalog so users request the right access without exposing unnecessary permissions?
- Non-Human Identity Access Management
- Why do access-request workflows matter for NHI governance?
- How should organisations use AI in access request approval without weakening control?
