NIS2 readiness for SMEs: operational readiness, not panic

For most SMEs, NIS2 readiness means putting a small, repeatable cybersecurity management system in place: assign owners, document key controls, rehearse incident reporting, and retain evidence. Start with scope and governance, then implement and prove the basics before optimising continuously.

Table of contents

Executive summary
NIS2 in plain English
Are you in scope? A practical scoping checklist for SMEs
Operational readiness, not paperwork
The first month: an evidence-first readiness plan
Evidence to retain (what reviewers ask for)
Incident reporting readiness (Article 23 without drama)
Common pitfalls that create panic
Conclusion
Frequently Asked Questions (FAQs)
External Resources

Executive summary

What it is: NIS2 (Directive (EU) 2022/2555) is a European Union (EU) cybersecurity directive that requires certain organisations to manage cyber risk and report significant incidents, implemented through national law.
Who should care: An SME (small and medium-sized enterprise) in an NIS2 sector, or an SME supplying NIS2-regulated customers, often needs a defensible, evidence-backed security baseline that stands up in reviews.
First month: confirm scope, assign accountable owners, set a minimum control set (risk, access, backup, logging, vulnerability handling), and write an incident reporting playbook.
Evidence to retain: keep an owned policy set, a control-to-evidence mapping, and a short evidence checklist that can be collected continuously without heavy tooling.
Common pitfalls: treating NIS2 as paperwork, ignoring supplier and incident workflows, and leaving ownership undefined until the week before a review.
What “ready” looks like: security measures can be explained, ownership is clear, and recent evidence can be produced quickly when asked.

An SME is operationally NIS2-ready when responsibilities are assigned, key measures are running in practice, incident reporting is rehearsed, and evidence can be produced quickly on request.

NIS2 in plain English

NIS2 is not a single compliance checklist. It is a directive. That means it sets outcomes and obligations at European Union (EU) level. Each Member State implements it through national law, regulators, and guidance. The details that matter day to day, such as who receives notifications, how registration works, and how supervision is carried out, are country-specific. The legal text and the European Commission overview are listed in the External Resources section as an authoritative reference.

Directive vs national law: why details differ by country

Operational readiness starts by separating what is stable across the EU from what changes by country. The stable part is the set of themes: governance accountability, cybersecurity risk-management measures, incident reporting, and oversight. The variable part is national implementation. That includes which competent authority supervises a given entity type and what reporting route is used. An SME operating in Denmark should track the official implementation status and points of contact, then confirm obligations in national law and guidance for its category and sector.

At a high level, NIS2 expects covered organisations to run cybersecurity as an operational discipline. That starts with deciding who is accountable. It also covers selecting and operating appropriate controls, managing third-party and supply chain risk, preparing to detect and respond to incidents, and producing evidence that these measures are in place. NIS2 also places explicit responsibility on the management body for approving and overseeing cybersecurity risk-management measures. An SME can turn those expectations into a manageable programme by focusing on ownership, a small repeatable control set, and an evidence routine that proves the controls are operating.

Are you in scope? A practical scoping checklist for SMEs

Many SMEs feel pressure around NIS2 without knowing whether the organisation is directly in scope, indirectly affected through customers, or simply using NIS2 as a benchmark. The fastest way to reduce uncertainty is to run a short scoping exercise and retain a brief record of the decision. That record becomes part of the evidence pack if a regulator, customer, or auditor asks why the organisation chose a given approach.

Sector and size basics, without guesswork

NIS2 identifies sectors and entity types in annexes and categorises entities as essential or important. In practice, SMEs should avoid assumptions based on headlines. A more reliable approach is to document the key facts: the services the organisation provides, the sector mapping that appears most relevant, and the country of establishment for supervision purposes. The organisation should validate this against national guidance and, where needed, legal counsel. The directive itself is the authoritative starting point for sector definitions and entity categories. National law determines how the directive is applied locally.

Audit-first tip: The scoping output does not need to be long. A short memo is enough if it states what was reviewed, who approved the conclusion, what sources were used, and what triggers a revisit, such as a major service change, acquisition, or move into a new sector.

Indirect pressure: when customers flow NIS2 requirements down the supply chain

Even when an SME is not directly supervised under NIS2, customers that are supervised may push similar controls down the supply chain. This often appears as security questionnaires, contract clauses, or requests for evidence such as policies, risk assessments, and incident response procedures. The practical response is the same: implement a small set of controls that are actually operated, and retain evidence. The difference is that the judge is a customer assurance process rather than a regulator.

