NIS2 Project Plan: Work Breakdown Structure for 8 Compliance Workstreams

Most NIS2 “roadmaps” are calendars — a list of tasks stacked into 30, 60, or 90-day blocks. A calendar tells you what to do this week. It doesn’t tell you what happens if the risk assessment slips two weeks, which downstream tasks get blocked, who signs off on the resulting policy set, or how a supervisory authority auditor will read your evidence trail six months from now. Those are project-management questions, and NIS2 implementation is, structurally, a project: it has a scope, a fixed set of deliverables defined by Article 21, a board that owns accountability under Article 20, and dependencies that determine what can run in parallel and what can’t.

This article builds the plan the calendar leaves out: a Work Breakdown Structure (WBS) that groups the 10 Article 21 measures into 8 resourceable workstreams, effort estimates per workstream, a two-tier governance model — Steering Committee and Working Group — with distinct decision rights, and a critical-path map showing exactly which workstreams block which. If you need a day-by-day starting sequence for a small team, our 90-day SME roadmap covers that ground. This is the structure underneath it — the plan a project manager, CISO, or compliance officer would actually build in project-management software before assigning a single task.

Why a Task List Isn’t a Project Plan

A task list answers “what.” A project plan answers “who, in what order, with how much time, reporting to whom.” Three things separate the two, and NIS2 implementations that skip them are the ones that stall at month four with half-finished policies and no clear owner:

• A Work Breakdown Structure — the full scope broken into workstreams small enough to staff and estimate, each with a defined deliverable and owner. Without it, “do risk management” becomes one undifferentiated blob nobody can size.
• A critical path — which workstreams must finish before others can start. Article 21 doesn’t specify sequencing; that’s a project-management decision, and getting it wrong means rewriting policies after the technical controls that were supposed to implement them are already built.
• A governance charter — who approves scope changes, who accepts residual risk, and who signs the policies the board is accountable for under Article 20. A RACI chart on a slide is not a governance charter; a documented decision-rights table that survives an audit request is.

The rest of this article builds all three, in order.

Step 1: Define Scope and Mobilise Governance

Before any workstream starts, two things need to exist: a documented answer to “does NIS2 apply to us, and as an essential or important entity,” and a governance body with the authority to approve what follows. Skipping this step is the single most common reason NIS2 projects restart — teams build an information security policy, then discover six months later that a business unit was scoped incorrectly and the policy’s asset inventory is wrong.

Run a formal gap analysis before anything else: current security posture against the Article 21(2) baseline, documented as current-state → required-state → effort-to-close (Low / Medium / High) for each of the 10 measures. This becomes the input to the WBS effort estimates in the next section — organisations with an existing ISO 27001 programme close most gaps at Low-to-Medium effort; organisations starting from an informal security posture should expect High effort across most workstreams.

In parallel, mobilise governance. Article 20 requires the management body to approve the Article 21 measures, oversee their implementation, and accept that it can be held liable for the entity’s infringements — which means the board needs a formal seat in the project from day one, not a final sign-off at the end. Section 5 below builds the full Steering Committee / Working Group structure this requires.

The Work Breakdown Structure: 8 Compliance Workstreams

Article 21(2) lists 10 minimum measures, (a) through (j). Treating each as a standalone project task creates 10 disconnected workstreams with overlapping owners and duplicated policy documents — access control and MFA end up as two separate “IT projects” run by two different people who don’t talk to each other. Grouped by the skill set and deliverable type they actually share, the 10 measures compress into 8 workstreams a project manager can staff, size, and sequence:

WBS #	Workstream	Article 21(2) measures covered	Primary deliverable
WS1	Governance & Program Mobilisation	Article 20 (board approval & oversight)	Project charter, Steering Committee/Working Group terms of reference
WS2	Risk Analysis & Security Policy	(a) risk analysis and information system security policies	Risk register, information security policy, risk treatment plan
WS3	Access & Identity Controls	(h) cryptography/encryption, (i) HR security/access control/asset management, (j) MFA/continuous authentication/secured comms	Access control policy, MFA rollout, asset register, encryption standard
WS4	Secure Development & Vulnerability Management	(e) acquisition, development and maintenance security, incl. vulnerability handling and disclosure	Secure SDLC policy, vulnerability management procedure, patch cadence
WS5	Incident Handling & Notification	(b) incident handling	Incident response plan, 24h/72h/1-month notification workflow
WS6	Business Continuity & Crisis Management	(c) business continuity, backup management, disaster recovery, crisis management	BCP, backup/DR procedure, crisis management plan
WS7	Supply Chain Security	(d) supply chain security incl. direct-supplier vulnerabilities	Supplier classification, security clauses, supplier assessment process
WS8	Training, Effectiveness Assessment & Documentation	(g) cyber hygiene and training, (f) effectiveness-assessment policies and procedures	Training programme, KPI/measurement methodology, audit-evidence file

