Privileged Access Management Policy Template: Govern Admin Accounts, Sessions and Elevation

Most organisations own a PAM tool but no policy that says which accounts are privileged, who may hold standing rights, how elevation is approved and what happens to a privileged credential after an incident, so the tool ends up covering only the accounts someone remembered to onboard. This template gives you a privileged access management policy with numbered statements you can adopt as written: definitions and tiers, roles, privileged account rules, authentication, just-in-time elevation, sessions and administration devices, credential management, non-human privileged identities, break-glass accounts, third-party access, logging and review. It is the governing document; the Privileged Access Management Guide explains the discipline and the PAM Buyer's Guide covers tooling. It is written for CISOs, IAM and infrastructure leads, and GRC teams who need a policy auditors can test against ISO/IEC 27001:2022 control 8.2 and NIST SP 800-53 AC-6.

How to use this template

• Replace text in square brackets, such as [Organisation], [PAM owner] and [X hours], with your own terms. Values in brackets are illustrative starting points, not requirements from any standard.
• "Must" is mandatory; "should" is recommended practice where a documented exception may apply.
• Keep product configuration (PIM role settings, vault safe design, session recording rules) in a supporting PAM standard and procedures. NIST SP 800-53 AC-1 expects a policy plus implementing procedures, and the policy should not need rewriting when a product changes.
• This policy sits under your Access Control Policy Template. Where the two overlap, the stricter statement applies to privileged access.
• Statements apply to non-human identities (service accounts, workload identities, API keys, automation and AI agent credentials) unless they say otherwise. Detailed NHI lifecycle rules live in the NHI Policy Template.

1. Purpose

This policy sets the requirements for identifying, granting, using, monitoring, reviewing and removing privileged access to [Organisation] systems, so that privileged rights are held by as few identities as possible, for as short a time as possible, from trusted devices, with strong authentication, under recorded approval, and with every privileged action attributable to a named person or an owned workload.

2. Scope

This policy applies to all privileged access to [Organisation] information systems, in production and non-production, on premises, in cloud tenants and subscriptions, in SaaS administration consoles, in operational technology, and in CI/CD and infrastructure-as-code pipelines. It covers privileged access by employees, contractors, managed service providers, vendors, and by non-human identities. It applies whether access is through the PAM platform or not; an account outside the PAM platform is still in scope.

3. Definitions and privilege tiers

Privileged access is any access that can change security configuration, grant or remove access for others, read or alter data at scale, bypass controls, or administer systems that other systems trust. The tiers below set the strength of control. Tier names follow the common control plane, management plane and workload model; NCSC guidance asks organisations to risk manage administration using tiers, and you may rename them.

Other terms: standing privilege is a privileged right that is active without a request; eligible assignment is a right a user may activate for a limited time; privileged access workstation (PAW) is a hardened device used only for administration.

4. Roles and responsibilities

• [CISO]: owns this policy, approves exceptions for Tier 0 and reports privileged access risk to [risk committee].
• [PAM owner]: runs the PAM platform and supporting standard, maintains the privileged account inventory, produces the metrics in section 7.
• System and data owners: define which roles on their systems are privileged, approve eligibility, and attest in reviews.
• Line managers: confirm business need for staff eligibility and trigger removal on role change or departure.
• Administrators: use privileged access only for approved tasks, from approved devices, through approved paths; never share or store privileged credentials outside the vault.
• Workload owners: own every privileged non-human identity they create, including its permissions, rotation and decommissioning.
• Security operations: monitor privileged activity and respond to alerts defined in section 5.11.
• Internal audit: tests compliance with this policy at least [annually].

5. Policy statements

5.1 Inventory and classification

1. [PAM owner] must maintain an inventory of all privileged accounts, roles and non-human identities with privileged rights, recording tier, owner, system, assignment type (eligible or standing) and last use.
2. Discovery must run at least [weekly] across directories, cloud tenants, SaaS admin roles, databases, network devices and code repositories. Newly discovered privileged accounts must be onboarded or removed within [30 days].
3. A privileged account not in the inventory is a policy breach and must be treated as a security finding.

5.2 Privileged accounts

