ISO 27001 Privileged Access: The Complete 2026 Guide

ISO 27001 privileged access is covered by exactly one Annex A control — 8.2 — and that control’s own purpose statement is wider than almost every implementation of it. It exists to ensure that only authorised users, software components and services hold privileged access rights. Most organisations read the first noun and stop. They produce a list of domain admins, a password vault, and a quarterly review of human accounts, then discover at Stage 2 that nobody can say who owns the service account with owner rights on the production database.

This guide covers what ISO 27001 privileged access actually requires under control 8.2, which 2013 controls it replaced, how it differs from the three neighbouring controls auditors routinely confuse it with, what evidence closes it out, and the review cadence you can defend when the standard itself refuses to give you a number.

What ISO 27001 Privileged Access Covers Under Control 8.2

ISO/IEC 27001:2022 — edition 3, published October 2022 — carries 93 Annex A controls in four themes: 37 organizational, 8 people, 14 physical and 34 technological. Control 8.2, titled simply Privileged access rights, sits in the technological theme. Its stated purpose is to ensure only authorised users, software components and services are provided with privileged access rights.

Two words in the control title do a lot of work. It is not “privileged accounts” and it is not “privileged users” — it is privileged rights. The unit of control is the entitlement, not the login. That distinction matters the moment you move into a cloud estate, where a privileged right is more often a role attached to a workload than a username attached to a person.

The control is also narrow in a way people miss. It governs the allocation, use and withdrawal of elevated entitlements. It does not govern the access control policy itself (that is A.5.15), the identity lifecycle (A.5.16), authentication secrets (A.5.17), or the provisioning and review of ordinary access rights (A.5.18). An ISO 27001 privileged access control that tries to carry all five ends up evidencing none of them cleanly.

Who Counts as Privileged — and Why Service Accounts Break Most Programmes

An honest ISO 27001 privileged access inventory lists every identity in your estate that can change a security setting, grant someone else access, read data in bulk, or stop a log being written. On most of those lists, the human administrators are a minority. The control’s reference to software components and services is not decoration; it is the half of the population that goes unevidenced.

CIS Critical Security Controls v8.1, published June 2024, makes the same split explicit and treats it as two separate jobs. Safeguard 5.1 requires an inventory of all accounts that at minimum includes user, administrator and service accounts, validated on a recurring schedule at minimum quarterly. Safeguard 5.5 then requires a separate inventory of service accounts carrying department owner, review date and purpose, also reviewed at minimum quarterly. NIST makes the point from the other direction: SP 800-53’s least-privilege control applies to “users (or processes acting on behalf of users)”, and enhancement AC-6(8) exists purely to stop software executing at a higher privilege level than the user who invoked it.

Privileged identity type	Typical example	What usually goes wrong	Evidence that closes it
Named human administrator	Domain admin, cloud global admin	Same account used for email and browsing	Separate admin identity plus an approval record
Break-glass account	Emergency tenant-level admin	Exists, is never tested, is never monitored	Sealed credential, use log, periodic test record
Service account	Application identity on a database	No named owner, no expiry, no review	Service account register with owner and purpose
Pipeline or automation token	CI/CD deploy credential	Scoped to the whole subscription “for now”	Scope definition plus rotation evidence
Vendor or support identity	Managed service provider admin	Standing access rather than time-boxed	Time-bound grant tied to a ticket
Cloud role or managed identity	Workload role with write permissions	Not treated as an account at all	Role inventory in the same register as humans

The practical test is simple. Ask whoever runs your ISO 27001 privileged access process to produce a single register that lists non-human identities alongside human ones, with an owner against each. If two registers come back, or if the second one does not exist, the gap is real and an auditor sampling from your cloud console rather than your directory will find it in minutes.

Where ISO 27001 Privileged Access Came From in the 2013 Standard

If you transitioned from ISO/IEC 27001:2013, your ISO 27001 privileged access documentation already exists — it is just filed under the wrong number. The 2013 standard’s Annex A.9 Access Control held 14 controls. Those 14 collapsed into 9 in the 2022 edition, and control 8.2 is one of only two in that family that came through as a dedicated privilege control.

2013 control	2013 title	2022 control	2022 title
A.9.1.1	Access control policy	A.5.15	Access control
A.9.1.2	Access to networks and network services	A.5.15	Access control
A.9.2.1	User registration and de-registration	A.5.16	Identity management
A.9.2.2	User access provisioning	A.5.18	Access rights
A.9.2.3	Management of privileged access rights	A.8.2	Privileged access rights
A.9.2.4	Management of secret authentication information of users	A.5.17	Authentication information
A.9.2.5	Review of user access rights	A.5.18	Access rights
A.9.2.6	Removal or adjustment of access rights	A.5.18	Access rights
A.9.3.1	Use of secret authentication information	A.5.17	Authentication information
A.9.4.1	Information access restriction	A.8.3	Information access restriction
A.9.4.2	Secure log-on procedures	A.8.5	Secure authentication
A.9.4.3	Password management system	A.5.17	Authentication information
A.9.4.4	Use of privileged utility programs	A.8.18	Use of privileged utility programs
A.9.4.5	Access control to program source code	A.8.4	Access to source code

