What do organisations get wrong when they treat NIS2 as a documentation exercise instead of an access control programme?

A common mistake is focusing on policy writing, templates, and checklist completion while leaving privileged access, account review, and enforcement gaps untouched. That approach produces paper compliance without reducing real risk. NIS2 expects practical security measures that can be verified in operation, so weak control execution will undermine the entire compliance effort.

Why NIS2 Becomes Hollow When It Is Treated Like Paperwork

NIS2 is about demonstrable security capability, not just completed templates. If an organisation can produce policies but cannot show who has privileged access, how access is reviewed, or how enforcement is verified, the compliance posture looks better than the actual control environment. The real gap is usually not wording, it is operational discipline around access, accountability, and evidence.

The directive’s practical pressure is on control effectiveness, which is why operational security measures matter more than document quality alone. That is also where many programmes fail, because access sprawl, stale permissions, and weak review routines persist long after the policy set has been approved. The EU NIS2 Directive expects organisations to be able to show that security measures work in practice, not merely that they exist on paper.

In practice, many teams discover the gap only during an incident, audit, or remediation sprint, when the documented control cannot be matched to any reliable enforcement evidence.

How Access Control Fails in Practice

When NIS2 is treated as a documentation exercise, the organisation usually optimises for artefacts instead of control states. That means policies are written, reviewed, and filed, while privileged accounts, third-party access, emergency access, and dormant accounts continue to operate with little operational oversight. The result is a gap between declared governance and actual exposure.

Access rights are approved once but not revalidated at a useful cadence.
Privileged roles are broader than required and remain unchanged after job or system changes.
Exceptions exist, but there is no durable process to expire them or test compensating controls.
Logs may exist, yet no one checks whether access enforcement matches the policy intent.

This is why access control must be understood as a living programme: identity lifecycle, least privilege, review, revocation, and monitoring all have to work together. A strong policy is only valuable if it drives measurable behaviour such as timely removal of access, rotation of sensitive credentials, and evidence that elevated privileges are both limited and observable. The operational burden is higher than a documentation-first approach, but the risk reduction is real.

Organisations also underestimate how often “approved access” becomes “permanent access” in practice, especially where shared admin roles, contractor accounts, and legacy integrations are involved. The CIS Controls v8 are useful here because they emphasise account management, access control, and continuous hygiene rather than one-time policy completion, and the NIST SP 800-53 Rev 5 Security and Privacy Controls give a more detailed control model for governing access, review, and auditability.

These controls tend to break down when ownership is split across IT, security, and application teams, because no single team is accountable for removing access as systems and roles change.

Common Variations and Edge Cases

Tighter access control usually increases operational overhead, so organisations have to balance speed and convenience against assurance and auditability.

Some environments are harder than others. Shared platforms, inherited admin rights, outsourced operations, and legacy applications often make access governance more complex than the policy language suggests. In those cases, the failure is rarely the absence of a rule, it is the absence of enforceable exceptions, periodic recertification, and revocation discipline. NIS2 programmes also fail when they assume all access can be governed the same way, because human user access, service access, break-glass access, and third-party access each need different control treatment.

Current guidance suggests the most defensible approach is to prove that access decisions are continuously manageable, not merely originally approved. That is where documentation-only efforts fall short: they can describe the intended state, but they do not show whether access has been reduced, monitored, and removed when circumstances changed. In high-change environments, the question is less “Do we have a policy?” and more “Can we prove the policy is shaping actual access decisions today?”

The OWASP Non-Human Identity Top 10 is relevant when machine or service access is part of the exposure, because unmanaged non-human access often becomes the hidden path that undermines otherwise solid documentation. For organisations trying to understand where access-control weaknesses concentrate, the Ultimate Guide to NHIs shows how visibility, rotation, and offboarding failures translate into persistent risk.

Risk and Threat Considerations

The main risk is false assurance: leadership believes NIS2 readiness is improving because documentation is complete, while the actual attack surface remains unchanged. That matters because excessive privilege, stale access, and weak revocation create direct exposure for misuse, compromise, and poor containment during incidents.

Failure mechanism: Attackers and insiders benefit when access is broadly granted, weakly reviewed, or rarely removed. If privileged accounts, credentials, or service access are not actively governed, a documented control can exist alongside a materially unsafe environment, and exceptions can persist long enough to be abused.

Impact: The organisation can lose containment discipline, fail an audit under operational scrutiny, and suffer broader blast radius during compromise because the access model never became restrictive in practice.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the technical controls, while NIS2 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIS2	Article 21 — Cybersecurity risk-management measures	NIS2 requires practical security measures, not just written policies.
Recommendation — Implement and evidence operational security measures that reduce real access risk.
CIS Controls v8	6 — Access Control Management	Directly covers account governance, least privilege, and access review.
Recommendation — Enforce least privilege, review access regularly, and remove stale accounts.
NIST CSF 2.0	PR.AC — Identity Management, Authentication and Access Control	Maps the need to govern access states, privilege, and enforcement.
Recommendation — Manage access states and privileges so they match current business need.
NIST SP 800-63	3 — Digital Identity Guidelines	Supports assurance for authentication and identity lifecycle decisions.
Recommendation — Use identity assurance and authentication practices that support trustworthy access decisions.

Practitioner Guidance

What to prioritise: Treat access control evidence as the real deliverable, not the policy pack. Focus first on privileged accounts, third-party access, emergency access, and any account that can change systems or data at scale. If those are not reviewable and revocable, the NIS2 programme is still mostly documentary.

What to verify: Verify that access reviews result in actual removals, not just sign-off records. You should be able to produce proof of who approved access, when it was last recertified, what was removed, and how exceptions expire. If that chain cannot be shown end to end, the control is not yet operationally credible.

Practitioner takeaway: The most important test is whether security controls change live access behaviour, because NIS2 maturity is measured by enforceable reduction in exposure, not by the quality of the paperwork.