NIS2 for EU SMBs: the technical readiness checklist, not the legal one

Most NIS2 writing is lawyers explaining the directive to other lawyers. This is the other half — what your IT actually has to look like, as an engineer would check it. NIS2's national transposition deadline was 17 October 2024, member states are now enforcing (unevenly, and with real infringement pressure from Brussels), and the questions arriving from clients are no longer "what is NIS2" but "we've been told we're in scope — what do we fix, and in what order." Here is that order. It is not legal advice; it is the technical baseline we implement.

First: are you actually in scope?

Do not spend a euro until you know. NIS2 covers "essential" and "important" entities in a list of sectors (energy, transport, banking, health, digital infrastructure, ICT service management, public administration, postal, waste, food, manufacturing of certain products, digital providers, and more), generally at medium size and above — broadly from 50 staff or €10M turnover, with some entities in scope regardless of size. Two traps for SMBs: you can be pulled in as a supplier to an in-scope entity even if you are small (supply-chain security is an explicit NIS2 duty), and because it is a *directive*, the exact thresholds and sector scoping are set by your country's transposition — so confirm against the national law, not the EU text. If you are genuinely out of scope, the measures below are still good hygiene; they are just not yet mandatory.

The baseline measures, as technical work

NIS2's Article 21 lists risk-management measures in legal language. Translated into what we actually configure:

• •Multi-factor authentication, everywhere that matters. MFA on email, VPN/remote access, admin accounts, and cloud consoles is the single highest-leverage control and the first thing an auditor or insurer checks. Phishing-resistant MFA where you can.
• •Logging and detection you can query. Centralised logs from servers, firewalls and identity, retained long enough to investigate, with alerting on the events that matter. "We have logs somewhere" is not detection.
• •Patch and vulnerability management with a clock. A known inventory, a feed for the CVEs that affect it, and a defined window to act — on your schedule, not the incident's.
• •Backups that survive an attacker — offline or immutable copies, and a restore you have actually tested. This is its own discipline; we wrote the ransomware-proof backup design separately because it is where "compliance" meets "the business survives."
• •Network segmentation. Flat networks turn one compromised laptop into a company-wide incident; segment users, servers, management and guests so a breach is contained.
• •Access control and least privilege. No shared admin accounts, no standing domain-admin rights, offboarding that actually removes access — the same gaps our Active Directory audits keep finding.
• •Supplier and supply-chain security. Know which vendors touch your systems and hold them to the same bar — the clause that is pulling smaller IT firms into scope through their clients.
• •Cryptography and secure configuration. TLS everywhere, encryption of sensitive data at rest, and hardened baselines rather than vendor defaults.

The part with legal teeth: incident reporting and accountability

Two NIS2 obligations change how you operate, not just what you own:

• •Incident reporting on a tight clock. For a significant incident the timeline is fast — an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month — to your national CSIRT/authority. You cannot hit those windows without the detection and logging above already in place; the reporting duty is what makes them non-optional.
• •Management is personally accountable. NIS2 puts responsibility on senior management, who must approve the risk measures and can be held liable. In practice this is what unlocks the budget — the board now owns the risk, so "we'll do it next year" is a decision someone signs for.

How to actually get ready

The order that works: scope (confirm in-scope status against your national law), gap-assess against the measures above, fix the high-leverage basics first (MFA, backups with a tested restore, logging, patching — these close most of the real risk and all of the easy audit findings), then write the thin layer of process NIS2 also wants (an incident-response plan with the reporting timers, an asset and supplier inventory, and management sign-off). Do not start with a 90-page policy; start with MFA and a restore test, then document what you did.

What we do

We run NIS2 readiness the engineering way: a gap assessment against the technical measures, then the actual implementation — MFA rollout, centralised logging and monitoring, managed firewall and segmentation, patch management, and immutable backups with tested restores — plus the incident-response plan that makes the 24/72-hour clock survivable. We are not a law firm and will not sell you a policy binder; we make the infrastructure match what the directive requires and what an attacker will actually test. If you have been told you are in scope, start with the gap assessment — it turns a vague obligation into a short, prioritised list of fixes.