ISO 27001:2022 Annex A 8.2 privileged access rights: practical rules

The security questionnaire asks who holds admin rights and who approved them. The honest answer is 'most of engineering', and the deal waits while you find a better one.

This guide gives the practical rules for ISO 27001:2022 Annex A 8.2 privileged access rights: how to assign, restrict, elevate and revoke admin access, and what an auditor will test. It is written for CTOs, heads of engineering and IT leads at 25–250-person firms who need to pass certification without buying enterprise tooling or slowing developers. Everything runs on the identity provider and cloud platforms you already pay for.

What does ISO 27001:2022 A.8.2 require?

ISO 27001:2022 A.8.2 privileged access rights asks firms to give admin access only against a proven need: approved, scoped to the minimum a role needs, time-limited, traceable to one named person, and removed when the reason lapses. ISO/IEC 27002:2022 control 8.2 privileged access rights spells out re-authentication, break-glass routes and logging that the 2013 version only implied.

Privileged access is any right beyond what a normal user holds: changing system settings, managing other people's accounts or switching security controls off. Admin rights override every other control, so A.8.2 treats them as the exception, never the default. Five principles carry it:

• Need-based. Every grant answers a stated business reason.
• Scoped. The role receives the minimum it needs, not tenant-wide power.
• Time-boxed. Rights expire or come up for review instead of lingering.
• Individually accountable. Each privileged action traces to one named person.
• Kept off everyday work. The identity someone administers with is not the one they read email with.

The control is the sharpest application of the access control policy under Annex A 5.15. Auditors test it alongside the provisioning lifecycle in Annex A 5.18 and the credential rules in Annex A 5.17. Much of the evidence serves all three. Think of ISO 27001 A.8.2 as the privileged tier of identity and access management.

The 2013 edition carried this control as A.9.2.3. If your access policy still follows that version, add the three items now spelled out. They are a step-up challenge before admin work, a defined break-glass route, and logs that admins cannot edit.

At 25–250 people, the usual failure is 'everyone in engineering is an admin because it was easier'. That leaves the company one phished credential from a company-ending incident.

Auditors, enterprise questionnaires and cyber insurers ask the same three questions in almost identical words: who has admin, who approved it, and is it behind MFA. Weak answers cost more than audit findings, because they price your premium and stall your deals.

How do you manage ISO 27001 privileged access day to day?

Manage ISO 27001 privileged access with five rules: census every place elevated rights exist, require a recorded approval from someone other than the requester, scope rights by role, prefer temporary elevation to standing admin, and review holders on a fixed cycle with HR leaver events wired into revocation. A ticket per grant is enough.

Take the rules in order, as a path from discovery to revocation:

1. Census first. List every place elevated rights exist: the identity provider, cloud consoles, databases, SaaS admin panels, CI/CD and local admin on laptops. Record each holder and the business reason. The ICO access control toolkit expects the same discipline: a maintained list of staff with privileged access and a senior person responsible for granting it.
2. Gate every grant. The requester states the need, someone else approves, and the grant records an expiry or review date. Nobody self-serves into admin.
3. Scope by role. Least privilege means the person who restarts a service doesn't need tenant-wide admin. Use the granular roles your platforms already offer.
4. Expire rather than stand. Grant admin for the change window and let it lapse automatically. NCSC guidance on privileged access management describes the pattern: the credential requests access, and an approved request returns a temporary credential.
5. Review and revoke. Review holders on a fixed cycle and after any reorganisation. Feed HR leaver and mover events straight into revocation.

An approval the requester can give themselves isn't an approval.

Because each grant is a ticket, the trail writes itself. Requester, approver, date and expiry sit in one record, and the developer makes one short request instead of joining a queue.

A standing admin right is a decision nobody remembers making.

These rules reverse the pitfalls that sink reviews: self-approval, global admin handed out for a one-off task and never taken back, and reviews that never happen. Without a review cycle, the admin list becomes an archaeology of past job titles, and privilege creep grows with every reshuffle.

Why do administrators need a separate admin identity?

Administrators need a dedicated second identity because one account used for email, browsing and production changes puts every phishing click inside the admin blast radius. NCSC guidance says administrators should use a normal account for normal activities and a separate account for administration only. Add MFA and a fresh step-up challenge.

Follow the NCSC guidance on preventing lateral movement and set up the admin identity like this:

• One named admin identity per administrator, separate from their standard account.
• MFA on every privileged identity, using phishing-resistant methods such as hardware security keys where the platform supports them.
• A fresh challenge at step-up, so a hijacked session can't quietly become a hijacked tenant.
• No email or browsing from the admin identity.

The same NCSC guidance goes a step further: admin accounts should only be used from separate admin devices. At 25–250 people, apply that first to the systems that matter most, such as the identity provider and production cloud accounts.

Generic root or admin logins are the other half of the problem. When ten people share one, every audit trail says 'admin did it', and the individual accountability the control demands disappears. Give each person a named admin identity and retire the shared login. The sealed emergency credential in the break-glass section is the only exception.

Privileged passwords deserve stricter handling than ordinary ones. Make them long and unique, hold them in a password manager or vault, and change them after any suspected exposure or staff departure.

Do you need a PAM tool to meet Annex A 8.2?

