DNSC notification step by step: registration, deadlines, common mistakes

When people say “notifying DNSC”, they usually mean one of two different things that are easily confused. The first is entity registration: once an organisation establishes that it falls under NIS2 in Romania, it has to make itself known to the authority. The second is significant incident reporting, which has its own deadlines, measured in hours.

Romania transposed Directive (EU) 2022/2555 through OUG 155/2024, approved with amendments by Law 124/2025. The national competent authority and national CSIRT is DNSC (the National Cyber Security Directorate). Some sectors also have sectoral authorities, so the first step is to check who you report to, not just how.

The registration duty is triggered by qualification: an entity that establishes it is essential or important must register with DNSC within the deadline set by national law — 30 days from qualifying, per the Romanian implementation. DNSC publishes the official form and submission platform; do not rely on templates copied from elsewhere.

Article 27 of the directive sets the minimum information entities provide to the authority. Have it ready before you open the form:

• the entity's name;
• address and up-to-date contact details, including email addresses, IP ranges and telephone numbers;
• the relevant sector and subsector from the directive's annexes;
• the list of Member States where the entity provides services, where applicable.

This data is not static. A changed IP range, a new point of contact or services extended to another Member State all mean the submitted information must be updated. Treat registration as a living record, not a form you file once.

The form itself is quick to fill in. Time is lost on internal questions nobody can answer on the spot. A preparation list that works in practice:

1. A written scoping analysis: sector, subsector, entity size and why you are essential or important.
2. Your public network inventory: allocated IP ranges, domains and exposed services — exactly what an attacker sees.
3. Security contacts with deputies, reachable outside office hours.
4. Management approval for the submission — Art. 20 places accountability on the management body, so the decision should exist in writing.
5. An owner who keeps the data current after submission.

Article 23 sets a staged timeline for significant incidents. The underlying idea: the authority wants a fast signal, even an incomplete one, and the details later.

If the incident is still ongoing when the final report is due, the directive provides for a progress report at that point and a final report within one month of the incident being handled. Where appropriate, the entity must also inform recipients of its services about significant cyber threats that may affect them.

Not every alert is reportable. The directive treats an incident as significant if it has caused or can cause severe operational disruption of services or financial loss for the entity, or has affected or can affect other natural or legal persons by causing considerable material or non-material damage.

In practice, the “do we report?” decision should be made against criteria agreed in advance, not during the crisis. Document your internal thresholds (downtime, number of affected users, compromised data) and who has the authority to decide. When in doubt, a cautious early warning costs less than a missed deadline.

• Mixing up the two notifications. Registration does not replace a reporting procedure, and a reporting procedure does not register you.
• Clocks in the wrong time zone. An incident discovered at 23:30 in one zone and logged in another can “lose” an hour out of 24. Keep timestamps in UTC and convert only for display.
• Stale contact details. DNSC cannot reach you on the address of someone who left.
• Nobody designated. The procedure says “the security team notifies”, but on the night of the incident it is unclear who has access to the platform.
• A final report written from memory. Without an incident log kept along the way, root cause and timeline are hard to rebuild a month later.
• Forgetting customers. The duty to inform service recipients, where it applies, is easy to overlook under pressure.

The 24h and 72h deadlines are met when they are prepared in advance: a written procedure, an early-warning template and an incident register that starts the clock as soon as the incident is logged. Regular tabletop exercises quickly show where the process gets stuck.

A minimal early-warning template, prepared in advance, should already have every field filled in that does not depend on the incident:

1. the entity's identification details and a contact person available for the next 72 hours;
2. the moment of awareness, in UTC, and who detected it;
3. affected services and an estimate of impact, even a rough one;
4. whether malicious action is suspected and whether customers or partners in other Member States are affected;
5. containment steps already taken and when the next update will follow.

For the technical measures DNSC may look at after an incident, see also NIS2 Art. 21 translated into technical controls.