NIS2 in Practice: What a Company Actually Has to Put in Place

Who falls under NIS2 and what changes for management#

NIS2 introduces an obligation to manage cyber risk across a wide range of sectors, and whether a company is directly or indirectly bound depends on its size and industry. In practice, this means management has to take personal ownership of security decisions, not just delegate them to IT. A board or director needs to be able to explain that measures were chosen based on a risk assessment, not chance.

The first task for management is working out whether the company falls under the scope directly, or whether it is part of the supply chain of a company that does. Many mid-sized suppliers of equipment, services and software feel the effects of NIS2 indirectly, because their customers write the same security requirements into contracts that they themselves must meet. It is worth asking who the company's key customers are and what security clauses already sit in those contracts.

Once it is clear the company falls under the legislation, the next decision is who inside the organisation owns compliance. This is not something one internal memo can settle - it requires a clear split of roles between management, IT, legal, and where relevant an external partner. Without that split, nobody ends up tracking incident-reporting deadlines or keeping the risk assessment current.

For organisations that are part of a group or run multiple business units, it also has to be decided whether requirements apply to the whole group or to each legal entity separately. That decision shapes how risk management is organised, who prepares reports, and who is the contact point for the supervisory authority. Unclear boundaries between a parent company and its subsidiaries are one of the more common problems in putting these requirements into practice.

System inventory and risk assessment as the foundation#

Before a company can decide on concrete security measures, it needs to know which systems, data and processes are critical to operations and how they connect to one another. Mapping information systems - including ERP, CRM, production systems and document systems - is the first concrete step NIS2 requires in practice. Without that inventory, a risk assessment stays generic and fails to show where the company is actually exposed.

A risk assessment has to cover technical vulnerabilities as well as organisational ones - for example, what happens if a key service provider fails, or an employee with broad access leaves without a proper handover of access rights. The result is not a document for a drawer, but the basis on which management decides where to direct security spending ahead. Companies that treat the assessment as a one-off exercise soon find it goes stale, because systems and suppliers change faster than the document does.

When connecting existing systems such as ERP, CRM and document systems, it is also worth assessing where API integrations open additional paths to data. Every new connection between systems is also a new point that belongs in the inventory and the risk assessment. Companies that add connections without reviewing the whole architecture struggle later to prove they have control over where data actually flows.

A risk assessment is never really finished - it needs repeating after any significant system change, new integration, or change of key supplier. Companies without an internal process for keeping the assessment current often turn to an external partner who takes on the review of architecture, infrastructure and data, and maintains the assessment together with the internal IT team.

• List of all business-critical applications and their owners
• Connections between systems via APIs and data exchanges
• Where data is stored and how it is retained
• List of external suppliers with access to systems
• Impact assessment of downtime for each system separately

Access and identity management#

One of the most commonly overlooked parts of NIS2 in practice is control over who has access to which system, and why. Companies with several departments and years of accumulated user rights often do not know precisely who can reach financial, HR or production data. Proper access management is one of the few measures that reduces risk and makes everyday IT work easier at the same time.

In practice this means clear rules for granting, changing and revoking access, especially when an employee or external collaborator leaves. Access that stays active after someone has left the company is one of the most common causes of an incident that could have been prevented without any new technology, simply through an orderly process. It therefore makes sense to tie access to a role rather than a person, which makes handover and revocation simpler and repeatable.

For systems handling sensitive or business-critical data, it is worth adding an extra layer of identity verification and separating development, test and production environments, so that not everyone testing a new feature has access to real data. That separation is also one of the things a company needs in order to demonstrate control over where real customer or employee data actually resides.

Access management is where the difference shows between a company that treats NIS2 as paperwork and one that treats it as a change in working habits. The first drafts an access policy nobody follows; the second builds a process IT actually runs every time there is a personnel change. The latter requires HR and IT to work together, since news of someone leaving has to reach the people managing access the same day.

Detecting incidents and reporting to the authorities#

NIS2 requires a company to be able to detect an incident and then notify the competent authority in stages - a brief early warning first, followed by a more detailed report and finally a closing report with root-cause analysis. In practice this means someone, or some team, has to be designated to decide whether an event even crosses the threshold for mandatory reporting.

