How should organisations implement NIS2 controls without turning compliance into a standalone project?

Making NIS2 part of the operating model

NIS2 becomes sustainable when it is treated as a way to strengthen existing control ownership, not as a one-off compliance campaign. Organisations should anchor the programme in their current ISMS or security governance structure, then use the directive to tighten how they already manage risk, incidents, access, logging, and third parties. The official NIS2 Directive text is the right reference point because it is written around operational risk management, not paperwork.

The practical test is whether teams can absorb NIS2 into recurring work without creating duplicate registers, separate approval chains, or a second set of controls. That usually means reusing the security committee, incident process, supplier review cycle, and audit evidence already in place, then adding the NIS2-specific expectations where they change the control outcome. ISO/IEC 27001:2022 Information Security Management is a strong baseline because it aligns well with control ownership, continual improvement, and auditability.

One useful way to avoid a standalone project is to map NIS2 obligations to the controls people already execute, then track whether those controls are actually producing evidence. For example, incident handling should already generate timestamps and decision logs, access reviews should already show who approved what and why, and supplier oversight should already capture security requirements and escalation paths. Where those records exist, NIS2 usually needs integration and clarification, not reinvention. ISO/IEC 27002:2022 Information Security Controls is useful here because it turns the management system into concrete implementation guidance.

Where programmes usually become fragmented

The most common failure mode is splitting compliance ownership from operational ownership. When legal, risk, and security each maintain different views of the same control, the organisation ends up with duplicate evidence requests, conflicting terminology, and controls that look compliant in a slide deck but are not exercised in production. That problem gets worse when logging, access control, and supplier due diligence are reviewed only at audit time instead of as part of routine security operations.

Another fragmentation point is the treatment of third-party and service access as a procurement issue rather than a security control. NIS2 pushes organisations to understand who can reach critical systems, what privileges they hold, and how quickly access can be removed or constrained when risk changes. This is especially important where supplier accounts, API keys, and other machine-held access are used to support production workflows. NHI Mgmt Group's Ultimate Guide to NHIs is relevant because it highlights how overprivilege, secret sprawl, and poor visibility can turn routine operational access into a compliance and resilience issue.

Audit readiness also fails when evidence is assembled after the fact rather than generated by the process itself. If a team cannot point to a current incident runbook, a recent access review, a logged supplier exception, or a measured remediation action, the control is probably too informal to support NIS2 at scale. Ultimate Guide to NHIs, Regulatory and Audit Perspectives is a useful reminder that audit trails and governance artefacts should emerge from normal operations, not be reconstructed for a deadline.

Practitioner Guidance

What to prioritise: Start with the controls that already touch NIS2 the most, incident response, access governance, logging, and supplier oversight. If those are stable, compliant evidence becomes much easier to produce without building a separate programme layer.

What to verify: Check that every NIS2 obligation has a real control owner, a repeatable workflow, and an artefact that is created as part of execution. If a requirement is only tracked in a tracker or spreadsheet, it is still a project item, not an operational control.

Common mistake: Do not let compliance teams define controls in isolation and hand them to engineering or operations later. That almost always creates duplicate work, shallow evidence, and brittle processes that collapse under audit pressure.

Practitioner takeaway: The goal is not to bolt NIS2 onto the business, but to make existing security work visibly meet NIS2 expectations, so compliance stays embedded in how the organisation actually runs.

Related resources from NHI Mgmt Group

• How should organisations implement document-free identity verification without weakening fraud controls or compliance checks?
• How should organisations implement password controls for SOC 2 without turning the policy into a box-ticking exercise?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?
• How should organisations implement PSD2 controls without adding too much checkout friction?