ISO 27001 Annex A Control 8.2: privileged access rights

A single compromised admin credential can turn a contained incident into a full-scale breach. When an attacker gains access to a privileged account that was never reviewed, never restricted, and never monitored, they move laterally through systems without triggering a single alert. Privileged accounts are the most common lateral movement vector in modern breaches because they bypass the controls that protect everything else. ISO 27001 Control 8.2 exists to close that gap by forcing organizations to restrict, manage, and continuously govern privileged access rights.

What 8.2 requires

ISO 27001 Annex A Control 8.2 requires organizations to restrict the allocation of privileged access rights to the minimum number of authorized users and services, and to manage those rights through a formal, repeatable process. The control objective is direct: privileged access must be explicitly authorized, tightly scoped, and reviewed frequently.

In practice, this means organizations must identify every account with elevated permissions across their environment and establish controls around who receives those permissions, how they receive them, and how long they retain them. The scope covers admin accounts, root access, service accounts, application super-users, and any credential that grants permissions beyond what a standard user needs.

The reason this control carries significant weight in ISO 27001 is that privileged accounts bypass normal security controls by design. An admin account can disable logging, modify access policies, extract bulk data, and alter system configurations. When these accounts are misused, whether through insider action or external compromise, the blast radius is effectively unlimited.

Control 8.2 frames privileged access as a continuous governance obligation, aligned with the broader ISO 27001 compliance framework, not a one-time provisioning task. Organizations must maintain an active inventory of privileged accounts, enforce formal request-and-approval workflows, apply the principle of least privilege, and conduct recurring reviews to catch privilege creep, orphaned accounts, and unnecessary standing access. The control also demands that organizations log and monitor privileged activity to detect anomalous behavior before it escalates.

Why 8.2 matters

An IT administrator changes roles within the organization, moving from infrastructure management to a project coordination function. Their active directory admin rights, root access to production servers, and elevated permissions across three cloud platforms persist because no access review is triggered by internal transfers. Six months later, a threat actor compromises that individual’s credentials through a targeted phishing campaign and inherits full administrative access to systems the employee no longer needs. The attacker exfiltrates customer data, modifies audit logs, and establishes persistence across the environment, all without triggering role-based access alerts because the account’s permissions were technically “authorized.”

This scenario represents two overlapping risk classes that 8.2 directly addresses. The first is insider threat, where legitimate users accumulate privileges beyond their current role and either misuse them or become high-value targets for social engineering. The second is external compromise of over-privileged accounts, where attackers specifically target credentials with broad access because the return on a single successful phish is exponentially higher.

The severity is high because privileged accounts have an unlimited blast radius. A compromised standard user account might expose a single mailbox or a departmental file share. A compromised admin account can expose the entire environment, disable security controls, and erase the forensic evidence needed to investigate the breach.

SANS Institute reports that identity-based attacks accounted for 60% of cyber incidents in 2024, underscoring why unmanaged privileged accounts represent the highest-value targets in any environment. Organizations that treat privileged access as a set-and-forget provisioning task rather than a continuously governed risk surface are exposed to exactly this class of attack.

What attackers exploit

• Orphaned privileged accounts: Employees leave the organization, but their admin rights persist in active directory, cloud platforms, and application databases.
• Shared or generic admin credentials: Teams share a single root password or admin account with no individual accountability, making it impossible to attribute actions to specific users.
• Missing or infrequent access reviews: Privilege creep accumulates silently over months or years, granting users far more access than their current role requires.
• Absence of Multi-Factor Authentication (MFA) on administrative accounts: Privileged accounts protected by passwords alone are vulnerable to credential stuffing, phishing, and brute force attacks.
• Standing privileged access instead of just-in-time elevation: Users retain permanent admin rights rather than requesting elevated permissions only when needed, expanding the attack window from minutes to months and increasing the risk of privilege escalation.
• Unmonitored privileged sessions: Without session logging and behavioral monitoring, lateral movement and data exfiltration go undetected until the damage is done.

How to implement 8.2

For your organization (first-party)

1. Inventory all privileged accounts across systems. Catalog every account with elevated permissions, including admin accounts in identity providers, root access on servers, service accounts running automated processes, and application-level super-users. This inventory becomes the privileged access register and should include the account owner, the business justification for elevated access, and the last review date.
2. Establish a formal request-and-approval workflow. Privileged access should never be granted informally. Implement a ticketed process where the requestor documents the business need, a designated approver reviews and authorizes the grant, and the approval is recorded with a timestamp. Most organizations implement this through IT Service Management (ITSM) platforms like ServiceNow or Jira Service Management.
3. Enforce account separation. Require dedicated admin accounts that are distinct from standard user accounts used for daily work such as email, browsing, and document editing. This limits the exposure if a standard account is compromised and creates a clear audit boundary between routine and privileged activity.
4. Implement least privilege and just-in-time elevation. Grant the minimum permissions required for each task and enforce time-limited elevation rather than standing access. Privileged Access Management (PAM) solutions like CyberArk, BeyondTrust, or Delinea enable just-in-time workflows where admin rights are granted for a defined period and automatically revoked when the session ends.
5. Require MFA on all privileged accounts. Enforce MFA at the identity provider level for every account with elevated permissions. This should be non-negotiable, with no exceptions for service accounts or break-glass credentials. Hardware security keys (FIDO2) provide the strongest assurance for high-privilege accounts.
6. Log and monitor all privileged sessions. Feed privileged session logs into a Security Information and Event Management (SIEM) platform or a PAM tool with session recording capabilities. Monitor for anomalous behavior such as off-hours access, bulk data operations, security configuration changes, and access from unusual locations. Configure real-time alerts for high-risk privileged actions.
7. Conduct regular reviews at a quarterly cadence minimum. System owners should review all privileged accounts assigned to their systems every quarter, validating that each account still has a business justification for elevated access. Remove or downgrade any account that no longer requires privileged permissions.
8. Document everything. Maintain an Access Control Policy that defines account types, approval workflows, and review cadence. Retain approval workflow records, review logs with sign-off evidence, and offboarding records that demonstrate timely revocation. This documentation forms the audit trail that auditors and certification bodies expect.

