Who should own NIS2 readiness when identity, security, and governance responsibilities span multiple teams?

Shared ownership works only when the accountabilities are separated

NIS2 readiness is a governance problem as much as a control problem. The core mistake is treating it as one team’s project, then discovering late that identity design, security policy, evidence collection, and operational execution were never aligned. Security leadership should own the control intent, IAM and PAM should own access enforcement, and GRC should own auditability and reporting. That split keeps the program coherent while avoiding the usual “everyone is involved, so nobody is accountable” failure mode.

The legal baseline is the NIS2 Directive, official EU legal text, which pushes organisations toward demonstrable governance rather than informal assurance. NIS2 readiness therefore depends on who can prove controls are operating, who can remediate gaps, and who can answer for exceptions. In practice, the programme usually fails when the right functions are consulted but no single owner is empowered to resolve conflicts across them.

How it works in practice

A workable model is a federated ownership structure with one accountable lead and several execution owners. Security leadership sets the readiness bar, defines the control objectives, and decides what “good” looks like across identity, logging, segregation of duties, and incident response readiness. IAM and PAM then implement the access model that supports those objectives, while GRC collects evidence, tracks exceptions, and prepares the material needed for internal assurance or regulatory scrutiny.

• Security leadership owns the policy intent, scope, and risk acceptance decisions.
• IAM owns identity lifecycle, authentication, access reviews, and role design.
• PAM owns privileged access workflows, elevation, session control, and break-glass governance.
• GRC owns evidence quality, control traceability, reporting cadence, and issue tracking.

This structure matters because NIS2 readiness is not just about having controls, it is about showing that they are consistently applied, reviewed, and maintained. The same principle appears in NIST Cybersecurity Framework 2.0, which emphasises governance and repeatable risk management, not isolated technical effort. For identity-heavy environments, the operating detail is often where readiness is won or lost: access reviews must be timely, privilege changes must be traceable, and exceptions must have expiry and owner approval.

Where teams go wrong is assuming that policy ownership automatically creates operational control. A policy document without enforcement in IAM and PAM, plus evidence in GRC, is usually too weak for readiness claims. These controls tend to break down when identity ownership is split across business units and no one can force standardisation across roles, approvals, and reporting.

Common variations and edge cases

Tighter ownership often increases coordination overhead, so organisations must balance speed against assurance. That trade-off becomes visible in matrixed enterprises, outsourced operations, and environments with shared platforms, where the control owner and the system owner are not the same person.

One common variation is when IAM is embedded in a platform team but governance sits elsewhere. That can work, but only if the control owner retains authority to set standards and reject weak implementations. Another edge case is partial outsourcing, where the provider runs operations but the regulated organisation still needs defensible evidence and exception handling. In that model, readiness depends on contract terms, reporting quality, and the ability to prove that provider activity maps back to internal obligations.

Another practical issue is that some teams over-focus on certification artefacts and under-invest in operational proof. A readiness programme should be judged by whether access control decisions are current, privileged pathways are constrained, and evidence can be produced without manual reconstruction. For NIS2, current guidance suggests ownership should follow control responsibility, not organisational hierarchy alone, because hierarchy rarely matches the actual path of remediation.

Risk and Threat Considerations

NIS2 readiness creates governance and operational risk when identity, security, and reporting responsibilities are fragmented. The main exposure is not a single technical failure, but a coordination failure where access controls, evidence, and exception handling drift apart over time. That makes readiness claims fragile and can leave gaps in privileged access oversight, auditability, and remediation discipline.

Failure mechanism: one team defines policy, another implements access, and a third collects evidence, but no single function owns end-to-end closure. Gaps then persist in role design, privilege review, or reporting because each team assumes another is handling remediation or sign-off.

Impact: the organisation may be unable to prove consistent control operation, may miss high-risk access exceptions, and may face avoidable compliance findings or delayed remediation of identity-related weaknesses.

Practitioner Guidance

Decision rule: assign one accountable owner for NIS2 readiness, then split execution by control domain. If a question involves policy interpretation, risk acceptance, or issue closure, it belongs to security leadership; if it involves access design or privilege mechanics, it belongs to IAM or PAM; if it involves evidence quality, it belongs to GRC.

What to verify: confirm that every key control has a named owner, a named approver, and a named evidence source. If any of those three are missing, the readiness model is still informal, even if the control itself exists.

Practitioner takeaway: NIS2 readiness is strongest when ownership follows the control path end to end, because distributed responsibility only works when accountability is explicit enough to survive audit, remediation, and escalation.

Related resources from NHI Mgmt Group

• Who should own an offensive security program when testing, triage, and remediation span multiple teams?
• How should security teams handle authentication governance for Kubernetes access when identity is managed outside the cluster?
• How should security teams use IAST and RASP in NHI governance?
• Who should own Copilot data governance across identity and security teams?