The first hour of a DNSC incident report

The first hour of a DNSC incident report

On 28 April 2026 the Romanian National Cyber Security Directorate (DNSC) announced two changes at once. The reporting flow inside PNRISC — the national platform for reporting cybersecurity incidents, at pnrisc.dnsc.ro — was rebuilt to be simpler for individuals and for the essential and important entities that report under NIS 2. Alongside it, DNSC published a public Blacklist at pnrisc.dnsc.ro/blacklist: domains involved in fraudulent activity, reported or found proactively, analysed and confirmed by DNSC's own technical staff, with a browser extension for Chromium browsers and Firefox.

Both are useful. Neither addresses the part that actually goes wrong. In the incidents we work on, nobody misses the 24-hour deadline because the form was confusing. They miss it because at 02:40 on a Saturday there was no agreement about who was allowed to press send, and the person who could have decided was asleep with their phone on silent.

What the ordinance actually asks for, and when

Article 15 of OUG 155/2024 sets the sequence. Reporting goes through PNRISC, and only through PNRISC.

  • Within 24 hours of becoming aware of a significant incident: an early warning that indicates, where applicable, whether the incident is suspected to be caused by unlawful or malicious action, and whether it could have cross-border impact.
  • Within 72 hours of becoming aware: an incident notification that updates the early warning, gives an initial assessment of severity and impact, and includes indicators of compromise if any are available.
  • An intermediate report on relevant developments, only if the national CSIRT asks for one.
  • A final report within at most 30 days of sending the 72-hour notification, covering a detailed description of the incident and its impact, the type of threat or likely root cause, the mitigations applied and in progress, and cross-border impact where relevant.
  • If the incident is still running when the final report falls due, a progress report instead, and the final report within 30 days of the incident being brought under control.

Two details are worth pinning down because they are routinely quoted loosely. The Romanian text says 30 days, not "one month" — the directive's wording, translated into a countable number. And the clock starts when you became aware of the incident, not when you finished understanding it. Trust service providers get a stricter version of the middle step: Article 15(8) replaces the 72-hour notification with 24 hours for significant incidents affecting their trust services.

There is a reciprocal obligation that few entities use. Under Article 15(9), the national CSIRT is required to respond to an early warning without undue delay and, where possible, within 24 hours — including, on request, operational guidance on mitigation measures. The 24-hour warning is not only an obligation you discharge. It is also the point at which you can ask for help.

Where the October 2026 date comes from

A deadline of October 2026, after which "incident reporting becomes mandatory," circulates on several Romanian compliance sites. We could not confirm it on dnsc.ro or in the ordinance, and it does not survive a reading of the text: the Article 15 reporting duties apply to identified essential and important entities already, and have since the ordinance applied to them.

What is genuinely dated to autumn 2026 is a different chain. DNSC Order no. 1/2026, published in Monitorul Oficial no. 712 and in force from 27 August 2026, sets out the cybersecurity risk-management measures and the methodology by which each entity calculates its own maturity level, organised across six functions — governance, identification, protection, detection, response, recovery — and three assurance levels. The deadlines around it run from each entity's own milestones, not from a single national date: the risk-level evaluation is due within 60 days of DNSC's identification decision, the maturity self-assessment within 60 days of that evaluation, and essential entities have a further 30 days to submit a remediation plan signed off by management.

So there is no one date on which the country switches on. There is your date, and it depends on when DNSC identified you. Separately, DNSC's deputy director Gabriel Dinu stated in September 2026 that the first sanctions under the NIS 2 framework are being drafted, starting at the lower end and with unregistered entities first.

Who signs at three in the morning

The ordinance does not name a signatory for the early warning. It requires something more demanding and more useful: Article 14(3) obliges the management bodies of essential and important entities to establish permanent means of contact, and the registration data under Article 18(3) includes those permanent contact means together with the person inside the entity charged with monitoring them.

That is a design instruction, not a form field. Practically, it means naming one primary and at least two deputies, in writing, with the authority to submit a 24-hour warning without a further approval step; publishing an out-of-hours contact route that does not depend on a single mobile number; and recording who held the role on which date, because at an inspection the question is not who signed but whether the arrangement existed before the incident.

What you need to know before you can notify

Less than most teams assume. The 24-hour early warning asks for a suspicion, not a conclusion: whether the cause looks malicious, and whether cross-border impact is possible. "We do not yet know the scope" is a legitimate answer at this stage, and Article 15(3) removes the usual reason for hesitating — reporting in itself does not expose the entity to increased liability.

The useful minimum for a first notification is the entity identifier and contact person, when you became aware and how, which service is affected and whether it is degraded or down, whether personal data may be involved, whether you suspect malicious action, whether other countries may be affected, and what containment you have already applied. Everything else belongs in the 72-hour notification, which is where severity, impact and indicators of compromise are expected.

The parallel clock at ANSPDCP

If the incident touches personal data, the same event triggers a second obligation that the DNSC report does not satisfy: notification to ANSPDCP within 72 hours under the GDPR, and direct notification of affected individuals where the risk to them is high.

The two 72-hour clocks look identical and are not. They start from different facts — awareness of a significant incident, and awareness of a personal data breach — and those moments are frequently days apart. Running them as one deadline is how organisations end up late on the one they started later. The practical fix is a single incident record with two separate timestamps and two separate owners.

What you put on the table at an inspection

An inspection asks for evidence that the process existed and ran, not for a narrative. That means an incident register with a stable identifier per incident; the awareness timestamp and how it was established; the named role that authorised each submission; the PNRISC confirmation for each of the three stages; the GDPR assessment and its outcome, including a reasoned decision when you concluded no notification was due; and the link to the remediation actions and their closure.

None of that is difficult. All of it is nearly impossible to reconstruct three weeks later from a chat thread, which is the actual failure mode.

A one-page checklist

  • Name a primary and two deputies with written authority to submit a 24-hour warning alone, and publish the out-of-hours route to reach them.
  • Pre-create the PNRISC accounts and verify that at least two people can log in today, not on the night you need it.
  • Write down the minimum data set for a 24-hour warning and agree that unknown impact is an acceptable answer.
  • Put the 72-hour and 30-day deadlines in a calendar the moment the first warning goes out, with the owner named on each.
  • Decide in advance who runs the GDPR assessment in parallel, and keep its clock separate.
  • Keep an incident register with the fields above, and rehearse the whole sequence once a year with management in the room.
  • Check a suspicious domain against pnrisc.dnsc.ro/blacklist during triage — it takes seconds and occasionally settles the question.

If you want the reporting chain tested rather than described, that is what a tabletop exercise is for, and it belongs next to the technical work — see our audit, risk and compliance practice, the NIS 2 and DORA readiness checklist, and the penetration testing evidence an inspection will ask for alongside the register.


Sources: DNSC press release, 28 April 2026, OUG nr. 155/2024, Art. 14, 15 and 18, PNRISC, Ziarul Financiar on the first NIS 2 sanctions, September 2026. The October 2026 "mandatory reporting" date appears only on secondary Romanian sources and we could not confirm it on dnsc.ro; the detail of DNSC Order no. 1/2026 above is reported by practitioner summaries and should be checked against the text in Monitorul Oficial before you rely on a specific deadline.

This article is general information, not legal or regulatory advice.

← Back to blog