Evidence to produce: Access Control Policy, privileged access register, approval workflow records, quarterly review logs with system-owner sign-off, MFA enforcement records, privileged session logs, and offboarding revocation records.

Tooling categories: Identity providers (Okta, Microsoft Entra ID), PAM solutions (CyberArk, BeyondTrust, Delinea), SIEM platforms (Splunk, Microsoft Sentinel, Elastic Security).

Common mistakes:

• Granting local admin rights to all employees “for convenience.” This eliminates the concept of least privilege and expands the privileged attack surface to every endpoint in the organization.
• Using shared admin credentials with no individual traceability. When three people share a root password, the audit trail is useless and accountability is impossible.
• Reviewing privileged access annually instead of quarterly. Twelve months between reviews allows significant privilege creep and orphaned accounts to accumulate unchecked.
• Forgetting service accounts and automation credentials in reviews. Service accounts often have the broadest permissions and the weakest oversight because they don’t map to a named individual.
• No formal offboarding process to revoke privileged access on termination. Without a defined revocation workflow tied to HR events, departed employees retain active admin credentials for weeks or months.

For your vendors (third-party assessment)

When performing a vendor risk assessment against Control 8.2, include these questions in security questionnaires:

• How does the vendor inventory and classify privileged accounts within their environment?
• What is the formal approval process for granting privileged access?
• How frequently does the vendor conduct privileged access reviews, and who signs off?
• Does the vendor enforce MFA on all administrative accounts?
• Does the vendor implement just-in-time privilege elevation or maintain standing admin access?
• How does the vendor revoke privileged access when employees terminate or change roles?

Evidence to request: Privileged access register (redacted), access review completion reports, MFA enforcement documentation, PAM solution configuration summary, and offboarding procedures.

Red flags that indicate weak privileged access governance include a vendor that cannot name which individuals hold admin access, the absence of any formal review process, and shared root credentials across teams. Any of these signals warrants deeper scrutiny.

Verification beyond self-attestation is essential. Request SOC 2 Type II reports and verify that the trust services criteria cover access control. Review recent penetration test results for findings related to privilege escalation or lateral movement. A vendor’s claim that they “follow best practices” is not evidence; documented, auditable controls are.

Audit evidence for 8.2

Auditors evaluate Control 8.2 by verifying that privileged access rights are restricted, formally managed, and regularly reviewed. The following evidence artifacts demonstrate compliance:

Prepare these artifacts in advance of certification audits. Auditors will sample recent access grants, verify that reviews occurred at the stated cadence, and test that offboarding procedures were followed for recent departures. Gaps in any of these evidence categories will generate nonconformities during the Stage 2 audit, so organizations should run an internal readiness review against this checklist before the external assessment.

Cross-framework mapping

Control 8.2 maps to equivalent requirements across major security and compliance frameworks. Organizations operating under multiple regulatory obligations can consolidate privileged access controls to satisfy several frameworks simultaneously.

Related ISO 27001 controls

Control 8.2 operates within a network of related controls that collectively govern identity, access, and monitoring across the ISO 27001 framework.

Frequently asked questions

What is ISO 27001 8.2?

ISO 27001 Annex A Control 8.2 requires organizations to restrict privileged access rights to the minimum number of authorized users and services, and to review those privileges frequently. It covers admin accounts, root access, service accounts, and any elevated permissions that bypass normal security controls.

What happens if 8.2 is not implemented?

Without 8.2, organizations face uncontrolled proliferation of admin accounts, orphaned credentials from departed employees, and no audit trail for privileged actions. These gaps are the primary access path attackers exploit for lateral movement and data exfiltration.

How do you audit 8.2?

Auditors verify 8.2 by requesting a privileged access register, reviewing approval workflows for recent grants, checking quarterly review completion records, and testing that MFA is enforced on admin accounts. They also look for evidence that privileged access was revoked promptly after role changes or terminations.

How UpGuard helps

Privileged access governance depends on knowing who has access to what, but most organizations lack visibility into the full scope of accounts and applications operating across their workforce. User Risk addresses this gap by discovering the human risk signals that traditional access management tools miss.

• Shadow SaaS and AI discovery: Identifies applications operating outside SSO and formal IT provisioning, revealing unsanctioned tools where privileged accounts may exist without oversight. Organizations typically discover that 50% of their SaaS applications operate outside SSO governance.
• Per-user risk scoring (0–950): Assigns a quantified risk score to each individual based on their application usage, permissions, and credential exposure, helping security teams prioritize which users and accounts to review first.
• Real-time contextual nudges: Delivers in-workflow coaching at the moment a risky action occurs, building measurable secure habits rather than relying on periodic compliance training that doesn’t change behavior.
• Compromised credential monitoring: Flags accounts exposed in third-party data breaches, identifying privileged users whose credentials may already be circulating on dark web marketplaces.