Most organisations can list their privileged accounts but cannot say which roles are privileged, why, who owns each role, or what controls a holder must pass before using it. This template gives [Organisation] one catalogue of every administrative role across directories, cloud platforms, SaaS applications and infrastructure, with a tier, an accountable owner, the permitted holders and the minimum controls for each role. It is the reference the PAM team onboards against, the access review checks against and the auditor samples from. It is for IAM and PAM engineers, platform owners and the control owners who sign off privileged access. The design reasoning for tier models and per-platform role guidance lives in the linked guides; this page is the register you fill in.
How to use this template
- Replace bracketed text such as [Organisation], [Tier 0 owner] and [90 days] with your own values. Bracketed numbers are illustrative starting points, not standards.
- Catalogue roles, not people. One row per role per platform (for example "Global Administrator, Entra tenant [name]"). Who holds a role is recorded in the assignment register in section 6, which links back to the role ID.
- Start with the identity planes that can change everyone else's access (directory, identity provider, cloud organisation root), then cloud platforms, then business SaaS, then infrastructure and data platforms.
- Keep the catalogue in a version-controlled file or your IGA or GRC tool, not only in a document. Export the role list from each platform each quarter and compare it with the catalogue (section 7).
- Use it with the Privileged Access Management Guide for programme design and the Active Directory Tiering vs Red Forest guide for the tier model rationale.
1. Purpose
This catalogue defines which roles at [Organisation] are privileged, assigns each one a tier and an owner, and sets the minimum controls that apply to anyone, human or machine, who holds it. It puts into practice the least privilege requirement for privileged accounts in NIST SP 800-53 AC-6(5) (Privileged Accounts), the review of privileges in AC-6(7), the role-based schemes for privileged users in AC-2(7) and the separation of duties in AC-5. In NIST CSF 2.0 it supports PR.AA-05: access permissions, entitlements and authorisations are defined in a policy, managed, enforced and reviewed, and incorporate least privilege and separation of duties.
2. Scope
A role belongs in the catalogue if it meets any of these criteria on any system [Organisation] runs or subscribes to:
- It can create, assign or change roles, permissions or group memberships for other identities.
- It can change authentication methods, credentials, MFA or conditional access settings for other identities.
- It can change security policy, logging, audit settings or security tooling.
- It can read or export restricted data in bulk, or bypass data access controls.
- It can change production infrastructure, network paths, encryption keys or backups.
- It can create or change machine identities: service accounts, service principals, OAuth applications, API keys or AI agent identities.
Criteria 1 to 3 match how Microsoft describes privileged permissions in Entra ID: permissions that can delegate directory management, modify credentials or authentication and authorisation policies, or access restricted data. Apply the same test to every platform, whether or not the platform labels roles for you.
Out of scope: end-user roles with no administrative capability. A business role that grants approval rights over money (for example payment release) is recorded in the separation of duties register, not here, unless it also meets a criterion above.
3. Roles and responsibilities
| Role | Responsibility for the catalogue |
|---|---|
| Catalogue owner ([IAM or PAM lead]) | Maintains the catalogue, runs the quarterly reconciliation, reports gaps |
| Role owner (one per row) | Accountable for who holds the role; approves assignments; attests at each review |
| Platform owner | Supplies the role list and permission detail for the platform; flags new or changed vendor roles |
| Security architecture | Approves tier assignments and the minimum controls per tier |
| Internal audit or second line | Samples assignments against the catalogue; checks evidence of review |
| [Access governance forum] | Approves exceptions under section 8 and any change to tier definitions |
4. Tier definitions
[Organisation] uses three tiers. Tier is set by the worst realistic outcome of the role being misused, not by job title or how often the role is used.
| Tier | Definition | Typical examples | Minimum controls for holders |
|---|---|---|---|
| Tier 0: control plane | Can take control of identity for the whole organisation or a whole cloud estate, directly or through one escalation step | Directory and identity provider super administrators, roles that manage other roles, roles that reset administrator credentials, cloud organisation root and management accounts, federation and certificate authority administrators | Separate admin account; phishing-resistant MFA; eligible (just-in-time) assignment only, except named break-glass accounts; approval for activation; activation limited to [4 hours]; privileged access workstation; session logging; review every [90 days] |
| Tier 1: high impact | Can change or read a significant business system, its data or its security settings, but not the identity plane | Application administrators for core SaaS, cloud account or subscription owners, database administrators, security tooling administrators, exchange and collaboration administrators | Separate admin account; phishing-resistant MFA; just-in-time assignment where the platform supports it; activation limited to [8 hours]; session logging for production; review every [90 days] |
| Tier 2: scoped administration | Administrative rights limited to a defined set of users, devices or resources | Help desk roles scoped to non-administrators, device administrators for a region, group managers, read-only security reader roles with access to sensitive logs | MFA; assignment scoped to an administrative unit, organisational unit or resource group where possible; review every [180 days] |
Two rules apply across tiers. First, any role that can reset credentials or MFA for holders of a higher tier role takes that higher tier, because it is an escalation path. Second, a role that can assign itself or others to a higher tier role is in that higher tier. The Entra ID Privileged Roles Guide works through these escalation paths for one directory.
5. The role catalogue
5.1 Catalogue fields
| Field | What to record |
|---|---|
| Role ID | [PRC-0001]: stable internal identifier used by the assignment register and access reviews |
| Platform and instance | [Platform name, tenant or account ID]. Production and non-production instances are separate rows |
| Role name (as the platform shows it) | Exact built-in or custom role name, and whether built-in or custom |
| What the role can do | Two or three lines in plain language, plus the scope criteria from section 2 it meets (1 to 6) |
| Platform privileged flag | Whether the platform itself marks the role as privileged, where it does |
| Tier | 0, 1 or 2, with a one-line reason |
| Escalation paths | Roles or permissions this role can reach in one step (for example "can reset passwords of Tier 1 admins") |
| Role owner | Named person and deputy, not a team mailbox |
| Permitted holder types | Human admin account / break-glass account / service account / workload identity / AI agent / vendor account |
| Assignment model | Permanent / eligible (just-in-time) / time-bound / break-glass only |
| Maximum holders | [Number]: the cap above which the owner must justify each new holder |
| Required controls | Tier minimums from section 4 plus any role-specific control |
| Where enforced | Identity provider, PIM or PAM tool, cloud policy, platform setting |
| Detection | Log source and alert for assignment, activation and use |
| Review cadence and last review | [90 days], date and reviewer |
| Status | Active / under review / to be retired |
5.2 Example rows
The rows below show how to fill the catalogue using built-in roles named in each vendor's own documentation. Platforms are listed alphabetically; the order is not a ranking. Tiers shown are this template's suggested starting point; confirm them against your own configuration and scoping.
| Role ID | Platform | Role name | What it can do | Tier | Assignment model | Max holders |
|---|---|---|---|---|---|---|
| [PRC-0001] | AWS (management account) | Permission set or role with the AdministratorAccess managed policy | All actions on all services and resources, including delegating permissions to others | 0 | Eligible via identity centre, approval required | [3] |
| [PRC-0002] | AWS (workload account) | Role with the PowerUserAccess managed policy | All actions except IAM, Organizations and account management, though it can still create service-linked roles | 1 | Eligible, time-bound | [10] |
| [PRC-0003] | Google Workspace | Super Admin | Full Admin console and Admin API access; only super admins create and assign admin roles and manage other admins | 0 | Permanent for two named accounts, kept separate from daily accounts | [3] |
| [PRC-0004] | Google Workspace | User Management Admin | Manages non-administrator users, including password resets and security settings; can be limited to organisational units | 2 (if OU-scoped) or 1 | Permanent, OU-scoped | [8] |
| [PRC-0005] | Microsoft Entra ID | Global Administrator | Manages all aspects of the tenant and can assign any role | 0 | Eligible through PIM, approval required; two break-glass accounts permanent | [4] |
| [PRC-0006] | Microsoft Entra ID | Privileged Authentication Administrator | Manages authentication methods for all users, including administrators | 0 (escalation path) | Eligible through PIM, approval required | [3] |
| [PRC-0007] | Okta | Super Admin | Full administrative control of the org, including managing other administrators | 0 | Separate admin accounts, minimal standing holders | [3] |
| [PRC-0008] | Okta | Help Desk Admin | Resets passwords and MFA factors for users in scope | 2 (if scoped away from admins) or 0 | Permanent, scoped to user groups that exclude administrators | [15] |
Vendor guidance to record against rows: AWS states that its job function managed policies do not follow least privilege and suggests custom policies based on permissions actually used. Google recommends at least two super administrators so one can recover the other. Microsoft recommends fewer than five Global Administrators and fewer than ten privileged role assignments overall, and marks privileged roles with a PRIVILEGED label in the admin centre. Okta documents a set of standard administrator roles from Super Admin to Read-only Admin, with some governance roles tied to specific subscriptions. Per-platform detail is in the AWS IAM Policies and Roles Guide, the Google Workspace Security Guide, the Microsoft 365 admin centres and admin roles guide and the Okta Admin Roles Security Guide.
5.3 Rows people forget
- Custom roles: every custom role gets its own row and is tested against the section 2 criteria; a custom role with one privileged permission is privileged.
- Non-production tenants and accounts: development and test tenants often hold real synchronisation, federation or trust links to production. Catalogue their admin roles at the tier of what they can reach.
- Delegated and partner administration: roles granted to managed service providers, resellers and vendor support accounts.
- Machine holders: service principals, automation accounts, CI/CD identities and AI agents holding admin roles or admin-equivalent API scopes. See the Privileged Account Discovery and Onboarding Guide for finding them.
- Security and audit roles: roles that can read every mailbox or every log are data-access privileged even when they are labelled "reader".
- Break-glass accounts: recorded as holders of their Tier 0 role with assignment model "break-glass only". The procedure itself sits in the Break Glass Access Procedure Template.
6. Assignment register
The catalogue says what a role is; the assignment register says who holds it. Keep them separate so that people changes do not alter role definitions.
| Field | Value |
|---|---|
| Assignment ID | [PRA-0001] |
| Role ID (from catalogue) | [PRC-0005] |
| Holder | [Admin account name] and the person or system it belongs to |
| Holder type | Must be one of the role's permitted holder types |
| Assignment type | Eligible / active / time-bound with end date |
| Business justification | [One line, linked to a ticket] |
| Approved by and date | Role owner, [date] |
| Expiry or next review | [Date] |
| Controls verified | Separate account, MFA method, PAW, logging: yes or no each |
Requests follow the Access Request and Approval Workflow Design Guide. A request for a role that is not in the catalogue is rejected until the role is catalogued and tiered.
7. Reconciliation and review
- Quarterly role reconciliation: export built-in and custom role definitions from each platform. Any role not in the catalogue is added within [10 working days]. Any new vendor-introduced role is assessed against section 2.
- Monthly assignment reconciliation (Tier 0) and quarterly (Tiers 1 and 2): export active and eligible assignments and compare them with the assignment register. Unregistered assignments are removed or registered within [5 working days].
- Owner attestation: each role owner confirms, at the cadence in the catalogue, that every holder still needs the role and that the holder count is within the cap. Use the Access Review Checklist.
- Event-driven review: role definitions are re-checked after a platform adds permissions to a built-in role, after a merger or tenant consolidation, and after any incident involving privileged access.
8. Exceptions
An exception is any departure from the tier minimum controls, the permitted holder types or the holder cap. Each exception records the role ID, the control not met, the compensating control, the risk owner, and an expiry no longer than [90 days] for Tier 0 and [180 days] otherwise. Expired exceptions are reported to [Access governance forum] and the assignment is removed if not renewed. Permanent Tier 0 assignments other than break-glass accounts always require an exception.
9. Metrics
| Metric | Target |
|---|---|
| Platform roles found in export but not catalogued | [0] at quarter end |
| Tier 0 assignments that are standing (excluding break-glass) | [0] |
| Roles over their holder cap | [0] |
| Assignments with no register entry | [0] |
| Owner attestations completed on time | [100%] Tier 0, [95%] others |
| Machine identities holding Tier 0 roles | Each one named, justified and under exception |
Implementation guidance
- Week 1 to 2, identity planes: catalogue every role in the directory, identity provider and cloud organisation management account. Set Tier 0 and name owners. This alone usually reveals more Tier 0 holders than anyone expected.
- Week 3 to 4, cloud platforms: add account, subscription and project level roles, including custom roles and wildcard policies. The How to find AWS IAM policies with wildcard actions walkthrough helps here.
- Month 2, SaaS and infrastructure: add admin roles in core SaaS, databases, hypervisors, network and security tools.
- Month 2 to 3, controls: move Tier 0 to eligible assignments with approval, then Tier 1. Pilot with one platform team first, keep the old standing assignments in a disabled state for [14 days] so you can roll back if a team loses access to something it genuinely needs, then remove them. The JIT Access Guide covers the activation model.
- Ongoing: run section 7 on schedule and report section 9 metrics to [Access governance forum].
Small organisations can run the catalogue as one spreadsheet with a dozen rows and quarterly reviews; the tier rules and owner field matter more than tooling. Large organisations should hold it in the IGA platform so access reviews and requests read the tier and owner directly. Watch for these common failures: cataloguing only the directory and ignoring SaaS admin roles; treating help desk roles as low risk when they can reset administrator factors; letting custom roles drift away from their catalogue description; and recording a team as role owner so that nobody attests. Assignment and use of Tier 0 roles should alert in the SIEM; adding cloud roles to accounts maps to MITRE ATT&CK T1098.003 Additional Cloud Roles, and use of valid cloud admin accounts to T1078.004 Cloud Accounts.
Standards and references
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls (AC-2(7), AC-5, AC-6(5), AC-6(7))
- NIST: Cybersecurity Framework 2.0 (PR.AA-05)
- Microsoft Learn: Privileged roles and permissions in Microsoft Entra ID
- AWS: AWS managed policies for job functions
- Google: Pre-built administrator roles
- Okta: Standard administrator roles and permissions
- MITRE ATT&CK: T1098.003 Additional Cloud Roles
Related NHI Mgmt Group resources: Privileged Access Management Guide, Entra ID Privileged Roles Guide, Okta Admin Roles Security Guide, Active Directory Tiering vs Red Forest, Privileged Identity Management (PIM) Guide.