NIS2 & DORA for SMBs: What Smaller Companies Actually Need to Do

Short answer: if you run a startup, SME, or mid-market company in the EU (or you sell to one), there is a real chance that NIS2, DORA, or both now apply to you — often through the back door of your customers' supply chains rather than because a regulator wrote to you directly. NIS2 pulls in medium and large companies across a wide sweep of sectors, plus many smaller firms that qualify as critical suppliers. DORA applies directly to financial entities and, crucially, to the ICT vendors that serve them. This article explains, in plain language, who is in scope, what each regime actually requires, how the two differ, where they overlap with ISO 27001, and a practical way to get compliant without boiling the ocean.

Why smaller companies are suddenly in scope

For years, EU cyber regulation felt like a big-company problem. That changed with two pieces of law that came of age recently: the NIS2 Directive (EU 2022/2555) and the Digital Operational Resilience Act, or DORA (Regulation EU 2022/2554), which has been directly applicable since 17 January 2025.

The surprise for most SMBs is not that they are named in the legislation — most are not. It is that their customers are, and those customers are now contractually obliged to manage the security of their supply chain. A 30-person SaaS company that provides scheduling software to a hospital, a managed IT provider serving a regional bank, or a data-analytics startup embedded in an energy utility can all find themselves answering detailed security questionnaires, signing up to incident-notification clauses, and submitting to audits — because the regulated entity above them has to demonstrate it has its suppliers under control.

So the practical question is not only "Am I directly regulated?" but "Do I sell to anyone who is?"

NIS2 in plain English

NIS2 is a directive, which means it sets EU-wide objectives that each member state must write into its own national law (transposition). This matters because the fine detail — supervisory authority, exact penalties, registration mechanics — is national, even though the core obligations are common.

Who NIS2 covers

NIS2 works on a size-cap plus sector logic. In general, an organisation is in scope if it operates in a covered sector and is at least a medium-sized enterprise — broadly 50+ employees or more than €10 million in annual turnover/balance sheet. Entities are then split into two tiers:

• Essential entities — larger operators in high-criticality sectors such as energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure, ICT service management, public administration, and space.
• Important entities — a broader set including postal and courier services, waste management, chemicals, food, manufacturing (including medical devices, electronics, machinery, vehicles), digital providers (online marketplaces, search engines, social platforms), and research.

The practical difference between the tiers is mainly supervision and penalties — essential entities face proactive supervision, important entities are supervised reactively (typically after an incident) — but the security obligations are largely the same.

Size is not the only route in. Certain entities are covered regardless of size, including qualified trust service providers, top-level domain name registries, and DNS service providers, plus entities designated as critical by a member state or where they are the sole provider of a service. This is one way smaller firms get pulled in directly.

What NIS2 requires

At its heart, NIS2 asks for a risk-based set of "appropriate and proportionate" technical, operational and organisational measures. Article 21 lists the baseline, which will look familiar to anyone who has seen an information security standard:

• Risk analysis and information security policies
• Incident handling
• Business continuity, backup management and disaster recovery
• Supply-chain security, including security in relationships with direct suppliers and service providers
• Security in acquisition, development and maintenance of systems (including vulnerability handling and disclosure)
• Policies to assess the effectiveness of measures
• Basic cyber hygiene and security training
• Cryptography and encryption
• Human resources security, access control and asset management
• Multi-factor authentication, secure communications and secure emergency communications

Two features deserve emphasis for SMBs:

Management-body accountability. NIS2 makes senior management explicitly responsible. Management bodies must approve the risk-management measures, oversee their implementation, and can be held liable for failures. Directors and managers are also required to undergo security training. Compliance is a board-level duty, not something you can quietly delegate to IT.

Incident reporting on a strict clock. Significant incidents must be reported to the national CSIRT or competent authority in stages:

• Early warning within 24 hours of becoming aware of a significant incident (flagging whether it looks like it stems from unlawful/malicious action or could have cross-border impact).
• Incident notification within 72 hours, updating the assessment and adding indicators of compromise.
• Final report within one month, with a detailed description, severity, impact, root cause and mitigations.

Transposition status in 2026

The transposition deadline was 17 October 2024, but member states moved at very different speeds. As of 2026, some countries transposed on or close to time, while several large economies — including Germany, Spain and others — finalised their national laws later, after the Commission opened infringement proceedings against the laggards. The practical takeaway: check the specific national law that applies to each entity you operate or sell into, because registration deadlines, thresholds and penalties are set nationally even though the security baseline is common. Assume NIS2 is now live law in most jurisdictions where you do business.

DORA in plain English

DORA is a regulation, not a directive. That means it applies directly and uniformly across all member states with no national transposition step — the text is the law everywhere, since 17 January 2025.

Who DORA covers

DORA targets the financial sector: banks, payment and e-money institutions, investment firms, crypto-asset service providers, insurers and intermediaries, fund managers, trading venues, and more — around 20 categories of financial entity. It applies regardless of size, though it includes a proportionality principle, and some very small or non-interconnected entities benefit from a simplified ICT risk framework.

