NIS2 compliance tools: what they do and what they do not

31 October 2026 is the date by which the baseline security measures set out in the ACN determinations must be operational, not planned. From that day the Italian cybersecurity agency moves from an accompaniment phase to a verification phase, with proactive supervision of essential entities and checks on report or incident for important ones.

In the weeks before a deadline like this, the same thing always happens: the market fills up with tools that promise compliance. The problem is that under that promise sit very different product categories, solving different problems, sold with the same vocabulary.

Whoever buys the wrong category does not notice straight away. They notice when the audit arrives and they are asked not for the document, but for proof that the document describes something real.

TL;DR

• The ACN determinations translate NIS2 into a closed list: 37 measures and 87 requirements for important entities, 43 measures and 116 requirements for essential ones. These are line items someone will come and check, one by one.
• The tools on sale fall into three families. GRC platforms organise evidence, map it onto requirements and produce documents. Technical tools (centralised logging, multi-factor authentication, asset inventory, vulnerability management, verified backups) produce the evidence itself. Managed services watch the technical tools for you, which is what decides whether the evidence stays current.
• A GRC platform with no technical tools underneath is a binder of assertions. It saves time for organisations that already have the measures. It does not implement them for you, and no product page says this that plainly.
• For SMEs under 50 employees our position is that in most cases the GRC platform is not needed: the volume of evidence to keep in order is manageable with tools the company already has, and the budget returns far more when spent on the technical measures that are missing.
• If you are a supplier to a NIS2 entity rather than a covered entity yourself, your problem is different again: you do not have to comply, you have to be able to answer. And that is a documentation problem, not a tooling problem.

What the determination actually asks for

Worth starting here, because this is the point where the sales conversation skips ahead.

The Italian framework does not leave NIS2 at the level of principle. ACN determination 379907/2025 breaks it down into measures and, under each measure, into verifiable requirements. The count is the one in the TL;DR: 37 measures and 87 requirements for important entities, 43 and 116 for essential ones, with the latter adding 6 measures and 29 requirements to the former.

Every requirement has one characteristic that changes everything: it is demonstrated, not declared. In an audit they do not ask whether you have an access management policy. They ask for the list of privileged accounts and the date of the last review.

This splits the work into two parts that need funding separately:

The technical part: making sure the evidence exists. If no system collects logs, there are no logs to show, and no document compensates for that.

The documentation part: organising the evidence so it is retrievable, current and mapped to the requirement it satisfies. This is real work, and in a structured organisation there is a lot of it.

The market mostly sells the second. The first costs more, shows less and requires touching the systems.

The three families of tools

Under the label “NIS2 software” the market actually sells three distinct categories.

The row to read twice is the second-to-last. The absence of a GRC platform costs time. The absence of technical tools costs compliance. The absence of monitoring costs continuity, which is the part you only discover in an audit, when the most recent piece of evidence is dated the day of installation.

The three categories are not alternatives to each other, and in a sales conversation they get presented as if they were.

The five pieces of evidence no platform can produce for you

If we had to reduce 116 line items to what is most often missing in Italian SMEs, it is these five. They are also the ones an auditor asks for first, in our experience, because they are the ones you can check in five minutes.

1. Multi-factor authentication on privileged access. The requirement is obvious, the gap is widespread, and the proof is trivial to ask for: log in as an administrator and show me. No document rescues an admin account with a password alone.

2. Centralised log collection and retention. It is not enough for systems to write logs: they have to land somewhere they persist, where they can be searched, and where whoever compromised the system cannot delete them. This is the technically hardest measure on the list for an organisation starting from zero, and it gets discovered late because it has no screen to show in a demo.

3. A current asset inventory. What you have, where it is, who owns it, what version it runs. It looks like the dullest item on the list and it is the one everything else depends on: you cannot manage the vulnerability of a system you do not know you have. A spreadsheet updated monthly satisfies the requirement. A spreadsheet from 2023 does not.

4. Vulnerability management with evidence of the cycle. Not “we run a scanner”. The scanner found these, we decided to fix these by this date, and this is the date we did. The part almost always missing is the third column.

5. Verified backups with restore proof. A backup nobody has ever tried to restore is not a backup, it is filed optimism. The requirement asks for proof of the test, with a date. It is the cheapest piece of evidence on the entire list to produce and one of the most frequently absent.

None of these five is bought with a compliance platform. All five are bought, or built, with technical tools, people’s time, and a decision about who owns them.

Is there a tool that produces audit-ready reports?

Yes, and the right question is a different one: ready starting from what.

An audit report is a document that lines up, requirement by requirement, the evidence satisfying it and the date it was collected. Any GRC platform generates one in seconds. The value of the report lies entirely in the quality of what sits underneath it: if the log retention requirement is marked compliant because somebody ticked a box, the report is a document asserting something untrue, and in an audit that is a worse position than having no report at all.

