NIS2: what you must be able to show
The hard part of NIS2 is not buying security products. It is producing evidence that the measures existed before the incident, in a form somebody outside your IT team can read.
NIS2 requires organisations in scope to have risk management, incident handling, business continuity, supply chain security and access control in place, and to report a significant incident within 24 hours of becoming aware of it. Management is personally accountable.
The practical consequence is documentation. Written policies that match what actually happens, logs retained long enough to reconstruct an incident, and a report a board can read without translation.
Even if you are not directly in scope, expect the questionnaires. Suppliers to in-scope organisations are pulled in through contracts, and that is how most mid-market companies first meet NIS2.
Are you in scope?
NIS2 covers essential and important entities in sectors including energy, transport, banking, health, drinking water, digital infrastructure, public administration, postal services, waste, chemicals, food, manufacturing and digital providers. Size thresholds apply, but the sector list is broad enough that a lot of mid-market companies are caught by it.
The second route in is contractual. If you supply an in-scope organisation, their supply chain obligations become your obligations through the contract. In our experience that is how most companies find out: a customer sends a security questionnaire that did not exist last year.
The five things it actually asks for
| Requirement | Evidence they will want |
|---|---|
| Risk management | A written risk analysis with owners and dates, reviewed at least annually |
| Incident handling | A procedure, a contact chain, and a log of actual incidents with times |
| Business continuity | Agreed recovery times and a dated restore test that met them |
| Supply chain security | A list of critical suppliers and what you checked about each |
| Access control | Multi-factor everywhere, and proof that leavers lose access promptly |
Note that every row is a document, not a product. You can own the best firewall on the market and still fail on the paperwork.
The 24-hour clock
A significant incident has to be reported with an early warning within 24 hours of becoming aware of it, a fuller notification within 72 hours, and a final report within a month. Twenty-four hours sounds generous until you realise the clock starts at awareness, which is usually the middle of the night or a Saturday.
What makes that deadline survivable is deciding in advance who declares an incident, who writes the notification, and where the evidence is. Those three answers written on one page are worth more than a great deal of tooling.
Logging is where most organisations fall short
You cannot reconstruct an incident you did not record. The common failure is logs that exist but only for seven or fourteen days, which is shorter than the time it typically takes to notice an intrusion.
We aim for enough retention to answer the question an investigator asks: when did this start, what else did the account touch, and did anything leave. In practice that means centralised logs, retained for months rather than days, with somebody looking at the alerts. We use Splunk and Grafana for that, described under managed IT.
The order we would do it in
NIS2 does not tell you where to start, so here is the sequence that removes the most exposure per euro and produces evidence along the way.
- Multi-factor authentication on everything. Cheapest control, largest effect, and immediately provable.
- An immutable backup with a dated restore test. Covers the continuity requirement and the worst-case scenario at once. See data and business continuity.
- Centralised logging with retention. Without this you cannot meet the reporting deadlines honestly.
- A written incident procedure with names in it. One page, tested once.
- Supplier register. Who can reach your systems, what did you verify, when.
- Then the firewall and segmentation work. Important, but later than most people put it.
What to ask your own IT supplier
Turn the questionnaire around. A supplier who handles your systems should be able to answer, without a delay: which certifications do you hold and who audited them, how do you handle an incident on our environment, what are your response times in writing, and where do your engineers sit.
Our processes are externally audited to ISO 9001, ISO/IEC 27001 and ISO 14001, with Kiwa NEN 4400-1 covering our staffing work. Our own people work the nights and weekends on a rota, so nothing about your environment is handed to a third party. That does not make you compliant on its own, but it means your auditor gets a straight answer about one link in your chain.
Make the evidence a by-product
The organisations that find NIS2 painful are the ones that produce evidence when asked. The ones that find it manageable produce it every month anyway, because the reporting rhythm already exists.
That is the whole idea behind service governance: one set of figures, one review cycle, one point of accountability. When the questionnaire arrives, the answer is a document you already have.
Questions we get about this
What management asks us once NIS2 lands on the agenda.
When does an incident have to be reported under NIS2?
An early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within a month. The clock starts at awareness, not at the time of the breach, which is why knowing who declares an incident matters more than the tooling.
Does NIS2 apply if we only supply an in-scope company?
Not directly, but in practice yes. In-scope organisations have supply chain obligations, and they pass those on through contracts and questionnaires. Most of the mid-market companies we work with met NIS2 through a customer, not a regulator.
Do we need a certification to comply with NIS2?
No certification is required. ISO/IEC 27001 covers a large share of what NIS2 asks for and makes the evidence easier to produce, but it is a means rather than a requirement. What is required is that the measures exist and can be shown.
How long does it take to get ready?
For a mid-market organisation starting from a reasonable baseline, three to six months to have the core controls and the documentation in place. The technical work is usually faster than the paperwork, which is the opposite of what people expect.
Where this lands in our work
The services this leans on.
Want this looked at for your own sites?
Half an hour on a call is usually enough to tell you whether we are the right party for it, and we will say so if we are not.