Two years after the transposition deadline, the question we are asked has changed. It used to be "does NIS2 apply to us". It is now "we think it applies, what exactly are we supposed to have".
This article answers the second question for the company we see most often: between one hundred and five hundred people, one or two legal entities, an IT team of three to eight, no compliance function, and a board that has recently discovered it is personally accountable.
First, settle scope — properly
Scope is not a judgement call, and getting it wrong in either direction is expensive.
The test has three parts: your sector must appear in Annex I or Annex II of the directive, you must exceed the size threshold — broadly, fifty employees or ten million euros of turnover — and you must be established in the member state concerned. Entities in Annex I above the medium threshold are essential; most others in scope are important. The difference matters: essential entities face proactive supervision, important entities are supervised after the fact.
Two traps catch mid-size companies.
The first is group structure. NIS2 applies entity by entity, in the country of establishment, not group by group. A French parent and a Belgian subsidiary may have different classifications, different registration duties and different national rules, because each member state transposed the directive in its own words.
The second is being in scope through a customer rather than through your own sector. You may not be a regulated entity yourself, but if you are a managed service provider or supply software to one, the supply-chain requirements in Article 21 land on you through their contracts. Commercially, that is the same problem.
Settle this in writing, entity by entity, with the reasoning recorded. It takes two to four days and every subsequent decision depends on it.
Register with the national authority
Most transpositions require in-scope entities to register with the national CSIRT or competent authority, and to keep contact details current. This is administrative, it is quick, and it is the first thing a supervisor checks. Do it, and diarise the review.
The ten measures, in the order we build them
Article 21 lists ten categories of measure. They are written as a list, but they are not equally urgent, and building them in list order wastes a quarter. This is the sequence we use.
1. Incident handling, with the notification clock built in. Article 23 gives you twenty-four hours for an early warning, seventy-two hours for a notification with an initial assessment, and one month for the final report. Those windows are short enough that the procedure has to exist before the incident, with the decision thresholds agreed and the authority's contact details in the document. Build this first: it is the obligation most likely to be tested, and the one with the least room for improvisation.
2. Backup, recovery and crisis management. Immutable backups, an isolated copy, and a restore you have actually performed and timed. If you do only two things this year, make them the notification procedure and a tested restore.
3. Risk analysis and information system security policy. A documented risk assessment on your real business scenarios, and a policy set your teams can follow. This is the spine everything else hangs on, and the artefact a supervisor will ask to see first.
4. Supply chain security. Supplier tiering, security requirements proportionate to tier, and contractual clauses that give you notification and audit rights. Most mid-size companies have hundreds of suppliers and no tiering, which makes this feel impossible. It is not: the top twenty suppliers usually carry ninety per cent of the risk.
5. Basic cyber hygiene and training. Multi-factor authentication, patching, least privilege, and awareness training with a record of who attended. Unglamorous, high-yield, and directly evidenced.
6. Access control and asset management. You cannot protect an inventory you do not have. Joiner-mover-leaver that actually removes access, and privileged accounts held somewhere you can audit.
7. Security in acquisition, development and maintenance, including vulnerability handling and disclosure. If you build software, this is where NIS2 starts to look like the Cyber Resilience Act, and the two should be built once.
8. Cryptography and encryption policy. A stated position on what is encrypted, with what, and who holds the keys.
9. Human resources security, covering vetting proportionate to role, and the security steps in onboarding and offboarding.
10. Policies to assess effectiveness. Internal audit, testing, and management review — the loop that turns the other nine from a project into a system.
The obligation people forget: the management body
Article 20 is short and it is the one that changes behaviour. The management body must approve the cybersecurity measures, supervise their implementation, and can be held liable for failing to do so. Members are required to follow training, and are expected to offer similar training to staff.
In practice this means three artefacts: a record of the board approving the measures, a dated attendance record for director training, and a standing item on the board agenda with a reporting pack that a non-technical director can actually read. Produce those and you have covered the part of NIS2 that supervisors have been most willing to pursue.
What "in place" looks like on paper
If you want a single test of readiness, it is this: could you, within one working day, produce the following without writing anything new?
- The scope analysis and your registration record
- The risk assessment and the information security policy set
- The incident response procedure with the 24/72/one-month clocks
- Evidence of the last restore test, with the measured recovery time
- The supplier register with tiering and the security clauses for tier one
- Training records, including the management body
- The minutes recording board approval of the measures
- The last internal audit report and its corrective actions
That list is the deliverable. Everything else is the work of producing it.
Roughly what it costs
For a company of this size with nothing formal in place, a realistic first programme is eight to twelve weeks of external support alongside internal effort, in the range of eighteen to thirty-five thousand euros, ending with a defensible position and a plan for the rest. Companies with an existing ISO 27001 system usually need far less, because roughly seventy per cent of the evidence already exists under different headings.
What we would avoid is a two-year programme that delivers its first artefact in month seven. Supervisors, insurers and customers all ask the same question — show me what you have — and the answer needs to exist early, even if it is still improving.