Without a way of detecting unusual activity on the network, a company often only learns an incident happened once the consequences already show externally - a service outage, or customer complaints. Detection is therefore closely tied to infrastructure monitoring and event logging that can be reviewed after the fact. Companies without their own security operations function often hand this task to an external partner who monitors activity and triggers the internal notification process against agreed criteria.

Just as important as technical detection is the internal procedure: who must be informed within the first hour, who drafts the report for the authority, and who talks to customers if the incident affected them. This procedure has to be written down in advance and rehearsed, because during a real incident, improvising costs the most time exactly when there is least of it to spare.

Companies that are part of a larger customer's supply chain often have to notify that customer directly, in addition to the authority, because of security clauses in the contract between them. It is worth deciding in advance, within the internal procedure, which incidents trigger an obligation to the customer and which only to the regulator, to avoid both unnecessary disclosure and, conversely, delayed notification.

• A clearly designated person or team who judges the severity of an event
• A process for gathering evidence and logging how the incident unfolded
• A contact list: authority, key customers, management
• Templates for the early warning and for the detailed report
• A way of communicating with staff and customers during the incident
• A post-incident review that feeds back into the procedures

Business continuity and recovery after an incident#

Beyond preventing incidents, NIS2 also requires a company to be able to keep operating if one happens anyway. That means having a plan for restoring key systems, for who takes decisions if management is unreachable, and for how to communicate externally until systems are back. A business continuity plan is not the same as a data backup, even though the backup is part of its starting point.

In practice, many companies have backups but no tested recovery procedure - the backup exists, but nobody has ever actually tried to restore a system from it under time pressure. A recovery drill, run in advance rather than during a real outage, is one of the more concrete pieces of evidence that a company takes its plan seriously. Such a drill often surfaces bottlenecks invisible on paper, such as a restore that depends on access only one person has.

For companies with multiple sites or production plants, it also has to be decided which processes can temporarily run manually until the information system is restored, and who makes that call. That decision belongs with the heads of the departments affected, not just IT, since they understand the consequences of downtime for production or procurement better than anyone else. Involving department heads in drafting the plan also makes it more likely the plan gets used for real, rather than filed away.

It is worth aligning the continuity plan with customer and partner requirements too, since many contracts already ask for proof that a supplier has one in place. A company that maintains and tests its plan regularly can use that as an argument when pursuing new business in industries where supply-chain security is a condition of doing business - otherwise, the plan tends to get thrown together in a hurry the moment a customer asks for it before signing.

Supply chain and contractor security#

NIS2 does not treat a company as an isolated entity but as part of a chain of suppliers and partners, so a company also has to assess the risk brought in by external providers with access to its systems or data. In practice this means reviewing existing contracts and asking which suppliers actually access which systems, and whether they have their own security in order. It is surprisingly common to find more external partners with internal access than management expected, added gradually over time and never reviewed together.

For new contracts, it is worth defining security clauses upfront - how the partner handles data, how quickly they must report an incident on their side, and who is liable if data is lost due to their error. These clauses are easier to build into a new contract than to add retroactively to an existing relationship; companies that only add them after an incident often find the old contract does not clearly allocate responsibility, which drags out any dispute.

Suppliers of software and hardware the company does not develop itself present a particular challenge, since the company has to trust their security practices. Requiring documentation, access and passwords as part of every handover helps here, since it lets the company keep track of what was actually delivered and who controls the source code and infrastructure. Without that documentation, a company loses visibility the moment it changes provider and cannot reliably assess the risk that creates.

Supply-chain oversight is not a one-off act - it repeats with every new partnership and every significant change at an existing supplier. Companies with an orderly process for assessing new suppliers before granting them system access avoid a situation where security questions only get raised once the collaboration is already well under way; it is worth running that process together with procurement, since they are the first to meet a new supplier.

• Which systems and data the supplier can access
• Whether the supplier has its own incident-notification policy
• Who is liable for damage caused by the supplier's error
• Whether the contract covers data return or deletion at termination
• Whether system documentation is a contractual obligation of the supplier

Technical and organisational security updates#

Beyond process, NIS2 also calls for concrete technical measures, including regular system updates, vulnerability management and encryption of sensitive data. In practice this means a company needs to know which systems run on outdated software and have a plan for when and how to update them without halting operations. Systems that cannot be updated immediately because they are tied to older production equipment need compensating controls instead, such as tighter access control or isolation in a separately secured part of the network.

