NIS2 in practice - what security measures and procedures should a company implement?
In the first part of this series, we explained what NIS2 is and which companies may be subject to the new requirements. If an organization is already in the preparation phase, a more practical question arises: what exactly needs to change in the company's day-to-day operations?
NIS2 doesn't mandate a single program, firewall, or off-the-shelf security suite. It requires a risk-based approach—technical, operational, and organizational measures must be appropriate to the scale of the business and the threats. In practice, this means streamlining several areas that often already exist within the company, but are not always consistent, regularly reviewed, or well-documented.
The Polish amendment to the Act on the National Cybersecurity System has been in force since April 3, 2026. Entities that met the criteria for a key or important entity on that date have until April 3, 2027 to implement the main obligations. The Ministry of Digital Affairs describes this schedule and scope of responsibilities on gov.pl.
1. Access and Accounts - Start with Who Can Do What
In many companies, the biggest problem isn't a lack of advanced security, but rather excessive permissions. Employees have access to resources they no longer need, old accounts remain active, and administrative accounts are used for regular day-to-day work.
When implementing NIS2, it's important to start with the principle of least privilege. Each user should have access only to the data and systems they need to perform their duties. Administrative access should be limited, and accounts of those leaving the company should be disabled according to established procedures.
The second element is multi-factor authentication, or MFA. This is particularly important for email, cloud services, VPNs, administrator accounts, and internet-accessible systems. A strong password alone no longer provides sufficient protection if it is compromised through phishing or a breach.
If your company uses a Windows domain, Active Directory, or Microsoft 365, it's a good idea to organize groups, roles, and access policies. A review can also be helpful. user and access management, especially if the environment has been developing for several years without regular permissions review.
One of the areas addressed in NIS2 is business continuity, including backup and disaster recovery management. From a business perspective, the question is simple: how long can a company operate without critical systems, and how quickly can they be restored?
Performing a backup alone doesn't provide the answer. You need to know what's being copied, how long the data is stored, who can delete the copies, and whether part of the backup is separated from the production environment. In the case of ransomware, a copy accessed from the same account may be encrypted along with the server.
The most important test, however, is recovery. A company should regularly verify that files, a database, a virtual machine, or an entire server can actually be recovered from a backup. This ensures that the problem is identified during a controlled test, not during a real failure.
In practice, it is worth introducing a schedule testing backups and data recovery procedures and determine which systems need to be restored first.
3. Updates, vulnerabilities and monitoring - security cannot work only after a failure
Another practical area is system maintenance. Computers, servers, network devices, applications, and cloud services require regular updates. Problems arise when a company lacks a single person or team responsible for verifying that updates have actually been implemented.
It's important to separate regular updates from critical vulnerabilities. If a vendor publishes information about a vulnerability being actively exploited by attackers, the company should be able to quickly assess whether it affects its environment and how quickly a fix or workaround can be implemented.
Monitoring is equally important. NIS2 doesn't assume that every incident can be stopped. However, a company should be able to detect unusual events: multiple failed logins, a sudden configuration change, a service stoppage, a lack of backups, or server overload. The sooner a problem is detected, the easier it is to mitigate its effects.
For smaller organizations, this doesn't always mean building their own security center. Some tasks can be performed within monitoring and maintenance of IT infrastructure, if the scope of monitoring and the method of response are clearly defined in advance.
4. Incident Response Procedure - What do we do in the first hour?
A cyber incident doesn't usually begin with a message saying, "An attack is underway." More often, an employee reports a suspicious message, someone loses access to files, the system begins behaving erratically, or an administrator notices a login from an unknown location.
Therefore, the response procedure should be simple and usable even by non-technical users. Employees must know where to report suspicious incidents. The technical team should know who makes the decision to disconnect a device, block an account, or stop service. Management should also know when a situation requires escalation and formal reporting.
A good procedure should include, at a minimum, incident identification, securing evidence and logs, mitigation, service restoration, and a brief post-incident debriefing. The latter is important because it allows for improved security based on a real event, not just theoretical scenarios.
For entities covered by the National Cybersecurity System (KSC), reporting serious incidents to the appropriate entities in the national cybersecurity system is also crucial. Therefore, an organization should determine in advance who is responsible for incident assessment and external communication, rather than making these decisions only in a crisis situation.
5. IT providers and the supply chain - a company's security does not end with its own network
A company can have well-secured computers and servers yet remain vulnerable to attacks from external providers. This applies to IT companies, software providers, hosting providers, cloud providers, ERP systems, monitoring providers, and remote infrastructure providers, among others.
NIS2 identifies supply chain security as one of the elements of risk management. In practice, this doesn't mean sending a multi-page survey to every supplier. First, it's worth identifying which suppliers have a real impact on key systems and data.
For such entities, it's crucial to verify the scope of access, login method, responsibility for updates, incident reporting policies, and the possibility of revoking access after termination. "Just in case" service access, left unchecked for years, is precisely the kind of risk worth eliminating.
Well-configured security measures are important, but a company must also understand who is responsible for them and how they are verified for their effectiveness. NIS2 therefore encompasses not only technology but also processes, people, and management accountability.
Documentation shouldn't be created solely for audit purposes. It should support daily work. A short list of system owners, a procedure for granting access, a backup test schedule, or incident reporting instructions are far more valuable than a lengthy document that no one in the company uses.
The same applies to training. Employees don't need to know the details of the KSC Act. However, they should recognize typical phishing attempts, know not to accept unexpected MFA requests, and be able to quickly report a suspicious event. Management should understand business risks and make decisions regarding priorities and resources.
How to check what is missing in your company?
The biggest mistake in implementing NIS2 is trying to fix everything at once. In most companies, some security measures are already in place. The problem is more of a lack of consistency: backups exist, but they haven't been tested; MFA works in Microsoft 365, but not over VPN; monitoring covers the server, but no one responds to alerts; the vendor has remote access, but no one knows which account they're using.
Therefore, a readiness audit is a good first step. It shouldn't end with just a list of errors. Its value lies in prioritizing actions: what needs to be improved immediately, what can be planned for the next stage, and which solutions are already serving their purpose.
In our work, we can begin with a technical review of the environment—accounts and permissions, backups, servers, network devices, Microsoft 365, remote access, and monitoring. We can then combine the results with organizational requirements and develop a realistic change plan. This ensures that NIS2 implementation doesn't become a "buy everything from scratch" project, but rather a process of prioritizing the company's most important risks.
The most important outcome shouldn't be obtaining a compliance certificate. A company should simply have a better understanding of what it protects, who has access, how it detects a problem, and what it will do if, one day, its security measures prove inadequate.
A short checklist before further implementation
- • Is MFA enabled on your most important accounts and services?
- • Are user and administrator permissions reviewed regularly?
- • Was the backup tested and not just executed?
- • Does the company monitor critical systems and respond to alerts?
- • Is there a simple procedure for reporting and handling an incident?
- • Is remote supplier access controlled and quickly retrievable?
- • Is it clear who is responsible for key security systems and decisions?
- • Do employees know how to report phishing or suspicious logins?
