Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.2 — Privileged Access Rights

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.2 ISO 27001ISO 27002BSI OPS.1.1.2

An IT administrator uses a domain admin account for daily email and web browsing. When they click a phishing link, the attacker gains full control of the Active Directory in seconds. A.8.2 exists to prevent this scenario: the control requires that privileged access rights are tightly restricted, separately authenticated and regularly reviewed.

Privileged accounts — admin, root, service accounts with elevated permissions — are the most valuable targets for attackers. A single compromised privileged account can undermine every other security control in the organization.

What does the standard require?

  • Restrict allocation. Privileged access rights are granted only to users who genuinely need them, for the minimum scope and duration necessary, following a formal authorization process.
  • Separate privileged and standard accounts. Privileged tasks use dedicated accounts, separate from everyday user accounts.
  • Re-authenticate for privileged actions. Users must re-authenticate before performing privileged operations.
  • Log all privileged activity. Every action taken with privileged rights is logged and reviewed.
  • Review regularly. Privileged access rights are reviewed at defined intervals and adjusted whenever roles change.
  • Avoid shared accounts. Generic or shared admin accounts are avoided; where technically unavoidable, individual accountability must still be ensured.

In practice

Inventory all privileged accounts. Before you can control privileged access, you need a complete list: domain admins, local admins, root accounts, database admins, cloud IAM roles with write access, service accounts. Many organizations discover 3-5x more privileged accounts than expected.

Implement just-in-time access. Rather than granting permanent admin rights, provision privileges on demand — the user requests access, a manager approves, and the rights are granted for a limited time window. PAM tools (CyberArk, BeyondTrust, HashiCorp Vault) automate this workflow.

Enforce session recording. For the most sensitive systems, record privileged sessions (screen recording or command logging). This creates a forensic trail and acts as a strong deterrent against misuse.

Conduct quarterly access reviews. Every quarter, each privileged account is reviewed: is it still needed? Is the scope appropriate? Is the owner still in the same role? Document the review outcome and any corrective actions taken.

Typical audit evidence

Auditors typically expect the following evidence for A.8.2:

  • Privileged access policy — documented rules for granting, reviewing and revoking privileged rights (see Access Control Policy in the Starter Kit)
  • Privileged account inventory — complete list with owner, scope and last review date
  • Access review records — documented quarterly reviews with outcomes
  • PAM tool logs — session recordings or checkout logs
  • Segregation evidence — proof that admin accounts are separate from standard user accounts

KPI

Percentage of privileged accounts reviewed and revalidated within defined cycle

Measured as a percentage: how many of your privileged accounts have been reviewed within the last quarter? Target: 100%. Any account that misses a review cycle should be automatically suspended until the review is completed.

Supplementary KPIs:

  • Number of permanently active privileged accounts (target: decreasing, moving towards just-in-time)
  • Mean time between privilege request and provisioning
  • Number of shared or generic admin accounts (target: zero)

BSI IT-Grundschutz

A.8.2 maps primarily to BSI modules for privileged operations:

  • OPS.1.1.2 (Orderly IT Administration) — the core module. Requires separate admin accounts, logging of all administrative actions, restriction to necessary privileges and regular review of admin rights.
  • ORP.4 (Identity and Access Management) — overarching requirements for the management of privileged identities, including the two-account principle and prohibition of shared admin accounts.
  • APP.2.1/APP.2.2 (Directory Services) — technical requirements for managing privileged accounts in Active Directory and LDAP.

Sources

Frequently asked questions

What qualifies as a privileged access right?

Any access right that allows a user to bypass normal security controls — local or domain admin accounts, root access, database admin roles, cloud IAM roles with write permissions to security-relevant settings, and service accounts with elevated permissions.

Can we use shared admin accounts?

ISO 27002 explicitly recommends against shared or generic admin accounts because they break individual accountability. Every privileged action must be traceable to a specific person. If a shared account is technically unavoidable, use a PAM tool that checks out credentials individually and logs every session.

How often should privileged access be reviewed?

Quarterly reviews are standard practice. For the most sensitive systems (domain controllers, firewalls, cloud root accounts), monthly reviews are common. Every review must be documented with date, reviewer and outcome.