NIS2 has applied since 18 October 2024, the day after the transposition deadline, and it repealed NIS1 with effect from the same date. Most member states missed that deadline. On 8 July 2026 the Commission referred Ireland, Spain, France, and the Netherlands to the Court of Justice for failing to transpose it. The practical consequence is that your obligations do not come from the directive itself. They come from whichever national law implements it in each country where you are established.
Directive (EU) 2022/2555 names no software. It names ten risk-management measures (Art. 21(2)), reporting deadlines that start when you detect an incident (Art. 23), a duty on the management body to approve and oversee those measures (Art. 20), and registration duties that feed both national entity lists and the ENISA registry (Art. 27). Run those in spreadsheets and shared drives and you rarely fail at the first piece of evidence. You fail in month twelve, when nobody can reconstruct what the state of play was on the day an incident happened.
This guide does not rank vendors. It sets out the four routes to NIS2 compliance, the features that actually carry the evidence, the criteria that decide the selection, and when starting pays off. For the regulation itself, read our full guide to the NIS2 Directive.
What NIS2 software does, and what it does not
NIS2 software pulls the work the directive requires into one system: the ten measures in Art. 21(2) with the evidence attached to each, the Art. 23 reporting sequence with a clock that starts at detection, your registration record in versioned form, a register of your direct suppliers and service providers, and proof that your management body completed the training Art. 20(2) requires of it.
The value is in the upkeep rather than the filing. NIS2 has no end date. Art. 21(1) requires measures that are appropriate and proportionate, and Art. 21(2)(f) separately requires policies and procedures to assess whether those measures are actually working. Software that collects evidence continuously can answer that question on any given day. A document store answers it as of the last time somebody edited it.
Three things no tool does for you. Classification under Art. 3 is a legal question, and it is not the simple test most summaries suggest. The adequacy judgment, whether your measures match your risk, is professional judgment. And accountability under Art. 20(1) sits with the management body, which must approve the measures and oversee their implementation.
One point matters for vendor selection: NIS2 creates no certification. Not for companies and not for software. Art. 24 only allows member states to require, in defined cases, ICT products and services certified under a scheme adopted under Regulation (EU) 2019/881. Any vendor offering you a NIS2 certificate or a NIS2 seal is selling something that does not exist.
Why the tooling decision cannot wait
The obligations already apply
NIS2 entered into force on 16 January 2023 and has applied since 18 October 2024. Member states were required to establish their lists of essential and important entities by 17 April 2025 under Art. 3(3), and entities in the Art. 27 categories had to submit their registry information by 17 January 2025. Both dates have passed.
The uneven transposition does not soften this. Where a member state has transposed, the national law applies in full. Where it has not, the Commission is now litigating, and the direction of travel across the Union is consistent. Starting now means catching up, not preparing.
Supervision works differently for the two tiers
Essential entities are supervised proactively under Art. 32, which means an authority can look at you without an incident having occurred. Important entities are supervised under Art. 33, and Art. 33(1) describes that regime as ex post, meaning scrutiny follows evidence of a problem. The term "ex ante" appears nowhere in Art. 32, so treat any source that attributes it to the directive with caution.
Art. 32(5) is also narrower than it is usually described. For essential entities, authorities may suspend a certification or authorisation, or request its suspension, and they may only request that a body or court impose a temporary management ban on a named individual. They cannot impose that ban themselves. Art. 32(5) does not apply to public administration entities at all.
The management body carries the accountability
Art. 20(1) requires management bodies to approve the risk-management measures, to oversee their implementation, and provides that they can be held liable for infringements. Art. 20(2) requires members of management bodies to follow training. For everyone else the directive only requires member states to encourage entities to offer similar training; the obligation covering staff awareness is Art. 21(2)(g), a different provision with a different scope.
For tooling this means two specific artefacts: an auditable record of who oversaw which measure and when, and a training record for the management body itself. Neither survives well in a shared drive. Our checklist for managing directors sets out the duties in full.
Fines under Art. 34, and what they attach to
Art. 34 sets fines of "a maximum of at least" 10 million euros or 2% of total worldwide annual turnover for essential entities, whichever is higher, and 7 million euros or 1.4% for important entities. The wording matters. These are floors for national maxima, not EU-wide caps, so your actual exposure is whatever your member state legislated at or above that level.
What they attach to matters more. The Art. 34 fines are triggered by infringements of Art. 21 or Art. 23, meaning the risk-management measures and the reporting duties. Those are exactly the two areas where evidence either exists or does not, which is why they are the two areas a tool has to carry.
Four routes to NIS2 compliance compared
Before you shortlist a product, decide the approach. There are four common ways to implement the obligations and keep them defensible. They differ mainly in how much work stays with your team, how quickly you reach a defensible state, and what the whole thing costs (as of August 2026).
| Route | Effort that stays in-house | Time to a defensible state | Total cost | Other frameworks | Fits |
|---|---|---|---|---|---|
| Spreadsheets and in-house build | Very high, every update by hand | Fast to start, brittle within months | Low licence cost, high internal cost | Barely transferable | Very small teams with no budget, as a stopgap only |
| Traditional consultancy | Moderate, implementation stays partly internal | Moderate, depends on consultant availability | High, frequently six figures in the mid-market | Depends on the consultant | Companies with no security function that need guidance |
| Self-service software | Moderate to high, the judgment stays with you | Fast where integrations are good | Moderate | Broad, depending on the platform | Teams with their own security and compliance roles |
| Platform plus experts | Low, automation plus guided decisions | Fast, weeks rather than months | Moderate, guidance included | Broad, one control set across frameworks | Companies that need pace without a large internal team |
The real trade-off sits in the second and last columns. Spreadsheets save licence fees, cost the most internal time, and break at precisely the moment a regulator asks what the position was six months ago. Consultancy takes work off your desk, costs the most in cash, and leaves the knowledge with the consultant. Self-service software is quick but hands you the judgment on whether your measures are adequate. The hybrid route pairs the platform's automation with people who make that judgment with you. Kertos works this way, combining the platform with certified experts who can also hold external CISO and data protection officer mandates.
The features that decide whether NIS2 software works
Not every product with NIS2 in its name carries the evidence. Five capabilities decide, in practice, whether a tool implements the directive's obligations or simply digitises a checklist.
Full coverage of the ten measures in Art. 21(2)
Art. 21(2) lists ten risk-management measures. They are the substance of the obligation and, read as a checklist, the most useful test you can run on a product. For each row, ask which evidence the system produces on its own and which you will still maintain by hand.
| Measure under Art. 21(2) | What the software has to produce | Most common gap |
|---|---|---|
| Risk analysis and information system security policies | Versioned risk register with assessment, owner, and treatment decision | Risks logged, acceptance decision never documented |
| Incident handling | Incident file with timestamps from detection to closure | The incident lives in the ticket system, the evidence nowhere |
| Business continuity, backup management, and crisis management | Proof of a tested restore, not just the backup policy | Policy in place, restore test never recorded |
| Supply chain security | Supplier register with criticality, assessment, and review dates | Questionnaires in an inbox rather than in the register |
| Security in acquisition, development, and maintenance, including vulnerability handling | Connections to scanners and repositories with traceable remediation deadlines | Scan reports with no link to the measure they evidence |
| Policies to assess the effectiveness of the measures | Scheduled reviews with result, deviation, and follow-up action | Effectiveness asserted, never tested |
| Basic cyber hygiene practices and security training | Per-person training records with date and content | Attendance lists with no link to what was taught |
| Cryptography and encryption | Policy plus technical evidence of the algorithms actually in use | Policy exists, implementation unevidenced |
| Human resources security, access control, and asset management | Current asset inventory and documented access reviews | Inventory from the rollout, untouched since |
| Multi-factor authentication and secured communications | Reading actual MFA status out of the identity system | MFA as a policy rather than as a measured state |
The wording in the table is condensed and does not reproduce the directive verbatim. Art. 21(2) governs. Our article on the NIS2 requirements works through them in detail.
Art. 23 reporting as a workflow with a clock
Reporting is the obligation most often described wrongly. Art. 23 is not a three-stage process, and reports do not go to a single fixed recipient: they go to the CSIRT or, where applicable, the competent authority.
| Report | Deadline | Content | Most common failure |
|---|---|---|---|
| Early warning | 24 hours | First indication of a significant incident | Nobody is authorised to report on incomplete information |
| Incident notification | 72 hours, or 24 hours for trust service providers | Assessment, severity, and indicators of compromise | Weak detection, so the clock has already been running |
| Intermediate report | On request of the CSIRT or competent authority | Relevant status update | No fixed deadline, so it is never planned for |
| Final report | Within one month of the notification | Root cause, mitigation, and cross-border impact | Root cause cannot be reconstructed after the fact |
| Progress report | Where the incident is ongoing at one month | State of handling, with a final report once it closes | Missed because the incident is treated as closed |
Two details are routinely dropped. The 24-hour deadline for trust service providers sits in the closing subparagraph of Art. 23(4), not in a separate article. And Art. 23(1) contains a customer-facing duty as well: where appropriate, you must notify the recipients of your services of significant incidents likely to adversely affect those services. That is a communications workflow, not just a regulatory one.
The test for a product is whether it runs this as a workflow with a clock that starts at detection, with authority to report assigned in advance, and with a log that later proves when each report went out. A form is not enough, because the first 24 hours are a decision problem rather than a documentation problem.
Supply chain security as a register, not a folder of questionnaires
Supply chain security is one of the ten measures and the requirement most programmes stall on. Art. 21(2)(d) covers the security of the relationships between each entity and its direct suppliers or service providers, which is an ongoing assessment rather than a questionnaire filled in once.
Check whether the product maintains a supplier register with criticality ratings, sets review dates, sends questionnaires, and links the answers back to the measures they support. A tool that generates questionnaires and files the PDFs has moved the work rather than absorbed it. Note also that the Union-level coordinated supply chain risk assessments under Art. 22 are discretionary, so do not plan around them.
Evidence that still holds twelve months later
A regulator does not ask about today. It asks about the position on the day of an incident or at the point of a review. That makes history the actual feature. Look for tamper-evident logs with timestamps and owners, versioned policies, and the ability to reconstruct the state of any given date.
The second half of this is exit. Check that you can export all evidence completely and in a usable format. Evidence readable only inside one platform ties you to that vendor and becomes a problem the moment you switch or have to answer a review outside the system.
One control set for NIS2 and ISO 27001
An ISMS certified to ISO/IEC 27001 covers a large part of the security requirements in Art. 21(2). What it does not cover are the NIS2-specific duties: registration, the Art. 23 deadlines, and the management-body evidence under Art. 20.
Effective software maps both layers onto one control set instead of running two systems in parallel. An access control implemented and tested for ISO 27001 should automatically evidence the corresponding NIS2 measure. We set out where the two overlap in NIS2 and ISO 27001.
Kertos maps NIS2, ISO 27001, GDPR, SOC 2, TISAX, and the EU AI Act onto a shared control set. More than 100 integrations pull evidence from the systems your teams already use and attach it to the measures it supports, which cuts manual compliance effort by around 80%.
How to choose NIS2 software
The decision is rarely settled by a feature list. Five questions carry most of it.
Confirm scope and classification before you compare anything
Without a defensible classification you are comparing products against a scope you have not established, and the test is not the one most summaries give.
Essential entities are not simply large entities in Annex I. Art. 3(1) is an enumerated list of seven categories, and large Annex I entities are only the first of them. Point (g) is the one most often missed: entities a member state had already identified as operators of essential services under NIS1 before 16 January 2023. Important entities are the residual category under Art. 3(2), meaning everything in scope that is not essential.
The size test comes from Recommendation 2003/361/EC and is easy to state wrongly. An enterprise is small if it has fewer than 50 persons and turnover and/or balance sheet total not exceeding 10 million euros, so it stops being small only when it exceeds both financial ceilings. It exceeds the medium ceilings, and counts as large, at 250 persons or more, or turnover above 50 million euros and balance sheet total above 43 million euros. Writing "turnover or balance sheet above 10 million" pulls legally small companies into scope that do not belong there.
Annex I lists 11 sectors and Annex II lists 7. Our NIS2 framework page covers the scope in full.
Check whether the software handles more than one member state
This is the question that separates products built for the directive from products built for a market, and it is the one most buyer guides skip.
Your obligations attach per member state. Art. 26(1) sets the default rule: jurisdiction follows establishment, not where you provide services. There are three exceptions. Providers of public electronic communications networks or services fall under every member state where they provide the services. The digital-provider category, which covers DNS service providers, TLD name registries, cloud computing, data centre, content delivery network, managed service, managed security service, online marketplace, search engine, and social networking providers, falls under the member state of its main establishment. Public administration entities fall under the state that established them.
Then Art. 26(3): an entity in that digital-provider category that is not established in the Union but offers services within it must designate a representative in a member state where it provides services. If it does not, any member state where it provides those services may take legal action against it. That is a live exposure for non-EU vendors and for EU groups with non-EU subsidiaries, and almost no compliance tool models it.
The practical test is simple. Ask whether the product can tell you which authority you report to for a given entity in your group, and whether it holds the national implementing rules for each country you are established in, or only the directive's article numbers. If your footprint is one country, this criterion costs you nothing. If it is three, it is the whole decision.
Where your data sits and who controls the vendor
A NIS2 platform contains a description of your weaknesses: open measures, risk assessments, incident files, supplier assessments. It is the most sensitive dataset most companies hand to a service provider.
Look past the hosting region to who controls the company holding the data, since regulated customers ask that question in procurement. Assess as well whether the platform was built for European frameworks or extended to them from a product designed for a different market. Kertos stores data in Germany and was built for European requirements from the start rather than adapted to them.
Decide who makes the adequacy judgment
Art. 21(1) requires measures that are appropriate and proportionate to the risk. Proportionality is a judgment, and software does not supply it. Self-service tools give you structure and automation; whether your access control is sufficient for your risk profile remains your call.
So establish where that competence sits before you choose. With a CISO and an established security team, self-service software is efficient. Without one, you need either consultancy alongside the software or a platform with the expertise included. Kertos pairs the platform with certified information security and data protection experts who make that assessment with you and can hold external CISO and DPO mandates.
Compare total cost of ownership, not the licence
The licence is the smaller part of the bill. Add implementation, the internal time spent maintaining records and collecting evidence, the effort of preparing for reviews, and the cost of outside help for anything the software does not cover.
A more expensive platform that collects evidence automatically is often cheaper in total than a low-priced one that still requires manual work. Compare as well against consultancy-led implementation, which frequently runs to six figures in the mid-market. Check which services sit inside the price and which arrive as a separate project.
When starting pays off
If you operate in more than one member state
Multi-country scope is where manual approaches break first, because the obligations diverge as each member state transposes. One register per country, maintained by hand, drifts within a quarter. This is the strongest single case for tooling.
If you already run ISO 27001
An existing ISMS is the cheapest possible starting point. The work narrows to confirming scope and classification, closing the gaps against the ten measures, standing up the reporting process, and adding the management-body evidence. Doing that inside the same platform that runs the ISMS saves maintaining two sets of records.
If customers are asking for evidence down the supply chain
Entities in scope have to assess the security of their direct suppliers, which cascades. If you sell to an in-scope company you will be asked for evidence whether or not NIS2 applies to you directly. Once those requests are frequent, a platform pays for itself on reusable answers alone.
If reporting depends on one person
A reporting process that depends on a particular person being reachable will not survive an incident. It is the most reliable trigger for changing tools, because the Art. 23 clock starts at detection, not at availability. The moment "who is authorised to report within 24 hours" has no documented answer, the process is the more urgent problem than the software.
Frequently asked questions
Do you actually need software for NIS2?
Not as a matter of law. The directive requires measures and evidence, not a tool. In practice, keeping the evidence current becomes hard above a certain size, because NIS2 requires ongoing documentation rather than a position as at a cut-off date. The break usually comes not at rollout but the first time somebody has to reconstruct an earlier state.
What does NIS2 software cost?
Price depends on company size, the number of frameworks, user count, and how much expert support is included. Total cost of ownership tells you more than the licence: implementation, ongoing internal work, and preparing for reviews. Compare it against consultancy-led implementation, which frequently runs to six figures in the mid-market.
Is an ISO 27001 tool enough for NIS2?
Partly. An ISMS certified to ISO/IEC 27001 covers a large part of the security requirements in Art. 21(2). It does not cover the NIS2-specific duties: registration, the Art. 23 reporting deadlines, and the management-body evidence under Art. 20. Choose a tool that maps both layers onto one control set.
Is there a NIS2 certification for software or for companies?
No. NIS2 creates no certification. Art. 24 only allows member states to require, in defined cases, ICT products and services certified under a scheme adopted under Regulation (EU) 2019/881. A NIS2 certificate for your company, or a NIS2-certified tool, does not exist.
We are based outside the EU but sell into it. Does any of this apply?
It can. Under Art. 26(3), an entity that is not established in the Union but falls into the digital-provider category and offers services within it must designate a representative in a member state where it provides those services. Without one, any member state where you provide services may take legal action. If that describes you, representative designation and the jurisdiction question belong on your requirements list before any feature comparison.
How fast can you become defensible under NIS2?
It depends mostly on whether a management system already exists. With an ISO 27001 ISMS in place it is a matter of weeks, because the work is limited to classification, closing gaps, the reporting process, and management-body documentation. Without one, building the management system is the work. For a reference point: AskUI reached ISO 27001 certification with Kertos in 8 to 10 weeks without external consultants.
Conclusion: NIS2 is a running programme, not a project
The software question is not about the longest feature list. It is whether your evidence still holds in twelve months, whether the Art. 23 deadlines depend on a process rather than a person, and whether the product knows which national rules apply to each of your establishments rather than only the directive's article numbers.
The rest follows from your position. If you run an ISMS, you need a platform that treats NIS2 as an extension of the same control set. If you have no security function of your own, you need the adequacy judgment supplied, because software does not make it. And if you are established in more than one member state, jurisdiction is the criterion to lead with.
Kertos pairs the platform with certified experts, maps NIS2 and ISO 27001 onto one control set, and maintains a 100% audit success rate across its customers.
See how your NIS2 evidence could be automated. Request a demo and we will work through your scope together.