Each measure in Article 21(2) lands in exactly one workstream — nothing is dropped, nothing is duplicated across two owners. WS5 also carries the Article 23 notification clock once an incident is declared: a 24-hour early warning, a 72-hour incident notification with an initial severity assessment, and a full report within one month of the notification — build that workflow once, inside WS5, rather than bolting it onto the incident-handling policy as an afterthought.

Workstream Effort Estimates and Staffing

Public “hours to comply” figures circulating in NIS2 commentary are mostly unsourced — several widely-shared numbers trace back to blog posts that cite no underlying survey. Rather than repeat an unverifiable statistic, the table below is a practical heuristic built from how these 8 workstreams typically staff in a mid-market organisation (roughly 250–1,500 employees) with no prior formal information security programme. Treat it as a starting planning range, not a guarantee — an organisation with an existing ISO 27001 certification will land at the low end of every row; one starting from zero documented security policy will land at the high end or beyond.

Workstream	Effort level	Typical range (person-hours)	Primary owner
WS1 Governance & Mobilisation	Low	20–40	Compliance Officer / Project Manager
WS2 Risk Analysis & Policy	High	120–200	CISO / Risk Manager
WS3 Access & Identity Controls	High	150–250	IT Security Manager
WS4 Secure Development & Vulnerability Mgmt	Medium	80–140	IT/DevOps Lead
WS5 Incident Handling & Notification	Medium	60–100	CISO / SOC Lead
WS6 Business Continuity & Crisis Mgmt	Medium	70–120	Operations Manager
WS7 Supply Chain Security	Medium	60–100	Procurement / Legal
WS8 Training, Assessment & Documentation	Low–Medium	40–80	Compliance Officer / HR

Summed, that’s roughly 600–1,030 person-hours across a first-year programme for a mid-market entity with no existing security programme — spread across several roles working part-time on the project, not a single full-time headcount. Organisations in higher-risk sectors, or those bringing in outside legal review of supplier contracts, should budget above this range; the figures compress significantly for entities that already run an ISO 27001 information security management system, since WS2, WS3, and WS6 largely become mapping exercises rather than ground-up builds.

Governance Structure: Steering Committee vs Working Group

Article 20 puts the board on the hook — it must approve the Article 21 measures and oversee their implementation, and its members must complete training in identifying and assessing cybersecurity risk. That obligation only functions if the project has a governance layer built to actually reach the board with decisions, rather than an operational team quietly building policies the board rubber-stamps unread three days before a deadline. Two bodies, with different composition, cadence, and authority, make that work:

	Steering Committee	Working Group
Composition	Board sponsor, CISO, Legal/Compliance lead, Finance, one business-unit director	Workstream owners (WS1–WS8 leads), IT/security analysts, Compliance Officer
Cadence	Monthly (or on-escalation)	Weekly or bi-weekly
Decision rights	Budget approval, residual-risk acceptance, final policy sign-off, scope changes	Task-level execution, workstream sequencing within approved scope, escalation to Steering Committee
Article 20 role	Fulfils the management body’s approval and oversight obligation directly	Produces the evidence and drafts the Steering Committee approves

Pair that with a role-responsibility table across the 8 workstreams, so no single person is silently accountable for a deliverable they were never told they owned:

Workstream	Responsible	Accountable	Consulted	Informed
WS1–WS8 (all)	Workstream lead	CISO / Compliance Officer	Legal, Steering Committee	Board (via Steering Committee minutes)
WS2 Risk & Policy, WS6 BCP	Risk Manager	CISO	Business-unit directors	Steering Committee
WS3 Access Controls, WS4 Secure Dev	IT Security Manager	CISO	IT/DevOps leads	Working Group
WS7 Supply Chain	Procurement lead	Legal/Compliance	Supplier account managers	Steering Committee

The Steering Committee is where Article 20 liability actually gets discharged — a board that never sees a risk-acceptance decision before it’s made can’t meaningfully be said to have overseen it, whatever the meeting minutes claim after the fact.

The Critical Path: What Blocks What

Not all 8 workstreams can start on day one, and treating them as independent parallel tracks is the second most common cause of rework after skipping the scope step. Four workstreams sit on the critical path — each one gates the next — while the remaining four can run in parallel once the risk baseline exists:

Sequence	Workstream	Why it blocks the next step
1	WS1 Governance & Scope	Nothing downstream has a valid deliverable owner or budget until this closes
2	WS2 Risk Analysis	Policies written before the risk register exists get rewritten once real risks surface
3	WS3/WS4 Policy → Technical Controls	Access control and secure-development policies define what the technical build must implement — building controls first means retrofitting them to match policy later
4	WS8 Effectiveness Assessment & Testing	You can’t measure whether a control works until it exists — this workstream closes the loop and produces the audit-evidence file

