ISO 27001:2022 Annex A.8.2 requires that the allocation and use of privileged access rights be restricted, controlled, and reviewed. The control is one of the most audit-intensive in the standard because privileged access failures are disproportionately represented in the security incidents that drive ISO 27001 certification in the first place. Organisations pursuing certification almost always have a privileged access policy. Fewer have implemented the technical controls that satisfy A.8.2’s allocation, use, and review requirements simultaneously.
The allocation requirement means privileged access must be granted through a formal process on a need-to-use basis. The use requirement means the use of privileged access rights must be logged at sufficient detail to reconstruct what occurred. The review requirement means privileged access entitlements must be periodically examined and those no longer required must be revoked.
Standing privilege, where administrators hold persistent, unrestricted access to target systems between sessions, fails all three requirements simultaneously. It cannot be said to be allocated on a need-to-use basis when it persists indefinitely. It cannot produce use evidence beyond authentication records without session-level recording. It cannot be reviewed in a meaningful way when entitlements have no defined scope or expiry.
This blog covers what each component of A.8.2 requires technically, why standing privilege is architecturally incompatible with A.8.2 compliance, and how JIT access with per-session ephemeral credentials and session activity logging constitutes the correct implementation.
A.8.2 requires that privileged access rights be allocated to users on a need-to-use and event-by-event basis in line with the access control policy. The event-by-event standard is specific: each privileged access event should be individually authorised, not covered by a standing entitlement that grants access indefinitely.
Need-to-use means that privileged access is granted only when there is a current, specific operational requirement. An administrator who needs to investigate an issue on a production server has a current need. That same administrator has no need for access to the server when they are not actively working on it. A standing entitlement that grants them permanent SSH access to the server satisfies neither the need-to-use nor the event-by-event standard.
Event-by-event means that each access event requires its own authorisation. A system administrator who needs to access three servers on three separate occasions needs three separate authorisations, not a single standing entitlement covering all future access to all servers.
Technically, this standard requires JIT access: privileged access is granted for the duration of a specific, approved session and automatically revoked at session close or on JIT window expiry. There is no standing access between sessions. Each session requires a new authorisation through the approval workflow.
A.8.2 requires that privileged access allocation follow a formal process. The process must produce a documented record of the authorisation: who requested access, to which system, for what purpose, for what duration, who approved, and when. This record is the allocation evidence that A.8.2 requires.
Akku’s session approval workflow produces this record automatically for every privileged session. The request captures target system, access level, duration, and justification. The approval captures approver identity and timestamp. No session opens without a corresponding approval record when the workflow is enabled.
AkkuArka implements the event-by-event allocation standard at the credential layer. For every approved privileged session, AkkuArka generates a unique, cryptographically random credential scoped to the target system. The credential exists only for the duration of the session: it is generated at approval, injected at the protocol layer by AkkuReka, and permanently revoked on session close. The user never sees or types the credential.
This model makes standing privilege architecturally impossible. No privileged user holds credentials to target systems between sessions. Every connection to a critical system requires a new approved session with a new ephemeral credential. The allocation is truly event-by-event.
A.8.2 requires that the use of privileged access rights be logged. The logging requirement is where most organisations have their largest A.8.2 gap: authentication logs confirm that privileged sessions occurred but record nothing about what occurred during them.
Use logging at the level A.8.2 requires means session-level activity recording. For an administrator accessing a Linux server, the use log must capture every command executed during the session. For a database administrator, the use log must capture every SQL query executed. For a Windows server administrator, the use log must capture screen activity sufficient to reconstruct what was done.
The use log is the accountability mechanism A.8.2’s restriction and control requirements depend on. If privileged access use cannot be reconstructed from logs, the control over how privileged access was used cannot be assessed. The allocation and review components of A.8.2 are undermined if the use component is absent.
The use log also satisfies the intersection between A.8.2 and A.8.15. A.8.15 requires logging of user activities. A.8.2 requires logging of privileged access use. For privileged users, the same session activity log satisfies both controls simultaneously.
SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka, producing the use log A.8.2 requires across all supported session types.
SSH sessions produce full screen recordings and complete keystroke logs. Every command typed by the privileged user is captured with timestamp, directory context, and output. This is the use log for Linux server and network device administration.
MySQL and PostgreSQL sessions produce full screen recordings and structured capture of every SQL query executed. Each query record includes query text, timestamp, and session context. This is the use log for database administration.
RDP sessions produce full screen video recordings at configurable frame rates. This is the use log for Windows server administration.
Kubernetes sessions produce session event recordings and command logs for kubectl operations.
All recordings are stored encrypted, indexed for forensic search, and accessible from the Akku admin console for in-browser playback. The append-only storage architecture ensures that use logs cannot be modified after generation, satisfying A.8.2’s control requirement.
A.8.2 requires that privileged access rights be reviewed at regular intervals. Reviews must assess whether current entitlements remain appropriate and revoke those that do not. The review is the mechanism for detecting and closing the gap between what privileged users are currently entitled to access and what they currently need.
Privileged access review requires a structured campaign where the current privileged access entitlements of all users with privileged access are presented to appropriate reviewers, typically the security team and system owners, for certification or revocation. Each reviewer must make a decision per entitlement, and that decision must be timestamped and logged.
For revocations, the review record must be linked to a deprovisioning record showing that access was actually removed. A review record showing that a privileged entitlement was revoked but no corresponding deprovisioning record is an incomplete evidence chain that ISO 27001 auditors will identify.
The review cadence for privileged access should be more frequent than for standard access. Quarterly reviews for privileged access entitlements are common at organisations seeking to demonstrate robust A.8.2 compliance. The higher-risk nature of privileged access, combined with the event-by-event allocation standard that limits standing privilege, means that the review is primarily examining role-level entitlements: which users have the PAM platform roles that permit them to request privileged sessions to which target systems.
Akku’s IGA access review and re-certification campaigns support privileged access review at the PAM role level. The campaign sends certification requests to designated reviewers for every user with PAM platform roles. Each reviewer makes a certify or revoke decision per entitlement. Decisions are timestamped and logged. Revocations trigger automated removal of the PAM role, preventing the user from requesting further privileged sessions to the covered target systems.
The campaign record, covering scope, reviewer assignments, decision timestamps, and deprovisioning records for revocations, constitutes the A.8.2 review evidence that ISO 27001 auditors examine.
Standing privilege, the model where administrators hold persistent credentials to target systems that are valid between sessions, fails all three A.8.2 requirements simultaneously. Understanding why clarifies what the JIT access model resolves.
A.8.2 requires allocation on a need-to-use and event-by-event basis. Standing privilege is a single allocation that covers all future access events indefinitely. It is not need-to-use because it persists when there is no current operational need. It is not event-by-event because it does not require separate authorisation for each access event. Standing privilege fails A.8.2’s allocation standard by design.
A.8.2 requires that use be logged. If administrators connect to target systems directly using standing credentials, the connection occurs outside any session proxy that would generate use logs. Authentication events are captured by the target system’s own logs, but these can be modified by a sufficiently privileged administrator. Session activity logs require a session proxy layer that stands between the administrator and the target system. Standing privilege allows connections that bypass this proxy, producing no use logs.
A.8.2 requires periodic review of privileged access rights. Standing privilege creates entitlements with no defined scope or expiry. The review must assess whether the standing entitlement should continue, but since the entitlement covers all future access without restriction, the review cannot assess whether specific planned future access remains appropriate. The review becomes a binary decision to retain or remove the standing entitlement, without the granularity that A.8.2’s restriction and control requirements imply.
JIT access with per-session ephemeral credentials resolves all three failures. Every access event is individually authorised (allocation), recorded through the session proxy (use), and the role-level entitlement that permits session requests is what the periodic review assesses (review).
Auditors select a sample of privileged sessions from the certification period and request the allocation records for each. They verify that each session has a corresponding approval record showing the justification, approver identity, and timestamp. Sessions that opened without a corresponding approval record, or with informal approval through email, are findings.
Auditors request the use logs for the sampled sessions. They verify that the logs capture session activity at an appropriate level: keystroke logs for SSH, query logs for databases, screen recordings for RDP. Sessions where only authentication records exist, with no session activity recording, indicate that the use component of A.8.2 is not implemented.
Auditors examine privileged access review records from across the certification period. They verify that reviews were conducted on a defined cadence, that every privileged access entitlement was covered, that decisions were timestamped with reviewer identities, and that revocations were actioned. A single review conducted in the pre-audit window does not satisfy the operating effectiveness standard for a 12-month certification period.
Akku’s ISO 27001 mapping shows Privileged Access Manager addresses A.8.3, A.16.2, A.16.6, A.16.7, and A.16.8 across five clause mappings. Identity and Access Governance, with 16 clause references, covers the broader access governance controls including the review component.
For any privileged session to a critical system in the last six months, can you produce the allocation record showing the approved justification, approver identity, and timestamp, and the use record showing session activity at the keystroke or query level?
Do privileged users in your organisation hold standing credentials to target systems that allow them to connect at any time without a new approval, or does every connection require a new approval and use a session-specific credential?
Has your organisation conducted a formal review of privileged access entitlements in the last 12 months, with timestamped certification or revocation decisions for every privileged entitlement, and deprovisioning records for all revocations?
Does your session recording coverage extend to all critical systems including Linux servers accessed via SSH, production databases, and Windows servers accessed via RDP, or are some critical systems outside the session recording perimeter?
When a system administrator’s employment ends, is their privileged access removed across all connected systems within the same business day, with a timestamped deprovisioning record as evidence?
See how Akku addresses ISO 27001 A.8.2 privileged access management requirements through JIT access, per-session ephemeral credentials, SMARTAudit Trails, and access review campaigns.
Book a conversation with the Akku team to assess your current privileged access posture against ISO 27001:2022 A.8.2 certification requirements.
What does event-by-event allocation mean in practice for a system administrator who needs regular access to production servers?
Event-by-event allocation means each access event requires its own authorisation rather than being covered by a standing entitlement. For a system administrator who regularly accesses production servers, this means submitting a session request for each access occasion, specifying the target system, purpose, and duration. The approval workflow handles routine requests efficiently: low-risk access to familiar systems can be auto-approved or approved by a designated approver within minutes. The event-by-event standard does not make routine access impractical; it ensures each access event has a documented justification and authorisation that satisfies A.8.2’s allocation requirement.
Does A.8.2 apply to service accounts as well as human administrators?
Yes. A.8.2 covers all privileged access rights, including those held by service accounts used for automated processes. Service accounts with privileged access to production systems should be subject to the same allocation, use, and review requirements as human administrator accounts. Where service accounts require privileged access for specific automated tasks, that access should be scoped to the minimum required, documented in the access governance records, and reviewed periodically. Unreviewed service accounts with broad privileged access are a common finding in ISO 27001 audits and represent a real attack surface if service account credentials are compromised.
How does A.8.2 interact with A.9.2 (user access provisioning) in the ISO 27001:2022 control set?
A.9.2 in the 2013 version of ISO 27001 covered user access provisioning and was reorganised in the 2022 version into A.5.16 (identity management) and A.5.18 (access rights). A.8.2 covers privileged access rights specifically as a technological control, while A.5.18 covers access rights review broadly. Together they define the complete access governance framework: A.5.16 covers identity lifecycle, A.5.18 covers periodic review of all access rights, and A.8.2 covers the specific additional requirements for privileged access including event-by-event allocation, use logging, and review. All three must be implemented and evidenced for complete access governance coverage in a certification audit.
What is the minimum review frequency for privileged access entitlements to satisfy A.8.2?
ISO 27001:2022 A.8.2 requires review at regular intervals without specifying a minimum frequency. In certification audit practice, quarterly review for privileged access entitlements is considered robust. Semi-annual review is generally accepted. Annual review is the minimum most auditors accept, though a single annual review produces limited operating effectiveness evidence for a 12-month certification period. The review cadence should be defined in the ISMS documentation and consistently applied throughout the certification period.
Can the same access review campaign satisfy both A.8.2’s privileged access review requirement and A.5.18’s general access rights review requirement?
Yes. A single access review campaign that covers both privileged and standard access entitlements satisfies both A.8.2 and A.5.18 review requirements from the same campaign record. The campaign must be structured so that privileged entitlements are reviewed by appropriate reviewers, typically security team and system owners, while standard entitlements are reviewed by line managers. The campaign record must document which entitlements are privileged and which review process applied to each. Running separate campaigns for privileged and standard access is also acceptable and may be operationally preferable if privileged access is reviewed more frequently than standard access.
How does AkkuArka’s per-session ephemeral credential model affect the A.8.2 review process?
Per-session ephemeral credentials mean that there are no standing target system credentials to review at the entitlement level. What the periodic review assesses is the PAM platform role assignments: which users have roles that permit them to request privileged sessions to which target systems. The review certifies or revokes PAM platform roles rather than individual system credentials. When a PAM platform role is revoked following a review decision, the user can no longer request sessions to the systems that role covers. This is a cleaner review model than reviewing standing credentials because the entitlement boundary is clearly defined at the role level in the IAM platform, not distributed across individual system credential stores.
Introduction IRDAI ICS Annexure III Item 10 requires that user accounts inactive beyond a defined…
Introduction ISO 27001:2022 Annex A.5.18 requires that access rights be reviewed at regular intervals and…
Introduction SOC 2 Trust Services Criteria CC5.1 requires that the entity selects and develops control…
Introduction SEBI CSCRF applies to all regulated entities but differentiates requirements by entity tier. Market…
Introduction SEBI CSCRF PR.AA.S1(G1g) and PR.AA.S1(G1h) require that user accounts inactive beyond a defined threshold…
Introduction ISO 27001:2022 introduced A.8.16 as a new control with no direct equivalent in the…