ISO 27001 A.8.2 Privileged access rights: Who Gets Admin, For How Long, and What Proves It
ISO 27001 A.8.2 Privileged access rights: decide which accounts count as privileged, how to grant and review them, and what evidence proves it.
/Autenix/9 min read
An engineer moves from infrastructure to product work, but the owner-level role on the production cloud account stays with them. Months later, a script run under that account deletes a storage bucket, and the log shows an identity nobody remembered was privileged. Privilege that nobody can explain is privilege nobody can safely remove.
What A.8.2 Privileged access rights asks for
A.8.2 Privileged access rights is an Annex A control. You select it through risk treatment and record the decision in the Statement of Applicability (SoA). Its intent is to limit and manage who holds elevated rights and how they are used. ISO/IEC 27002 guidance covers identifying who needs privileged access per system, granting it on a need-to-use basis, keeping an authorization record, setting expiry, avoiding generic administrator identities, and using privileged identities only for administrative tasks. Your risk assessment decides which of these apply.
Boundaries with sibling controls:
Ordinary access provisioning and review belong to A.5.18 (Access rights).
Authentication strength belongs to A.8.5 (Secure authentication).
Collecting logs belongs to A.8.15 (Logging), and reviewing them for anomalies to A.8.16 (Monitoring activities).
A.8.2 Privileged access rights covers who holds elevated rights, why, and for how long.
Depends on: A.5.16 (Identity management). Privileged actions can only be attributed to a person if each person has a unique identity.
Decide your A.8.2 Privileged access rights scope
The hardest decision is where "privileged" starts. Scope follows what an account can change, not its job title.
| Profile | What is in scope | How the Privileged Access Register changes | When to review scope |
|---|---|---|---|
| Small cloud-first team | Top-level cloud account, identity provider admin, source control and CI/CD admin, production data stores | One shared register, two tiers, grants mostly time-limited | A new production system or a first outside contractor |
| Mid-size, hybrid on-premises and cloud | The above plus directory admin, network and security tooling, backup admin, database admin | Three tiers, a separate admin account per person for Tier 1, owners per system | A merger, a new data centre or a new cloud provider |
| Outsourced IT or managed service provider | Provider staff and tooling with admin rights on your systems | Provider accounts listed as named identities, with your approver on each grant | A change of provider, scope or contract |
What to exclude, minimize, or deprioritize
- Reduce: admin roles on low-risk systems with limited scope, such as a team-level setting in a collaboration tool, can use lighter approval and a longer review cycle. Record the risk behind that choice.
- Minimize: standing access on rarely used systems. Time-limited grants cost less to review than permanent ones.
- Do not reduce: the top-level cloud account, identity provider admin, backup and security tooling admin, service accounts or API keys with admin rights, and emergency (break-glass) accounts. These have the widest impact and often sit outside HR-driven reviews.
What good looks like
A. Copy this: Privileged Access Register
Adapt the values to your own risk assessment. They are illustrative, not requirements.
| Account or role | System | Tier | Holder and approver | Justification | Grant type | Expiry or review date | Sign-in requirement | Logs go to |
|---|---|---|---|---|---|---|---|---|
| Cloud owner role | Production cloud account | 1 | A. Holder / Head of Engineering | Platform operations | Time-limited, requested per task | End of task or 8 hours (example) | Separate admin account with stronger sign-in | Central log store |
| Identity provider super admin | Identity provider | 1 | B. Holder / Security lead | Directory administration | Standing, two holders only (example) | Quarterly review | Separate admin account with stronger sign-in | Central log store |
| Database admin | Customer database | 2 | C. Holder / Data owner | Schema changes | Time-limited | Per change ticket | Individual named account | Database audit log |
| Space admin | Team wiki | 3 | D. Holder / Team lead | Content administration | Standing | Annual review | Standard sign-in | Application log |
Illustrative tier rules: Tier 1 is reviewed quarterly, Tier 2 every six months, Tier 3 annually. Tier 1 and 2 grants are time-limited where the system supports it. Authorized exceptions are logged in the Privileged Access Exceptions Log with an owner and an end date.
A document alone does not prove implementation. The records below do.
B. Bad vs. good
| Bad | Good |
|---|---|
| "IT staff have admin rights to everything so they can respond quickly." | Admin rights are granted per system and tier, with an approver, a justification and a review date. Emergency access uses a break-glass account whose every use is recorded in the Break-glass use record. |
| Fast, but nobody can say who holds what or why. | Fast enough for emergencies, and every grant can be explained. |
C. Measures and evidence
| Measure | Why it matters | What sufficient looks like | Evidence |
|---|---|---|---|
| Privileged account coverage | An unlisted privileged account is invisible to every other control | Every privileged account in a Tier 1 or 2 system appears in the register, or is on the exceptions log | Privileged account export; Privileged Access Register; Privileged Access Exceptions Log |
| Grant justification and approval | Shows rights are given on need, not habit | Each grant has a named approver and a reason before it takes effect | Access approval records; Privileged Access Register |
| Separation of admin and daily use | Limits what a stolen everyday login can do | Tier 1 holders use a separate admin account, with documented exceptions | Privileged account export; Privileged Access Register |
| Review of privileged rights | Catches rights that outlived the need | Reviews happen at the tier's interval, and removals follow the review | Privileged access review record |
| Attribution of privileged actions | An action no one can trace cannot be explained | A sampled privileged action traces back to a named person or approved shared-account process | Privileged activity log sample |
| Emergency access | Break-glass is where controls are most often bypassed | Each use is approved after the fact, credentials are rotated or checked, and the use is reviewed | Break-glass use record |
The example values are starting points, not requirements specified by ISO.
D. How to validate it yourself
- Register against reality. Compare the Privileged account export from the identity provider and each Tier 1 system with the Privileged Access Register. Success: every difference is either resolved or on the Privileged Access Exceptions Log. Record: the Privileged account export with the differences marked.
- Movers and leavers. Take a sample of people who changed roles or left in the last period and check whether their privileged rights ended on time. Success: rights ended with the role change, or an approval explains why they remain. Record: the Privileged access review record.
- Attribution test. Perform a harmless privileged action with a test account and trace it through the logs. Success: the action is attributable to one person. Record: the Privileged activity log sample. This shows traceability on one path, not that your monitoring would notice misuse. That belongs to A.8.16 (Monitoring activities).
- Break-glass check. Review the last use of an emergency account. Success: use was approved, credentials were handled as your process says, and the use was reviewed. Record: the Break-glass use record.
Independent review adds value when you want a second view of how your tier decisions hold up against your risk assessment. It is not required unless a genuine requirement applies to you.
Common implementation mistakes with A.8.2 Privileged access rights
- A shared "admin" login is used by the whole team. Symptom: the log shows one identity and nobody can say who acted. Fix: give each person a named account and list any remaining shared account in the Privileged Access Exceptions Log with a compensating process.
- A whole engineering group holds the admin role "for convenience". Symptom: the Privileged account export is far longer than the Privileged Access Register. Fix: grant by role per system, and move routine tasks to lower roles.
- Service accounts and API keys with admin rights are missing from the register. Symptom: reviews list people but not machine identities. Fix: add them with an owning person, a purpose and a review date.
- Reviews approve the list without checking use. Symptom: the reviewer ticks every row because removal feels risky. Fix: have the system owner confirm the need per row, and record each removal in the Privileged access review record.
See how Autenix Compliance as a Service maps your systems, frameworks and gaps.
If you have one afternoon
- List the Tier 1 accounts (cloud top-level, identity provider admin, backup and security tooling, production data) and draft the Privileged Access Register for them.
- Export the privileged account lists from your identity provider and cloud account, compare them with the register, and log the differences in the Privileged Access Exceptions Log.
- Check the last two role changes or departures for leftover privileged rights and save the result as a Privileged access review record.
An afternoon will not complete the control, but it gives you a baseline to improve on.
How Autenix helps with A.8.2 Privileged access rights
Platform
Autenix Compliance is a continuous compliance platform for 35+ frameworks, including ISO 27001. Four of its listed features connect to the work above:
- Policy Generator has customizable policy templates with version control and change tracking. That fits keeping the access rules behind your tiers as versioned documents.
- Risk Management has automated risk scoring and prioritization and control effectiveness monitoring. That supports the risk assessment that decides which systems are Tier 1.
- Audit Readiness offers automated evidence collection, an audit trail with version history, and evidence export in an auditor-ready format. That supports the evidence named above. Which items can be collected automatically depends on the integrations you connect, so check that your identity provider and cloud accounts are covered.
- Continuous monitoring sends real-time alerts when a control drifts. That helps you notice gaps like a shared admin login, a group admin role, missing service accounts, and reviews that never check use, between reviews.
The platform supports your documentation and evidence. It does not satisfy the control on its own.
Services
Autenix's Compliance as a Service delivers the platform as a managed service. Its Discover step maps your current systems, frameworks and gaps, which is the same ground as the register comparison in the first validation check. Setup, integrations and training are included. You still own which accounts count as privileged, the approvals, the review decisions and the account settings themselves. The service is optional help with setting up and running the platform, and the two are designed to be used together.
Request an ISO 27001 demo to see how versioned policies, risk scoring and audit-ready evidence export fit around your afternoon checklist and validation steps. Request an ISO 27001 demo.