The organisational side of updates means changes do not go straight into live use, but pass through review and testing before reaching production. A step that is already standard practice for development teams becomes, under NIS2, a demonstrable obligation - the company has to be able to show a change was not pushed through outside the agreed procedure. In practice that means separate development, test and production environments, and a clear record of who approved a change and when.

For companies with older or unfinished systems taken over from a previous provider, the first step is a review of source code, architecture, infrastructure and data, before it is even possible to judge which security measures are missing. Only on that basis can a company decide whether the system can be upgraded or part of it needs rebuilding from scratch - and such a review often reveals a gap between what management assumed the system supported and what it actually supports.

Technical measures alone are not enough without an organisational framework, since a tool by itself does not prevent an error if nobody maintains or monitors it. It makes sense to tie technical updates to ongoing monitoring, bug fixing and further development, which a company can run itself or hand to an external partner after go-live. Deciding who looks after security updates after launch is a decision better made before the project closes than after the first incident.

Staff training and management accountability#

Technology does not solve the risk created by an employee who does not recognise a phishing email or shares a password with a colleague for convenience. That is why NIS2 also requires training tailored to role in practice - different for someone running a production system than for someone in finance or HR. Generic training everyone completes once a year, disconnected from their actual job, rarely changes the behaviour behind most incidents.

Under NIS2, management is personally responsible for measures being in place and maintained, which means it also has to keep up with the basics of cybersecurity itself, rather than just signing off reports IT prepares. That does not mean a director needs to understand technical detail, but it does mean knowing which questions about risk to ask - a board that never asks them will struggle, after an incident, to claim security was properly delegated to specialists.

Training is worth repeating after any major system or process change, since a new tool often brings new risks an old training programme does not cover. It also helps to supplement training with short, recurring reminders rather than a single lengthy session employees forget within weeks - brief, frequent exercises, such as checking how staff spot a suspicious message, give a better picture of real readiness than a one-off knowledge test.

Documentation and proving compliance#

In practice, NIS2 also means a company has to be able to prove, not just claim, that it meets the requirements - with a written risk assessment, a record of system changes, training logs and evidence that security measures have been tested. Documentation produced only when the supervisory authority asks for it rarely convinces, because it lacks a dated trail over time; it is better built continuously, as a by-product of everyday work, rather than as a separate project just before an audit.

Part of that documentation is a clear split of ownership - source code and data remain the customer's property, while documentation, access and passwords are part of every handover, regardless of whether a system is built by an internal team or an external provider. Without that split, a company risks losing access to its own system or data the moment it changes provider, so clear contractual terms on ownership matter as much as the technical measures themselves.

An audit trail is useful independent of the legislation too, since it helps with troubleshooting - if it is clear when a change went in and who approved it, it is easier to find the cause when something stops working as expected. Companies that keep documentation consistently often find it also shortens the time spent resolving everyday technical issues, not just the time spent preparing for an audit.

Choosing a partner for implementation#

Because NIS2 requires processes, technology and accountability to be addressed together, there is rarely a single department that can carry the task alone. In practice, companies choose between building up internal IT and bringing in an external partner to take on one part of the work - from the system inventory to setting up incident-handling procedures - or the whole project. The choice depends on how much in-house expertise already exists and how much time the team can give the project alongside its regular work.

When choosing a partner, it is worth checking whether they can take over an existing or unfinished system after reviewing source code, architecture, infrastructure and data, not just build new. It is equally worth asking how they separate development, test and production environments and how they handle data in the test environment, since that directly affects security during development itself - a partner who cannot answer clearly probably does not separate environments strictly enough in practice either.

It is just as important to agree what happens after go-live - who takes over monitoring, bug fixing, technical and security updates and further development, and what classes of issue apply, from an outage down to a minor change request. Defining those classes upfront prevents disputes later about what is urgent and what can wait; a company that only defines them during its first serious outage often finds its expectations and the provider's do not match.

Since the cost of an NIS2 implementation project depends on scope of functionality, the number of connected systems, testing requirements and the level of post-launch support - not a single flat number - it makes sense to start with a short analysis that breaks the scope into manageable parts. That approach lets each part be scoped and delivered separately, instead of the company waiting on one large estimate for the entire project.

• Whether they can take over an existing system after reviewing code and infrastructure
• How they separate development, test and production environments
• Who is responsible for support and bug fixing after go-live
• What issue classes they use and how they set priority
• How documentation, access and passwords are handed over