Because these frameworks are applied in contexts where organisations must demonstrate that access controls are operating, not merely described. Static policy documents do not prove that permissions were current, justified and enforceable during real business activity.
Why NIS2 and ENS move IAM from documentation to evidence
NIS2 and ENS both push programmes away from static statements and toward proof that access decisions are operating in practice. That matters because an access policy can exist on paper while entitlements stay stale, approvals are inconsistent, or privileged paths are still open. The evidentiary burden is therefore operational: show current enforcement, not just intent.
For practitioners, the practical shift is from “do we have a policy?” to “can we demonstrate the policy is being applied across live accounts, roles, and exceptions?” In that sense, IAM becomes a control system with records, not a document set with assumptions.
Why policy documents are not enough for auditability
Policy documents define the rule set, but they do not prove the control environment is aligned to that rule set at the time business activity occurs. A reviewer still needs artefacts such as access reviews, provisioning and deprovisioning records, approval trails, exception handling, and evidence that privileged access was bounded. That is why lifecycle management and governance evidence matter as much as role design. See IAM and IGA Basics for the control family view, and Identity Security Regulatory Map for how identity controls map to regulatory obligations.
This is especially true where identities are not just human users. Machine, workload and service identities can accumulate standing permissions that never get revisited unless there is continuous inventory, rotation and offboarding evidence. NIS2-style assurance is weaker when a programme can only point to an old policy and cannot show the actual state of access. NHI Lifecycle Management Guide and Ultimate Guide to NHIs, Regulatory and Audit Perspectives both reinforce why lifecycle evidence is part of control effectiveness.
What continuous evidence looks like in an IAM programme
continuous evidence usually means the programme can produce fresh, system-generated proof that access is governed in near real time or on a reliable cadence. Typical examples include access recertification outcomes, logs of privilege grant and revoke events, just-in-time activation records, detected orphaned or dormant accounts, and exception registers that show who approved temporary deviations. The key idea is that evidence is accumulated from control operation, not reconstructed after the fact.
For cloud and hybrid estates, the evidence must also prove that effective permissions match intended permissions, especially where role inheritance, cross-account trust, service principals, or secret material can expand reach beyond what a policy describes. Controls around right-sizing and privileged access are most defensible when teams can show who had access, why they had it, and when it was removed. Cloud PAM and CIEM Guide and Cloud Workload Identity Guide are useful for understanding why entitlement evidence and keyless, short-lived access patterns matter.
Continuous evidence also improves operational resilience. If a control only exists in policy form, teams discover drift late, usually during an incident, audit, or major change. If evidence is built into the operating model, drift becomes observable sooner, and remediation can be targeted to the actual account, role, or secret path that is out of tolerance.
Risk and Threat Considerations
When IAM is documented but not evidenced continuously, the main risk is control drift: access stays broader, longer, and less attributable than the policy says it should. That creates audit findings, but more importantly it creates a practical path for privilege abuse, stale access, and hidden standing permissions across human and machine identities.
Failure mechanism: permissions, approvals, and reviews are treated as periodic paperwork rather than live control outcomes, so excessive access and unreconciled exceptions persist between review cycles.
Impact: organisations lose assurance that access was justified at the time of use, which increases the blast radius of compromise and weakens evidence for regulatory, incident response, and assurance purposes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Continuous evidence depends on recorded access events and control operation traces. |
| IA-5 — Authenticator Management | The question concerns proving credential and access control operation, including current enforceability. | |
| AC-2 — Account Management | NIS2 and ENS pressure programmes to show accounts are provisioned, reviewed and removed in practice. | |
| Recommendation — Log access grants, revocations and privileged actions so control operation is provable. Manage credential lifecycle and rotation so access evidence remains current and verifiable. Maintain authoritative account records and recertification evidence for all active access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The topic is about demonstrating operational access control, not merely policy wording. |
| A.5.18 — Access rights | The answer depends on proving rights are current, approved and revoked when needed. | |
| Recommendation — Use access-control records to prove enforced access decisions and exceptions. Track, review and revoke access rights on a defined lifecycle cadence. | ||
Practitioner Guidance
What to verify: Make sure your evidence is generated from authoritative systems, not assembled manually from spreadsheets. The useful question is whether you can prove who had access, when it changed, and what justified it for both human and non-human identities.
Implementation sequence: Start with the highest-risk access paths first, privileged roles, external access, and long-lived or shared credentials, then expand to the rest of the estate. That sequencing gives you defensible evidence where failure would hurt most, before broadening to lower-risk populations.
Common mistake: treating a completed review as proof of control health. A passed review is only meaningful if it is backed by current provisioning, revocation, and exception evidence that matches the live environment.
Practitioner takeaway: For NIS2 and ENS, the real test is not whether the policy exists, but whether the programme can continuously demonstrate that access is controlled, current, and revocable in the systems that actually run the business.
Related resources from NHI Mgmt Group
- What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
- How should organisations prove continuous IAM compliance for NIS2 and ENS?
- Why do application security audits now require evidence rather than policy documents alone?
- How should enterprises move from role-based access control toward policy-driven authorization without disrupting existing IAM programmes?