A.9.2.3 maps one-to-one onto A.8.2 with nothing merged into it, which makes this one of the easiest transitions in the whole standard. The only change is the title: the 2013 control was Management of privileged access rights, the 2022 control drops the first two words. If your 2013 procedure was sound, it still is. Compare that with control management elsewhere in the 2022 edition — change management, for instance, absorbed four separate 2013 controls — and you can see why ISO 27001 privileged access rarely shows up as a transition problem.

What does show up is the reverse of that comfort. Because nothing changed, nobody reopened the document, so it still reflects a 2013 on-premises estate with a domain controller and a password vault, and says nothing about cloud roles or pipeline credentials.

What Control 8.2 Expects You to Do

ISO/IEC 27002:2022 provides the implementation guidance behind Annex A, and its guidance on ISO 27001 privileged access breaks into eight recognisable expectations. Paraphrased, they are:

1. Identify who and what needs privileged access for each system, application and process — rather than inheriting whoever happens to be in the admin group.
2. Allocate rights on a need-to-use basis, event by event, consistent with your access control policy and the minimum required by the functional role.
3. Run an authorisation process and keep a record of every privilege allocated. The record is the audit artefact; without it the process is unverifiable.
4. Apply expiry dates and time limits. Standing privilege is the default failure mode, and a time-boxed grant is the cheapest fix available.
5. Require re-authentication before privileged rights are used. This is the single most commonly missed item in the guidance.
6. Use a separate identity for privileged work, distinct from the one used for routine business duties.
7. Review duties, roles, responsibilities and competence of privileged holders regularly, and specifically after organisational change.
8. Control generic administration IDs — prevent standard built-in usernames and shared passwords being used unattributably, and protect the authentication information of any that must exist.

Item 5 deserves its own paragraph because it is where most tooling stops short. Being logged into a privileged session is not the same as having just proved you are the person entitled to it. Step-up authentication at the point of elevation — not merely at the start of the working day — is what the guidance is asking for, and it is what a modern just-in-time elevation model gives you almost for free.

Item 7 is the one with teeth in an audit. Competence is not usually treated as an access control question, but the guidance ties the right to hold privilege to the holder’s current duties and their competence. That is a direct hook into clause 7.2, which requires you to determine competence, ensure it, and retain documented information as evidence of it. If your administrators hold rights on systems they were never trained to operate, you have a finding available in two different places at once.

ISO 27001 Privileged Access Versus Its Three Nearest Neighbours

Four controls touch elevated access, and ISO 27001 privileged access is only one of them. They are four separate lines in your Statement of Applicability, which clause 6.1.3 makes a mandatory document. Each one has to be justified and evidenced on its own.

Control	Title	What it governs	Typical primary evidence
A.5.15	Access control	The rules themselves — who may access what, on what basis	Access control policy
A.5.18	Access rights	Provisioning, modification, removal and periodic review of all access	Joiner-mover-leaver records, access review output
A.8.2	Privileged access rights	Allocation, use, expiry and attribution of elevated entitlements	Privileged identity register, approvals, session logs
A.8.18	Use of privileged utility programs	Tools capable of overriding system and application controls	Approved tool list, restricted install rights, usage logs

A.8.18 is worth dwelling on because it is the one almost nobody evidences. It came through from 2013’s A.9.4.4 with its title completely unchanged, and it covers software that can bypass the controls you have just finished documenting: disk and registry editors, debuggers, database administration consoles, packet capture tools, endpoint management agents and cloud shells. Most organisations mark it applicable, write “covered by the access control policy” in the justification column, and attach nothing. An ISO 27001 privileged access programme that inventories accounts but not the utilities those accounts can run leaves half of its elevation surface undocumented.

The split also matters in the other direction. If you are building a documented ISO 27001 access control policy, resist the urge to pour privileged access procedure into it. The policy states the rules; the privileged access procedure and register carry the operational detail for A.8.2.

How Often to Review ISO 27001 Privileged Access

ISO/IEC 27001:2022 does not state a review frequency for ISO 27001 privileged access anywhere — not in Annex A, not in clause 9. ISO/IEC 27002’s guidance asks for review “regularly” and specifically after organisational change. That is deliberate: frequency is a risk decision, and a certification body will test whether your stated interval is justified and met, not whether it matches someone else’s number.

What you can do is anchor your interval to a published benchmark and record why you chose it. The figures below are the defensible reference points, all drawn from free, citable sources.