In Denmark and the Nordics, a common pattern is that an SME supplying ICT services, cloud services, hosting, or operational technology into regulated sectors may be asked to demonstrate mature security management. A calm approach is to treat this as resilience work and build a repeatable evidence routine that can satisfy both customer reviews and potential regulatory expectations.

Operational readiness, not paperwork

NIS2 readiness is often framed as compliance. For an SME, the safer framing is operational readiness. The organisation can keep services running, limit the blast radius of incidents, and respond in an orderly way when something goes wrong. Documents matter, but only as a way to define ownership, standardise how work is done, and prove that it is being done.

Article 21 risk-management measures: the practical themes

Article 21 of the directive sets out cybersecurity risk-management measures and related policy areas. The full list is in the directive. For SME operations, these measures usually group into a small set of themes that can be owned and evidenced:

Governance and risk management: a simple risk process, clear accountabilities, and management oversight.
Asset and access control: knowing what matters, limiting access, and reviewing privileges.
Vulnerability and change management: how vulnerabilities are identified, prioritised, fixed, and verified.
Detection and response: logging, monitoring, triage, and a clear incident playbook.
Business continuity: backups, recovery tests, and continuity planning for critical services.
Supplier and supply chain security: expectations, assurance, and response when a supplier fails.

For certain categories of digital infrastructure and ICT service management entities, Commission Implementing Regulation (EU) 2024/2690 adds more detailed technical and methodological requirements. It also further specifies cases in which an incident is considered significant for those entity types. ENISA, the EU Agency for Cybersecurity, provides technical implementation guidance with practical advice and evidence examples. These sources help turn high-level themes into tasks that can be scheduled and checked.

Turning measures into owned, repeatable activities. An SME often stumbles on NIS2 readiness for a couple of reasons. Either the organisation writes policies that do not reflect reality, or the organisation has good technical practices but cannot prove them. The antidote is to convert each policy area into an operating rhythm. That means a named owner, a cadence, and a short set of evidence artefacts that are naturally produced by doing the work.

For example, vulnerability handling becomes a cadence for identifying, prioritising, and remediating vulnerabilities, with a ticket trail and verification notes. Access control becomes a joiner-mover-leaver process. That means how access is granted, changed, and removed, with approvals and periodic access reviews. Incident handling becomes a playbook plus a record of exercises or post-incident reviews.

Where documentation is created or updated, an organisation should avoid aspirational language. A policy should describe what the organisation does now, or state clearly what is planned and how progress will be shown. This reduces audit friction and reduces operational confusion.

The first month: an evidence-first readiness plan

This plan is designed for an SME that needs fast operational traction. It assumes limited specialist bandwidth. It prioritises actions that create real risk reduction and clean evidence. It is described as phases rather than a rigid calendar because national implementation, scope, and current maturity will differ.

Phase one: governance, gap scan, and minimum controls

Decide scope and accountability. The organisation should document whether it is in scope, in which category, and what authority is relevant. Then it should assign a senior accountable owner and a day-to-day operational owner for cybersecurity risk management. Evidence to retain includes the scoping memo, a named ownership matrix, and management approval.

Run a rapid gap scan. The goal is not a perfect assessment. It is a list of gaps that are clear enough to act on. A simple approach is to map current practices to the Article 21 themes and record current state, gaps, and next action. Evidence to retain includes the gap scan worksheet and the decision log for priorities.

Set a minimum control set. In practice this means a basic risk process, access and identity hygiene, backups and recovery checks, logging for critical systems, and a vulnerability handling process. The organisation should ensure that each control has an owner and produces evidence as part of normal work.

When the organisation needs structured delivery and quality control for documentation, a defined workflow and QA routine can keep policies, procedures, and mappings consistent. Accel Comply documents an example delivery and QA approach on the Process and QA page.

Phase two: evidence routine, incident playbook, and sign-off. Evidence should not be a quarterly scramble. An SME should decide what evidence is collected automatically, what is collected by process, and what needs a lightweight manual check. The outcome is a short evidence checklist tied to control owners, with a simple storage location and naming convention.

