For Annex A control 8.2, "Privileged access rights", show that admin rights are few, named, approved and reviewed. In a dev team that means lists of organization owners, cloud administrators and CI admins, an inventory of long lived tokens, and a record of how emergency access is granted and removed.
Where privilege hides in engineering
Privileged access is wider than a root account. In a typical software team it includes organization owners on the source host, people who can change branch protection, admins of the CI system, cloud roles that can edit identity policy, registry publish rights and anyone who can read production secrets.
Control 8.2 sits in the technological theme, and the 2022 edition lists it next to 8.3 "Information access restriction" and 8.4 "Access to source code". Read the standard text for what it requires. This post sticks to artifacts that engineers can produce.
The evidence set
| Question an assessor may ask | Artifact |
|---|---|
| Who holds privileged rights? | Export of admins and owners per system |
| Why do they hold them? | Approval ticket with business reason |
| Are they still needed? | Dated review with keep or remove marks |
| What non human credentials exist? | Inventory of tokens, keys and service accounts with owner and expiry |
| What happens in an emergency? | Break glass procedure and a log of each use |
Keep the numbers low and the names real. If the list of organization owners has fourteen people and four of them are former contractors, you have found your own finding before anyone else.
Steps to tighten and document
- Define what privileged means for each system in one short page.
- Export holders of those roles today.
- Remove standing admin rights that nobody can justify. Prefer time boxed elevation where your tooling allows it.
- Move shared admin credentials to named accounts with multi factor authentication.
- Inventory personal access tokens and deploy keys with scopes, owners and expiry dates, and rotate the oldest.
- Write the emergency access path, test it once, and keep the test record.
- Schedule the next review and put it in the team calendar as a recurring ticket.
Step 5 is the one most teams skip, and tokens often outlive the people who created them.
Evidence that is easy to get wrong
A policy document alone is not evidence of operation. Neither is a list with no date. A review sign off with no export attached makes it hard to see what was reviewed. Aim for the trio of list, decision and result, each dated, stored together.
Also check that privileged activity is logged. Records of who changed what are the other half of this control in practice, and they connect to your logging control.
Where Safeguard fits
Safeguard includes agent identity and an MCP Guardrail, along with compliance and evidence automation, if you need access and tool call records for AI agents. You can try the free scan at gold.safeguard.sh/scan. An auditor decides what counts as sufficient evidence.
Quick check
Is a break glass account allowed under 8.2?
The control title does not forbid emergency access. What matters is that it is controlled: approved path, strong authentication, logging and a review after each use.
How many admins is too many?
The standard gives no number. Count the people who need the right to do their job, justify each one, and record the reasoning.
Sources
- ISO 27001 Annex A controls list, Security Compliance Guide
- ISO 27001 Annex A controls explained, Glocert International
Last reviewed: 19 October 2026.
