What Is ISO 27001 Annex A Control 8.2?
If there is one area where information security breaches consistently originate, it is uncontrolled privileged access. Whether it is a former employee whose admin account was never disabled, a developer with unrestricted database access, or a third-party vendor given more permissions than they needed for a one-off job, the pattern is almost always the same. Too much access, for too long, with too little oversight.
On this page
ISO 27001 Annex A Control 8.2 addresses this directly. It requires organisations to restrict and manage the allocation and use of privileged access rights. In the 2022 version of the standard (ISO/IEC 27001:2022), this control sits within the Technology controls category and is one of the more operationally demanding controls to implement well.
This article breaks down exactly what Control 8.2 requires, why it matters, and how to implement it in a way that will satisfy an auditor and, more importantly, actually protect your organisation.
Understanding Privileged Access Rights
Before getting into the control itself, it helps to be clear on what “privileged access rights” actually means. Not all user accounts are equal. Standard user accounts let someone log in, read files, and do their day-to-day work. Privileged accounts go further. They can change system configurations, install software, access sensitive databases, create or delete other accounts, override security settings, or view data across the entire organisation.
Common Examples of Privileged Access
- System administrator accounts on servers or workstations
- Database administrator (DBA) accounts with full read and write access to production databases
- Root or superuser accounts on Linux or Unix systems
- Domain administrator accounts in a Windows Active Directory environment
- Cloud platform administrator roles (such as AWS root accounts or Azure Global Administrator)
- Network device management accounts on routers, firewalls, and switches
- Application-level admin accounts in business software such as ERP or CRM systems
- Service accounts used by automated processes or applications
The risk with these accounts is straightforward. If someone gains access to a privileged account, whether through a phishing attack, credential theft, or insider misuse, the damage they can do is exponentially greater than with a standard account. They can exfiltrate data, encrypt systems for ransom, cover their tracks, or simply cause widespread disruption.
This is why ISO 27001 dedicates a specific control to managing them.
What Control 8.2 Actually Requires
The control itself is concise in the standard, but the implementation guidance covers several distinct obligations. Here is what organisations are expected to do.
Identify All Privileged Access Rights
You cannot manage what you cannot see. The first step is maintaining a complete inventory of all privileged accounts and the access rights associated with them. This includes human user accounts, shared accounts, service accounts, and any accounts used by automated scripts or applications.
Many organisations are surprised by how many privileged accounts they actually have when they conduct this exercise for the first time. Shadow IT, legacy systems, and accounts created for temporary projects that were never removed all contribute to a sprawling and often invisible attack surface.
Allocate Privileged Access on a Need-to-Use Basis
Control 8.2 requires that privileged access rights are allocated only when there is a clear business need. This ties directly to the broader principle of least privilege, which means users and systems should have the minimum access required to perform their function, and nothing more.
In practice, this means a software developer should not have standing administrator access to the production database just because they occasionally need to run a query. Instead, access should be granted for the specific task, then removed or time-limited.
Separate Privileged Accounts From Regular User Accounts
The standard expects that privileged activities are performed using separate accounts, distinct from the user's standard day-to-day account. A system administrator should have a normal account for email and general work, and a separate admin account used only for administrative tasks. This limits the exposure if the standard account is compromised, since the credentials for the privileged account are different.
Authenticate Privileged Access Appropriately
Higher-risk access should require stronger authentication. This typically means multi-factor authentication (MFA) for all privileged accounts. Using just a username and password to access an admin account is considered inadequate under a mature ISO 27001 implementation.
Review Privileged Access Rights Regularly
Access rights must be reviewed at defined intervals and whenever a user's role changes. If someone moves from a technical role to a management role, their admin access should be revoked. If someone leaves the organisation, their privileged accounts should be disabled immediately, ideally before they walk out the door.
Log and Monitor Privileged Account Activity
All actions taken using privileged accounts should be logged, and those logs should be protected from tampering. This is critical both for detecting misuse and for forensic investigation if an incident occurs. The logs themselves need to be treated as sensitive information, since an attacker who can delete logs can cover their tracks entirely.
Real-World Implementation Examples
Abstract requirements are easier to understand when you see how they apply in practice. Here are some scenarios that illustrate how Control 8.2 works across different types of organisations.
Example 1: A Managed Service Provider (MSP)
An MSP managing IT infrastructure for multiple clients will have technicians who need admin access to client systems. Under Control 8.2, this organisation would be expected to use a Privileged Access Management (PAM) tool that issues time-limited credentials for each session, logs every action taken, and requires MFA before access is granted. No technician should have standing admin credentials stored on their laptop. When a technician leaves the business, their access to the PAM system is revoked and all client access is cut off simultaneously.
Example 2: A SaaS Software Company
A software company running cloud infrastructure on AWS might have several developers who previously had broad IAM (Identity and Access Management) permissions. Under Control 8.2, the organisation would review and tighten those permissions so that developers have access only to the environments and services relevant to their role. Production database access would require a separate approval process, be logged, and be time-limited. The AWS root account would be locked away, with MFA enabled, and used only in genuine emergencies.
If you are working through ISO 27001 certification for a software company, understanding how controls like 8.2 apply to your cloud environment is one of the more technically demanding parts of the process. You can read more about this in our guide on how to get ISO certification for a software company.
Example 3: A Healthcare Organisation
A private hospital running an electronic medical records (EMR) system would identify all accounts with access to patient data at the database or system level. Clinicians would have standard user accounts for day-to-day access. Only a small number of IT staff would hold privileged accounts, and those accounts would be subject to strict controls. Any access to bulk patient data outside normal clinical workflows would trigger an alert for review. This kind of monitoring is especially important given Australia's Notifiable Data Breaches (NDB) scheme, which requires organisations to report eligible data breaches to the Office of the Australian Information Commissioner.
Example 4: A Financial Services Firm
A mid-sized accounting firm would apply Control 8.2 to its financial systems by ensuring that no single person has both the ability to create a payment and the admin rights to modify the audit trail. Separation of duties, combined with privileged access controls, reduces the risk of both external attack and internal fraud. All admin actions on the financial system would be logged and reviewed monthly by a manager who does not hold those same privileges.
Common Gaps Auditors Find With Control 8.2
Having conducted and reviewed many ISO 27001 audits, the same weaknesses come up repeatedly when it comes to privileged access. Knowing these in advance gives you a chance to address them before an auditor arrives.
No Formal Inventory of Privileged Accounts
Organisations often have no documented list of which accounts are privileged, what systems they apply to, and who holds them. An auditor will ask for this list. If you cannot produce it, that is a nonconformity.
Shared Admin Accounts
Multiple people sharing a single admin account is extremely common, particularly in small IT teams. The problem is that when something goes wrong, you cannot determine who did what. The standard expects individual accountability, which means shared accounts should either be eliminated or tightly controlled with session recording.
Stale Accounts That Were Never Removed
Former employees, contractors, and vendors whose accounts were never disabled represent a significant and ongoing risk. Periodic access reviews, at least annually and ideally more frequently, are expected under Control 8.2. Many organisations do not have a formal process for this.
No MFA on Admin Accounts
This is increasingly considered a baseline expectation, not an optional extra. If your privileged accounts are protected only by passwords, expect this to be raised as a finding. This is particularly true for cloud-based systems where accounts are accessible from anywhere on the internet.
Logs That Are Not Reviewed
Logging privileged account activity is only useful if someone actually looks at the logs. Organisations that can demonstrate logging is in place but cannot show evidence of regular log review will still receive a finding. The control requires both logging and monitoring.
How to Document Control 8.2 for Your ISMS
Documentation for this control typically includes several components. You do not need an enormous amount of paperwork, but you do need evidence that the control is operating effectively.
- Privileged Access Rights Policy: A policy that defines what constitutes a privileged account, who can hold one, under what conditions access is granted, and how it is reviewed and revoked.
- Privileged Account Register: A maintained list of all privileged accounts across all systems, including who holds them and the date of last review.
- Access Request and Approval Records: Evidence that privileged access was requested, justified, and approved by an appropriate authority before being granted.
- Access Review Records: Documentation of periodic reviews confirming that all privileged access remains appropriate and that stale accounts have been removed.
- Audit Logs: Logs from systems showing privileged account activity, along with evidence that these logs are reviewed at defined intervals.
For organisations building their Information Security Management System from scratch, understanding how to structure this documentation is part of the broader challenge of implementing ISO 27001. Our beginner's guide to what is an Information Security Management System covers the foundational concepts that underpin controls like 8.2.
Tools and Technologies That Support Control 8.2
While ISO 27001 is not prescriptive about which tools you use, certain technologies are widely used to meet the requirements of Control 8.2 in a scalable and auditable way.
Privileged Access Management (PAM) Solutions
PAM tools such as CyberArk, BeyondTrust, and Delinea are purpose-built for managing privileged accounts. They provide credential vaulting (so users never see the actual password), session recording, time-limited access, and detailed audit trails. For larger organisations or those in high-risk industries, a dedicated PAM solution is often the most effective way to meet the requirements of this control.
Identity and Access Management (IAM) Platforms
For cloud environments, native IAM tools such as AWS IAM, Azure Active Directory (now Entra ID), or Google Cloud IAM allow fine-grained control over who can do what. Role-based access control (RBAC) and just-in-time (JIT) access features directly support the least privilege requirements of Control 8.2.
SIEM and Log Management Tools
Security Information and Event Management (SIEM) platforms aggregate logs from across your environment and can be configured to alert on suspicious privileged account activity, such as logins outside business hours, access to unusual systems, or bulk data downloads. This supports the monitoring requirement of the control.
The ISO/IEC 27001:2022 standard published by ISO provides the authoritative source for all Annex A control requirements, including Control 8.2, and is worth referencing directly when building your implementation approach.
Control 8.2 in the Context of the Broader ISMS
Control 8.2 does not operate in isolation. It connects directly to several other controls and clauses within ISO 27001. Understanding these relationships helps you implement it more effectively and avoid gaps.
Control 5.18 (Access rights) covers the broader access rights management process, of which privileged access is a specific and higher-risk subset. Control 8.3 (Information access restriction) deals with limiting access to information and application functions. Control 8.15 (Logging) and Control 8.16 (Monitoring activities) support the logging and monitoring requirements that underpin effective privileged access management.
If you are working through the risk assessment process that drives your control selection, our guide on ISO 27001 risk assessment for non-technical business owners provides a practical starting point for understanding how risk informs your approach to controls like 8.2.
Getting Help With ISO 27001 Implementation
Control 8.2 is one of those controls where the gap between having a policy on paper and actually operating effective controls is often significant. The technical complexity of managing privileged access across modern IT environments, cloud platforms, legacy systems, and third-party services means that many organisations benefit from working with an experienced consultant who has done this before.
If you are working towards ISO 27001 certification and want to compare quotes from verified consultants who specialise in information security, CertBetter makes that process straightforward. Submit one form and receive up to three competing quotes from vetted providers, at no cost to your business.
