What a NIS2 readiness gap actually looks like
Signal
A manufacturer came to us convinced NIS2 meant a new set of documents to write. Their first question was which template to fill in.
Context
They were in scope as an important entity, supplying larger firms that had started asking about their security. They had a firewall, antivirus, and a yearly backup test — and no way to tell what was happening day to day.
What it meant
The real gap was not documentation. It was that nobody could describe what normal looked like on their network, so they could not have noticed an intrusion until it caused visible damage. NIS2 expects risk management and incident handling, and both depend on visibility they did not have.
What to do
We started with monitoring and a written, tested incident response plan — the two things that reduce real risk and also happen to be what an assessor looks for. The documentation followed naturally, because by then it described something true.
Being in scope is not the same as being ready
NIS2 broadened the range of organisations expected to manage cybersecurity risk and report incidents. A lot of mid-sized firms discovered they were in scope through a customer questionnaire rather than a regulator, which is its own kind of pressure.
The instinct is to treat it as a compliance form. But a directive that asks you to manage risk and handle incidents is really asking whether you can see what is happening and act on it. Those are operational questions, not clerical ones.
Why visibility comes before documentation
You cannot write a credible risk assessment about threats you have no way to detect. In this case, the team had logs scattered across devices that nobody aggregated or reviewed. Anomaly detection had nothing to measure against because there was no baseline.
We established that baseline first. Within weeks, ‘what is normal’ became a question with an answer, which made every later document — the risk register, the response plan — grounded rather than theoretical.
The order we worked in
First, aggregate and monitor the logs that already existed. Second, write an incident response plan with named roles and test it with a tabletop exercise. Third, map those activities to the NIS2 expectations and record the evidence.
This order matters. Done the other way around, you produce a binder that describes controls you do not actually operate — which is worse than an honest gap, because it creates false confidence.
The takeaway for a team under NIS2 pressure
If a customer or regulator has put NIS2 on your desk, resist the urge to start with templates. Start by being able to see your environment and respond to an incident. The paperwork is much easier — and much more honest — once those two things are real.
Written by Elena Vogt. Field Notes are anonymised; identifying details are changed or removed.
Wondering where your own gaps are?
The readiness check gives you an honest starting point in about three minutes.