So the question to put to the vendor is very specific: which requirements does your tool mark compliant by reading real technical data, and which does it mark because a user declared it so? In serious products the first group is a small and clearly stated subset, typically the ones verifiable through connectors into the systems (MFA status, antimalware coverage, last scan result). Everything else is declarative, and the platform organises it without verifying it.

And maintaining it over time?

This is the second question we get most often, and it has a precise operational answer: compliance does not expire all at once, it expires in pieces and on different cycles.

On the perimeters we see, the minimum calendar looks like this:

• Quarterly: privileged access review, vulnerability scan results with the decisions taken, verification that logs are still arriving from every expected source.
• Half-yearly: documented restore test, asset inventory update, review of the relevant supplier list.
• Annually: risk analysis review, procedure updates, documented staff training.
• On event: significant incident notification, with a 24-hour early notification and a 72-hour full one. This obligation has been operational since January 2026 and does not wait for the October deadline.

A tool helps you not to forget the deadlines. It does not execute them. Every one of those items is somebody’s work, and the question that decides whether compliance survives two years is a plain one: who, with what time allocated, and who notices if a quarter is skipped.

Red flags to recognise in a negotiation

Four phrases that, when they show up in a commercial proposal, tell you something about the vendor:

“NIS2 certification”. It does not exist. NIS2 provides no certification scheme in the way ISO 27001 does: it provides obligations and supervision. A vendor selling a NIS2 certification is selling a private attestation no authority recognises.

“Turnkey compliance”. Impossible by construction, because some requirements concern internal organisational processes no external supplier can execute for you.

“We cover 100% of the requirements”. That describes the mapping, not the coverage. Ask for the two separate lists, as above.

“Guaranteed compliance”. No supplier can guarantee the outcome of a supervisory review, and no serious contract says otherwise. If it appears, it is worth reading what the clause actually says.

Log management, the item most often missing

It deserves its own section because it is the technically hardest measure and the one where we have seen most evaluations fail.

The requirement is not satisfied by turning logging on: that is almost always already on. It is satisfied when logs leave the system that produces them and land somewhere with three properties: they are retained for a defined period consistent with your risk analysis, they can be searched in reasonable time when somebody asks, and they cannot be modified or deleted by whoever compromised the source system. The third is what separates a log collection from a log copy.

Two questions cut the evaluation down to half an hour: how long do you retain, and who can delete? The first is a choice you have to make and justify, because the Italian implementing legislation does not set one number for everybody. The second is technical and has a binary answer.

Watch the cost. Log management is the line that scales worst on the entire list, because price follows data volume and data volume follows system count. An industrial company with connected machinery can end up with a logging line more expensive than everything else combined. The lever is source selection: not everything needs retaining the same way, and deciding what to collect is design work that belongs before signing a volume-based contract.

What it costs, in orders of magnitude

Necessary caveat: almost nobody in this market publishes a price list, prices form in negotiation and depend on users, devices and data volume. The numbers below are orders of magnitude observed in the Italian market, not quotes, and should be used to understand the structure of the cost rather than to build a budget.

The structure is more useful than the figure, and it has three lines:

Technical tooling subscription. It grows with devices, users and log volume. This is the line that scales badly: doubling the endpoints doubles the subscription, and the log volume of an industrial company with connected machinery can be the dominant order of magnitude.

GRC platform subscription, if you take one. It grows with users and with the number of frameworks managed. It is the easiest line to compare across vendors and the least important.

Person-days. Almost always the dominant line and almost always the one nobody budgets. NIS2 compliance is a project, not a budget line: somebody has to map the systems, set priorities, configure, test and then maintain the whole thing every quarter. An organisation that buys tools without allocating people has bought the subscription, not the compliance.

The question to ask any vendor: “which of the requirements in the determination does your product satisfy with no further work from us, and which require us to do something?” A serious vendor answers with two lists. A vendor who answers “we cover NIS2 100%” is describing the mapping, not the coverage.

When you should not buy anything

This is the section no vendor will write, and for a small organisation it is the one worth the most.

We do not sell any of the tools discussed in this article: we develop custom software. None of the recommendations below earns us anything.

If you are an important entity under 50 employees, with infrastructure mostly on third-party managed services and no connected industrial systems, our position is that a GRC platform is not needed in year one. Three reasons:

The evidence volume is manageable without one. Eighty-seven requirements over a small perimeter can be kept in order with a structured folder, a shared register and a quarterly review in the calendar. It is not elegant, it satisfies the requirement, and it costs nothing in licences.

The budget returns more elsewhere. The same money spent on multi-factor authentication, log centralisation and a documented restore test produces real evidence instead of the index of evidence that does not exist.

The platform can be bought later, and bought better. Once the technical measures are in place and the evidence exists, you know exactly what needs organising. Buying first means buying blind and spending the first six months typing in assertions with no fact underneath.

The moment a platform starts to make sense is recognisable: when more than three or four people are involved in collecting evidence, when there is more than one framework to manage (typically NIS2 plus ISO 27001, or NIS2 plus customer requirements), or when the time spent chasing evidence exceeds the subscription. Before that point it is premature optimisation of a process that does not yet exist.

