How should critical infrastructure teams sequence NIS2 readiness work when they are starting from a low OT maturity level?

Start with the OT baseline, not the control catalogue

When maturity is low, the first sequencing decision is to understand what is actually deployed, how it is segmented, where remote access exists, and which systems are most operationally sensitive. A formal OT assessment gives teams the baseline they need before they try to map NIS2 obligations into controls. For critical infrastructure teams, the NIS2 readiness problem is not “which controls exist”, but “which gaps are most consequential in this environment.”

That baseline should include inventory accuracy, trust boundaries, logging visibility, backup and recovery assumptions, and the current incident-handling path. Without that picture, teams often overinvest in policy documents or tooling before they know where their weakest pathways are. The right sequencing is to reduce uncertainty first, then convert the findings into a targeted control plan.

That is why an OT maturity approach such as the OT Security Maturity Model is useful here, because it helps teams turn a broad readiness mandate into a staged improvement plan.

Prioritise visibility and incident readiness before hardening everything

Once the baseline is clear, the next work should focus on controls that improve visibility, detection, and response in the shortest time. In low-maturity OT environments, the practical sequence is usually monitoring, alert routing, asset awareness, and incident workflows before deeper optimisation or major platform change. Those capabilities make the environment observable enough to support the rest of the programme.

This sequencing matters because many NIS2 obligations are difficult to demonstrate if you cannot see what changed, what failed, or which systems are in scope. Teams should therefore prioritise the controls that improve operational awareness and make incident evidence easier to collect. That typically means strengthening event collection, defining escalation paths, and clarifying who can take action during an outage or security event.

Where a control uplift also affects response expectations, the useful question is not whether it is “advanced” but whether it measurably improves the organisation’s ability to detect, contain, and report. The readiness roadmap should therefore be tied to evidence that can be shown to auditors, operators, and management, not just to a technical aspiration.

For this stage, the EU NIS2 Directive is the primary reference for the obligation context, while the ENISA Threat Landscape helps teams understand why visibility and response readiness are so central in critical infrastructure.

Build policy alignment and response maturity after the basics are working

After the most important operational gaps are addressed, teams can align policies, standards, and incident procedures with the actual OT environment. This is where readiness becomes more durable: ownership is clearer, reporting triggers are documented, and security decisions stop depending on tribal knowledge. If the organisation starts with this layer too early, it often produces paper compliance without operational effect.

Policy alignment should reflect the real operating model, including change windows, vendor support arrangements, emergency access, and the practical limits of patching in OT. Response workflows should also be exercised against realistic scenarios, because NIS2 readiness is not only about having a plan, but about whether the plan can be executed under uptime and safety constraints. In other words, sequencing should move from understanding, to observing, to governing, then to optimising.

That is also where sector-specific guidance becomes useful. Teams that need OT-specific security baselines should anchor their implementation around the NIST SP 800-82 Rev 3 OT Security Guide, because it helps translate readiness into OT-aware security decisions rather than generic enterprise controls.

Risk and Threat Considerations

Low OT maturity creates a sequencing risk: teams can spend time implementing controls that look mature on paper while still leaving the most exposed paths, such as remote access, weak visibility, and weak recovery assumptions, largely unchanged. That is especially problematic in critical infrastructure, where disruption, containment, and reporting obligations can all become harder once an incident begins.

Failure mechanism: If the organisation cannot accurately inventory assets, observe normal behaviour, or rehearse response, it may mis-rank priorities and build around an incomplete operating picture. Attackers and operational failures both benefit from those blind spots, because unmonitored or poorly governed pathways are harder to detect, contain, and recover.

Impact: The result is slower incident detection, weaker evidence for reporting, and greater chance that a control investment fails to reduce the most material operational exposure. In a NIS2 context, that can leave the organisation with high effort and low assurance, which is the wrong outcome for a readiness programme.

Practitioner Guidance

What to prioritise: Start with the minimum set of capabilities that tells you what exists, what is exposed, and what would hurt most if it failed. If the environment is still largely unknown, do not let policy work outrun visibility work.

Decision rule: If a proposed control does not improve asset knowledge, event visibility, or incident execution in the first wave, defer it until the baseline and response gaps are better understood. If it does improve one of those three, move it up the queue.

What good looks like: A mature enough sequence produces a short, defensible roadmap: assessed baseline, highest-risk gaps ranked, monitoring and response improved first, then governance and optimisation layered on top.

Practitioner takeaway: In low-maturity OT environments, NIS2 readiness succeeds when teams sequence for operational truth first and control depth second, because the best compliance plan is the one built from an accurate picture of risk and response capability.

Related resources from NHI Mgmt Group

• Guide: NIS2 Directive Guide
• How should critical infrastructure teams implement microsegmentation around OT systems?
• How should teams use agentic AI for low-level engineering work?
• How should healthcare and critical infrastructure teams implement vulnerability disclosure programs under NIS2?
• What should critical infrastructure teams prioritise after OT protocol exploit activity is detected?