Access Control Policy Template: Least Privilege, Reviews and Non-Human Access

Most access control policies say "least privilege" and "regular reviews" but never say who approves access, how fast a leaver loses it, or what happens to the service accounts and API keys that now outnumber staff. This template gives you an internal access control policy with numbered statements you can adopt as written: account types, approval, joiner-mover-leaver timings, privileged access, non-human identities, access reviews, logging and exceptions. It covers access by your own workforce and your own workloads to your own systems. Access by vendors, contractors, managed service providers and external integrations is covered in the companion Third-Party Access Policy Template. It is written for CISOs, IAM leads and GRC teams.

How to use this template

• Replace text in square brackets, such as [Organisation], [IAM team] and [X days], with your own terms and values. Values shown in brackets are illustrative starting points, not requirements from any standard.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a justified exception may apply.
• Keep product settings (Conditional Access, PIM, IAM conditions) in a supporting standard; NIST SP 800-53 AC-1 expects a policy plus implementing procedures.
• Statements on ownership, approval, review and removal apply to non-human identities unless they say otherwise.

1. Purpose

This policy sets the requirements for granting, using, reviewing and removing access to [Organisation] information systems and data, so that every identity, human or non-human, is known, owned and uniquely identifiable; access is limited to approved need with incompatible duties separated; privileged access is restricted and recorded; and access is removed promptly when no longer needed.

2. Scope

This policy applies to all [Organisation] information systems, applications, cloud tenants and subscriptions, databases, networks, SaaS services and data, in production and non-production environments, and to all identities that access them:

• Workforce identities: employees, interns and temporary staff employed by [Organisation].
• Administrative identities: separate accounts or roles used for privileged tasks.
• Non-human identities (NHIs): service accounts, managed identities, workload identities, service principals, API keys, access tokens, certificates, SSH keys, CI/CD pipeline identities, bots and AI agents owned and operated by [Organisation].
• Emergency (break-glass) accounts.

Access by third parties, including contractors not employed by [Organisation], suppliers, managed service providers and vendor-owned integrations, is governed by the [Third-Party Access Policy], which applies this policy's principles with additional requirements.

3. Roles and responsibilities

4. Policy statements

4.1 Principles

1. Access must be granted on the basis of least privilege: only the access necessary to perform an approved task, for the time it is needed. This applies equally to processes and workloads acting on behalf of users.
2. Access must be denied by default. Any access not explicitly granted is prohibited.
3. Access should be granted through roles or groups defined by system owners; direct permission assignments are exceptions.
4. Duties that would allow one identity to initiate, approve and conceal a sensitive action must be separated. System owners must document such incompatible combinations in [SoD rule set], and the provisioning process must block or flag them.
5. Network location alone must not be treated as proof of authorisation.

4.2 Account types

Only the account types below are permitted. Any other type, including shared accounts used by several people, is prohibited unless approved under section 5.

4.3 Requesting, approving and provisioning access

1. All access must be requested through [access request system] and approved by the system or data owner, and by the line manager for workforce identities. Requesters must not approve their own access.
2. Privileged roles, [Restricted] data access and SoD conflicts require a second approval from [Security team].
3. Accounts must be provisioned from authoritative sources ([HR system], [NHI inventory]), automated through SCIM where supported.
4. Access must use single sign-on through the [corporate identity provider] wherever supported; exceptions must be recorded in [application register].
5. Multi-factor authentication must be required for all workforce access to [Organisation] systems, and phishing-resistant methods (FIDO2 security keys, passkeys or certificate-based authentication) must be required for administrative access.

4.4 Movers and leavers

1. When a person changes role, access tied to the old role must be removed within [5] business days of the effective date unless the new manager approves its retention for a defined handover period of no more than [30] days.
2. Workforce accounts must be disabled within [4 hours] of the termination time recorded in [HR system], and immediately for involuntary or hostile terminations.
3. On disablement, active sessions and refresh tokens must be revoked, and any credentials known to the leaver that cannot be individually revoked (shared secrets, group account passwords, break-glass credentials) must be rotated.
4. Non-human identities owned by a leaver must be transferred to a new owner within [10] business days, or suspended.
5. Accounts with no successful sign-in for [45] days must be disabled automatically, and deleted after a further [45] days unless retained for a recorded legal or audit reason.

4.5 Privileged access

1. Privileged access must be limited to named individuals approved under 4.3, with the number of standing global or domain-level administrators kept to [the minimum operationally required, target no more than 5 per platform].
2. Privileged roles should be eligible rather than permanently assigned, activated just in time with a justification, for no longer than [8] hours.
3. Administration should follow a tiered model: credentials for identity providers, domain controllers, cloud management planes and secrets managers must not be used on lower-trust devices.
4. Use of privileged functions must be logged, and sessions on [critical systems] should be recorded through [privileged access management platform].

4.6 Non-human identities