Article 23 of the directive sets staged incident reporting obligations and expectations for communication, including an early warning within 24 hours, an incident notification within 72 hours, and a final report not later than one month after the incident notification. The exact recipient and process will be defined nationally. Operationally, an SME should define what counts as an incident, who decides whether it is significant, who communicates with authorities and customers, and what information is captured during the event. Evidence to retain includes the playbook, contact lists, escalation paths, and records of rehearsal exercises.

Management oversight is a recurring theme in NIS2. A practical step is to schedule a short management review, approve the scoped control set, and commit to the operating rhythm. Evidence to retain includes meeting minutes, approvals, and a communication record to staff and relevant stakeholders.

For teams that want to see what audit-ready artefacts look like, the Inspectable samples page provides examples of formats and structures. For an overview of how a structured engagement can be run remotely, the How it works page provides the typical steps.

Evidence to retain (what reviewers ask for)

Audits and regulatory reviews rarely fail because a policy document is missing a paragraph. They fail because ownership is unclear, controls are not operating, or evidence is inconsistent. A minimum evidence pack for SMEs should be built around a small set of questions: what was decided, what is being done, and how it is proven.

A minimum evidence pack SMEs can maintain without theatre

Scoping decision memo: entity category, services considered, sources reviewed, approval, and review trigger.
Governance artefacts: ownership matrix, management approvals, and periodic management review notes.
Risk artefacts: a simple risk register and records of risk treatment decisions for key risks.
Control set documents: core policies and procedures, written in current-state language.
Access control evidence: joiner-mover-leaver records, privileged access approvals, and access review outputs.
Vulnerability handling evidence: scan or advisory inputs, prioritisation decisions, remediation tickets, and verification notes.
Backup and recovery evidence: backup configuration summary and recovery test records for critical systems.
Logging and monitoring evidence: logging scope for critical systems and triage records for security events.
Supplier evidence: supplier inventory, due diligence checks for key suppliers, and contract or policy expectations.
Incident readiness evidence: playbook, contacts, escalation paths, and exercise notes or post-incident reviews.

Keep it inspectable. Evidence should be easy to locate and easy to interpret. A simple folder structure, clear file naming, and a short mapping from NIS2 themes to artefacts can save significant time during reviews.

Keep it truthful. If a control is not yet implemented, the evidence pack should show the plan and the current status. Reviewers tend to respond better to clarity than to optimistic statements that do not match operating reality.

Incident reporting readiness (Article 23 without drama)

Incident reporting is where panic tends to spike. The directive expects prompt staged reporting of significant incidents to the national CSIRT (Computer Security Incident Response Team) or competent authority. It also expects organisations to share information that helps assess cross-border impact. The key for an SME is to reduce ambiguity in the first hours of an incident. Reporting should be possible without derailing stabilisation work.

Decision process and staged reporting deadlines

Article 23 sets a staged reporting model with explicit deadlines, including an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report not later than one month after the incident notification. Rather than trying to interpret legal language during an outage, an SME should embed a short decision process into its incident response procedure:

Detect and stabilise: confirm whether service impact is ongoing and preserve initial logs.
Classify: decide whether the event is an incident, a near miss, or a routine fault. Record the rationale.
Assess significance: evaluate impact, including disruption, financial loss, and potential harm to other parties. Use the directive language and any national guidance.
Notify: if the incident meets the significance threshold, follow the staged reporting process and national channels.
Update: send follow-up information as the investigation matures, and record what was shared and why.
Close out: run a post-incident review, confirm corrective actions, and retain the report and evidence.

For certain digital infrastructure and ICT service management categories, Commission Implementing Regulation (EU) 2024/2690 further specifies cases in which an incident is considered significant. ENISA’s technical implementation guidance provides practical examples of how to implement these expectations and how evidence can be retained.

What information to capture, who owns it, and how to rehearse

An incident reporting playbook should be short and executable. It should specify who owns each part of the information set. That avoids scrambling across teams. A practical minimum set includes:

The service(s) affected and a customer impact summary.
Start time and detection method, including the first known indicator of compromise (a sign that a system may have been breached).
Initial severity assessment and what is known versus unknown.
Containment actions taken and immediate risk controls applied.
Systems, suppliers, or third parties involved.
Current mitigation plan, expected restoration steps, and communications plan.

Rehearsal can be lightweight. A tabletop exercise is a structured discussion of a scenario. It is enough to test the playbook, validate contact lists, and confirm that decision-making works under pressure. Evidence to retain includes the exercise agenda, attendance, decisions made, and follow-up actions.