Activity	Published benchmark	Source	Applies to
Validate all active accounts, including administrator accounts	At minimum quarterly	CIS v8.1 Safeguard 5.1	Implementation Groups 1, 2 and 3
Review the service account inventory	At minimum quarterly	CIS v8.1 Safeguard 5.5	Implementation Groups 2 and 3
Disable dormant accounts	After 45 days of inactivity	CIS v8.1 Safeguard 5.3	Implementation Groups 1, 2 and 3
Review privileges assigned to roles or classes of user	Organisation-defined frequency, with reassignment or removal where the need fails revalidation	NIST SP 800-53 AC-6(7)	Any system using the catalogue
Review access rights after organisational change	Event-driven, in addition to the periodic cycle	ISO/IEC 27002 guidance for 8.2	All privileged holders

The ISO 27001 privileged access pattern that survives audit is a shorter cycle for privileged identities than for ordinary ones, with the difference written down and justified. Quarterly for privileged and annually for standard is a common and defensible shape. If you already run a general user access review, the cheapest route is to split privileged identities out as their own campaign rather than letting them ride along on the annual sweep, where line managers approve them without understanding what the entitlement grants.

One trap: event-driven review is not optional padding. If your only trigger is the calendar, a restructure in month two leaves nine months of unjustified privilege. Tie the review to your leaver and role-change process, not just to a date.

Mapping ISO 27001 Privileged Access to NIST and CIS

Annex A gives you the ISO 27001 privileged access requirement; other free frameworks give you the testable detail. NIST SP 800-53 Rev. 5 — whose current minor release, 5.2.0, was issued on 27 August 2025 — carries AC-6 Least Privilege with ten enhancements, and between them they read as a ready-made completeness test for control 8.2.

Expectation under A.8.2	NIST SP 800-53 Rev. 5	CIS Controls v8.1
Minimum necessary entitlement, for people and for processes	AC-6 Least Privilege	Control 6 overview
Restrict privileged accounts to defined roles	AC-6(5) Privileged Accounts	Safeguard 5.1
Separate identity for routine versus privileged work	AC-6(2) Non-Privileged Access for Nonsecurity Functions	Safeguard 5.4
Authorise access to security functions explicitly	AC-6(1) Authorize Access to Security Functions	Safeguard 6.8
Control privileged commands reached over the network	AC-6(3) Network Access to Privileged Commands	Safeguard 6.7
Exclude non-organisational users from privileged access	AC-6(6) Privileged Access by Non-Organizational Users	Safeguard 6.2
Periodic revalidation of assigned privileges	AC-6(7) Review of User Privileges	Safeguard 5.1 and 5.5
Software must not run above its invoker’s privilege	AC-6(8) Privilege Levels for Code Execution	Safeguard 5.5
Log privileged activity	AC-6(9) Log Use of Privileged Functions	Control 8 overview
Block privileged functions from ordinary users	AC-6(10) Prohibit Non-Privileged Users from Executing Privileged Functions	Safeguard 5.4
Strong authentication at the point of elevation	IA-2 family	Safeguard 6.5

Two of these are worth quoting into your own procedure. AC-6(3) requires that network access to privileged commands be authorised only for compelling operational need, with the rationale documented in the system security plan — a written justification requirement that Annex A implies but never states. And AC-6(9) is a one-line control: log the execution of privileged functions. That is the hinge between A.8.2 and the logging controls, and it is why your ISO 27001 logging design has to treat privileged sessions as a distinct event class rather than as ordinary authentication noise.

On the operational side, the UK National Cyber Security Centre’s identity and access management guidance is the clearest free statement of what good looks like: a tiered model for administrative accounts, full-privilege accounts used only when genuinely necessary, separate accounts for day-to-day work such as email and browsing, multi-factor authentication on every administrative account with hardware tokens considered for the highest tiers, administrative access separated onto its own devices with unnecessary web and email access blocked, and unnecessary privilege reviewed and revoked on a regular basis. Those six statements, implemented honestly, satisfy most of the ISO 27001 privileged access requirement on their own.

The Evidence an Auditor Will Ask For

Certification bodies test ISO 27001 privileged access by sampling. Expect the auditor to pick two or three privileged identities from your own tooling — not from your register — and trace them backwards. Have these ready:

• A privileged identity register covering human accounts, service accounts, automation credentials and cloud roles, each with a named owner and a stated purpose.
• Approval records for a sample of grants, showing the requester and the approver were different people.
• Evidence of separation — that named administrators hold a second, non-privileged account and that routine work happens there.
• Expiry or time-boxing evidence for at least the highest-privilege tier, whether that is just-in-time elevation or a dated grant with a review record.
• Review output from your last privileged access review, including the decisions made and the removals actioned — not just the list that was circulated.
• Privileged session logs showing activity attributable to an individual, which is what rules generic shared accounts out.
• Leaver evidence proving privileged rights were withdrawn on the day, since this is the sample an auditor takes most often.
• An approved utility program list and the restriction preventing their installation, for A.8.18.
• Competence records for privileged holders, linking back to clause 7.2.

