The 10 key cybersecurity areas under NIS2
An unusual sign-in to a Microsoft 365 mailbox, an encrypted file server or an unavailable production system are not only IT problems. They are events that can stop sales, halt customer service and put commitments at risk. The ten cybersecurity areas set out in NIS2 give those risks a structure: the emphasis moves from a one-off purchase of security tools to continuously managing security and being able to keep operating despite an incident.
NIS2 is the EU cybersecurity directive – Directive (EU) 2022/2555 – which broadens and strengthens the requirements placed on entities in defined sectors. The directive sets common EU-level expectations, and each Member State transposes it into its own national law. The specific obligations that apply to a given company, along with deadlines, thresholds and supervisory arrangements, come from that national legislation.
Not every organisation falls within scope. It depends on the sector, the type of activity, the size of the entity and criteria set in national law. It is still worth treating the NIS2 measures practically even where a company is not yet certain whether it is directly covered – business partners, customers and insurers increasingly expect a similar level of security maturity regardless.
What the ten NIS2 areas actually are
The ten areas come from Article 21(2) of the directive. They are not a shopping list of products or a fixed technical design. They are risk-management measures that should be appropriate and proportionate to the risk, the scale of the business and the potential consequences of an incident.
1. Risk analysis and security policies
A company should know what it protects and what it protects it from. In practice that means identifying key systems, data, privileged accounts, suppliers and business processes, then assessing risk scenarios – mailbox takeover, ransomware, a cloud provider outage, a leak of documentation.
Security policies should translate that assessment into day-to-day rules. In a smaller company they do not need to fill a binder. They should clearly set out how passwords and multi-factor authentication are handled, who has access to what data, how systems are updated and how suspicious events are reported.
2. Incident handling
Detecting an incident is not enough on its own. The organisation has to know who makes decisions, who disconnects an affected computer, how evidence and important information are preserved, and how management, customers or the relevant authorities are informed when the situation requires it.
The response procedure should be short, tested and available even when company email or the file server is down. It helps to separate incidents by priority. A phishing message reported by one employee calls for a different response from active encryption of data on a server.
3. Business continuity, backup and recovery
NIS2 covers business continuity, crisis management, backups and disaster recovery. That distinction matters: a backup on its own does not guarantee a fast return to work. You also need to know whether it can be restored, how long bringing systems back will take and which services take priority.
For an accounting firm the priority will be accounting systems and client documents. In a manufacturer, production planning systems, network access and supplier communication may be equally critical. A recovery plan should follow real operational needs, and its assumptions are worth testing periodically.
4. Supply chain security
A company’s security also depends on its software vendors, cloud providers, IT support and anyone with remote access to its systems. In practice this does not mean running an extensive audit of every partner. It does mean consciously assessing who has access to important data and infrastructure, and what happens if the incident occurs on the supplier’s side.
Practical steps include reviewing third-party permissions, setting rules for remote access, checking how suppliers report incidents and defining responsibilities in contracts. Pay particular attention to suppliers whose outage could stop a key business process.
5. Secure acquisition, development and maintenance of systems
This area covers security when choosing, deploying and maintaining IT systems, along with vulnerability management. In an SME it often comes down to a simple but consistent habit: before a new tool goes live, check what data it will process, who gets access, whether the vendor provides updates and how discovered vulnerabilities will be handled.
Companies developing their own applications also need secure development practices. Where the business runs mainly on off-the-shelf systems, what matters most is patching, correct configuration and removing unused accounts and services.
6. Assessing the effectiveness of security measures
A policy that is never checked quickly becomes an archive document. NIS2 points to the need to assess how effective the measures in place actually are. That can be done through audits, configuration reviews, penetration testing, incident response exercises and reviewing what monitoring is producing.
The scope of this work should match the real risk. A company with a dozen employees does not need to copy the model of a large corporation. It should, however, regularly confirm that the basics genuinely work: that backups restore, that multi-factor authentication is configured correctly, and that critical devices and systems are patched and monitored.
7. Cyber hygiene and staff training
Many incidents start with a phishing message, a reused password or a login approval clicked without thinking. That is why NIS2 includes basic cyber hygiene and training. Neither should be reduced to a single deck shown once a year.
Short, regular sessions built around situations that actually occur in the company work best. An employee should be able to spot a suspicious payment request, a fake login page or an unexpected call from someone claiming to be a supplier. Just as important is a simple way of reporting incidents without fear of being judged.
8. Cryptography and encryption
Encryption can limit the consequences of a lost device, intercepted traffic or unauthorised access to data. In practice it may cover laptop disk encryption, secure connections to company services, protection of backups and proper key management.
The choice of measures should follow the environment and the level of risk. A law firm handling confidential client documents has different needs from a logistics operator with mobile terminals. Encryption should be applied where it is the appropriate control, as part of a broader approach to information security.
9. Access control, personnel and asset security
Access to systems should match a person’s actual duties. An administrator should not use a highest-privilege account for daily work, and an employee who changes role should not keep access to their previous resources. The same principle applies to contractors and external firms.
NIS2 also covers asset management. A company should have a current picture of its laptops, servers, network devices, cloud accounts and software. Without that, it is hard to protect and monitor the parts of the infrastructure that are genuinely in use.
10. Multi-factor authentication and secure communications
Multi-factor authentication, or MFA, makes it considerably harder to take over an account using a stolen password alone. In practice the areas that need it most are email, administrative accounts, cloud services, VPN and any system holding important data.
NIS2 also points to MFA or other continuous authentication solutions, along with secured communications and emergency communication arrangements, appropriate to the risk and the nature of the organisation.
It is worth deciding in advance how management and the IT team will communicate if the primary tools stop working. It is a small part of the plan that can save a great deal of time during an incident.
Management cannot hand the whole thing to IT
NIS2 markedly strengthens the role of company leadership. The people responsible for managing the entity should approve cybersecurity risk-management measures, oversee their implementation and understand the most significant threats.
That does not mean the board or the owners have to read technical logs themselves. It does mean they should receive intelligible information about risk, incidents, the state of security controls and the priorities for action.
Reporting obligations for significant incidents are another important element. NIS2 provides for an early warning within 24 hours and an incident notification within 72 hours of becoming aware of the event, followed in some cases by a final report. The detailed thresholds, timelines and reporting channels always have to be read against the applicable national law and the circumstances of the specific organisation.
How to start without paralysing the organisation
The most sensible first step is a short assessment of where things stand. Establish which systems are critical, where data sits, which accounts hold broad privileges, whether backups have been tested, and who detects and handles incidents outside working hours.
Only then set the order of work. The biggest improvements often come from practical decisions: turning on MFA, tidying up administrative accounts, patching key systems, testing a restore and preparing an incident response procedure.
The next stage can be continuous monitoring, which helps surface irregularities on computers, servers, firewalls and in cloud environments before they turn into a serious incident or business downtime.
For companies without their own security team, monitoring and event handling can be delivered as SOC as a Service. VIRTUO SOC supports organisations in building that approach, combining 24/7 security monitoring, threat analysis and incident response support with a practical view of what NIS2 asks for.
It is worth being clear, though, that SOC monitoring on its own does not automatically satisfy every NIS2 requirement. A SOC is one element of a security system, and it can support an organisation in detecting and handling incidents, monitoring the IT environment and improving its ability to respond to threats.
The most useful move is not producing a stack of documents for their own sake. It is naming an owner for the preparation work, identifying the critical services, and checking whether the company can actually detect an incident and keep working safely when one occurs. If you would like help mapping that out, get in touch.
Chief Technology Officer (CTO). For security reasons we do not publish authors’ names – articles are signed by role only, without details identifying a specific person.