Common pitfalls that create panic

Most NIS2 panic scenarios are self-inflicted. They come from late ownership decisions, unclear evidence, or over-scoped programmes that cannot be operated. Common pitfalls include:

Starting with templates instead of ownership: policies get written but no one runs the processes.
Confusing documentation complete with controls operating: evidence is missing because work did not become routine.
Ignoring suppliers: key services depend on third parties, but there is no inventory or response plan for supplier incidents.
Overloading the team: too many controls are introduced at once, so none are executed consistently.
Leaving incident reporting until the end: the first real incident becomes the first test of reporting.
Using vague language: policies say should or may and create audit friction and operational confusion.

A calmer alternative is to implement a small control set thoroughly, build an evidence habit, then expand coverage. That approach creates defensible readiness and reduces operational noise.

Conclusion

NIS2 readiness for SMEs is best treated as resilience work with proof. The organisation should decide scope, assign accountable ownership, operate a small set of controls consistently, and retain evidence as a natural by-product of doing the work. This is compatible with limited SME bandwidth because it focuses on repeatable routines rather than large compliance projects.

In plain English, ready looks like this: leaders can explain what is protected and why, teams know who owns each security process, incidents are handled and reported through a rehearsed playbook, and evidence can be produced quickly and cleanly when a regulator, auditor, or customer asks.

For organisations operating in Denmark and the Nordics, the final step is to align the operational approach to national implementation details. The External Resources section includes official starting points, and the organisation should keep a dated record of how scope and reporting routes were confirmed.

Frequently Asked Questions (FAQs)

Does NIS2 apply to an SME if it is small but operates in a listed sector or provides a critical service?

NIS2 scope depends on sector, entity type, and how national law implements the directive. A small organisation should not assume it is excluded. A practical approach is to map services to the directive’s sector annexes, then confirm the applicable national rules and competent authority guidance for the country of establishment. The organisation should retain a short scoping memo with sources and approvals.

If an SME is not directly in scope, what NIS2-style requirements might customers still ask it to meet as a supplier?

Customers that are supervised under NIS2 often flow expectations down the supply chain. An SME supplier may be asked for policies, incident response procedures, evidence of vulnerability handling, backup testing, access reviews, and supplier due diligence. The most efficient response is an evidence-first baseline that is operated continuously, so customer requests can be answered quickly without last-minute document work.

What does appropriate and proportionate cybersecurity risk management mean for an SME in practice?

It means controls should match the organisation’s risks, scale, and service criticality. For an SME, that usually looks like clear ownership and governance, a basic risk process, access and identity discipline, vulnerability handling, backups and recovery checks, logging for critical systems, and a workable incident playbook. The organisation should be able to explain why these measures are appropriate for its services and retain evidence that they operate.

What counts as a significant incident and how should a decision be made quickly during an outage or breach?

The directive describes significance in terms of impact, including disruption and potential harm to other parties, and national guidance may add practical thresholds for supervision. An SME should avoid ad hoc judgement during an incident. A better approach is to define a short significance assessment checklist, agree who makes the call, and record the rationale. If the event meets the significance threshold, the playbook should guide staged reporting and communications.

What evidence should be retained so readiness can be demonstrated without building a compliance bureaucracy?

The minimum evidence pack should show scope decisions, ownership, risk decisions, operating controls, and incident readiness. In practice this can be a small set of documents and records: a scoping memo, an ownership matrix, a simple risk register, core policies and procedures, and routine operational evidence such as access reviews, remediation tickets, recovery test records, and incident exercise notes.

Can ISO/IEC 27001, NIST CSF, or CIS Controls work reduce NIS2 effort, and how should it be mapped?

Yes. Existing work often transfers well when it is genuinely operated and evidenced. ISO/IEC 27001 (an international information security management standard) provides structured governance and control expectations. NIST CSF (the NIST Cybersecurity Framework from the US National Institute of Standards and Technology) supports a risk-based programme structure. CIS Controls (a prescriptive control set from the Center for Internet Security) supports practical technical safeguards. The organisation should map existing controls and evidence to NIS2 themes, identify gaps, and retain the mapping and evidence trail as part of its readiness pack.

NIS2 for SMEs: Operational Readiness, Not Panic