Privileged access rights

What the control asks

The granting and use of privileged access rights are to be limited and managed. Purpose: limit privileged access to the people, software components and services that are authorized for it. Guidance: allocate privileged rights through an authorization process under the access control policy (5.15), considering: identifying who needs privileged access for each system or process, whether an operating system, a database platform or an application; granting it as needed and per event, only to people competent to carry out the privileged activity and at the minimum their role requires; keeping an authorization process (who may approve, and no privilege before approval) and a record of all privileges granted; defining and applying expiry of privileged rights; making users aware of their privileges and of when they are operating in privileged mode, using dedicated identities, interface settings or even separate equipment; stronger authentication than for normal access, possibly re-authentication or step-up before privileged work; reviewing privileged users regularly and after organizational change to confirm their duties, role and competence still justify it (5.18); rules to avoid generic administrator accounts such as root where systems allow, and protecting their credentials (5.17); temporary elevation only for the window needed to carry out an approved change or activity instead of standing privilege, often called break glass and frequently automated by privileged access management tools; logging all privileged access for audit; never sharing privileged identities among several people, giving each person a separate identity, though identities may be grouped to simplify management; and using privileged identities only for administration, never for everyday tasks like email or browsing, for which a separate normal identity is used. Other information: privileged rights let an identity, role or process do what ordinary users or processes cannot, as system administrators typically need; abuse of administrator powers able to bypass system or application safeguards is a leading cause of failures and breaches; ISO/IEC 29146 gives further guidance.

Purpose in the standard’s terms, in our words: Limits privileged access to authorized people, software components and services.

Attribute values in one line: Preventive; Confidentiality, Integrity, Availability; Protect; Identity and access management; Protection.

The five attribute values

These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.

Evidence an auditor asks for

The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.

• An inventory of privileged accounts per system (operating systems, databases, applications, cloud consoles) mapped to named individuals
• Authorization records for each privileged grant with approver, justification and expiry
• Privileged access management configuration showing time-limited elevation, step-up authentication and session recording
• Privileged access review records performed periodically and after organizational changes
• Logs of privileged access retained for audit
• Evidence that administrators use separate accounts for administration and for email and browsing, and that generic accounts such as root are controlled

Where audits commonly find gaps

• Administrators use their privileged account for email and web browsing
• Shared generic administrator accounts are used with no individual accountability
• Privileged rights are standing and never expire
• Service accounts with administrative rights are excluded from reviews

What ISO/IEC 27028 changes for this control

It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. Its earlier numbering (09.2.3) is kept in the register so an older audit file can still be traced.

The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.

Controls that share its values

• 8.3 Information access restriction
• 8.4 Access to source code
• 8.5 Secure authentication

Read the five attributes All 93 controls