Policy compliance says the organisation has rules. Identity control proves those rules are enforced in live access data, including who has access, what they can reach and whether the access is removed when it is no longer justified.
Policy compliance vs identity control under NIS2
Policy compliance is the paper trail: policies, standards and procedures exist, are approved and are periodically reviewed. Identity control is the operational proof: access is assigned, limited, monitored and removed in the live system in line with the policy. Under NIS2, that distinction matters because auditors and regulators look for evidence that governance actually changes access behaviour.
For a NIS2 programme, the practical test is whether the control can answer four live questions: who has access, to what, under what approval, and for how long. A written rule can say “least privilege”, but identity control shows whether privileged access, dormant accounts and cross-system entitlements are actually under control.
That makes identity control a stronger indicator of implementation maturity than policy compliance alone. A policy can be complete and still miss stale accounts, unmanaged service accounts, weak joiner-mover-leaver handling, or delayed revocation. In NIS2 terms, that gap is where governance claims stop matching operational reality.
What each one proves to an auditor or assessor
Policy compliance proves intent, scope and accountability. It shows the organisation has defined requirements for access management, review cadence and ownership. It is necessary, but it does not by itself prove the organisation has enforced those requirements across human and non-human access, systems, or environments.
Identity control proves enforcement. It is the evidence that access governance is embedded in the control plane, not just documented. That includes provisioning and deprovisioning records, access review outcomes, privileged access pathways, and evidence that exceptions are time-bounded and remediated. NHIMG’s Identity Security Regulatory Map is useful here because it ties identity controls directly to regulatory expectations such as NIS2, DORA and GDPR.
In practice, the assessor is asking a simple question: does the organisation merely describe the control, or can it show the control operating consistently? Under NIS2, that usually means policy documents must be backed by inventories, access review evidence, revocation records and exception handling that can be traced to specific identities and resources.
Why the difference matters in NIS2 remediation work
The difference becomes material when a team has strong governance language but weak access hygiene. For example, a policy may require periodic recertification, but the live directory still contains orphaned accounts, long-lived privileged access or unmanaged credentials. In that case the control objective exists on paper, but the underlying risk remains.
This is why identity control is the layer that closes the gap between compliance and resilience. The difference is especially visible in lifecycle management, where provisioning, access changes and offboarding must be timely and provable. NHIMG’s NHI Lifecycle Management Guide and Ultimate Guide to NHIs , Regulatory and Audit Perspectives both support that operational view by showing how lifecycle and audit evidence work together.
Where organisations get this wrong, they often treat access review as a paperwork exercise instead of a control test. Under NIS2, that is a weak position because the relevant question is not whether the policy exists, but whether the access state in production matches the approved state the policy requires.
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 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | NIS2 access governance depends on provisioning, review, and removal of accounts. |
| AC-6 — Least Privilege | The question turns on whether access is actually limited to justified need. | |
| AU-6 — Audit Review, Analysis, and Reporting | Identity control must produce evidence that access rules are being enforced. | |
| Recommendation — Enforce account lifecycle controls and verify access removal is timely and auditable. Restrict entitlements to the minimum access needed and review exceptions routinely. Review audit evidence to confirm access changes, reviews, and revocations are actually happening. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | This directly captures the gap between policy statements and live identity enforcement. |
| Recommendation — Operate identity lifecycle controls that prove access is managed, revoked, and audited. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | NIS2 access governance aligns with controlled granting, review, and removal of access. |
| Recommendation — Define and enforce access control rules that match approved business need. | ||
Practitioner Guidance
What to verify: Check whether every policy requirement has a corresponding live control signal, such as current entitlements, privileged access records, and revocation evidence. If the policy cannot be traced to actual access data, treat it as governance only, not control evidence.
Decision rule: If the issue is “do we have the policy?”, focus on compliance documentation; if the issue is “are access rights actually governed?”, focus on identity data, exceptions and remediation latency. For NIS2 readiness, the second question is the one that usually determines whether the control will hold up.
Common mistake: Teams often overvalue annual access reviews and undervalue continuous hygiene. A clean review report does not offset stale privileges, unremoved access after role changes, or missing offboarding evidence.
Practitioner takeaway: Policy compliance shows you can define the rule, but identity control is what proves the rule is enforced where risk actually lives, in active access and entitlement state.
Related resources from NHI Mgmt Group
- What is the difference between patching a vulnerability and reducing identity blast radius?
- What is the difference between compliance-driven identity control and threat-centric identity control?
- What is the difference between Kubernetes network policy and identity-based access control?
- What is the difference between real control evidence and policy-based compliance proof?