1. Privileged access must use a separate, dedicated account from the person's everyday account. Everyday accounts must not hold administrative rights and must not have mailboxes or browsing on privileged systems.
2. Every privileged account must be attributable to one named person or one owned workload. Shared privileged accounts are prohibited unless the system cannot support individual accounts, in which case the credential must be vaulted, checked out to a named user and rotated after use.
3. Privileged roles must follow least privilege and separation of duties: no single person may both request and approve their own elevation, or both change and approve a Tier 0 configuration.
4. The number of standing Tier 0 assignments must not exceed [number per platform], excluding break-glass accounts.
5. Privileged accounts unused for [45 days] must be disabled, and removed after [90 days].
6. Privileged access must be removed by the end of the working day on departure, and within [5 working days] of a role change.

5.3 Authentication

1. All privileged access must use phishing-resistant multi-factor authentication (FIDO2 security keys or passkeys, or certificate-based authentication). SMS, voice and one-time passcodes must not be used for Tier 0 or Tier 1.
2. Re-authentication with MFA must be required at each elevation or vault checkout.
3. Privileged credential resets and MFA re-registration must require identity verification to the standard in [help desk verification procedure], never on a phone call alone.

5.4 Just-in-time elevation

1. Tier 0 rights must be eligible, not standing, and activated only through the PAM platform for a maximum of [4 hours] per activation.
2. Tier 1 rights should be eligible; where standing rights are retained, they must be listed as exceptions under section 6.
3. Activation must record a business justification and, for Tier 0, a ticket reference and approval by a second authorised person.
4. Activation of Tier 0 roles must notify [security operations] in real time.

5.5 Sessions and administration devices

1. Tier 0 administration must be performed only from a privileged access workstation. Tier 1 administration must be performed from a PAW or an approved hardened jump host.
2. Administration interfaces must not be reachable from the internet or from the general user network; access must pass through [PAM proxy, jump host or ZTNA policy].
3. Tier 0 sessions and interactive Tier 1 sessions to production must be recorded. Recordings must be retained for [12 months] and protected from change by the administrators recorded.
4. Idle privileged sessions must terminate after [15 minutes].

5.6 Privileged credential management

1. Privileged passwords, keys and tokens must be stored only in the approved vault or secrets manager. They must not be stored in scripts, files, tickets, chat, browser password managers or personal accounts.
2. Vaulted human privileged passwords must be rotated after each checkout or at least every [30 days].
3. Local administrator passwords must be unique per device and rotated automatically.
4. All privileged credentials that may have been exposed must be rotated as part of incident containment, including credentials believed to be unused.
5. SSH keys granting root or administrative access must be inventoried, owned, and replaced by short-lived certificates or vault-issued keys where supported.

5.7 Privileged non-human identities

1. Every privileged non-human identity must have a named owner, a documented purpose and a review date.
2. Workloads should use workload identity federation or managed identities instead of long-lived secrets. Where secrets are required, they must be vaulted and rotated at least every [90 days].
3. Service accounts must be denied interactive logon unless documented as an exception.
4. Permissions for AI agents and automation must be scoped to the tools and resources the task needs. Actions with high impact (deleting data, changing access, production deployment) must require human approval.

5.8 Privileged utilities

1. Utilities capable of overriding system controls (remote execution, credential tools, debuggers on production) must be restricted to approved administrators and their use logged.

5.9 Emergency (break-glass) access

1. [Organisation] must maintain at least two emergency accounts per critical identity platform, not tied to one person's everyday identity and not dependent on the systems they recover (for cloud identity, cloud-only accounts).
2. Emergency accounts must use phishing-resistant authentication that differs from the normal admin method, with credentials or keys held in secure storage in separate locations.
3. Every emergency account sign-in must raise a critical alert to [security operations] and be followed by a recorded review.
4. Emergency accounts must be tested at least every [90 days] and after changes in the staff authorised to use them.

5.10 Third-party privileged access

1. Vendor and managed service privileged access must use named accounts, pass through the PAM platform, be time-bound to the contracted task, and be recorded.
2. Third parties must not hold standing Tier 0 access without CISO approval. See the Third-Party Access Policy Template.

5.11 Logging and monitoring

