What may at first glance look like a highly IT-technical task, on closer inspection requires both significant business knowledge and support from the traditional disciplines involved in the sound management of information, documents and data – hereafter, for simplicity, simply referred to as “data”. It is this information-management perspective on NIS 2 that we will examine more closely in a couple of articles. In this first article, we look at the requirements and issues that the rules directly and indirectly give rise to in the management of data, and how we can identify the data on which the company is particularly dependent – the data we will refer to as “critical data” in this article.

Introduction: What is NIS 2 fundamentally about?

And why can you, as someone who works with the company’s data, documents and information, contribute?

NIS stands for Network and Information Systems. NIS 2 is the EU’s second directive on cybersecurity in network and information systems.

The fundamental purpose of NIS 2 is to ensure that companies and organisations on which society depends are sufficiently resilient to cyberattacks, system failures and other digital incidents. It covers a number of sectors, including energy, transport, healthcare, financial market infrastructure and digital infrastructure.

NIS 2 sets requirements, among other things, for how the companies and organisations covered by the directive must manage cybersecurity risks, prevent and handle incidents, ensure business continuity and report significant incidents. The requirements cover technical, operational and organisational measures.

What do the rules say – directly and indirectly – about data?

The NIS 2 Act defines a network and information system. The definition consists of three parts:

a) an electronic communications network,

b) devices that, by means of software, process digital data, and

c) the digital data stored, processed, retrieved or transmitted by these elements.

The wording of the law in point c is:

“Digital data stored, processed, retrieved or transmitted by elements in points a and b for the purpose of their operation, use, protection and maintenance.”
(Source: NIS 2 Act, Section 3, no. 21, point c – NIS 2 Act = Act no. 434 of 6 May 2025).

With regard to network and information systems, the NIS 2 Act states that the companies and organisations covered by the legislation must implement appropriate and proportionate technical, operational and organisational measures to manage the risks to their security. This includes, among other things, incident handling, business continuity, backup and recovery, supplier security, access control and asset management.

And what does security mean when we look specifically at the data? Here, the law is very direct. In the definition of security in network and information systems, it states that the systems must be able to withstand events that may be:

“[…] detrimental to the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data […]”
(Source: NIS 2 Act, Section 3, no. 28).

This means that the protection of data is not merely something we infer from the rules. The availability, authenticity, integrity and confidentiality of data are explicitly part of the concept of security on which NIS 2 is based.

So there is a clear task within the field of information management: to contribute to identifying and protecting the data involved in the operation, use, protection and maintenance of the systems.

But there is also a less direct – and equally important – information-management task.

NIS 2 includes requirements for, among other things, incident handling, business continuity, backup and recovery, crisis management, supplier security, access control and asset management. To perform these tasks in practice, the company depends on information whose importance does not necessarily stem from the fact that it is directly processed in the systems supporting operations, but from the fact that it is necessary to operate, protect, handle incidents involving, or recover the systems and the services they support.

This could, for example, be operational and contingency procedures, plans for emergency operations and recovery, information about system and supplier dependencies, contact and escalation lists, overviews of critical assets, recovery priorities, configuration information or documentation that tells employees what to do when normal operations are no longer functioning.

It is therefore not sufficient simply to look inside the systems and ask what data they contain. We also need to look around the systems: at the workflows, people, suppliers and information needed to keep operations running or restore them after an incident.

Some of this information may only prove to be truly critical when the normal situation breaks down. A contingency procedure that is almost never used in day-to-day operations may, for example, be essential during an incident. The same may apply to an up-to-date contact list or documentation describing how a critical service is operated manually until the normal systems are available again.

NIS 2 does not explicitly state that the company must create a specific category called critical data. But when the requirements are translated into practice, there is a fundamental question that is difficult to avoid:

What data and information does the company depend on to maintain its critical processes and services – both during normal operations and when something goes wrong?

These are what we refer to as critical data in the following.

What information-management questions does NIS 2 raise?

When we translate the requirements into the practical management of data, a number of questions become relevant. This is not a legal checklist, but an information-management way of breaking down the issue:

Criticality: Which data do the company’s critical processes and services depend on – both during normal operations and during an incident?

Dependencies and availability: Where is the critical data located, which systems and suppliers do we depend on to access it, and can the right people access it when needed?

Confidentiality, integrity and authenticity: Is the data protected against unauthorised access and changes, and can we trust that it is complete, genuine and comes from the source we believe it does?

Recovery: If data or systems become unavailable, can the information be recovered in a way that means it can still be understood and used?

Responsibility, control and documentation: Is it clear who is responsible, which requirements apply to the management of the data, and can the company document that the necessary controls actually work?

In this first article, we begin with the first question: Which data is critical – and how do we find it?

How do we find the critical data?

The starting point is the company’s operations. Before we can identify the critical data, we need to know which processes and services the company depends on being able to maintain.

Here, we can use the landscapes and analyses that the company hopefully already works with as a starting point. For example, there may be a process landscape describing the key business processes and a system landscape showing which IT systems support them.

The key point for our further work is that the critical processes and services have been identified.

And here we need to remember the point from earlier: It is not only about the processes supported by the critical systems. It is also about the workflows around the systems that are necessary to keep operations running, protect them or maintain emergency operations if the normal systems are not functioning.

Once the critical processes have been identified – with the business as a central participant – we can begin to look at them through an information-management lens.

For each process, we can ask: Which data, documents and other information must be available for the process to function? And correspondingly: Which information must be available if the process has to switch to emergency operations?

This can be identified through workflow analyses. We follow the individual process and look at what information comes in, what information is used along the way, what is produced, and which information employees depend on to carry out their work.

The result is a picture of the information and data groups on which the company’s critical processes and services depend. These are the company’s critical data.

Where is the critical data located?

Once we have identified the information and data groups on which the critical processes depend, the next question is: Where are they located?

Here, the company’s IT or system landscape is an obvious starting point. It typically shows which systems the company uses, how they are connected, and which business areas or processes they support.

From an information-management perspective, however, a layer is often missing. A system landscape can tell us that the company uses, for example, SharePoint, an ERP system, a maintenance system and a number of specialised systems. It does not necessarily tell us which information groups are actually located in each system.

We can therefore review the system landscape system by system and describe which types of information are stored in them. Under SharePoint, for example, it should not simply say SharePoint, but also include information groups such as operational documentation, contingency plans, customer agreements or technical instructions. The same is done for the other systems and information environments.

Once this has been done, we have an information landscape: a consolidated overview of the company’s information groups and where they are located.

Only then can we connect it back to the workflow analysis.

Here, we have already identified which data the critical processes and services depend on. We can now use the information landscape to determine where this critical data actually resides.

Now we know what needs to be protected

In this way, we identify both the data the company depends on and its location in the landscape where it needs to be protected, accessed and potentially recovered.

The mapping can also reveal dependencies that are otherwise easy to overlook. Critical data may, for example, be distributed across several systems, held by an external supplier or depend on specific integrations in order to be usable at all.

We have therefore, in principle, answered what is critical in the NIS 2 context we are examining here.

But there is an important distinction. A company may have other information that is business-critical for other reasons – for example, because its loss could have serious legal or financial consequences in the longer term. This information will not necessarily be identified through the analysis we are conducting here. Our focus is on the data the company depends on to operate, protect and recover the processes, systems and services that are relevant in the context of NIS 2.

With that distinction, we have created a foundation for moving from identifying the critical data to deciding how it should be managed and protected. In the next article, we look at how we can describe the critical data more precisely and use classification to translate our knowledge of it into concrete requirements for its management.