All of that belongs in your Statement of Applicability as two distinct lines with two distinct justifications. Writing “see access control policy” against both is the fastest way to turn one weak document into two observations.

Five Mistakes That Turn ISO 27001 Privileged Access Into a Nonconformity

These are the failures that come up again and again, in order of how often they appear.

1. Only human accounts are in scope. The register lists administrators and nothing else. Service accounts, pipeline tokens and cloud workload roles hold more privilege in aggregate than the people do, and the control’s purpose statement names them explicitly. This is the single biggest gap in ISO 27001 privileged access programmes.

2. Standing privilege with no expiry. Everything was justified when it was granted, three years ago, and nothing has expired since. Without time limits you cannot distinguish current need from historical accumulation, and the register becomes a record of privilege creep rather than a control.

3. One account for admin work and email. It is the oldest finding in the book and it is still the most common. Both CIS Safeguard 5.4 and the NCSC guidance address it directly, and it is one of the eight expectations in the 27002 guidance. There is no risk-based argument for it.

4. Shared generic administrator credentials. A built-in administrator account whose password four people know destroys attribution. If the account must exist, it belongs in a vault with checkout logging, and the credential has to change when anyone with knowledge of it leaves or moves role.

5. Review that produces a list but no decisions. The review ran, the spreadsheet was circulated, every line was approved, nothing was removed. A review with a zero removal rate across a whole estate is evidence that the review did not happen in substance, and experienced auditors treat it that way. Record the challenges and the revocations, not just the sign-off.

ISO 27001 Privileged Access FAQ

Is a privileged access management tool required for ISO 27001?

No. ISO 27001 requires no named technology for any control, and a certification body cannot insist on a product. What ISO 27001 privileged access requires is that allocation is authorised and recorded, use is attributable and logged, rights expire or are reviewed, and privileged identities are separate from routine ones. A vault with checkout logging and just-in-time elevation makes all of that much easier to evidence in a large estate; in a 20-person company a directory, a documented approval route and a quarterly review will pass.

Do service accounts really count as privileged access?

Yes, when they hold elevated entitlements — and this is the part of the control most often missed. The purpose statement for 8.2 names software components and services alongside users. CIS v8.1 Safeguard 5.5 requires a dedicated service account inventory with owner, purpose and review date, and NIST’s least-privilege control extends explicitly to processes acting on behalf of users. A register that stops at human administrators is incomplete on the face of the control.

Is a separate privileged access policy a mandatory document?

No. ISO 27001 names a short list of mandatory documents and a privileged access policy is not on it. Access control is covered by A.5.15, which expects documented rules, and in practice ISO 27001 privileged access is most cleanly handled as a procedure plus a register underneath that policy. The register is what the auditor samples from, so if you build only one artefact, build the register.

How is A.8.2 different from A.5.18?

A.5.18 Access rights covers provisioning, modification, removal and review for all access, and it absorbed three separate 2013 controls. A.8.2 covers only elevated entitlements, and adds requirements that do not apply to ordinary access: separate identities, expiry, re-authentication at elevation, competence review and attribution of shared administrative credentials. They are two SoA lines and need two justifications.

How often should ISO 27001 privileged access be reviewed?

The standard sets no interval. Pick one, justify it against your risk assessment, and meet it. Quarterly for privileged identities against annually for standard users is the common and defensible shape, and it lines up with the quarterly minimum in CIS v8.1 Safeguards 5.1 and 5.5. Add event-driven reviews on role change, restructure and departure, because a calendar-only trigger leaves months of unjustified privilege after a reorganisation.

Getting the Documents Written

ISO 27001 privileged access is not conceptually hard. The work is in the artefacts: a privileged access procedure that covers non-human identities, a register with owners and expiry dates, an approval route that separates requester from approver, a review campaign scoped to privileged identities alone, and a Statement of Applicability that treats A.8.2 and A.8.18 as the two separate controls they are. Drafting that set from a blank page takes a competent person several weeks, and most of it is structure rather than thought.

The ISO 27001 Toolkit — 165 templates covering the full standard, including the access control policy, privileged access procedure, access register and Statement of Applicability, for $99 — gives you that structure already written and cross-referenced to the 2022 control set, so the time you spend goes on the decisions that are specific to your estate. If you are still working out which controls apply at all, start with the full ISO 27001:2022 controls list and come back to 8.2 once your scope is settled. You can confirm the current edition and its amendment status directly on the ISO catalogue page for ISO/IEC 27001.