If you are a supplier and not a covered entity

This is the situation most Italian software houses are in, and it gets confused with the previous one constantly.

NIS2 does not make you covered. It makes you named: your customer, an essential or important entity, has to inventory the suppliers relevant to the security of their services, and they have put you on that list. From that moment their deadlines become yours contractually, without you signing anything new and often without anyone telling you.

What arrives is a questionnaire. And the questionnaire is a documentation test, not a security test: the questions are about what you have written down and can show, not about how good you are.

So the problem gets solved by preparing, once and properly, five things: a description of how you manage access to the customer’s systems, an incident notification procedure with the timelines you commit to, the list of sub-suppliers who touch that data, your system update policy, and the name of a person who answers. Prepared once, those five things answer 80% of the questionnaires that will arrive, and turn a request that costs two days today into one that costs an hour.

We covered the general framing in NIS2 for Italian software houses and the technical requirements that end up in tenders in NIS2-compliant software.

Common mistakes

1. Buying the platform before the measures. This is the mistake this article exists to prevent. It produces a dashboard full of red items nobody can turn green because the systems underneath are missing.

2. Confusing framework coverage with requirement coverage. Every product “covers NIS2” in the sense that it knows the list. Very few execute anything on your behalf.

3. Treating it as a project with an end date. 31 October 2026 is not the end: supervision begins after that date, and evidence has to be maintained. A project that finishes on 30 October leaves an organisation compliant for a week.

4. Not assigning ownership. The question “who owns NIS2 compliance here” must have a name attached. Where it does not, evidence goes stale and nobody notices until the audit.

5. Forgetting suppliers downstream. If you are a covered entity, the supply chain is inside the perimeter. Your ERP vendor, whoever holds your backups and whoever administers your systems have to be inventoried and questioned, with the same questionnaire you receive from your own customers.

FAQ

What is the real NIS2 deadline in Italy?

For entities that received their inclusion notice in the first cycle, baseline security measures must be operational by 31 October 2026. For entities brought into scope during 2026 the path shifts: measures by 31 July 2027 and incident notification from 1 January 2027. The notification obligation for the first cycle has instead been operational since January 2026, with a 24-hour early notification and a 72-hour full notification.

Do you need a GRC platform to be compliant?

No. No rule requires a specific tool. The determination requires measures to be implemented and demonstrable, and the format of the demonstration is free. A platform saves time where evidence is voluminous and many people are involved. It does not add compliance.

How much does getting compliant cost?

The figure depends almost entirely on the starting point, and the variable that weighs most is not company size but how many of the five baseline technical measures are already in place. An organisation that already has MFA, a current inventory and tested backups faces mostly documentation work. An organisation starting from zero faces a technical project, and the dominant line will be person-days, not licences.

We are a 30-person company: are we really covered by NIS2?

That has to be checked against sector of activity and thresholds, and it does not follow from size. There is only one way to know for certain: the notice of inclusion in the national list, which comes from ACN. Anyone who has not received it and operates in a sector listed in the annexes may still be captured in later cycles, and in any case is likely to receive questionnaires from customers who are covered.

What happens if we are not ready on 31 October 2026?

After that date ACN moves into verification, with proactive supervision of essential entities and mostly reactive checks, that is after an incident or a report, on important ones. In practice, the most immediate risk for most companies is the customer asking for evidence before renewing a contract.

Does it make sense to go for ISO 27001 instead of NIS2?

They are different things with a large technical overlap, and anyone running a working ISO 27001 management system starts with much of the evidence already produced. Getting certified purely for NIS2 rarely pays off, because it is a longer and more expensive route than what is required. Already having it is a significant advantage, and in that case the GRC platform becomes more defensible because there are two frameworks to manage.

The right order, which is the least sellable one

The NIS2 compliance tooling market sells two different things under the same name, and the distinction is easy to hold on to: some organise the evidence and some produce it. The first group saves time for those who already have the measures. The second group is the measures.

For an organisation starting now, with weeks to the deadline, the correct order is the commercially least attractive one: first the five baseline technical measures, then the evidence, then possibly a tool to keep it in order. The reverse order produces a tidy dashboard describing things that do not exist, and in an audit that is worse than disorder, because it documents awareness of the gap.

If you need to work out where you stand against the requirements in the determination and which measures you are actually missing, let’s talk. We sell neither platforms nor tools, so the output of an assessment is a list of things to do rather than a quote.

For more: the NIS2-compliant software page, the security-aware custom software pillar, and the article on what NIS2-compliant software actually means for the development side.

Note on sources: the counts of measures and requirements refer to ACN determination no. 379907/2025 and to the deadlines published by the agency. Determination references and timing windows are updated periodically and secondary sources do not always agree: before committing spend, check the current position on the ACN portal. Verified as of 15 August 2026.