Most organisations cannot say, on any given day, how many accounts can administer their domain, cloud tenants and critical systems, who owns each one, and whether it is vaulted and protected by MFA. This template gives you the register to answer that question for human privileged accounts: named administrator accounts, emergency (break glass) accounts, shared and built-in administrative accounts, and privileged roles in cloud and SaaS platforms. Each record captures the owner, the privilege held, the vaulting, MFA and review status, so the register doubles as the onboarding list for a privileged access management (PAM) programme and as audit evidence. It is written for IAM and PAM teams, security engineers and auditors. Service accounts, API keys and other non-human identities have their own register: use the Service Account Inventory Template alongside this one. How to find these accounts in the first place is covered in the Privileged Account Discovery and Onboarding Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [PAM team] and [Vault], with your own values. Fields marked Required are the minimum for audit evidence; fields marked Recommended make the register useful for risk reduction and incident response.
- Use Section 4 (common fields) for every account, then the type-specific fields in Sections 5 to 7. In a spreadsheet use one tab per account type with the common fields repeated; in an IGA or PAM tool, map each field to an attribute.
- Use drop-down values for every field with a fixed list (tier, account type, vault status, MFA method) so you can filter and count.
- Never record a password, recovery code, private key or MFA seed in the register. Record where the credential is held and who can retrieve it.
- Treat the register itself as sensitive: it is a map of the most valuable accounts in the organisation. Restrict access to [PAM team], [Security team] and auditors, and log who views it.
- Pair the register with the Privileged Access Management Policy Template, which makes keeping it current mandatory, and measure progress with the PAM Maturity Model.
1. Purpose
1.1 This register records every human account at [Organisation] that holds administrative or otherwise privileged rights, so that each account has an accountable owner, a justified level of privilege, a known protection status and a review history.
1.2 It is the authoritative list used to onboard accounts into [PAM tool], to run privileged access reviews, to investigate incidents and to evidence compliance with CIS Controls v8.1 Control 5 (Account Management) and Control 6 (Access Control Management), NIST SP 800-53 Rev. 5 AC-2(7) Privileged User Accounts and AC-6(5) Privileged Accounts, and ISO/IEC 27001:2022 Annex A 8.2 Privileged access rights.
2. Scope and account types
2.1 An account is in scope if it can change security configuration, grant access to others, read or change data it does not own as part of its function, or administer infrastructure, on premises, in the cloud or in SaaS.
| Account type | Examples | Primary discovery source | Special handling |
|---|---|---|---|
| Named administrator account | Dedicated admin accounts such as adm-jsmith, separate from the person's daily account | [Directory] group membership, cloud role assignments | One per person per tier; MFA mandatory |
| Directory tier 0 membership | Members of Enterprise Admins, Domain Admins, Administrators and Schema Admins in Active Directory | [Directory] queries, AD security tooling | Keep as close to empty as possible; every member justified |
| Cloud and identity provider roles | Global Administrator and Privileged Role Administrator in Microsoft Entra ID, AWS root user and administrator permission sets, Google Cloud Organisation Administrator | [Cloud] role assignment exports, PIM reports | Prefer eligible (just-in-time) over permanent assignment |
| Emergency (break glass) account | Cloud-only emergency administrator accounts, offline domain administrator accounts | [Emergency access procedure] register | Section 6 fields; every use alerts |
| Shared and built-in admin account | Built-in Administrator, root on Unix and Linux, network device enable accounts, database sa and similar, vendor accounts shared by a team | Endpoint and server inventory, network configuration backups, database instances | Section 7 fields; vault and rotate, record each user |
| Local administrator rights | Users or groups in the local Administrators group on servers and workstations | [Endpoint management tool], LAPS reports | Record at group level; exceptions individually |
| Privileged application and SaaS roles | ERP superuser, CRM system administrator, code repository organisation owner, HR system administrator | Application role exports, [IGA tool] | Record the role and its holders; review with the application owner |
2.2 Out of scope: service accounts, workload identities, API keys and other non-human identities, which are recorded in the [Service account inventory]. If a human-named account is actually used by a script or service, record it here with the flag in Section 4 and raise a remediation item to move it to a proper service identity.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| [PAM team] | Owns the register, its fields and data quality; reconciles it against discovery sources; onboards accounts into [Vault]; reports metrics |
| Account owner | Named individual accountable for each account: for named accounts the user; for shared and emergency accounts a named manager, never a team mailbox |
| Platform owner | Owner of the system the privilege applies to; approves privilege levels and attests in reviews |
| Line manager | Confirms continued need when a person moves or leaves; triggers removal through the joiner, mover and leaver process |
| [Security team] | Uses the register for monitoring and investigations; audits completeness; investigates privileged accounts found outside it |
| Internal audit | Tests the register and the review evidence independently |
4. Common fields for every privileged account
| Field | Status | Format or allowed values | Why it matters |
|---|---|---|---|
| Record ID | Required | Unique, never reused, for example [ORG]-PA-00123 | Joins the register to tickets, reviews and logs |
| Account name | Required | Exact login name, user principal name or ARN | Matches the account in logs and directories |
| Platform | Required | Directory, cloud tenant, server, network device, database or application, with environment (production, test) | Where the privilege applies |
| Account type | Required | From Section 2 | Drives which extra fields apply |
| Owner | Required | Named person, taken from the identity provider or HR record | Accountability; orphaned privileged accounts are a common finding |
| Linked daily account | Required for named accounts | The person's standard user account | Proves admin and daily use are separate, as CIS Safeguard 5.4 and NIST AC-6(2) expect |
| Privilege held | Required | Groups, roles or permission sets, by name | What the account can actually do |
| Tier | Required | 0, 1 or 2, see Section 8 | Prioritises controls and review frequency |
| Business justification | Required | Short text and approving ticket reference | Evidence that privilege is needed |
| Assignment model | Required | Permanent, eligible (just in time), time-bound with end date | Standing privilege is the main risk to reduce |
| Vault status | Required | Vaulted and rotated, vaulted not rotated, not vaulted, not applicable (personal credential with MFA) | Shows PAM coverage |
| Credential rotation | Recommended | Rotation interval and date last rotated; rotate after each checkout for shared accounts | Limits the life of a stolen credential |
| MFA status | Required | Enforced, enforced with exceptions, not enforced | CIS Safeguard 6.5 and NIST IA-2(1) expect MFA for administrative access |
| MFA method | Required | Passkey or FIDO2 key, certificate or smart card, authenticator app with number matching, SMS or voice | Phishing-resistant methods should be the target for tier 0 |
| Access path | Recommended | Privileged access workstation, jump host, PAM session proxy, direct | Shows whether sessions are controlled and recorded |
| Session recording | Recommended | Yes or no | Evidence for investigations |
| Interactive use by automation | Required | Yes or no | Flags human accounts used by scripts, a common hidden risk |
| Last used | Required | Date of last successful sign-in from logs | Finds dormant accounts to disable (CIS Safeguard 5.3) |
| Created date and creator | Recommended | Date and approving ticket | Spots accounts created outside process |
| Last review date and result | Required | Date, reviewer, kept, reduced or removed | Review evidence (NIST AC-6(7)) |
| Next review due | Required | Date from Section 8 | Drives the review calendar |
| Open risk or exception | Recommended | Exception reference and expiry date | Tracks accepted gaps |
5. Additional fields for named administrator and role assignments
| Field | Status | Format or allowed values |
|---|---|---|
| Employment type | Required | Employee, contractor, third-party supplier |
| Contract or engagement end date | Required for non-employees | Date; account expiry set to match |
| Eligible roles and activation rules | Recommended | Role, maximum activation time, approval required yes or no |
| Admin workstation | Recommended | Device ID of the privileged access workstation used |
| Training completed | Recommended | Date of privileged user training |
6. Additional fields for emergency (break glass) accounts
6.1 Emergency accounts are designed to bypass normal controls, so they need the strictest record. Microsoft's guidance for Entra ID, for example, recommends at least two cloud-only emergency access accounts on the onmicrosoft.com domain, phishing-resistant authentication that differs from normal admin accounts, an alert on every use and a check that they work at least every 90 days.
| Field | Status | Format or allowed values |
|---|---|---|
| Purpose and trigger | Required | Scenario the account exists for, such as identity provider outage or MFA failure |
| Dependency independence | Required | Cloud-only or local, not federated, not synchronised; not dependent on the systems it is meant to recover |
| Credential custody | Required | Storage locations (for example two separate safes), custodians, dual control yes or no |
| Policy exclusions | Required | Which access policies exclude this account, and why |
| Use alert | Required | Alert rule name and destination |
| Last tested | Required | Date and result of the last sign-in test |
| Last used in anger | Required | Date, incident reference, credential reset after use yes or no |
6.2 The procedure for using these accounts belongs in the Break Glass Access Procedure Template; design guidance is in the Break-Glass Account Guide.
7. Additional fields for shared and built-in accounts
| Field | Status | Format or allowed values |
|---|---|---|
| Why it cannot be personal | Required | Built-in account, device limitation, vendor requirement |
| Authorised users | Required | Named people or a PAM access policy reference, never "the team" |
| Checkout model | Required | Checkout with approval, checkout without approval, session injection without password reveal |
| Rotate on check-in | Recommended | Yes or no |
| Local admin password solution | Recommended | For workstation and server built-in administrators: LAPS or equivalent managed yes or no |
| Default credential changed | Required | Yes, with date; especially for network, OT and appliance accounts |
| Vendor access | Recommended | Vendor name, contract reference, access window |
8. Tiering and review frequency
| Tier | Definition | Minimum controls | Review frequency |
|---|---|---|---|
| 0 | Control of identity itself: directory administrators, identity provider global roles, PAM and vault administrators, emergency accounts | Vaulted or phishing-resistant MFA, privileged access workstation, just in time where possible, alert on use | [Monthly] |
| 1 | Control of servers, cloud subscriptions, databases and business-critical applications | MFA, vaulted shared credentials, session recording for production | [Quarterly] |
| 2 | Control of workstations and lower-risk applications, help desk roles | MFA, managed local administrator passwords | [Every six months] |
8.1 Microsoft's Active Directory guidance treats Enterprise Admins, Domain Admins and the built-in Administrators group as effectively equivalent, because a member of any one can gain the others, and says Domain Admins membership should be needed only in break glass scenarios. Record all three as tier 0.
9. Maintenance and reconciliation
9.1 [PAM team] reconciles the register against discovery sources at least [monthly] and after any major change: directory group memberships, cloud role assignments, local administrator reports, application role exports and the PAM vault.
9.2 Any privileged account found in a discovery source but not in the register is treated as unauthorised until an owner and justification are recorded within [5 working days]; otherwise it is disabled.
9.3 Privileged accounts unused for [45 days] are disabled, and removed after a further [45 days] unless an exception is recorded. Emergency accounts are exempt from automatic clean-up but not from testing.
9.4 When a person moves role or leaves, their privileged accounts are removed or reduced by the same joiner, mover and leaver event that changes their daily access. See the Joiner-Mover-Leaver Guide.
9.5 The register is reviewed in full by the account owners and platform owners on the frequency in Section 8, with results recorded in the fields in Section 4. See the Access Reviews Guide.
Implementation guidance
- Start with tier 0: list directory, identity provider and vault administrators first. They are few, they matter most, and getting them right shows quick value.
- Build from systems, not from memory: export group memberships and role assignments rather than asking teams who has admin. Interviews find the shared accounts; exports find everything else.
- Expect surprises: nested groups, human accounts used by scripts, accounts belonging to people who left and vendor accounts with permanent access are typical first-run findings. Record them, then fix them through tickets.
- Use the register to drive onboarding: sort by tier and vault status to produce the PAM onboarding backlog, and report the percentage vaulted and MFA-protected each month.
- Metrics to report: number of tier 0 accounts and trend; percentage of privileged accounts with phishing-resistant MFA; percentage of shared accounts vaulted and rotated; number of standing versus eligible cloud admin assignments; dormant privileged accounts; reviews completed on time.
- Audit evidence: keep the register history, reconciliation reports, review sign-offs and exception approvals. Auditors typically sample accounts from discovery sources and trace them back to the register.
- Framework alignment: CIS Controls v8.1 Safeguards 5.1, 5.3, 5.4 and 6.5; NIST SP 800-53 Rev. 5 AC-2, AC-2(7), AC-6(2), AC-6(5), AC-6(7) and IA-2(1); ISO/IEC 27001:2022 Annex A 5.15, 5.18 and 8.2.
- Key sources: CIS Controls: Account Management; NIST SP 800-53 Rev. 5; Microsoft Learn: Manage emergency access accounts in Microsoft Entra ID; Microsoft Learn: Privileged Accounts and Groups in Active Directory.
Related NHI Mgmt Group resources: Privileged Access Management Guide · PAM Maturity Model · Service Account Inventory Template · Privileged Access Workstations Guide