The Governance Foundations of a NIS2 Programme

Article 20 of NIS2 requires the management body to approve the organisation's cybersecurity risk management measures and oversee their implementation. Oversight is continuing, so a point-in-time remediation exercise cannot by itself satisfy it.

What follows from that is a matter of governance practice rather than statutory wording. Material changes to the measures should return to the management body for further approval. A management body that can produce dated approvals, a record of the reporting it received during delivery, and evidence that the approved controls are still maintained and reviewed after close is in a position to show how it discharged its approval and oversight responsibilities. One that cannot is relying on assertion.

Supervisory scrutiny is not confined to the moment a programme closes. It can arise through inspection, audit, an incident, or an indication of non-compliance, depending on whether the entity is classified as essential or important and on the applicable national law. 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, will struggle to show that oversight continued. The programme's scope must account for what happens after it closes from the point it begins.

Five elements make a programme governed rather than merely active.

Programme mandate

A formally documented mandate is 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

The gap register records what the assessment found against the obligations applying in each jurisdiction, each finding owned and tracked to closure. It is the source from which the management body receives a consolidated view of the compliance position, and it carries into business-as-usual operation as the ongoing status record.

Target operating model

The design of the target compliance state is approved before delivery begins, specifying what each control looks like when complete, who owns it afterwards, and how it is evidenced and reviewed. Cross-checked against the full set of applicable obligations, it also shows that none has been left without a named owner.

Named workstream ownership

Each workstream has a named lead and defined close conditions across the full range of Article 21(2) obligations. A workstream does not close until its deliverables are built, evidenced, and confirmed as ready for named permanent owners to sustain.

Closure and handover record

Closure is formally documented, covering the incident notification exercise result and the 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 records findings against the obligations applying 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 rarely receives the governance attention it requires.

Third, does each workstream have a named permanent 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? Without formal management body sign-off on the outcome, the governance record of the programme is left incomplete.