ISO 27001 A.8.2: Restrict and manage privileged access

What A.8.2 requires in practice

A.8.2 deals with privileged access rights, meaning permissions that go beyond ordinary use, such as administering systems, changing security settings or managing other accounts. The control has two halves: how rights are allocated, and how they are used. Both must be restricted and managed.

In practice an organisation needs to be able to show who holds elevated rights in each relevant system and why, what each holder may do, and who approved it. It also needs a way of controlling how those rights are exercised, for example by separating administrative work from everyday work and keeping a trace of significant actions.

Outputs include a current picture of privileged holders, approved assignments, a routine for removing rights when roles change and records showing the arrangement operates. Service and automated accounts fall within the idea as well as people. One method Sterling's teams use is a periodic review of holders; the control does not fix a frequency or require a specific privileged-access product.

Identify the capability, not just the account name

Determine which permissions allow significant actions in each relevant system. A role need not be called “administrator” to change sensitive information or bypass an ordinary restriction. Consider operating systems, applications, cloud services, databases and automated components. An inventory limited to a central directory can miss locally assigned or application-specific privileges.

For each assignment, establish the business need, permitted actions, appropriate owner and required competence. The minimum suitable permission may be narrower than the platform's broad default role. An employee's seniority does not itself justify technical administration rights, and a service account should have a defined purpose rather than inherit unrestricted access for convenience.

Separate routine work from privileged activity

Where practical, use distinct arrangements for ordinary work and administrative tasks so users know when elevated authority is active. Avoid routine email and browsing through a privileged identity. Strong authentication, controlled access routes and appropriate logging can reduce the consequences of misuse or compromise, but they do not justify granting unnecessary rights.

Time-limited access can be suitable for a particular task or change. Define who approves it, how it becomes available and how it expires. The technical result matters: a request marked “temporary” is not temporary if the permission remains indefinitely. Review emergency arrangements separately so urgent recovery does not become an undocumented route around normal control.

Why privileged access matters to the business

A small number of accounts can do disproportionate damage. An administrator who is careless, compromised or leaving on poor terms can change security settings, read everything or delete evidence. Most serious breaches involve elevated rights at some stage, whether stolen or misused. Clients who hand over sensitive data want to know who inside your business can see it all, and regulators ask the same question after an incident. Tight control also protects accurate administrators, because clear records show what they did and did not do. The cost of managing this properly is modest compared with the cost of explaining unrestricted access after something has gone wrong, and auditors treat it as a core test of access management maturity.

How to implement A.8.2

The aim is to make elevated access deliberate, visible and short-lived.

1. Find privileged capability in every relevant platform, including local database rights, cloud roles, application administrators and service accounts.
2. Record for each holder the business need, the owner who approves it and the narrowest suitable permission rather than the broadest default role.
3. Separate administrative identities from everyday ones so elevated rights are not present during email and browsing.
4. Use time-limited elevation for specific tasks where practical, with a defined approval and an expiry that really takes effect.
5. Log significant privileged activity and decide who reviews it, so misuse is noticed by someone other than the holder.
6. Tie role changes and departures to removal of rights, and review the full list of holders on a regular cycle.
7. Plan emergency access in advance, including who may authorise it and how its use is reviewed afterwards, so urgent recovery does not become an unrecorded shortcut.

Illustrative software example: deployment permissions after a release

Illustrative manufacturing example: emergency supplier administration

A hypothetical manufacturer needs a supplier to investigate a production-support system outage. The supplier normally has no administrative access, but an old shared emergency credential is available in a team document. Using it would make attribution and later removal difficult.

The organisation follows an authorised emergency route that provides the necessary access under controlled conditions. It records the responsible person, purpose and relevant activity, then withdraws the temporary permission and reviews the use afterward. The exact technology depends on the system. The management result is attributable, bounded access, rather than indefinite reliance on a secret everyone on the support team knows.

Review use as well as assignment

A rights review should ask whether current responsibilities and competence still justify the permission. It should also consider whether the account is being used in the expected way. Unused powerful accounts, repeated emergency elevation or administration from unexpected contexts can merit investigation.

Shared or built-in identities need particular care where a system cannot avoid them. Define how credentials are protected, who can obtain access and how activity can be attributed as far as the platform allows. Record the limitation and appropriate additional treatment. Do not claim perfect accountability where the technical evidence cannot support it.

Evidence that demonstrates effective restriction

Common nonconformities with A.8.2

Privileged access findings tend to cluster around accounts nobody owns and rights nobody removes.

• Former employees or suppliers still holding administrator rights long after their work ended.
• Daily-use accounts that also carry administrative rights, so every email click happens with elevated authority.
• Shared administrator credentials with no way to attribute actions to a particular person.
• Service accounts with broad rights, no named owner and no recorded purpose.
• Temporary elevation approved for a task but never withdrawn, and no evidence that anyone reviews what privileged accounts actually did.