IAM-007 Privileged Access Management
Description
Privileged accounts (administrative, root, superuser and equivalent) are inventoried, tightly controlled and issued only to named individuals with a documented business justification. Privileged access is time-limited where technically feasible. All privileged actions are logged. Privileged roles are segregated from standard user roles. Utility programs and break-glass tooling able to override an application or system control are inventoried, restricted to named privileged roles and logged on each use. Privileged activity carries monitoring beyond action logging: sessions are recorded or equivalently captured, and privileged activity is reviewed for behaviour that the action log alone would not surface, at defined intervals. Where a customer agreement provides for it, provider access to that customer's tenant data by a high-risk privileged role is granted only on that customer's recorded approval. Administration operations run on accounts set up for that purpose only, separate from the holder's standard user account and carrying no entitlement outside administration.
Rationale
Privileged accounts are the highest-risk identities in any environment and their compromise can mean complete system takeover. Utility programs sit beside them because they reach the same outcome by a different route: a tool that bypasses application logic leaves an application audit trail that looks normal. Session capture and behavioural review answer a question the action log cannot, which is whether a legitimate privileged action was part of a pattern that was not. Customer approval of provider access to tenant data is a contracted capability in enterprise agreements and the approval record is the artefact that proves the boundary held. A second account for administration is what keeps a compromise of ordinary work off the privileged path, and it is the account half of a pair: the systems those accounts are used from, and the rule that an administration account reaches nothing else, are IAM-016. This control holds the account and its use; IAM-016 holds the machine.
Applicability (9 profiles)
164.312(a)(2)(ii) is a required specification and reverses IAM-007's emphasis: the duty is to have an established route for obtaining necessary data in an emergency, not only to restrict the break-glass tooling that provides one.
Annex point 11.3.2(b), accounts set up to be used for system administration operations exclusively, is now stated in the control: administration operations run on accounts used for that purpose only, separate from the holder's standard account and carrying no entitlement outside administration. Point 11.3.2(d) moved to IAM-016 with the administration systems it depends on.
Framework Mappings (20)
| IAM-09 | Segregation of Privileged Access Roles | full |
| IAM-10 | Management of Privileged Access Roles | full |
| IAM-11 | Service Customers' Approval for Agreed Privileged Access Roles | full |
| IAM-09 | Segregation of Privileged Access Roles | full |
| IAM-10 | Management of Privileged Access Roles | full |
| IAM-11 | Service Customers Approval for Agreed Privileged Access Roles | full |
| HIPAA-164.312.a.2.ii | Emergency Access Procedure | partial |
| 8.18 | Use of privileged utility programs | full |
| 8.2 | Privileged access rights | full |
| NIS2-CIR-11.3 | Privileged Accounts and System Administration Accounts | partial |
| NIS2-CIR-11.6 | Authentication | informative |
| AC-2(7) | Account Management | Privileged User Accounts | partial |
| AC-6 | Least Privilege | informative |
| AC-6(1) | Least Privilege | Authorize Access to Security Functions | partial |
| AC-6(10) | Least Privilege | Prohibit Non-privileged Users from Executing Privileged Functions | full |
| AC-6(2) | Least Privilege | Non-privileged Access for Nonsecurity Functions | full |
| AC-6(5) | Least Privilege | Privileged Accounts | full |
| AC-6(9) | Least Privilege | Log Use of Privileged Functions | full |
| AU-14 | Session Audit | partial |
| SI-4(20) | System Monitoring | Privileged Users | full |
Evidence (4)
Privileged account inventory and configuration settings showing all admin, root, and superuser accounts with named owners, MFA enforcement, and time-limited or just-in-time (JIT) access where supported.
Example: AWS IAM privileged-user/role export, Azure AD Privileged Identity Management (PIM) role assignment report, or PAM tool (CyberArk, HashiCorp Boundary) account listing showing each privileged account, its owner, MFA status, and session duration limits.
Test: Export all accounts with admin, root, or equivalent privileges. Verify: (1) every privileged account maps to a named, individually identified user, with no shared admin accounts, (2) MFA is enforced on all privileged accounts, (3) where JIT or time-limited access is available in the tooling, it is in use, (4) any permanent privileged access is backed by a documented business justification. (5) each named individual holding system administration privileges exercises them on an account set up for administration only, distinct from that person's standard user account, and that account carries no entitlement outside administration.
Privileged action audit logs showing that all administrative and elevated-privilege operations are recorded with actor identity, timestamp, and action detail.
Example: AWS CloudTrail management event logs, Azure AD audit log, or PAM session recording archive filtered for privileged-role actions over the last 30 days, showing no events with an unidentifiable or system-generated actor for human-initiated actions.
Test: Query the privileged-access audit log for the past 30 days. Verify: (1) every privileged action entry contains a named user identity rather than a shared or anonymous account, (2) log retention meets the policy-defined period, (3) a sample of 10 privileged actions can be cross-referenced to a valid change or approval record, (4) no privileged access events originate outside approved access paths, (5) privileged sessions in the sample have a recording or equivalent capture retained alongside the action log, (6) a behavioural review of privileged activity was completed within the defined interval and its findings resolve to an action or a recorded decision.
Inventory of utility programs and break-glass tooling able to override an application or system control, with the privileged roles permitted to run each and the record of its last use.
Example: privileged-utility-inventory-2026-08.csv
Test: Export the utility and break-glass inventory. Verify: (1) every tool able to bypass application access control, input validation or application logging appears, (2) each entry names the roles permitted to run it, (3) each invocation in the last 90 days resolves to a named individual and to an approval or an incident record, (4) no principal outside the named roles holds execute permission on any listed tool, (5) direct database and direct object-store access paths are treated as listed tools rather than left out.
Customer approval records for provider access to customer tenant data by a high-risk privileged role, for the agreements that provide for it.
Example: Tenant access approval log Q2 2026, customer-approval-gated tenants
Test: Identify the customer agreements that carry an access approval provision. Verify: (1) each access by a high-risk privileged role into one of those tenants has an approval recorded before the access began, (2) the approval names the requester, the scope of data reachable and an expiry, (3) access attempted after expiry was refused, evidenced in the access log, (4) an access recorded without a matching approval is treated as an incident and has an incident record.
Questions (2)
Is an inventory of all privileged accounts maintained?
Every privileged account must map to a named individual with a documented business justification. Shared admin accounts are not acceptable.
Which controls are applied specifically to privileged accounts in your environment?
Options run from the most commonly held to the least. MFA and full action logging are the minimum. A separate account for administration is a different thing from segregating the roles: one person can hold both roles on one account and satisfy segregation on paper. Session recording with a behavioural review answers what the action log cannot, which is whether a legitimate action was part of a pattern that was not. Utility and break-glass tooling is the gap most often missed: a tool that bypasses application logic leaves an application audit trail that looks normal. Product names belong in an implementation note, not here.