1. All privileged authentication, elevation, vault checkout, role assignment change and privileged command must be logged and forwarded to [SIEM] within [5 minutes].
2. Logs of privileged activity must be protected from change and deletion by the administrators they record, and retained for [12 months] online.
3. Security operations must alert at minimum on: Tier 0 role assignment outside the PAM platform, emergency account use, privileged sign-in from an unapproved device, disabling of logging or session recording, and privileged non-human identity use from unexpected locations.

5.12 Reviews

1. System owners must review Tier 0 eligibility and standing assignments every [quarter], and Tier 1 and privileged non-human identities every [6 months].
2. Access not confirmed in a review must be removed within [10 working days].

6. Exceptions

Exceptions must be requested through [GRC tool], state the statement affected, the reason, compensating controls and an expiry no longer than [6 months]. Tier 0 exceptions require [CISO] approval; others require [PAM owner] and the system owner. Expired exceptions are breaches of this policy.

7. Compliance and monitoring

[PAM owner] must report these measures to [CISO] [monthly]:

Breaches of this policy may lead to removal of privileged access and disciplinary action under [HR policy].

8. Review and approval

This policy is reviewed at least [annually] and after a significant incident involving privileged access, a major platform change, or a change in regulation. Approved by [name, role] on [date]. Version [1.0].

Implementation guidance

This section is for the policy owner and is not part of the issued policy.

Phased adoption

1. Agree tiers and inventory first. Run discovery, classify every privileged role into the section 3 tiers and record owners. Do not publish the policy before you know how many standing Tier 0 assignments exist, or the targets will be fiction.
2. Protect Tier 0. Create and test break-glass accounts, move Tier 0 to eligible assignments with approval, and enforce phishing-resistant MFA. Pilot with the identity team before other admins; keep the old standing assignment disabled, not deleted, for [2 weeks] as rollback.
3. Separate accounts and devices. Issue dedicated admin accounts and PAWs to Tier 0 staff, then jump hosts for Tier 1.
4. Vault and rotate. Onboard shared and service credentials, deploy unique local admin passwords, and remove credentials found in scripts.
5. Bring in machines and third parties. Assign owners to privileged non-human identities and route vendor access through PAM.
6. Measure and enforce. Switch on the section 7 report, start reviews, and turn the section 5.11 alerts into tested detections.

Small and large organisations

A small organisation may run the policy with built-in cloud capabilities (eligible role assignment, conditional access, native audit logs) and a dedicated admin laptop rather than a full PAM suite; keep the statements, adjust the mechanism. A large organisation should add a formal PAM standard per platform, automated reconciliation between discovery and the vault, and a control for each tier in its control library. See the PAM Maturity Model to set realistic targets.

Control mapping

The attacker behaviour this policy targets is mainly MITRE ATT&CK T1078 Valid Accounts (T1078.002 Domain Accounts, T1078.004 Cloud Accounts), T1098 Account Manipulation and T1003 OS Credential Dumping.

Common failure patterns

• Policy covers the vault, not the privilege: accounts outside the PAM platform are treated as out of scope. Statement 5.1.3 closes this.
• Credentials in scripts: in the Uber Breach 2022 the attacker claimed to have found hard-coded admin credentials in a PowerShell script on a network share; Uber did not confirm it, but the pattern is common and is why statement 5.6.1 names scripts and files.
• Service credentials stored in personal accounts: the Okta Support System Breach 2023 involved a service account saved in a personal browser profile.
• "Unused" credentials left unrotated after an incident: in the Cloudflare Thanksgiving Breach 2023 one service token and three service accounts not rotated after the Okta breach were used by the attacker. Statement 5.6.4 requires rotation of anything possibly exposed.
• Break-glass accounts nobody tests: they fail during the outage they exist for, or are used silently. Test and alert per 5.9.
• Help desk resets privileged MFA on a phone call: statement 5.3.3 ties resets to a verification procedure; see the Help Desk Identity Verification Policy Template.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• NCSC: Secure System Administration
• CIS: Control 5 Account Management
• CIS: Control 6 Access Control Management
• Microsoft Learn: Privileged access strategy
• Microsoft Learn: Manage emergency access accounts in Microsoft Entra ID
• Microsoft Learn: What is Privileged Identity Management?

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Privileged Access Management Guide · JIT Access Guide · Break-Glass Account Guide · Privileged Access Workstations Guide · PAM RFP Template