NIS2 detection and reporting for operators with industrial (OT) systems

1. Who this is for, and what changed on 27 August 2026

This guide is for people who run, secure or answer for an organisation that operates a physical process: a power plant, a hydro cascade, a water treatment plant and its pumping stations, a district heating network, a gas distribution grid or a production line. In these organisations the office network (IT) and the industrial network (OT) are usually owned by different teams. NIS2 does not recognise that boundary. It sees one entity, one management body and one set of reporting duties.

If you are the IT or security manager, the automation engineer, the compliance officer or the general director of an operator with 50 or more employees in one of the 18 sectors covered, read on. Most operators with more than 250 employees in the energy, water and manufacturing sectors of Annex I are "essential" entities. That category carries planned audits and an explicit duty to file a remediation plan.

What changed. On 27 August 2026 the National Cyber Security Directorate (DNSC) published Order 1/2026 in the Official Gazette, Part I, numbers 712 and 712bis. The Order sets the cybersecurity risk management measures and the method by which each registered entity calculates its own maturity level. It comes with three self-assessment instruments, one per assurance level: EVAL_MMS_B (Basic), EVAL_MMS_I (Important) and EVAL_MMS_E (Essential). Entities whose overall risk score has been validated submit the self-assessment through the NIS2@RO platform.

Three consequences follow.

1. The self-assessment is mandatory and has a clock. It is due within 60 days of the risk-level evaluation you submitted under Order 2/2025. Many operators are in that window now.
2. A low score becomes a filed commitment. Gaps found in the self-assessment go into a remediation plan with dates. Secondary sources describe the plan as due within 30 days of the self-assessment and as explicitly required of essential entities; confirm the term for your category with your legal adviser.
3. Enforcement has started. Gabriel Dinu, deputy director of DNSC, confirmed in September 2026 that the first fines are being issued: first to entities that never registered, then to entities that registered but did not complete their obligations. The first fines are at the minimum of the scale.

Where will the score be lowest? On detection, monitoring and incident handling. The FORT Cyber study of 211 Romanian organisations (May to July 2026) found that 84% have antivirus or a firewall on all devices, 82% use multi-factor authentication and 81% make and test backups. Yet only 27% can concretely respond to a cyberattack, and 15% have eight or nine of nine technical measures in place and have never tested their incident response plan. Prevention has largely been bought. Detection and evidence have not. The study states that it is not statistically representative, so read the figures as an indication, not a census.

2. The obligations in plain words

NIS2 is Directive (EU) 2022/2555. Romania transposed it through Government Emergency Ordinance (OUG) 155/2024, approved and amended by Law 124/2025. DNSC is the competent authority. This section uses the directive's article numbers, which are stable.

Article 21: the measures that concern detection and monitoring

Article 21 requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage the risks to their network and information systems. The measures cover the whole entity, the office network and the industrial network alike. Four items of the minimum list in Article 21(2) bear directly on detection.

• Point (a), policies on risk analysis and information system security. You cannot analyse the risk of a network you cannot see. An inventory of systems and of the logs they produce is the first practical step.
• Point (b), incident handling. Handling means detecting, analysing, containing and recovering, and being able to state afterwards what happened, in what order, with what evidence.
• Point (d), supply chain security. Equipment vendors who connect remotely to your controllers are part of your attack surface. Their sessions must be visible.
• Point (f), assessing the effectiveness of the measures. A detection capability that has never been tested is not yet a measure.

Article 20 places the approval of these measures and the supervision of their implementation on the management body. Under the Romanian transposition, management carries personal liability, and complementary measures include binding compliance orders and a temporary ban on holding management functions.

Article 23: the reporting timeline

Article 23 requires the entity to notify significant incidents to the national authority, in Romania DNSC, in three steps. The table shows the three deadlines and what each step must carry.

On "becoming aware". The clock starts when the entity becomes aware of the incident, not when the incident began. For an operator with no detection in the industrial network, this can mean months of unnoticed activity followed by a 24-hour sprint. The final report will then ask for a root cause and a timeline that nobody can reconstruct. This is why detection and reporting belong in the same conversation.

Two neighbouring regulations deserve a sentence each. Under the General Data Protection Regulation (GDPR), Recital 49 recognises processing personal data that is strictly necessary and proportionate for ensuring network and information security as a legitimate interest, so security logs that contain user names or addresses have a recognised lawful basis if you keep them proportionate and documented. Under the Cyber Resilience Act, from 11 September 2026 manufacturers of products with digital elements must report actively exploited vulnerabilities within 24 hours; a supplier's notification is one of the ways you "become aware".

