NIS2 compliance in the public sector: identity and process gaps

At a glance

What this is: This is an analysis of why NIS2 compliance in public services breaks down when identity governance and service processes are not tightly controlled.

Why it matters: It matters because IAM, process control, and supplier oversight are often the practical difference between a policy requirement and evidence that can withstand audit in public-sector environments.

Context

Public-sector NIS2 compliance is not only a legal question. It is an operating-model problem because the directive expects consistent risk management, incident reporting, resilience, and supply-chain oversight while many public bodies still run with fragmented identity and service processes.

In that environment, access control and workflow governance become evidence problems as much as security problems. If an organisation cannot show who had access, who approved it, and how incidents were handled across systems and vendors, it will struggle to prove control under NIS2.

The article’s core point is that compliance pressure lands on day-to-day process discipline. That makes identity governance, service desk workflows, and third-party accountability central to the public-sector response, not supporting details.

Key questions

Q: What breaks when public-sector NIS2 controls are only documented and not operationalised?

A: Written controls lose value when risk, incident, resilience, and supplier processes are handled manually or inconsistently. The organisation may appear compliant on paper but cannot reliably prove that approvals happened, incidents were reported on time, or vendor oversight was maintained. Under NIS2, repeatable execution matters as much as policy intent.

Q: Why do identity controls matter so much for NIS2 compliance?

A: Because NIS2 compliance depends on proving who had access, what they could do, and how quickly you can respond when something goes wrong. Identity controls create the evidence trail for access control, incident handling, and accountability. Without reliable identity telemetry, incident reporting becomes slower, less accurate, and harder to defend.

Q: What are the signs that NIS2 incident handling is too manual?

A: Common signs include inconsistent categorisation, delayed documentation, unclear handoffs, and reporting steps that depend on individual staff rather than a defined workflow. When those signals appear, the organisation is likely to miss the speed and consistency expected by NIS2, especially under resource pressure.

Q: How should public organisations balance NIS2 compliance with operational efficiency?

A: They should build compliance into service workflows rather than treat it as a separate governance exercise. Centralised access control, automated incident handling, and tracked supplier oversight reduce manual effort while creating the evidence needed for audit and resilience decisions.

Technical breakdown

Why NIS2 compliance breaks down in public-sector operating models

NIS2 raises the bar on risk management, incident handling, resilience, and supply-chain oversight, but public-sector organisations often run these obligations across legacy platforms and manual processes. That creates a gap between written policy and repeatable execution. The issue is not simply whether controls exist, but whether they are embedded in service operations that can scale across departments, suppliers, and endpoints. In practice, compliance depends on whether the organisation can turn governance into consistently executed workflows rather than one-off administrative effort.

Practical implication: map each NIS2 obligation to a named operational workflow and assign clear ownership before the next audit cycle.

How identity governance supports audit-ready NIS2 controls

The article’s access-control emphasis shows why identity is part of compliance evidence, not just a security function. Role-based access control helps limit who can reach sensitive systems and data, while centralised management makes it easier to demonstrate that access decisions were consistent. For public bodies, this matters because access governance is often distributed across teams and tools. Without traceable provisioning, review, and revocation, the organisation may have policy intent but weak proof of enforcement.

Practical implication: align RBAC, access reviews, and approval records so auditors can trace access decisions end to end.

Why service management and incident workflows become compliance controls

ITSM and ESM tools matter here because they turn incident response and third-party oversight into documented process. The article points to automated categorisation, documentation, and reporting of incidents, which is exactly where many public organisations struggle under strict notification timelines. The same is true for supplier governance: if third-party risks, contracts, and certifications are not centrally tracked, supply-chain assurance becomes ad hoc. The compliance challenge is therefore procedural as much as technical.

Practical implication: formalise incident triage, notification, and supplier review workflows so the organisation can prove they were followed.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Public-sector NIS2 compliance fails first as a process discipline problem, not a policy problem. The directive asks organisations to demonstrate repeatable risk management, reporting, resilience, and supplier oversight, but many public bodies still rely on manual coordination and fragmented ownership. That makes compliance dependent on individual effort rather than governed execution. The practical conclusion is that NIS2 readiness should be judged by process consistency, not by the existence of policy documents alone.

