Regulatory Requirements for Privileged Access
This page documents the specific regulatory articles and control requirements that mandate privileged access management. It is framed from the organization's obligation perspective — what you must implement — rather than how any particular product addresses it.
For how GrantFlow maps to these requirements, see Compliance Coverage.
NIS2 Directive — Article 21
The Network and Information Security Directive 2 (EU 2022/2555) requires essential and important entities to implement cybersecurity risk-management measures. Article 21 is the core obligation for access control.
Article 21(2)(i): Access Control Policies
NIS2 explicitly requires "policies and procedures regarding the use of cryptography and, where appropriate, encryption" and "human resources security, access control policies and asset management." The access control requirement encompasses:
- Privileged account management — organizations must have documented policies for managing accounts with elevated permissions
- Least privilege enforcement — access must be limited to what is necessary for each role
- Access review processes — regular verification that access assignments remain appropriate
Article 20: Management Body Accountability
NIS2 holds management bodies directly responsible for approving and overseeing cybersecurity risk-management measures. Board members and executive leadership can face personal liability if the organization fails to implement required measures — including privileged access controls.
This is significant because it elevates PAM from an IT decision to a board-level governance obligation. Management cannot delegate accountability by claiming ignorance of technical details.
What "Appropriate Measures" Means for PAM
NIS2 uses the phrase "appropriate and proportionate technical, operational and organisational measures." For privileged access, this means organizations must demonstrate:
- A documented policy for who can hold privileged access and under what conditions
- Technical controls that enforce time-limited, justified access rather than permanent assignments
- Audit evidence showing the policy is implemented and operational
- Regular review and improvement of access controls based on evolving threats
NIS2 Compliance Deadline
EU member states were required to transpose NIS2 into national law by October 17, 2024. Organizations in scope should already be implementing these measures. The directive applies broadly — covering energy, transport, health, digital infrastructure, ICT service management, public administration, and many other sectors.
DORA — Article 9
The Digital Operational Resilience Act (EU 2022/2554) establishes ICT risk management requirements for financial entities. Article 9 specifically addresses ICT access control.
Article 9(4): Access Control Requirements
DORA Article 9(4) requires financial entities to implement ICT policies that include:
| Sub-Requirement | Obligation |
|---|---|
| (a) Identity management | Unique identification of all users accessing ICT systems |
| (b) Account management procedures | Granting, modifying, and revoking access rights with documented processes |
| (c) Access restrictions | Limiting access based on the principle of least privilege and need-to-know |
| (d) Authentication mechanisms | Strong authentication for privileged access, including multi-factor authentication |
| (e) Privileged access management | Specific, documented controls for accounts with elevated ICT privileges |
Sub-requirement (e) is particularly explicit: financial entities must have dedicated privileged access management — not just general access controls. This means organizations in the financial sector cannot treat administrative accounts the same as regular user accounts.
Article 12: Logging Requirements
DORA requires financial entities to maintain logs of ICT operations that are sufficient to support incident detection and response. For privileged access, this means every elevation, every action taken during elevation, and every deprovisioning event must be logged with enough detail to reconstruct the timeline during an incident.
ISO 27001:2022 — Control A.8.2
ISO 27001 Annex A Control A.8.2 specifically addresses privileged access rights. Organizations seeking or maintaining ISO 27001 certification must demonstrate implementation of this control.
What A.8.2 Requires
The control states that the "allocation and use of privileged access rights shall be restricted and managed." Implementation guidance specifies:
- Identification of all privileged access — you must maintain a current inventory of all accounts with elevated permissions
- Allocation on a need-to-use basis — privileges should be granted only when required, not permanently
- Time-limited access — where possible, privileged access should be granted for a defined period and automatically revoked
- Authorization process — a formal approval process must exist for granting privileged access
- Logging and monitoring — all use of privileged access must be recorded and reviewed
What Certification Auditors Look For
During an ISO 27001 audit, assessors typically examine:
- Evidence of a privileged access policy — a documented policy defining how privileged access is managed
- Technical enforcement — proof that the policy is enforced technically, not just documented
- Access review records — evidence of regular reviews of who holds privileged access
- Revocation evidence — proof that privileged access is removed when no longer needed
- Audit trail — logs showing who accessed what, when, and why
An environment with permanent Domain Admin or Global Administrator assignments and no compensating controls will typically receive a non-conformity finding on A.8.2.
SOC 2 — CC6.1 and CC6.3
SOC 2 Trust Services Criteria address privileged access under the Security principle, specifically in CC6 (Logical and Physical Access Controls).
CC6.1: Logical Access Security
CC6.1 requires that the entity implements logical access security software, infrastructure, and architectures over protected information assets. For privileged access, this means:
- Technical controls that prevent unauthorized privilege escalation
- Mechanisms to restrict privileged access to authorized personnel only
- Evidence that controls are operating effectively over the audit period
CC6.3: Role-Based Access and Least Privilege
CC6.3 requires that the entity authorizes, modifies, and removes access to data, software, functions, and other protected information assets based on roles and responsibilities. For privileged access, this means:
- Role-based access assignments tied to documented job responsibilities, not ad-hoc group memberships
- Periodic access reviews with evidence of remediation when access is no longer justified
- Separation of duties — no single account should have unchecked privileged access
- Timely removal of privileged access when roles change or assignments are no longer required
SOC 2 Audit Evidence
SOC 2 auditors examine a continuous period (typically 6–12 months) and look for consistent evidence. Point-in-time cleanups are insufficient — the controls must operate throughout the audit period. JIT access provides this continuous evidence automatically through activation logs, approval records, and deprovisioning timestamps.
BSI IT-Grundschutz — ORP.4
The BSI IT-Grundschutz framework is the German standard for information security management, widely adopted in the DACH region. Building block ORP.4 (Identity and Authorization Management) contains the relevant requirements.
Key Requirements
| Requirement | Obligation |
|---|---|
| ORP.4.A1 | Documented rules for creating, modifying, and deleting user accounts |
| ORP.4.A2 | Formal processes for granting and modifying access rights, including approval |
| ORP.4.A3 | Documentation of all granted access rights |
| ORP.4.A6 | Timely revocation of access rights when no longer needed |
| ORP.4.A16 | Special handling of privileged access — stricter controls, enhanced logging, regular review |
ORP.4.A16 is particularly relevant: it requires that privileged accounts receive dedicated, stricter controls compared to standard user accounts. This aligns with the NIS2 and DORA requirements for explicit privileged access management.
DACH Region
Organizations operating in Germany, Austria, or Switzerland frequently face BSI Grundschutz requirements — either through direct regulatory obligation (for government and critical infrastructure) or through customer contract requirements. The ORP.4 building block is a common audit focus area.
Scale Cross-Framework Summary
Despite different terminology and structures, all five frameworks converge on the same core requirements for privileged access:
| Requirement | NIS2 | DORA | ISO 27001 | SOC 2 | BSI |
|---|---|---|---|---|---|
| Inventory of privileged accounts | Art. 21(2)(i) | Art. 9(4)(a) | A.8.2 | CC6.1 | ORP.4.A3 |
| Formal approval for privilege grants | Art. 21(2)(i) | Art. 9(4)(b) | A.8.2 | CC6.3 | ORP.4.A2 |
| Least privilege / time-limited access | Art. 21(2)(i) | Art. 9(4)(c,e) | A.8.2 | CC6.1 | ORP.4.A16 |
| Logging of privileged activity | Art. 21(2)(b) | Art. 12 | A.8.15 | CC7.2 | ORP.4.A3 |
| Regular access reviews | Art. 21(2)(i) | Art. 9(4)(b) | A.8.2 | CC6.3 | ORP.4.A6 |
| Management accountability | Art. 20 | Art. 5 | Clause 5.1 | CC1.2 | — |
This convergence means that implementing JIT access addresses the privileged access requirements of all five frameworks simultaneously — rather than building separate controls for each.