The part that catches SMBs is third-party reach. DORA governs how financial entities manage their ICT third-party service providers — which means cloud hosts, SaaS vendors, data providers, and managed service providers serving financial clients inherit obligations through contract. If you supply software or IT services to a bank or insurer, expect DORA-driven contractual requirements even though you are not a financial entity yourself. A subset of the very largest providers can additionally be designated Critical ICT Third-Party Providers (CTPPs) and fall under direct oversight by the European Supervisory Authorities — but the vast majority of vendors are managed through their financial customers, not supervised directly.

What DORA requires — the five pillars

1. 1ICT risk management — a comprehensive governance framework, owned by the management body, covering identification, protection, detection, response and recovery.
2. 2ICT-related incident management, classification and reporting — a consistent process to detect, classify and report major ICT incidents to competent authorities on defined timelines (an initial notification, an intermediate report, and a final report), plus voluntary reporting of significant cyber threats.
3. 3Digital operational resilience testing — a programme of regular testing, and for significant entities Threat-Led Penetration Testing (TLPT), broadly aligned with the TIBER-EU framework, at least every three years.
4. 4ICT third-party risk management — due diligence, mandatory contractual clauses, a register of information on all ICT arrangements, concentration-risk management, and exit strategies.
5. 5Information sharing — voluntary arrangements to exchange cyber threat intelligence.

NIS2 vs DORA at a glance

Which one wins when both could apply

For financial entities, DORA is lex specialis — it takes precedence over NIS2 for ICT risk management and incident reporting. In practice a bank follows DORA for its digital operational resilience obligations rather than doubling up under NIS2. For everyone else in a NIS2 sector, NIS2 is the governing regime. Many SMB suppliers, however, end up feeling both: DORA-style clauses from financial customers and NIS2-style clauses from customers in energy, health, manufacturing and digital infrastructure.

How this overlaps with ISO 27001

Here is the good news for smaller firms feeling overwhelmed: NIS2, DORA and ISO/IEC 27001 are asking for the same underlying disciplines. A well-run ISO 27001 Information Security Management System (ISMS) already delivers the majority of what both regimes want — governance, risk assessment, access control, cryptography, supplier management, incident handling, business continuity and continuous improvement.

ISO 27001 is not a legal substitute — neither NIS2 nor DORA says "get certified and you're done" — but it is the strongest possible foundation. The gaps you typically still need to close on top of a mature ISMS are:

• Regulatory incident reporting to the right authority on the 24h/72h/1-month (NIS2) or DORA timelines — an obligation an ISMS does not impose by itself.
• Management-body training and documented sign-off, evidenced, not just implied.
• For DORA: the register of information on ICT third parties, specific contractual clauses, and TLPT for significant entities.
• Supply-chain depth — flowing requirements down to your own subcontractors.

Because the control sets overlap so heavily, the efficient approach is to implement once and map to many, rather than run a separate project per regulation.

A practical compliance approach for SMBs

You do not need a large team to get this right. You need sequence and evidence.

1. 1Confirm scope — for yourself and your customers. Determine whether you are directly in scope of NIS2 (sector + size, or a size-independent category) or DORA (financial entity). Then list the regulated customers who can pass obligations down to you. This single step often reframes the whole exercise.
2. 2Pick an anchor framework. For most SMBs, ISO 27001 is the pragmatic backbone. Build the ISMS once and treat NIS2 and DORA as overlays.
3. 3Run a gap assessment against a mapped control set. Map ISO 27001 controls to NIS2 Article 21 measures and DORA's pillars so you can see, in one view, what is covered and what is missing.
4. 4Fix the universal basics first. MFA everywhere, tested backups, patch and vulnerability management, access reviews, security awareness training, and an incident response plan you have actually rehearsed. These satisfy multiple requirements at once.
5. 5Stand up regulatory incident reporting. Know your authority, your thresholds, and your clock. Pre-draft the 24h / 72h / 1-month templates before you need them.
6. 6Get governance on record. Brief the management body, deliver their training, and document their approval of the risk-management measures.
7. 7Tackle supply chain in both directions. Update contracts with your suppliers; build the DORA register of information if you serve financial clients; be ready to answer customer security questionnaires with evidence, not promises.
8. 8Test and keep evidence continuously. Regular testing (and TLPT where DORA requires it), with a continuous audit trail so you can prove compliance on demand rather than scrambling before each audit.

Conclusion

For most SMBs the honest position in 2026 is this: you are probably touched by NIS2 or DORA — if not directly, then through the customers you serve. The regimes are less about buying new tools and more about doing security systematically and provably: govern it from the top, manage supplier risk in both directions, report incidents on a strict clock, and keep evidence you can show. Treat these as overlapping expressions of the same good practice, anchor on a single framework, and the workload becomes manageable rather than existential.

This is exactly the multi-framework problem Axelia built ISMShed to solve: implement your controls once and map them across ISO 27001, NIS2, DORA, ENS, SOC 2 and GDPR, with an AI Compliance Copilot, MAGERIT risk management, evidence management and continuous audit trails that keep you audit-ready. Where you need hands-on help — from a NIS2/DORA gap assessment to Threat-Led Penetration Testing — Axelia's GRC consulting and offensive security teams work alongside the platform. If you have just discovered you are in scope, the fastest first step is simply mapping where you stand.