WS5 (Incident Handling), WS6 (Business Continuity), and WS7 (Supply Chain) don’t depend on the technical build finishing — they can start as soon as WS2’s risk register exists and run in parallel with WS3/WS4, provided they share the same risk register as their input. The practical rule: scope and risk analysis are always sequential and always first; everything that consumes the risk register can fan out in parallel; testing and effectiveness assessment always come last, because there’s nothing to test until the earlier workstreams have produced something.

If you’re tracking this in standard project-management software (a Gantt chart, a Kanban board with dependency links, or even a shared spreadsheet with start/finish columns), model WS1 → WS2 → {WS3, WS4} → WS8 as the critical-path chain and WS5, WS6, WS7 as parallel tracks feeding into WS8 for their own effectiveness checks. The total programme length is set by the critical-path chain, not by the sum of all 8 workstreams’ individual effort — that’s the whole point of identifying which four actually gate the finish date.

Documentation and Audit-Evidence Checklist

A national competent authority reviewing your NIS2 file isn’t looking for good intentions — it’s looking for a paper trail. Germany’s BSI, for instance, runs its own phased approach to NIS2 oversight (analysis, organisation, current-state assessment, resource planning, core-measures implementation, continuous improvement) and expects entities to produce evidence at each stage, not just a finished policy binder at the end. Build the evidence file as the project runs, not retroactively:

• Steering Committee minutes documenting Article 21 measure approval and any residual-risk acceptance decisions
• Management-body training records (mandatory under Article 20 — track attendance, not just scheduling)
• Risk register with dated versions, showing the assessment methodology and treatment decisions
• Signed and version-controlled policies for each of the 8 workstreams, with review dates
• Supplier security assessments and contractual clauses (WS7), not just a supplier list
• Incident log, including any early-warning/notification/final-report submissions under Article 23
• Training completion records and the effectiveness-assessment methodology and results (WS8)

This checklist maps directly to the RACI table in the previous section — each item has a named Accountable role, which is what turns a folder of documents into evidence a supervisory authority will accept. Version and date every document rather than treating the “final” version as the only one worth keeping; auditors frequently ask how a policy evolved over the programme, not just what it says today, and a WS2 risk register with only one dated snapshot reads as a box-ticking exercise rather than a live risk-management process.

Common Project-Planning Mistakes

Three failure patterns show up repeatedly across NIS2 implementations that stall, based on how the workstreams above interact in practice:

• Treating WS3 and WS4 as parallel tracks from day one. Both depend on WS2’s risk register and the policies it produces. Starting technical builds before the policy that defines requirements exists means rebuilding access controls once the real policy lands.
• Letting the Steering Committee run the project. Its job is monthly decision-making, not weekly task tracking — a Steering Committee that meets weekly to review task lists burns board time and slows the Working Group down waiting for sign-offs it doesn’t need yet.
• Building documentation as a final step instead of a running output. WS8’s audit-evidence file should accumulate from WS1 onward. Assembling it retroactively in the final month is where most evidence gaps — missing training records, undated risk registers — actually originate.

Frequently Asked Questions

What is a NIS2 project plan, specifically?
It’s the combination of a Work Breakdown Structure (the 8 workstreams above), a governance charter defining who approves what, and a critical-path sequence showing which workstreams must finish before others start. A checklist of the 10 Article 21 measures is not, by itself, a project plan — it has no owners, no sequencing, and no decision-rights structure.

How long does a full NIS2 implementation take?
Most mid-market organisations run the 8 workstreams over 6–12 months, driven primarily by how long WS2 (risk analysis) and WS3 (access controls) take to close, since both sit on the critical path and both scale with organisational complexity rather than headcount.

Who should own the project — the CISO or a dedicated compliance officer?
Either can hold the Accountable role for the overall programme, but the RACI table needs a named individual either way. Organisations without a CISO should not leave WS2/WS3 ownership informal — assign a Risk Manager or IT Security Manager explicitly, even if that person also holds another title.

Do small organisations really need a formal WBS?
The scale changes, not the structure. A 40-person essential entity still has 8 workstreams and a critical path — it just staffs each one with fewer hours and may combine several Responsible roles into one person. Skipping the structure to save time is what produces the rework described above, regardless of headcount.

What’s the practical difference between the Steering Committee and Working Group?
The Steering Committee approves and accepts risk — it’s where Article 20 accountability lives. The Working Group executes and escalates. If your project only has one meeting series covering both, board-level decisions and weekly task updates compete for the same limited time, and one of them loses.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• Directive (EU) 2022/2555 (NIS2 Directive) — EUR-Lex, Official Journal of the European Union
• NIS2 Directive, Article 20 — Governance — nis-2-directive.com
• NIS2 Directive, Article 21 — Cybersecurity risk-management measures — nis-2-directive.com
• NIS2 Directive, Article 23 — Reporting obligations — nis-2-directive.com
• European Commission — NIS2 Directive policy overview, Shaping Europe’s Digital Future
• Bundesamt für Sicherheit in der Informationstechnik (BSI) — NIS-2-regulierte Unternehmen, Germany’s national competent authority