Monitoring and NIS2: detection, logging, incidents
What Directive (EU) 2022/2555 asks for in incident handling, detection and logging, what it does not say, and the share a monitoring tool such as FirstSI can take on
Directive (EU) 2022/2555, known as NIS2, sets cybersecurity obligations for a large number of European organisations. This guide sums up what the text says about incident handling, detection and logging, then the share a monitoring tool can take on.
It replaces neither the text, nor the law that transposes it in your country, nor the opinion of your national authority.
Who is concerned
The directive covers "essential entities" and "important entities" in the sectors listed in its Annexes I and II. Annex I covers, among others, energy, transport, banking, health, water, digital infrastructure, managed service providers and public administration. Annex II covers, among others, postal services, waste management, chemicals, food, manufacturing, digital providers and research.
As a general rule, it applies from the size of a medium-sized enterprise, within the meaning of Recommendation 2003/361/EC. Article 2 provides for exceptions, in both directions.
Each Member State transposes the directive into its own law. The exact obligations, the timetable and the competent authority therefore depend on your country. In France, ANSSI publishes information on the transposition and on the organisations concerned.
What the text asks for
Article 21: risk-management measures
Article 21 requires "appropriate and proportionate" measures. Its paragraph 2 lists ten of them. Several bear directly on monitoring:
| Point | Measure | Link with monitoring |
|---|---|---|
| a | policies on risk analysis and information system security | indirect |
| b | incident handling | detect, qualify, handle, keep a record |
| c | business continuity, such as backup management and disaster recovery, and crisis management | know that backups succeed |
| e | security in the acquisition, development and maintenance of systems, including vulnerability handling | know the flaws in the fleet |
| f | assessing the effectiveness of the measures | measure over time |
| g | basic cyber hygiene and training | indirect |
| i | human resources security, access control and asset management | inventory, privileged accounts, leavers |
| j | multi-factor or continuous authentication, secured communications | know who uses it |
Points d (supply chain security) and h (cryptography and encryption) are mainly a matter of policy and contracts.
Article 23: reporting significant incidents
An incident is "significant" if it has caused or can cause severe disruption of the services or financial loss, or if it has affected other persons by causing considerable damage. It is reported to the CSIRT or the competent authority, in several stages:
| Stage | Deadline |
|---|---|
| Early warning | without undue delay, and at the latest 24 hours after becoming aware of it |
| Incident notification | at the latest 72 hours after becoming aware of it |
| Intermediate report | at the request of the CSIRT or the authority |
| Final report | at the latest one month after the notification |
The final report describes the incident, its severity and impact, the threat or root cause, and the measures taken. To meet 24 hours, you first have to see the incident, then gather the facts quickly: machines, accounts, timeline.
Article 20: management is accountable
Management bodies approve the measures of Article 21, oversee their implementation and can be held liable. Their members must follow training.
What the text does not say
- It does not cite any tool: no SIEM, no antivirus, no particular product.
- It does not set a retention period for logs.
- It does not describe how detection is organised (in-house team, provider, on-call rota).
For certain digital entities (cloud computing, data centres, managed services, managed security services, among others), Implementing Regulation (EU) 2024/2690 details these requirements, including monitoring and logging. For the others, national law and the authority's recommendations spell out what is expected.
What you need to be able to show
During an inspection or after an incident, the same questions come back:
- Which events do you monitor, and on which machines?
- How long do you keep logs, and who can delete them?
- How is an incident detected, qualified, followed and closed? Who handled it, and when?
- Do your backups succeed, and have you checked?
- Who has administrative rights, and who approved that list?
- Which known vulnerabilities remain open in the fleet?
For each one, a written procedure is not enough. You also need the record of its application: an export, a history, a dated decision.
What FirstSI covers
FirstSI provides part of the technical evidence. It does not report to the authority, does not write your risk analysis, and replaces neither training nor governance.
| Expectation | In FirstSI |
|---|---|
| Detection (Art. 21, b) | SIEM correlation rules, Active Directory alerts, persistence on servers, Microsoft 365 leaks, exposure seen from the Internet |
| Incident follow-up (Art. 21, b; Art. 23) | numbered incidents, life cycle from opening to closing, qualification on resolution, response times (SLA), action history, CSV or PDF export |
| Backups (Art. 21, c) | backups and integrity checks of SQL Server databases (Database background jobs), heartbeats of backup scripts (HostMonitor) |
| Vulnerabilities (Art. 21, e) | software inventory matched against CVEs every night, actively exploited flaws flagged, end of support (AssetMonitor) |
| Effectiveness (Art. 21, f) | directory posture score charted over 180 days, fleet security score charted over 90 days (Machine security status) |
| Access control, assets (Art. 21, i) | access review of sensitive groups, exportable to CSV, leavers, machine inventory |
| Strong authentication (Art. 21, j) | two-factor authentication methods of a Microsoft 365 account, two-factor authentication that can be made mandatory for the FirstSI console (Customer security and SSO) |
| Logging | retention adjustable from 1 to 365 days, directory changes kept for at least 3 years, console audit log (Data, GDPR and audit log) |
Active Directory, persistence, database background jobs and Microsoft 365 leaks open their incidents without any rule to turn on, once their collection is in place. The SIEM correlation rules, on the other hand, are installed turned off: turn on the ones that match your modules. See SIEM: correlation and security incidents.
Where to start
- Check with your national authority whether your organisation is concerned, and in what capacity.
- List your critical systems, those whose outage stops the business.
- For each one, answer the six questions above with evidence, not an intention.
- Write the reporting procedure: who decides that an incident is significant, who reports, with what information, within 24 hours.
- Test it once a year on a mock incident.
Further reading
- Directive (EU) 2022/2555 on EUR-Lex: the text, Articles 20, 21 and 23 in particular.
- Implementing Regulation (EU) 2024/2690 on EUR-Lex: the detailed requirements for certain digital entities.
- ANSSI: the transposition in France and the organisations concerned. In other countries, refer to the national authority designated by the transposition law.
- Checking the security of your Active Directory: access control and privileged accounts, in practice.
Overview: SIEM for SMEs: incident detection
Source: · FirstSI Docs · updated 2026-10-11