1. Every non-human identity must be registered in [NHI inventory] before it receives production access, recording its owner, purpose, systems accessed, permissions, credential type, credential location, expiry and environment.
2. Each workload, pipeline and agent must have its own identity. Non-human identities must not be shared between applications, and people must not sign in interactively with a service account.
3. Platform-issued, short-lived credentials (managed identities, workload identity federation, OIDC federation for CI/CD) should be used in place of static secrets wherever the platform supports them.
4. Static credentials that cannot be avoided must be stored only in [approved secrets manager], never in source code, configuration files in repositories, tickets, chat, browser profiles or personal password managers, and must be rotated at least every [90] days and immediately on suspected exposure.
5. Non-human identities must not be granted owner, administrator or wildcard permissions in production without approval by [CISO or delegate] and quarterly review.
6. Non-human identities unused for [90] days must be reviewed by their owner and disabled if not required. Decommissioning must revoke all credentials and remove role assignments, not only delete the account object.

4.7 Access reviews

Access must be reviewed by the accountable reviewer at the frequency below. Reviewers must confirm that each entitlement is still required; access that is not confirmed within [14] days of the review closing must be removed.

4.8 Logging and monitoring

1. Authentication events, access grants and removals, privileged role activations and changes to permissions must be logged with the identity, time, source and outcome, and retained for [12] months.
2. [Security operations] must alert on: sign-ins by disabled or leaver accounts, interactive sign-in by service accounts, break-glass use, privilege grants outside the request process, and use of a credential from an unexpected location or workload.

5. Exceptions

Where a requirement cannot be met, the system owner must request an exception through [exception process], stating the requirement affected, the business reason, the risk, compensating controls and an expiry date of no more than [12] months. Exceptions are approved by [CISO] for high risk and by [Security team] otherwise, recorded in [exception register], and reviewed before expiry. An expired exception is non-compliance. See the Security Exceptions and Risk Acceptance Guide.

6. Compliance and monitoring

• Continuous checks: [IAM team] reconciles accounts against [HR system] and [NHI inventory] at least [daily] and reports orphaned accounts, ownerless NHIs and dormant accounts.
• Metrics reported [monthly] to [Security steering group]: median and 95th percentile time from HR termination to account disablement; percentage of access reviews completed on time and percentage of entitlements revoked in them; number of standing privileged role assignments against target; percentage of non-human identities with a current owner; percentage of static secrets older than the rotation period; number of open and expired exceptions.
• Assurance: [Internal audit] tests samples of joiners, leavers, privileged grants and NHIs [annually].
• Non-compliance: accounts or identities found in breach may be disabled. Deliberate breaches by staff may be handled under [disciplinary procedure].

7. Review and approval

This policy is owned by [CISO] and approved by [Executive committee / Board risk committee]. It must be reviewed at least [annually] and after a significant incident involving access, a major change to the identity platform, or a change in applicable regulation.

Implementation guidance

Rolling it out

1. Inventory first. Export every account from the identity provider, directories and top cloud and SaaS platforms, and separate human, administrative and non-human identities. Reconcile humans against HR. Assign owners to non-human identities before enforcing anything.
2. Fix leavers before roles. Connect HR termination events to the identity provider and measure time to disable.
3. Separate and reduce privilege. Create separate admin accounts, move standing administrators to eligible just-in-time roles, and set the phishing-resistant MFA requirement in report-only or audit mode first, then enforce it for one admin group before the rest.
4. Bring NHIs under the policy. Register service accounts and keys, move credentials into the secrets manager, and replace static keys with federated or managed identities, starting with CI/CD and cloud workloads. See the Service Account Inventory Template.
5. Run the first review as a pilot. Start with privileged roles on two or three critical systems, measure revocation rates and reviewer complaints, then expand. Do not auto-remove on non-response until owners are trained.
6. Plan rollback. Before enforcing dormant-account disablement or MFA, keep a break-glass path, disable rather than delete, and keep an owned, expiring exclusion group.

Decision guidance

• RBAC or ABAC: role-based access is easier to review and suits stable job families; attribute-based rules suit large or fast-changing populations and data-level decisions but are harder to certify. See the Authorisation Models Guide.
• Small organisations: keep the account types, leaver timing, separate admin accounts and an annual review using the identity provider's built-in reviews.
• Large or regulated organisations: drive provisioning from HR through an IGA platform, express SoD rules in it, and use just-in-time elevation for all privileged roles. See the IAM and IGA Basics.

Common failure patterns

• Service account credentials outside the vault: in the Okta support system breach, credentials for a support service account were saved in an employee's personal Google profile in Chrome, and their exposure gave the attacker access to files for 134 customers. Statement 4.6.4 exists for this reason.
• Rubber-stamp reviews: reviewers approve what they cannot interpret. Show plain-language descriptions and last-used dates, and report revocation rates. See the Access Reviews Guide.
• Disable without revoke: refresh tokens and API keys created by the leaver keep working. See the Joiner-Mover-Leaver Guide.
• Ownerless NHIs: service accounts outlive their projects, keep broad rights and are never reviewed. See the Service Account Security Guide.

Framework mapping

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls (AC, IA, PS and AU families)
• NIST: Cybersecurity Framework 2.0
• CIS: Control 5, Account Management
• CIS: Control 6, Access Control Management
• NCSC: 10 Steps to Cyber Security, Identity and Access Management
• NCSC: Secure System Administration
• Microsoft Learn: What are access reviews?

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Information Security Policy Template · Third-Party Access Policy Template · NIST SP 800-53 Guide · Zero Trust Identity Guide · Security Policy Framework Guide