3. Why the industrial network remains uncovered

In an office network, detection is a technically solved problem: servers, laptops and firewalls write logs, and a collector gathers them. In the industrial network it is not, for four reasons.

Many industrial devices produce no security logs. A programmable logic controller (PLC) installed in 2006, a remote terminal unit at a pumping station or a protection relay in a substation does what it was built for: it runs the process. It does not record who connected, what was changed or when. Our research in Romanian plants kept finding the same situation: equipment that cannot be updated, equipment vendors who connect over VPN on their own schedule, and no exact list of what is connected to the industrial network.

IT security tools do not understand industrial protocols. Modbus, Siemens S7 and the other protocols of industrial networks look to a standard security tool like unknown bytes on unusual ports. The tool cannot tell a legitimate setpoint change from a malicious one, because it cannot read them.

Attacks that reach OT usually start in IT. The two Romanian incidents of December 2025 illustrate this. Complexul Energetic Oltenia lost its enterprise resource planning system, document management, email and website to the "Gentlemen" ransomware on the night of 26 December 2025. Administrația Națională Apele Române had about 1,000 systems affected across ten of its eleven regional branches and was blocked for roughly a week; critical water operations were reported as unaffected. In both cases the affected systems were on the office side. The question for every operator is whether the path from the office side to the industrial side is monitored. Deloitte's analysis of the Romanian energy sector notes that IT-to-OT segmentation is often weak or undocumented.

Nobody sees both networks in one place. In the operators we studied, IT reports to a technical or general director and automation reports to production. Each side sees half of the picture, and each side's monitoring, where it exists, stops at the boundary. When the 24-hour clock starts, two teams reconstruct two half-timelines, and the compliance officer signs a report that neither team can fully vouch for.

What "detection" means for a plant. A realistic definition for an industrial operator has three parts.

1. Logs where they exist. Firewalls, servers, jump hosts, historians, engineering workstations, SCADA servers, remote-access gateways, Windows event logs. Collect them centrally.
2. Network traffic where logs do not exist. A copy of the traffic on the industrial network, read passively and decoded at protocol level, so that new devices, new connections, new commands and out-of-hours engineering activity become visible.
3. Passive only. No software installed on controllers, no active scanning, no way to send commands to the process. A mirror (SPAN) port or a network TAP produces a copy of the traffic; the monitoring sensor only listens and never transmits anything toward the process. Remove the sensor and the plant is exactly as it was.

The third part is what makes detection acceptable to the person accountable for the process not stopping. Nothing is attached to a industrial network without the automation engineer's agreement, and passive collection is usually the condition of that agreement.

4. A detection-and-reporting checklist you can run in a quarter

An operator with a small IT team, an automation team and, where needed, an external partner can complete the twelve items below in about three months. Each item produces an output you can attach to a remediation plan or show an auditor. The order matters: the first items create the visibility the later ones depend on.

1. Inventory the log sources you have. List every system on the office side and the industrial side, whether it produces logs, in what format and where they go today. Mark the systems that produce nothing. Output: a dated log inventory.
2. Centralise collection. Send all existing logs to one collector under your control, inside your network. Synchronise the clocks of the sources; a timeline built from unsynchronised clocks is not evidence. Output: a list of connected sources with the date each was connected.
3. Obtain a passive view of the industrial network. Configure a mirror (SPAN) port on the industrial-network switch, or install a network TAP, and connect a sensor that only listens. Start on one non-critical line or station, witnessed by the automation engineer. Output: a written statement that the sensor cannot send anything to the process.
4. Build the equipment list from what you see. The passive view will show devices the inventory missed: vendor laptops, forgotten test rigs, an unexpected remote-access path. Reconcile the list with the automation team. Output: an industrial-network equipment list signed by both teams.
5. Establish what normal operation looks like. After two to four weeks of observation, write down what is normal: which devices talk to which, over which protocols, at what hours. Output: a baseline document per site.
6. Define alerts for deviations from the baseline. A new device, a new connection between zones, engineering commands outside maintenance windows, remote access from an unknown source. Start with few alerts and add. Output: an alert catalogue with the reasoning behind each rule.
7. Analyse alerts on the evidence. Every investigated alert ends in a written decision (real attack, false alarm or insufficient information), and the decision cites the log lines or traffic records it rests on. Output: a register of analysed alerts.
8. Rehearse timeline reconstruction. Take one past event, real or simulated, and reconstruct it end to end: first sign, entry point, movement, impact, containment. Time it. If it takes two days by hand, that is a finding for the remediation plan. Output: a reconstructed timeline with cited evidence.
9. Write the reporting workflow. Who declares an incident significant. Who drafts the 24-hour early warning, from which template, with which facts. Who reviews. Who signs. How the 72-hour notification and the one-month report build on the first. If your legal adviser confirms a six-hour national duty, add it. Output: a one-page workflow with names.
10. Assign roles and deputies. The NIS2 responsible person, the incident lead, the OT contact, the compliance contact and the signatory from management, each with a named deputy, because incidents do not respect holidays. Output: a roles table.
11. Set retention. Decide how long you keep raw logs, traffic records, alerts, alert decisions and reports, and where. Record the lawful basis for personal data in logs under GDPR Recital 49 and keep the volume proportionate. Output: a retention schedule.
12. Test the whole chain. Run a tabletop exercise that starts with an alert and ends with a draft 24-hour early warning in the compliance officer's hands. Record what broke. Repeat every six months. Output: an exercise report with dates and participants.

