NIS2 in practice: what a company really has to document

1. Having rules is not enough - you also have to show that you follow them

When preparing for NIS2, the conversation often starts with technology: security solutions, audits and new systems. But an important part of compliance also consists of documented procedures, clear responsibilities and evidence that the agreed measures really are carried out in practice.

A good starting question is therefore: what could you show if you had to explain tomorrow how you manage risks, incidents, access and suppliers?

This article gives a practical process overview and is not legal advice. The scope of the obligations depends on your activity, your size, the position of your organisation and the applicable national legislation, so it should be checked with a qualified specialist or the competent authority.

2. An inventory of services, systems and responsibilities

A useful inventory is not just a list of devices or applications. It has to connect business services with systems, data, dependencies and the people responsible.

For every important service it should be clear:

• which systems and suppliers support it,
• who owns the service, the system and the data,
• what the consequences of an outage would be,
• where the data is processed and who has access,
• which fallback procedures are available.

An inventory without named owners is mainly just a list. During an incident it is essential that it is immediately clear who decides and who has to act.

3. The incident handling procedure

The procedure has to describe the whole sequence: detecting the event, the initial assessment, classification, containing the consequences, notification, resolving the problem and the closing review.

For significant incidents, NIS2 provides for multi-stage reporting: an early warning within 24 hours, an incident notification within 72 hours and a final report generally no later than one month. How this works in practice also depends on national arrangements and the guidance of the competent authority.

Because the deadlines are short, it has to be settled in advance:

• who judges whether an incident is significant,
• who approves and submits the notification,
• who deputises for the person responsible,
• where the data and evidence are collected,
• how deadlines and follow-up tasks are tracked.

The criteria have to work under time pressure too

Assessing an incident must not rest on one person's instinct alone. Criteria set in advance can include the duration and extent of the disruption, the number of users affected, the impact on key services, the type of data affected and any cross-border consequences.

4. Suppliers and the supply chain

Organisations have contracts with their suppliers, but often have no single overview of which services those suppliers support, which systems they access and what risks they present.

For important suppliers it is worth recording:

• the services and systems they support,
• the type and extent of their access,
• the owner of the supplier relationship,
• the obligations agreed in the event of an incident,
• the date of the last review and the validity of access rights.

Particular attention is needed for access rights that stay active after a project ends or the working relationship changes.

5. The difference between a policy and evidence

A policy describes how the organisation should act. Evidence shows that it did act that way. An effective system needs both.

Typical pairs are:

• a backup policy and a record of a successful restore test,
• a business continuity plan and the minutes of an exercise that was carried out,
• an awareness programme and a record of the training delivered,
• an access management procedure and an audit trail of approvals and revocations,
• an incident handling procedure and a log of the incidents that actually occurred.

Good evidence cannot be created retrospectively. It has to build up as part of everyday work.

6. Where the system most often gets stuck

In practice, similar problems keep appearing:

• inventories are out of date and depend on one person,
• incidents are handled by e-mail and chat with no single record,
• deadlines are not linked to reminders and named owners,
• supplier access has no set review or revocation date,
• evidence is scattered across different folders and departments.

These are not merely technical shortcomings. Above all they are a sign that the process, the responsibilities and the way records are kept have not been defined clearly enough.

7. How to build the requirements into a traceable process

Start by documenting the way you actually work. Then define the people responsible, the criteria, the deadlines and the evidence required. Only then choose the tool that will support the process.

In a well-structured system, every incident has its own status, owner, deadlines, decision history and associated evidence. Reminders are created automatically, and the report is assembled from the data that built up while the incident was being handled.

A good indicator of maturity is simple: if you can gather the required evidence without a special project and a lengthy search, the process is probably set up well.

8. A BizIT example

To support a process like this, we developed the ComplyIT solution together with a partner. It allows incidents to be recorded and classified, deadlines to be tracked and data to be prepared for reporting. The tool does not replace the agreed procedure, but makes sure that it is followed traceably and on time.