Your NIS2 spreadsheet is a good start, but not yet evidence

There comes a moment every IT manager of a company under NIS2 will recognise. The spreadsheet with the assessment framework has been filled in, the information security policy is on the intranet, and the feeling says it is all sorted. That feeling holds until a major client sends a supplier assessment, an auditor asks for substantiation or the regulator gets in touch. At that moment it becomes clear how large the difference is between having something and being able to demonstrate it.

Why the spreadsheet does have value

To begin with, that spreadsheet deserves more credit than it usually gets. Whoever has completed the official NIS2 control framework has thought about the ten duty-of-care topics of article 21, from risk analysis and incident handling to supply chain security and cyber hygiene. That thinking is half the work, and it is exactly why the spreadsheet is an ideal starting point.

The problem, then, is not the content but the limitations of the tool.

What a spreadsheet cannot do

A judgement in a cell, say "compliant", leaves three questions unanswered, and those are precisely the questions an auditor or client will ask. The first question is why the requirement is met: the rationale is missing, or it lives in the head of whoever filled in the cell. The second question is where the evidence is: the policy document, the configuration screenshot or the test report sits somewhere in a folder or mailbox, but not with the judgement. And the third question is whether the picture is still current: a spreadsheet starts ageing the day you save it, and nobody gets a signal when the review date of a policy passes or a control is never tested.

There is also a fourth limitation that only becomes visible later: a spreadsheet knows no coherence. The risk does not know which controls cover it, last month's incident has not adjusted the risk assessment, and the supplier that made the news at the end of last year is not linked anywhere to the processes that depend on it.

From filling in to demonstrating in three steps

The move from a static overview to a demonstrable register is smaller than it seems, precisely because the thinking has already been done.

The first step is to import what already exists. Take the existing spreadsheet as the starting point and convert every requirement into a status line with an owner. What was "compliant" stays compliant; it merely gains a rationale field and a fixed place for evidence.

The second step is to attach the evidence to the judgement. Every "compliant" without evidence remains an opinion. So link the document, the screenshot or the reference to its location per requirement. From that moment on, an auditor's question is no longer a search of weeks but a matter of one click.

The third step is to switch on the monitoring: review dates on policies, test dates on controls and end dates on exceptions. You do that not because the standard prescribes it, but because it is the only way the register stays current without anyone having to think about it every week.

Are you done then?

No, and that is fine. Being demonstrably in control is not a finish line but a rhythm: you detect what changes, you assess what it means, you resolve what is missing and you demonstrate what is in place. You recognise the organisations that have found that rhythm by one thing: when a client or regulator unexpectedly asks for the file, nobody starts searching; somebody exports.

The spreadsheet was a good start. The goal is being able to show it.