NIS2 requires some SMEs to implement proportionate cybersecurity measures and to be ready to report “significant” incidents within a 24-hour and 72-hour regime. You can get this done in 90 days if you treat it like a project: scope, risks, technical minimum, procedures, and evidence.
Does your company even fall under NIS2, and what does that mean for SMEs?
NIS2 isn’t “for everyone.” It applies to entities in specific sectors and services (including energy, transport, healthcare, banking, digital infrastructure, ICT service providers, and parts of manufacturing), and then splits them into “essential” and “important” entities. Every case has to pass through two filters: sector, and size and role in the supply chain.
In practice, this means three things for an SME:
- you must be able to prove that the board consciously oversees cybersecurity (this is part of the requirements),
- you implement technical and organizational measures “proportionate to the risk,”
- you have an incident reporting process and a customer communication process for incidents that could harm them.
What are the hard deadlines, and what’s fixed vs. what depends on Polish legislation?
The EU-level certainty: NIS2 is a directive, so member states transpose it into national law, and the transposition deadline was October 2024.
The practical certainty: the obligations companies trip over most often are described in the directive itself and are stable — the required areas of security measures (Article 21) and the incident reporting deadlines (Article 23). (EUR-Lex)
The Polish context (important, because this will be “your” inspection): the government adopted a draft amendment to the KSC Act on 21 October 2025 and sent it to the Sejm (parliament) on 7 November 2025. The announcement also cited the scale of reports to CSIRT NASK: over 39,000 (2022), over 75,000 (2023), and over 103,000 (2024). That’s good ammunition for a conversation with the board about risk and budget. (Gov.pl)
What does a 90-day NIS2 rollout plan look like, week by week?
Below is a “minimum compliance + maximum sense” plan. This isn’t paperwork for its own sake. It’s a plan that genuinely lowers your risk of ransomware, data leaks, and downtime.
Days 1-7: Set the scope, owners, and system map
Goal: know what you’re protecting and who’s responsible for it.
- Appoint a NIS2 owner (ideally an IT Security Lead) and a board-level sponsor.
- Build an inventory: critical systems, data, vendors, integrations, remote access points.
- Define service classes: what’s “critical” (e.g., production, order processing, financial systems).
- Create a simple data flow and dependency map (who depends on whom, including in the cloud).
Evidence by the end of the week: an asset list + a list of critical services + system owners.
Internal link (semantically relevant): “Identity and access management: from MFA to passwordless.”
Days 8-14: Risk assessment and a decision on the “proportionate minimum”
Goal: choose measures that match your risk and budget, as Article 21 requires.
- Run a risk workshop (2 hours). Threat list: ransomware, BEC, data leaks, vendor outage, compromise of privileged accounts.
- Set priorities: top 5 scenarios + a risk-reduction plan.
- Board sign-off: not technicalities, just decisions about risk and priorities.
Evidence: a risk register + a board approval record.
Days 15-30: Quick technical wins that make a difference
Goal: close the most common gaps without a “grand revolution.”
The minimum that most often saves an SME’s skin:
- MFA everywhere possible: email, VPN, cloud consoles, financial systems, remote-access tools.
- Privileged access: separate admin accounts, least-privilege principle, a review of group memberships.
- 3-2-1 backup with a restore test (not just backups — proof they actually work). Article 21 explicitly covers business continuity, backups, and DR.
- Updates and vulnerabilities: a steady patching rhythm, critical CVEs first, a simple exceptions policy.
- Logs: collect at least the minimum needed for incident analysis (AD, M365/Google, firewall, VPN, EDR). Without logs, you don’t know what happened.
Evidence: screenshots or exports of MFA settings, a restore test report, a list of admin accounts and policies, confirmation of log retention.
Internal link: “Preparing your company for ransomware in 2026.”
Days 31-60: Processes, procedures, and training — what auditors like most
Goal: build repeatability.
- Incident handling procedure: triage, escalation, isolation, communication, board decisions.
- Playbooks: ransomware, data leak, email compromise, cloud provider outage.
- Training: the board is required to “get up to speed” on the topic and complete training, and the organization should train employees regularly.
- Effectiveness review of your measures: set KPIs, e.g., time to roll out critical patches, MFA coverage rate, incident detection time.
Evidence: procedures + a training log + tabletop exercise records (incident simulation).
Days 61-90: Supply chain, testing, and reporting readiness
Goal: close out the requirements that usually only surface after an incident.
- Vendors: assess critical vendors, require minimum safeguards, and set up an alert channel. Article 21 explicitly addresses supply chain security.
- Testing: a vulnerability scan, a basic pentest, or a configuration review of key systems.
- Monitoring: set up alerts and an on-call rotation, even a “business” one, so the 24-hour reporting window is actually achievable.
- Final review: an internal audit — “do we have the evidence.”
Evidence: a vendor register + security requirements + test reports + incident reporting instructions.
Internal link: “Zero Trust for a small company: a step-by-step rollout.”
How do you set up the incident reporting process in practice?
Under NIS2, deadlines are key. The minimal framework looks like this:
- within 24 hours of “becoming aware of a significant incident,” you send an early warning,
- within 72 hours, you submit an incident notification with an initial impact assessment and indicators of compromise, if available,
- then a final report on a set schedule (NIS2 requires a final report no later than one month after the notification).
How to implement this in an SME without over-engineering it:
- Define “significant incident” for your company’s own purposes (thresholds: downtime, data loss, customer impact, cost).
- Create one “Incident One Pager”: who to call, what to collect, who approves communications.
- Run a 60-minute simulation once a quarter. This usually surfaces gaps you’d never see on paper.
Which technical minimum delivers the biggest impact?
NIS2 explicitly lists the areas: incident handling, business continuity, supply chain security, cryptography, access control and asset management, MFA, and training.
If I had to name the “top 6” for SMEs, based on 15 years of hands-on experience:
- MFA on everything remote and administrative,
- backups with a restore test,
- segmentation and limiting lateral movement,
- EDR, or at least a sensible AV plus hardening policies,
- centralized logging of the most important sources,
- control over privileged accounts.
Why? Because in real incidents, SMEs lose not for lack of “super technology,” but for lack of the basics that stop the spread and shorten detection time.
How do you avoid the typical SME mistakes with NIS2?
The most common slip-ups:
- “We have a policy, so we’re compliant” — with no proof of implementation.
- Backups with no restore test.
- MFA only on email, while remote desktop and admin panels go unprotected.
- No owner and no board decision, even though NIS2 requires governance and management training.
- Critical vendors with no security requirements, even though the directive puts real emphasis on the supply chain.
When is it worth bringing in a SOC, an audit, or hardening?
If you have:
- critical services running 24/7,
- a small IT team with no on-call coverage,
- a hybrid environment (cloud + on-prem),
- pressure to report incidents quickly,
then monitoring and response stop being optional and become a practical condition for meeting the time-based requirements.
In your blog content you can frame this neutrally, without a hard sell: “If you want to verify your configuration, build monitoring, or run hardening, do it with a team that can deliver evidence and procedures, not just ‘set up a tool.'”
Summary: your evidence set at the end of 90 days
If after 90 days you have:
- an inventory of assets and critical services,
- a risk register and board decisions,
- MFA, tested backups, basic logging,
- an incident procedure and a tabletop exercise,
- vendor rules,
then you’re at the point where NIS2 stops being a “scare word” and becomes a normal risk management system.