Who is bound, and how strictly
Directive (EU) 2022/2555, known as NIS2, applies to public and private entities in the sectors listed in its Annexes I and II. As a rule it covers medium-sized and larger enterprises: in practice, those with at least 50 employees, or with both an annual turnover and a balance-sheet total above €10 million. Some categories are covered regardless of size, among them providers of public electronic communications networks and services, trust service providers, top-level domain name registries and DNS service providers (Article 2).
In-scope entities are classified as essential or important. Articles 21 and 23 apply to both. The categories differ in supervision, which is proactive for essential entities and largely reactive for important ones (Articles 32 and 33), and in the ceiling for administrative fines: at least €10 million or 2% of total worldwide annual turnover for essential entities, and at least €7 million or 1.4% for important entities, whichever amount is higher (Article 34).
Member States had until 17 October 2024 to transpose the Directive (Article 41), and several did so late. National law designates the competent authorities and the CSIRT and sets the registration procedure, so the channel through which an entity reports is always national.
Management bodies carry personal responsibility. They approve the cybersecurity risk-management measures, oversee their implementation, can be held liable for infringements, and must follow training (Article 20). For monitoring, this moves the question from whether a tool is installed to whether the management body can show that the measures work.
Article 21: monitoring as evidence for the measures
Article 21(1) requires "appropriate and proportionate technical, operational and organisational measures", taking into account the state of the art, the cost of implementation, the entity's exposure to risk, its size, and the likelihood and severity of incidents. Article 21(2) then sets the minimum the measures must cover:
- (a) policies on risk analysis and information system security;
- (b) incident handling;
- (c) business continuity, such as backup management and disaster recovery, and crisis management;
- (d) supply chain security;
- (e) security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure;
- (f) policies and procedures to assess the effectiveness of the measures;
- (g) basic cyber hygiene practices and cybersecurity training;
- (h) policies and procedures on cryptography and, where appropriate, encryption;
- (i) human resources security, access control policies and asset management;
- (j) multi-factor or continuous authentication, and secured voice, video, text and emergency communications, where appropriate.
The Directive prescribes outcomes, not products, and encourages the use of European and international standards (Article 25). Monitoring data is direct evidence for four of the ten areas. For incident handling (b), it is the detection layer and the first record of what happened. For business continuity (c), it shows whether backups ran and whether services returned within their targets. For the assessment of effectiveness (f), measured availability, alert volumes and response times are the closest an organisation gets to an objective metric. For asset management (i), an inventory built from discovery data such as SNMP and LLDP stays more current than one maintained by hand. For the other areas monitoring supplies inputs at most: a supply-chain policy (d) or a cryptography policy (h) is written, approved and reviewed by people.
The digital-infrastructure rules: logging made concrete
For one group of entities, the Commission has turned Article 21(2) into detailed technical requirements. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 applies to DNS service providers, TLD name registries, cloud computing and data centre service providers, content delivery network providers, managed service providers and managed security service providers, providers of online marketplaces, online search engines and social networking platforms, and trust service providers. Point 3.2 of its Annex, on monitoring and logging, is the most precise statement in EU law of what monitoring has to achieve. In summary, these entities must:
- lay down procedures and use tools to monitor and log activity on their network and information systems, so as to detect events that could be incidents and respond to them (3.2.1);
- automate monitoring, continuously or at periodic intervals, keeping false positives and false negatives to a minimum (3.2.2);
- log, where appropriate, inbound and outbound network traffic, the creation, modification and deletion of users and the extension of permissions, access to systems and applications, authentication events, privileged access and administrative activity, access to and changes of critical configuration and backup files, logs of security tools, the use of system resources, physical access, access to network equipment, the activation and pausing of logging itself, and environmental events (3.2.3);
- review logs regularly for unusual trends, with alarm thresholds set at appropriate values (3.2.4);
- keep and back up logs for a predefined period and protect them from unauthorised access and change (3.2.5);
- synchronise the time sources of their systems, and make the monitoring systems themselves redundant (3.2.6);
- review the procedures and the list of logged assets regularly, and after significant incidents (3.2.7).
Two of these requirements are easy to underestimate. Clock synchronisation is what makes a timeline defensible: a 24-hour deadline is measured in timestamps, and logs from devices whose clocks drift cannot reconstruct a sequence of events. Redundancy of the monitoring system means that, for these entities, a single monitoring server is a finding in its own right.
For entities outside this list the Implementing Regulation is not binding. ENISA's technical implementation guidance of June 2025 maps the same requirements to examples of evidence and is a reasonable benchmark for what an assessor will look for.
Article 23: the reporting sequence
Article 23 concerns significant incidents. An incident is significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage (Article 23(3)). Notifications go to the national CSIRT or, where national law so provides, to the competent authority. Where appropriate, recipients of the service who are likely to be adversely affected must also be informed without undue delay (Article 23(1) and (2)).
The sequence in Article 23(4) runs from the moment the entity becomes aware of the incident:
| Step | Deadline | Content |
|---|---|---|
| Early warning | Without undue delay, and within 24 hours of becoming aware | Whether the incident is suspected of being caused by unlawful or malicious acts, and whether it could have a cross-border impact |
| Incident notification | Within 72 hours of becoming aware | An update of the early warning, an initial assessment of severity and impact, and indicators of compromise where available |
| Intermediate report | At the request of the CSIRT or competent authority | Relevant status updates |
| Final report | No later than one month after the incident notification | A detailed description including severity and impact, the type of threat or root cause, applied and ongoing mitigation, and any cross-border impact |
| Progress report | If the incident is still ongoing when the final report is due | Followed by the final report within one month of the incident having been handled |
The CSIRT or competent authority responds without undue delay and, where possible, within 24 hours of receiving the early warning, with initial feedback and, on request, guidance on mitigation (Article 23(5)). The NIS Cooperation Group has adopted common templates for incident reports.
The practical consequence is that the clock starts at awareness, not at confirmation. A team that opens an incident record only once the root cause is understood will routinely miss the 24-hour mark. What the reporting duty asks of operations is modest in technology and demanding in discipline: a timestamped detection, an incident record opened when the entity becomes aware, an append-only timeline of what was observed and done, a recorded decision on significance with its reasons, and report drafts built from that timeline rather than reconstructed afterwards.
What a platform can evidence, and what it cannot
| Obligation | Evidence a platform can produce | What remains a decision of the organisation |
|---|---|---|
| Detect events (Art. 21(2)(b); IR 2024/2690, 3.2.1) | Alerts, syslog and security events with synchronised timestamps | What counts as an incident; alarm thresholds |
| Become aware (Art. 23(4)) | When the incident record was opened, and the alerts linked to it | The moment of awareness in the legal sense |
| Classify significance (Art. 23(3)) | Affected services, duration, users affected, impact data | The determination itself |
| Report (Art. 23(4)) | The timeline and a structured export in the expected format | Approval of the content and the submission |
| Assess effectiveness (Art. 21(2)(f)) | Availability history, SLA reports, alert response times | The assessment method and its conclusions |
| Protect logs (IR 2024/2690, 3.2.5) | Retention settings and a tamper-evident audit trail | The retention policy |
Software that promises to make an organisation "NIS2 compliant" overstates what software can do. Compliance is a property of an organisation's measures and governance, assessed by its competent authority; tools produce the evidence.
Where AtlasEye fits
AtlasEye covers the evidence column of that table for small and mid-sized networks. Each incident has a lifecycle with an ordered timeline and carries the three Article 23 milestones, so the team sees what is due and when. Reports can be exported in JSON or XML prepared for the CSIRTs of the 27 Member States and sent by e-mail. Actions are kept in a hash-chained audit log with a chain-verification check. The Enterprise plan adds an Article 21(2) control assessment that states which inputs are measured on the installation and which are properties of the product. Syslog over UDP and TCP port 514, brute-force and port-scan detection, device and service monitoring and the IP address inventory provide the underlying data. The incident, audit and NIS2 features belong to the Pro and Enterprise plans.
The limits matter as much as the features. AtlasEye runs on a single node without geo-redundant high availability, which an entity bound by Implementing Regulation 2024/2690 must weigh against the redundancy requirement of point 3.2.6. Two-factor authentication is TOTP only. AtlasEye is a tool that supports NIS2-related work; it is not a certification and does not guarantee compliance. For the product details, see AtlasEye for NIS2; for a comparison with other platforms, see Replacing PRTG under NIS2.
Sources
- Directive (EU) 2022/2555 (NIS2), Official Journal L 333 of 27 December 2022: EUR-Lex
- Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024: EUR-Lex
- ENISA, Technical implementation guidance on cybersecurity risk-management measures, version 1.0, June 2025: ENISA
- European Commission, "NIS2 Cooperation Group adopts common templates for incident reporting": digital-strategy.ec.europa.eu
- AtlasEye product facts, verified against version 1.2.341 on 30 September 2026: atlaseye.eu/nis2