ISO 27001 A.8.2: Privileged Access Rights

ISO 27001 A.8.2 requires that privileged access rights, the elevated permissions that let a person change configuration, read all data, or bypass controls, are allocated and used on a restricted, need-to-use basis and reviewed. The action teams get flagged on most is attribution: shared admin accounts and standing break-glass credentials that nobody can tie to a named person on a given day.

What is ISO 27001 A.8.2?

ISO 27001 A.8.2 Privileged access rights governs how elevated permissions are granted, used, and controlled. In the words of ISO/IEC 27001:2022, Annex A, the control title is Privileged access rights. The intent, as described in ISO/IEC 27001:2022, Annex A, is that the allocation and use of privileged access is restricted and managed so that elevated permissions are given only where needed and only for as long as needed.

Privileged access is any permission that exceeds a standard user: domain and system administrator rights, root and sudo, cloud account owner and IAM administrator roles, database owner accounts, hypervisor and virtualization consoles, and the accounts that manage security tooling itself. A.8.2 falls within the broader access control intent of A.5.15 and applies it specifically to these high-impact permissions, where a single misused account can change or expose an entire environment.

How do you implement A.8.2?

Implement ISO 27001 A.8.2 by treating privileged access as a controlled, time-bound exception rather than a standing entitlement. The sequence a team follows:

1. Identify every privileged role. Enumerate which permissions count as privileged across the estate: infrastructure admin, cloud account owner, IAM administrator, database owner, security-tool admin. This list is the scope for every later step.
2. Allocate on a need-to-use, time-limited basis. Grant privileged rights against a specific business need and an authorization record rather than by default. Where possible, grant them for a defined window and remove them when the task is done, rather than leaving them standing.
3. Separate privileged identities from standard accounts. A person with admin duties gets a separate named admin identity for privileged work and a normal account for day-to-day email, browsing, and documents. Everyday activity never runs with elevated rights.
4. Use unique named admin accounts, never shared ones. Every privileged account resolves to one person. Shared administrator logins are the most common way attribution breaks, and they are the first thing an auditor probes.
5. Enforce MFA on all privileged access. Multi-factor authentication is expected on every path that reaches elevated permissions, whether that is the cloud console, the VPN, or the bastion, and is typically enforced through the identity provider, such as Okta or Microsoft Entra ID.
6. Elevate just in time through a PAM workflow. A privileged access management tool (for example, Teleport or CyberArk) or a cloud just-in-time mechanism grants elevation on request, for a bounded window, with approval and session recording, then revokes it automatically.
7. Log and review privileged activity. Privileged sessions and administrative actions are logged, and privileged access rights are reviewed on a defined cadence to confirm each grant is still warranted.
8. Define a break-glass procedure. For the rare case where normal access fails, keep emergency credentials in a controlled vault, alert on every use, investigate each alert, and rotate the credential afterward.

In cloud environments

In cloud environments, A.8.2 is implemented through the provider's identity and access primitives rather than standing admin logins. IAM roles and policies define privileged entitlements, and permission boundaries cap how far any role can escalate. Just-in-time elevation through a privileged identity mechanism (Azure AD Privileged Identity Management, or equivalent role-assumption workflows in AWS and GCP) grants an administrator elevated rights for a bounded window with approval, instead of a permanent admin assignment. Administrative and API activity is captured in the provider's audit log (AWS CloudTrail, Azure activity logs, GCP Cloud Audit Logs), which becomes the evidence that privileged actions are attributable to named identities.

On-prem / self-hosted

On-prem and self-hosted environments implement A.8.2 by controlling directory privilege groups and forcing all admin access through a monitored path. Membership of Active Directory privileged groups (Domain Admins, Enterprise Admins, local Administrators) is the primary thing to restrict and review, since these grant environment-wide control. A PAM vault checks out and rotates privileged credentials with session recording, and a bastion host is the only system permitted to reach production for administrative work, tying every privileged session to a named individual. Routing all administrative work through one monitored path is a security architecture decision that shapes every control in the sequence above. Break-glass credentials for the rare directory-down scenario live in the vault with alerting on every use. The on-prem access control guide covers the Active Directory, bastion, and PAM implementation in depth.

Cloud vs on-prem at a glance

What evidence demonstrates A.8.2?

Evidence for ISO 27001 A.8.2 is the record that privileged access is inventoried, granted deliberately, and reviewed, and that its use is attributable. Teams that wire elevation logs and access-review exports into automated evidence collection are practicing GRC engineering, which keeps these records continuous instead of reconstructed at audit time.

How does A.8.2 map to SOC 2?

ISO 27001 A.8.2 maps to the SOC 2 access control criteria that govern how logical access is restricted and how privileged and terminated access is removed.

Organizations running both frameworks can reuse privileged access evidence almost wholesale across A.8.2 and the CC6 criteria. The SOC 2 to ISO 27001 control mapping covers the full crosswalk and where SOC 2 work transfers to ISO 27001.

Related controls

ISO 27001 A.8.2 applies the general access control intent to elevated permissions specifically. A.5.15 access control sets the overall rules for granting and restricting access, and A.5.18 access rights governs the provisioning, review, and removal lifecycle that privileged accounts also follow. A.8.3 information access restriction limits what an authenticated identity can reach once inside, and A.8.18 use of privileged utility programs controls the high-privilege tooling those admin accounts run. All four belong to the Technological theme covered by the ISO 27001 certification guide.

Frequently Asked Questions

What is ISO 27001 A.8.2?

ISO 27001 A.8.2 is the Annex A control titled Privileged access rights, in the Technological theme. It requires that elevated permissions such as administrator, root, and cloud account-owner rights are allocated and used on a restricted, need-to-use basis, separated from standard accounts, and reviewed, so that high-impact access stays controlled and attributable.

What evidence satisfies A.8.2?

Typical A.8.2 evidence includes a privileged role and account inventory, authorization records for each privileged grant, MFA configuration on privileged access paths, PAM or just-in-time elevation logs, privileged session and activity logs, periodic privileged access review records, and a break-glass inventory with usage alerts and investigation notes.

Is A.8.2 new in ISO 27001:2022?

No. Privileged access rights carried over from the 2013 version of the standard and was not introduced in the 2022 revision. The 2022 revision reorganized Annex A into four themes and placed privileged access rights under the Technological controls as A.8.2, but the control itself is not new.

How do you handle shared privileged accounts under A.8.2?

Make shared privileged credentials the documented exception rather than the default. Create unique named admin accounts for daily privileged work so activity is attributable, and reserve any shared credential for break-glass emergencies in a controlled vault. Alert on every break-glass use, investigate each one, and rotate the credential afterward so the shared account no longer breaks attribution.

How does A.8.2 map to SOC 2?

A.8.2 has Full overlap with SOC 2 CC6.1 and CC6.3, the criteria covering logical access restriction and role-based, least-privilege access. Privileged access evidence, including the account inventory, MFA configuration, elevation logs, and access reviews, is reusable across both frameworks with little adaptation.