No. At 25–250 people, the approval, expiry and elevation features built into modern identity providers and cloud platforms cover Annex A 8.2. A dedicated PAM product earns its keep at a scale most growing firms haven't reached. Spend the effort on the census, the approval trail and expiry instead.

Most identity providers and cloud platforms already offer the three tools the control needs. They are an access-request workflow with a distinct approver, time-limited role assignment that expires on its own, and granular roles. Switch those on, document the procedure, and the control is operating.

A practical test tells you when to revisit the question. If your estate outgrows what the native features can show an auditor in one export, a dedicated product starts to make sense. Enterprise credential-vault architectures sit outside this guide, and a licence does not produce the census, the tickets or the expiry settings on its own.

How do you handle local admin rights on developer laptops?

Treat local admin rights on laptops as privileged access in the census. Record who holds them and why, remove them by default, and grant elevation per task with approval and expiry. Unmanaged endpoint admin hands malware the rights your server estate was protected from, and auditors check this corner often.

Device management makes this routine. The enrolment policy removes local admin group membership, and an elevation tool grants a time-limited right once someone other than the developer approves the request. A software catalogue covers the routine installs, so elevation requests stay rare and developers keep their pace.

Expect the auditor to ask for the list of people with local admin and how you enforce it. One census row for endpoints, with an owner and a review date for every exception, answers both questions.

How should break-glass emergency accounts work?

A break-glass account is the one sealed emergency credential kept for when the identity provider is down. Vault it, seal it, alert on every use, and review each use afterwards. Without a defined emergency route, someone improvises with a credential nobody tracks, and the audit trail ends there.

The procedure has five parts:

1. Vault it. Store the credential in a secrets manager or safe, with named custodians.
2. Seal it. Make retrieval deliberate and visible, so nobody uses it casually.
3. Alarm it. Alert a second person and the security channel on any sign-in by the account.
4. Review each use. A reviewer other than the user checks the log against the incident, then the credential is changed.
5. Test the route. Exercise it on a schedule, so it works on the day the provider really is down.

This is the one tolerated exception to individual accountability, so it must be rare enough that every use is an event. Hold at least one emergency account outside the identity provider's own dependency chain, because the scenario you are planning for is that provider being unavailable.

How do you automate Annex A 8.2 evidence and enforcement?

Automate Annex A 8.2 with four API-driven jobs: continuous checks of admin role membership against the approved register, just-in-time elevation through IdP requests or chat-ops approvals, HR-driven same-day revocation, and generated review packs. The machine gathers the evidence; the reviewer only judges.

Privileged access is one of the highest-yield controls to engineer, because the identity provider, cloud platforms and code hosts all expose their data through APIs. The jobs turn the control into a running pipeline that produces its own evidence. This is the evidence automation GRCMANA's GRC engineering work builds first, because access data is the easiest to wire up.

The quarterly review stops being a spreadsheet exercise. It becomes an automatic export of holders, grants and last-use data, and the reviewer's job is judgement: does this person still need this role? At this scale, that cadence satisfies both auditors and enterprise customers.

What audit evidence does ISO 27001 Annex A 8.2 need?

ISO 27001 Annex A 8.2 evidence is seven artefacts: the privileged account register with justifications, grant tickets with a distinct approver, review sign-offs, MFA and expiry configuration screenshots, the break-glass procedure and use log, leaver reconciliation records, and privileged session logs held where administrators cannot edit them.

Each artefact has a natural export point:

1. Register: exported from the identity provider and cloud consoles, reconciled against approvals.
2. Grant tickets: pulled from the ticketing system, showing requester, approver and date.
3. Review sign-offs: the review pack, plus the removals it triggered.
4. MFA and expiry settings: screenshots of the privileged roles in the IdP and cloud admin settings.
5. Break-glass records: the procedure and the alert history with the reviewer named.
6. Leaver reconciliation: HR departure dates matched to revocation timestamps.
7. Session logs: cloud audit and admin logs shipped to a protected store.

The artefacts for ISO 27001:2022 A.8.2 privileged access rights are by-products of the earlier sections. The census gives you the register, the gate gives you the tickets, and the review cycle gives you the sign-offs.

Logging is the weak link to check first. Elevated sessions that produce no logs, or logs the admin can delete, leave the other six artefacts unable to prove who did what. Ship logs to an account or store that admins cannot write to.

How do auditors test ISO 27001:2022 Annex A 8.2 privileged access rights?

Auditors pull the live admin list from your identity provider and cloud consoles, trace two or three names back to an approval and forward to a review, cross-check recent leavers against revocation records, and ask for expiry evidence on a real just-in-time grant. Admin-by-default or shared root credentials grade major; isolated lapses grade minor.

Expect questions in these shapes:

• Show me everyone with admin rights in your identity provider and cloud accounts. Who approved each?
• Do engineers use the same account for email as for production changes?
• Are there shared admin credentials, and how do you know who used them last Tuesday?
• What happens to elevated rights when someone changes role or leaves? Show me your last leaver.
• Walk me through your emergency access route and the last time it was used.

In certification-body practice, isolated lapses are things like a missed review, one leaver revoked late or a missing expiry on a single grant. Repeated across the estate, those same lapses add up to a major.

Run the sample on yourself first. Pull the admin list, trace three names to tickets and reviews, and check the last leaver's revocation timestamp. Walk in with those answers ready, and the audit becomes a tour of work you have already done.

Frequently asked questions