Governing a NIS2 Programme

Article 20 of NIS2 requires the management body to approve the organisation's cybersecurity risk management measures and oversee their implementation. The obligation is not satisfied by a point-in-time remediation exercise. The management body must be able to demonstrate that it approved the measures, received ongoing reporting on their implementation, and that the controls it approved are maintained and periodically reviewed after the programme closes.

Supervisory authorities have inspection and audit powers and may investigate at any point, not only following an incident. An organisation that has completed a compliance project but built no mechanism for maintaining what it produced, and no reporting structure to keep the management body informed, cannot demonstrate ongoing compliance in the way Article 20 requires. The programme's scope must account for what happens after it closes from the point it begins.

Five elements distinguish a governed programme from a compliance project.

Programme mandate

A formally documented mandate approved at management body level, establishing who holds programme authority, what decisions require management body approval, and what the governance forums are. Without it, the programme cannot make the decisions that arise across twelve to twenty-four months of delivery.

Gap register

An obligation-mapped gap register that connects every workstream deliverable to a specific NIS2 requirement in the applicable national transposition. The register is how the management body understands the compliance position at any point during delivery, and how it carries into BAU as the ongoing status record.

Target operating model

A design of the target compliance state, approved before delivery begins, that specifies what each control looks like when complete, who owns it in BAU, and how it is evidenced and reviewed. This is the standard the assurance phase measures against when the programme approaches close.

Named workstream ownership

Named leads and defined close conditions for each workstream across the full Article 21(2) obligation landscape. A workstream does not close until its deliverables are built, evidenced, and confirmed as ready for named BAU owners to sustain.

Closure and handover record

A formally documented closure record, including the incident notification tabletop exercise result and the programme closure report presented to the management body, with the sustained compliance owner confirmed in post before the programme stands down.

Four questions determine whether a programme brief will produce an adequate outcome. First, does a gap register exist that maps planned workstream outputs to specific NIS2 obligations in each relevant jurisdiction, or is the programme scoped to a generic framework? The gap register is the foundation on which every delivery decision rests.

Second, is the target operating model a named programme deliverable, scoped and resourced before delivery begins, or is it deferred to programme close? A model assembled under pressure at the end of a long programme will not receive the governance attention it requires.

Third, does each workstream have a named BAU owner confirmed before the workstream closes? Ownership that is not confirmed before handover is not ownership. Fourth, is the programme closure report to the management body a formal deliverable with defined approval conditions? A programme that closes without formal management body sign-off on the outcome has not completed.