Identity governance is the evidence layer of NIS2 compliance. Access control is not only about who can enter a system, but whether the organisation can prove that access was authorised, time-bound, and reviewable. In public-sector environments, role drift and distributed administration often weaken that evidence chain. The implication is that access governance must be treated as audit infrastructure, not a back-office administrative task.

Supplier oversight becomes a resilience control when public services depend on external providers. NIS2’s supply-chain expectations are difficult to meet if third-party reviews, certifications, and contract status sit in separate systems or spreadsheets. That creates blind spots in accountability and slows response when a vendor issue becomes an operational issue. The conclusion is that third-party governance must be centralised enough to support incident, risk, and assurance decisions together.

Process automation is now a compliance control, not just an efficiency gain. The article’s emphasis on automated categorisation, documentation, and reporting reflects a broader shift in public-sector governance. If incident handling still depends on manual routing, the organisation will struggle with timeliness and consistency under NIS2. The practitioner takeaway is to treat service workflows as part of the control plane.

NIS2 in the public sector exposes the gap between security ambition and administrative capacity. Restricted budgets, scarce specialist skills, and legacy systems make it unrealistic to assume compliance can be added on top of existing operating habits. The broader lesson is that public-sector security programmes need governance models that fit constrained environments. Practitioners should design for repeatability, not heroic intervention.

What this signals

Identity evidence, not just access policy, is what separates NIS2 intent from NIS2 proof. Public-sector teams need traceable approvals, periodic reviews, and revocation records that can survive audit scrutiny. If those records are scattered across systems, compliance becomes difficult to demonstrate even when the controls exist in theory.

Service workflows are part of the control plane. Incident reporting, supplier review, and risk triage should be executed through governed processes rather than informal coordination. That shift matters because constrained public-sector environments need repeatability more than heroic manual effort.

For practitioners

• Define NIS2 control owners by workflow Assign named owners to risk, incident, resilience, and supplier processes so each obligation has a documented execution path rather than informal responsibility.
• Centralise access evidence for sensitive systems Use role-based access control and review records to show who approved access, when it changed, and why sensitive public-sector systems remained restricted.
• Automate incident categorisation and reporting Build service workflows that capture incident classification, documentation, and notification steps in the same system used for operational handoff.
• Track third-party assurances in one register Keep contracts, certifications, and risk ratings together so supplier review supports both NIS2 oversight and incident decision-making.

Key takeaways

• NIS2 in public services is difficult because compliance depends on whether governance is executed consistently across people, systems, and suppliers.
• The practical failure mode is not ignorance of the directive, but fragmented access and process control that weakens evidence and timeliness.
• Public-sector teams should treat identity governance and service workflows as operational controls that support audit, incident handling, and resilience.

Key terms

• NIS2 Compliance Evidence: NIS2 compliance evidence is the operational record that proves controls are working, not just written down. It usually includes access logs, incident timestamps, approval history, supplier reviews, and revocation records that show governance was executed consistently across the organisation.
• Identity Governance Evidence Chain: Identity governance evidence chain is the record of policies, controls, logs, approvals, and remediation steps that proves identity risk is being managed consistently. It links what an organisation says it does with what it can actually demonstrate to auditors, regulators, and internal reviewers across multiple frameworks.
• Service Workflow Governance: Service workflow governance is the use of controlled processes to manage incidents, requests, approvals, and escalations. In regulated environments, the workflow itself becomes part of the control set because it determines whether actions are timely, traceable, and repeatable.
• Supplier Oversight: Supplier oversight is the process of extending security and compliance controls to third parties that can access, process, or transmit protected information. For CMMC programmes, it includes contractual obligations, access governance, evidence collection, and offboarding discipline so subcontractor risk is controlled rather than assumed away.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.