NIS2 implementation step by step

Implementing NIS2 is not about buying one tool or assembling a binder of procedures. It is an orderly process of managing cyber risk, meant to help a company limit the impact of incidents and keep operating. For the board it means better control over business risk; for the IT function, clear priorities, ownership and a way of acting when something goes wrong.

NIS2 applies primarily to organisations in the sectors named in the legislation and to the businesses around them. Whether a given company is subject to specific obligations, and to what extent, requires looking at its activity, its size and the national rules currently in force. It is worth treating preparation more broadly, though: as a sensible way of strengthening the company’s resilience to ransomware, phishing, account takeovers and operational downtime.

Where to start

The most common mistake is starting with technology. A company buys an email security product, adds firewall rules or commissions a penetration test, but does not know which processes and assets are genuinely critical. The result is spending that improves one part of the environment without solving the main problems.

The right starting point is a management decision. The board or owner should name someone to coordinate the work, give them access to information and define the scope. In a smaller organisation that might be the operations director, the IT manager or an external vCISO. What matters is that responsibility does not stop at the system administrator. Cybersecurity also covers people, suppliers, procedures and business decisions.

Step 1: Set the scope and inventory your assets

You cannot protect what the company cannot name. So the first task is an inventory: computers, servers, network devices, privileged accounts, business applications, data, backups and cloud services such as Microsoft 365.

A list of devices is not enough on its own. For each asset, answer three questions: who owns it on the business side, which data or process does it serve, and what happens if it stops working for a day. A reception computer is not the same as a production server, an accounting system or a domain administrator account.

At the same stage, describe the dependencies on suppliers. A company may use hosting, an external ERP, an accounting practice, a telecoms operator or an IT services provider. An incident at a partner can halt your own business just as effectively as a failure of local infrastructure.

Step 2: Run a risk assessment, not just a document audit

A risk assessment should combine the technical and the business perspective. Its purpose is not to produce a long table of threats, but to decide which risks the company accepts, which it reduces and which need immediate action.

For example, a Microsoft 365 account takeover can enable fake invoices to be sent to customers, give access to correspondence and enable further phishing. The risk rises if multi-factor authentication is not in use, sign-ins are not monitored and staff do not know how to report suspicious messages.

A good assessment weighs the likelihood of an event, its impact on the business and the controls already in place. Not every gap warrants the same response. A critical vulnerability in an internet-facing system should rank higher than a low risk on an isolated device that processes nothing important. Priorities should be written down, assigned to owners and reviewed periodically.

Turning requirements into practice

After the assessment comes the plan. In an SME a staged approach works best: close the most significant gaps first, then develop processes and tooling. Trying to implement everything at once usually overloads the team and produces controls that exist only on paper.

Step 3: Put the basic controls in place

Access management is the foundation. Each employee should hold only the permissions their work requires, and administrative accounts should be separated from ordinary user accounts. Multi-factor authentication should cover email, remote access, financial systems and administrative accounts first.

Patching is the next area. Establish who watches for vulnerability announcements, how quickly fixes are applied, and what happens to systems that cannot be updated without risking an operational break. In that case compensating measures are needed – restricted network access, additional monitoring or a modernisation plan.

Backups matter just as much. A backup is not effective simply because the job runs automatically. The company has to know whether the copies are complete, separated from the production environment and restorable within an acceptable time. A regular restore test checks not only the technology but the team’s readiness to act under pressure.

Step 4: Build the ability to detect and respond

Many incidents are not noticed at the moment of the break-in. An attacker may spend a long time testing access, taking data or preparing to encrypt systems. It is therefore worth translating the NIS2 requirements into continuous monitoring of key events, rather than periodic log reviews.

Monitoring should cover computers, servers, firewalls, cloud environments and user accounts. The events that matter include unusual sign-ins, repeated failed access attempts, new administrative accounts, antivirus protection being switched off and suspicious data transfers.

Collecting logs does not provide protection on its own. You need alert analysis, the ability to tell a real threat from a configuration error, and a defined response path. SOC as a Service can be a practical answer for companies that need 24/7 monitoring but do not want to build their own analyst team. VIRTUO SOC supports organisations with event monitoring, threat analysis and incident response.

Step 5: Prepare incident procedures and test them

An incident response procedure should be short, understandable and available when it is needed. It has to say who makes decisions, who contacts the IT provider, how evidence is preserved and when management, customers or other relevant parties are informed.

The scenarios should reflect what is most likely for the company: phishing, a lost laptop, an account takeover, ransomware, a data leak or a cloud provider outage. There is little point writing one very general document for every situation. Simple instructions for specific events work better, supported by a contact list that also works outside office hours.

Testing is essential, because it exposes the gap between procedure and reality. A short exercise simulating a mailbox takeover can reveal that the company does not know who owns a system, has no current contact details or cannot revoke a user’s session quickly. That is valuable information to have before a real incident. A workable response plan is what makes the difference here.

People, suppliers and board oversight

NIS2 is not solely an IT task. Employees should know how to recognise a suspicious message, who to report it to and why hiding a mistake helps nobody. Training should refer to everyday situations in the company rather than being a one-off presentation.

Supplier risk is worth assessing too. This is not about pushing every obligation onto partners, but about establishing who is responsible for updates, backups, incident reporting and administrative access. Clear agreements reduce the confusion when hours matter.

Management should receive concise information regularly: the main risks, the status of remediation, test results and incidents. That kind of oversight allows decisions based on facts rather than after a problem has already occurred.

A well-planned implementation does not have to start with a large investment. The greatest value often comes from clarifying responsibilities, securing key accounts, proving the backup works and putting monitoring in place so a problem is noticed early enough. Those are the elements worth starting from – and the ten NIS2 measures give you the wider frame. If you would like help mapping it out for your organisation, get in touch with our team.