Every one of these outputs is something an auditor can ask for.

5. What an auditor or DNSC will ask for, and how to keep it

Under the Romanian framework, essential entities face planned audits at least once every two years with 30 days' notice, and unannounced audits with at least 24 hours' notice. Important entities are audited after incidents, complaints or sector risk flags. Secondary sources describe these rules; confirm the details for your category with your adviser.

An auditor does not check whether you own a tool. An auditor checks whether you can prove that the measures you declared in the self-assessment exist, work and were followed. The evidence requested falls into four groups.

Timelines with citations. For every incident and every exercise: what happened, in what order, and which record proves each step. A timeline is evidence only when each entry points to a log line, a traffic record or a timestamped screenshot.

Audit logs of the monitoring itself. Who configured which alert, who changed a rule, who accessed which record, and when. If the monitoring system does not log its own operation, you cannot show that the evidence was not altered.

Decisions and approvals. The alert decisions from item 7, the incident declarations from item 9, the management approval of the risk measures under Article 20, and the signatures on each report sent to DNSC. Keep the drafts as well as the final versions. Drafts show that the 24-hour report was written with the information available at hour 24, not rewritten afterwards.

Proof of testing. Exercise reports with dates, participants and findings: the answer to Article 21(2)(f). Recall the FORT Cyber finding that 15% of Romanian organisations have almost every technical measure and have never tested their plan. An auditor will look for exactly that gap.

How to keep it. Three rules cover most cases. Keep evidence inside your network, on systems you control, with access logged. Keep it in a form that can be exported and read without the tool that created it. Keep it for a defined period written in your retention schedule, and keep the schedule itself.

6. Where AI helps, and where it does not

Artificial intelligence is useful in security monitoring in three situations and must be kept under control in one.

Plain explanations, with the evidence alongside. A human analyst cannot read every log line behind 4,000 alerts. A well-built AI agent can group the alerts, explain what happened (“this account authenticated from a new address, then connected to the engineering workstation, then sent a write command to controller 14”) and attach the exact records for each step. The explanation helps you understand what happened and what to do. The links to the evidence show you that nothing was invented. An explanation without evidence remains an opinion.

Campaign reconstruction. An attack that crosses from office to plant leaves traces in different systems with different formats and clocks. Correlating them by hand is the "two days, manually, from files" that Romanian IT managers describe. An AI agent that queries all sources and assembles the timeline shortens that work from days to hours, and the timeline is what the 72-hour notification and the one-month report require.

Report drafting. Given a reconstructed and cited timeline, drafting the 24-hour, 72-hour and one-month documents is a structured writing task. AI drafts well; people decide what is sent. The draft must have its evidence attached, so the compliance officer can check each statement before signing.

No autonomous actions on the process. An AI agent in an industrial environment must never send commands to controllers, block traffic on the industrial network or isolate a device without a named person confirming the action. The agent proposes, a person confirms. The EU Artificial Intelligence Act does not classify cybersecurity detection tools as high-risk, because of an explicit carve-out for components used solely for cybersecurity, but its human-oversight and record-keeping articles (Articles 14 and 12) are a sensible design standard regardless.

No invented facts. A system that can say openly "I do not have enough information" is safer than one that always produces an answer. Ask any vendor to show you what the system says when the evidence is incomplete.

No transfer of accountability. Reports to DNSC are signed by people who carry personal liability. AI can make those people better informed and faster. It cannot sign for them, and no product can guarantee compliance.

7. Sources and verification date

All sources were accessed on 21 September 2026 for the research behind this guide. Legal texts change: before relying on a deadline or an article number, check the consolidated text or ask your legal adviser. Items marked "under legal review" above are those where sources disagree or where only secondary sources were available.