NIS2 lists ten measure areas and makes management approve the result; Implementing Regulation 2024/2690 expects a named owner and a date for every risk treatment measure. The task list between adopting the framework and passing its audit is yours to derive. Three properties let it survive an audit date.
NIS2 lists ten measure areas and makes management approve the result; Implementing Regulation 2024/2690 expects a named owner and a date for every risk treatment measure. The task list between adopting the framework and passing its audit is yours to derive. Three properties let it survive an audit date.
The framework's adopted, the kickoff is done, and an audit date sits in someone's calendar. The next morning brings a very concrete question: what exactly gets done now, and who does each piece? The text you adopted the framework for won't answer it. NIS2 Art. 21(1) requires "appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems". That's one sentence that generates months of work and lists none of it. Between "we adopted the framework" and "we passed the audit" sits a worklist someone has to write, and there are three repeatable ways it goes wrong. All three are visible in the regulatory text itself, so that's where I want to start.
Let's read what Art. 21(2) actually lists. It frames the measures as an "all-hazards approach" that "shall include at least the following", and then gives ten points. Two of them in full. Point (b): "incident handling;". Point (d): "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;". The other eight have the same shape: policies on risk analysis, business continuity and crisis management, secure acquisition and development including vulnerability handling, effectiveness assessment, cyber hygiene and training, cryptography, HR security and access control and asset management, multi-factor authentication and secured communications. Each point is a heading over work the directive doesn't enumerate. And "at least" makes the list a floor, so even full coverage of the ten headings isn't automatically the whole job.
Art. 20(1) makes someone accountable for the gap between heading and work: "Member States shall ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation and can be held liable for infringements by the entities of that Article." Approval and oversight need an object. A management body can't meaningfully approve "incident handling"; it can approve a concrete set of measures with owners and dates.
The Commission got one level more specific in Implementing Regulation 2024/2690. Let's be honest about scope before we lean on it: under its Art. 1 it binds a specific roster of entity types (DNS service providers, TLD registries, cloud and data center providers, CDNs, managed and managed security service providers, marketplaces, search engines, social networks, trust services). For everyone else it functions as the Commission's concretization of what Art. 21(2) means in practice, and what it expects is planning vocabulary. Annex point 2.1.2(i) has entities "identify who is responsible for implementing the risk treatment measures and when they should be implemented". Point 2.1.4 has them "review and, where appropriate, update the risk assessment results and the risk treatment plan at planned intervals and at least annually". The phrase "at planned intervals" recurs across the Annex, from roles (1.2.6) to risk treatment (2.1.4) to security testing (6.5.3). Who, when, reviewed on a schedule: that's a worklist described in regulatory prose. One caveat, since NIS2 is a directive: obligations reach entities through national transposition, which member states were to adopt by 17 October 2024 (Art. 41(1)).
The tempting way to produce the list is a workshop. People who know the organization write down what needs doing, and the output looks reasonable. Here's my problem with it: its completeness is luck, because nothing connects the list to the obligations. A measure area nobody in the room thought about produces zero tasks, and no one notices, because absence is invisible on a list. The audit is where the gap surfaces, and the directive already names what follows: an entity that finds it does not comply with the Art. 21(2) measures "takes, without undue delay, all necessary, appropriate and proportionate corrective measures" (Art. 21(4)). Discovering enumeration gaps at the audit is the expensive version of enumeration.
The alternative is derivation: walk the adopted framework requirement by requirement and ask what work each one implies for your organization. This is mechanical enough that a regulator has done it in public. ENISA's Technical Implementation Guidance (June 2025) walks 2024/2690 point by point; per its own structure note, "Each requirement is followed by three elements: guidance, examples of evidence and tips". For Annex point 1.2.1, on assigning security responsibilities, the guidance includes "Assign security roles and responsibilities to personnel and include these roles in the organisational chart", and the evidence examples include "Job descriptions" and a "List of security roles, who occupies them and contact information". ENISA is explicit that the guidance is "not legally binding" and "non-exhaustive", so treat it as proof that the requirement-to-task mapping is derivable rather than as a list to copy. The property worth keeping: every task on your list should trace to the requirement it serves. Traceability is what turns "we did a lot of work" into "we covered the framework", and it's the difference an auditor can actually check.
The second failure is slower. The list is complete and every row has a name in the owner column. By the time the audit arrives, some of those people have changed teams or left. Tasks assigned to someone who's gone are orphans; the org chart changed and the list didn't. Nothing dramatic marks the moment it happens, which is why it goes uncaught.
The regulation's own vocabulary points at the fix. Annex point 1.2.1 of 2024/2690 has entities "lay down responsibilities and authorities for network and information system security and assign them to roles". The noun the regulation chooses is "roles". A role survives a resignation, and the review that point 1.2.6 expects — roles "reviewed and, where appropriate, updated by management bodies at planned intervals and when significant incidents or significant changes to operations or risks occur" — has a stable object to review. Ownership by role means "whose plate is this on?" has a current answer, namely whoever holds the role today, with no archaeology required. Assignment to a named individual still has a place: genuine one-offs, where the work belongs to a person rather than a function. The default is what matters, and I'd set it to roles every time. If the default is people, the list decays at the speed of your churn. If the default is roles, it decays only when the organization's design changes — and the 1.2.6 review is exactly the moment to catch that.
With a derived, role-owned list in hand, the audit date creates the third temptation: build a plan — a timeline spreadsheet, a slide with phases, a Gantt chart. I've come to think the second plan is the quietest failure of the three, because it looks like diligence while it happens. The moment the plan is a second artifact, it starts drifting: the work changes daily and the plan is updated at the pace of meetings. Tasks close late, new tasks appear out of a risk assessment, and the plan now describes a project that no longer exists. Reviews "at planned intervals" then get pointed at the artifact instead of the work, and they pass.
The plan that can't drift is a view: the same worklist, filtered and grouped by time. Planning backwards from the audit date then means exactly one thing: setting deadlines on the real tasks so the open work distributes across the window between now and the date. Two properties follow at no extra cost. Overdue becomes computable and shows up where the work lives, because the deadline sits on the task rather than in a parallel document. And progress needs no separate status report; you count the tasks.
That completes the tool-agnostic version. A worklist survives contact with an audit date when it has three properties:
Any issue tracker can hold this. So can a spreadsheet, if deadlines and owners live in the task rows and nowhere else.
Those three properties were the design brief for devguard's Tasks and Roadmap modules. Here's how we built them, and one behavior you should know about before relying on it.
Derivation is seeding: adopting a framework creates the tasks its templates describe, per organization. A task that serves a control is linked to that control from the moment it's created, so traceability is built in rather than left to a naming convention. Seeding the same framework twice never duplicates tasks; work that already exists is left alone. Every task moves through the same plain statuses — open, in progress, in review, done, or canceled.
Ownership follows the role-first argument: a task's owner is either a person or a business role, never both. We made that default deliberately — people don't own records; roles do. A task relates to at most one record: a policy, an evidence item, a risk, an asset, a vendor, or an audit.
The roadmap is the view in the strict sense: it stores nothing of its own beyond the target date you pick for the adoption, and everything it shows is read live from the tasks. That's why the roadmap owns nothing: a view can't drift from the work. Planning means picking a target date at least two weeks out; anything closer is refused. The open tasks are then spread from one week after planning to the target date, with each deadline landing on the Friday of its week, so the roadmap reads as weekly work batches. Progress is reported as counts, done versus open and open tasks past deadline, deliberately without an "on track" label.
The behavior you should know about is re-planning. A re-plan reschedules only the open seeded tasks. Done and canceled tasks keep their dates, and hand-created tasks are never touched. But the boundary cuts the other way too: a hand-set deadline on an open seeded task is not protected. A re-plan gives every open seeded task a fresh scheduled deadline, hand-set dates included. That's the trade we chose: the roadmap stays a pure function of target date plus open work, at the cost of not honoring manual date edits inside it.
One boundary is deliberate: tasks are human work. Scheduled creation of tickets in external systems lives in a separate Actions module.
Everything else is a view of it or an input into it: the risk assessment extends it (2.1.2(i)'s who-and-when becomes rows), the roadmap queries it, the status report counts it. Get the three properties right and the audit date turns into a set of deadlines on work you can already see. What happens after you pass is a different problem — keeping the state rather than reaching it — and that one has its own post: Audit-ready is a state you keep.
The seeding, assignment, and roadmap mechanics described above are devguard's Tasks module, part of devguard.ch/platform.
Angelo runs strategy and the relationships behind devguard. He spends his time with the teams who live with compliance day to day, and keeps what we build tied to what they actually need.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.