NIS2 for SMBs: a 90-day plan to start without freezing operations

NIS2 is not solved by buying a tool. For an SMB, real progress starts when the team knows which assets are critical, who owns them, and which evidence can be shown after an incident or audit.

This guide is not legal advice. It turns a broad obligation into an initial technical plan that a small team can execute without freezing the business.

Short answer

An SMB should start NIS2 with three deliverables: an asset inventory, a risk register, and a prioritized control plan. Then it should close basic controls around identity, backups, patching, incident response, and supplier management.

Initial prioritization

Week	Goal	Useful evidence	Risk reduced
1-2	Define scope and critical assets	Inventory of systems, domains, applications, and owners	Not knowing what to protect
3-4	Assess the main risks	Risk matrix with impact, probability, and owner	Prioritizing by intuition
5-6	Review identity and access	Privileged users, MFA, joiners and leavers	Account compromise
7-8	Validate backups and recovery	Documented restore test	Long operational outage
9-10	Review critical suppliers	List of third parties and processed data	Inherited third-party risk
11-12	Simulate an incident	Runbook, owners, and response times	Improvisation during a crisis

Recommended workflow

flowchart TD
  A[Asset inventory] --> B[Risk map]
  B --> C[Priority controls]
  C --> D[Remediation plan]
  D --> E[Evidence test]
  E --> F[Monthly review]
  F --> B

Controls that usually pay back first

Control	Why it matters	Pragmatic implementation
MFA on critical accounts	Reduces unauthorized access from leaked credentials	Start with email, admins, VPN, and cloud panels
Tested backups	An untested backup is an assumption	Run a partial restore every quarter
Patch management	Lowers exposure to known vulnerabilities	Monthly windows and justified exceptions
Supplier register	NIS2 looks at the supply chain	Classify third parties by criticality and data handled
Incident runbook	Prevents slow decisions during a crisis	One-page document with roles, contacts, and steps

The common mistake

The common mistake is starting with long documents before knowing which systems support the operation. Documentation matters, but it must come from technical reality: assets, data, permissions, logs, backups, and contracts.

A good first diagnosis answers:

1. Which systems cannot be down for more than one day.
2. Which accounts could cause the most damage if compromised.
3. Which suppliers have access to data or infrastructure.
4. Which evidence exists today and which evidence is missing.
5. Which measures reduce the most risk with the least disruption.

Progress indicators

Indicator	Good	Bad
Inventoried assets	Owner and criticality defined	Technical list with no owner
Risks	Prioritized by operational impact	Everything has the same priority
Evidence	Screenshots, logs, tests, and dates	Claims without proof
Incidents	Roles and timing defined	”Call IT”
Suppliers	Contracts and access reviewed	Nobody knows who can access what

Working sources

• Google Search Central recommends useful, original content with demonstrable experience. This article avoids promising a magic checklist and focuses on verifiable operational decisions.
• Security practices must be adapted to each company’s sector, size, systems, and concrete obligations.