Romania now has a national control catalogue, and your level is not your class

What was published

Order no. 1 of 6 August 2026 of the director of the DNSC appeared in Monitorul Oficial, Partea I, nr. 712 and nr. 712 bis of 27 August 2026, and took effect on publication. The order sits in nr. 712; the annexes, which carry the catalogue itself, sit in the bis issue. It approves two documents: the cybersecurity risk-management measures for the networks and information systems used by essential and important entities, and the methodology for self-assessing how mature those measures are.

This is not a guidance note. Article 12(1) of Ordonanta de urgenta nr. 155/2024 — the Romanian transposition, as approved and amended by Legea nr. 124/2025 — directs the DNSC to set the technical, operational and organisational requirements by order. The order is that instrument. Until 27 August, Romanian entities had the ten measures of article 13 of the ordinance and nothing under them.

Six functions, not ten headings

Article 13 restates the ten measures of article 21(2) of the directive, in the directive's own order and without adding an eleventh. The catalogue does not follow that shape. It is organised as functions, categories, subcategories and controls, across six functions: governance, identification, protection, detection, response and recovery.

If your Romanian evidence pack is filed under the ten headings of article 21(2), it will not line up. That is a re-cut, not a re-do, but budget for it: the mapping between a flat list of ten and a six-function tree is the kind of work that looks trivial until someone asks which control answers which point.

The part that catches people: your level is assigned

There are three assurance levels, and they are cumulative. Nivel de baza is 34 controls. Nivel important adds to that, for 133 in total. Nivel esential adds again, for 218 in total. The naming is the trap.

The level does not follow from your entity class. It follows from the risk level evaluated for your entity under the methodology issued on article 10(2) of the ordinance, and validated by the DNSC. Being classified an important entity does not put you on nivel important, and nothing in the vocabulary warns you. Settle your risk level first; everything downstream — scope, budget, the size of the evidence pack — depends on it, and it is the one input you do not choose.

Two scores per control, and evidence behind both

Each applicable control is scored twice, not once: maturity of documentation and maturity of implementation, each an integer from 1 to 5. Each value has to be justified in writing, and the declared level has to be supported by operational evidence.

The split is deliberate and it is unforgiving in a useful way. A written policy with nothing behind it moves one number and leaves the other where it was, which is exactly the gap an auditor looks for. It also means a documentation sprint before the filing produces a visibly lopsided profile rather than a good score.

The filing, and the two obligations behind it

The self-assessment is conducted through the NIS2@RO platform. The DNSC also publishes downloadable tools, one per assurance level — EVAL_MMS_B, EVAL_MMS_I and EVAL_MMS_E — but those are the fallback for when the platform is unavailable, not the normal route.

Two duties around the filing come from the ordinance itself and are easy to miss because they are not in the order. Article 12(4) makes the maturity self-assessment annual, and requires it to be signed off by the entity's management — this is a management-liability document, not a technical return. Article 12(5) gives essential entities thirty days after the self-assessment to file a plan remedying the deficiencies it identified, also management-signed. Finding a gap therefore starts a clock.

A cybersecurity audit is a third and separate obligation, under article 11(5), on conditions and a periodicity fixed by DNSC order according to risk level. Do not plan the self-assessment as if it discharged the audit.

CyFun is still true, and is no longer the answer

Romania is a joint owner of the CyberFundamentals framework alongside Belgium and Ireland. That has not changed, and it is still the right thing to know about a group operating in all three. What has changed is which document a Romanian supervisor reads. The filing is made on the DNSC's own control identifiers, through the DNSC's platform, against the DNSC's catalogue. Co-ownership of a scheme is not a national reference.

One observation we are deliberately not turning into a claim. The totals 34, 133 and 218 are exactly the published control totals of CyFun Basic, Important and Essential, and Romania co-owns CyFun. That is a coincidence worth investigating and it is not an equivalence: no source we have read says the DNSC catalogue is CyFun, and we are not publishing a crosswalk inferred from three matching integers. Our framework page for the catalogue therefore records the mapping to article 21(2) as not recorded yet, and says why.

The same honesty applies to the annex. The DNSC site refuses automated reads and the national legislation portal did not answer, so we have not read the control list in nr. 712 bis. What is above is what the official gazette summary, the order's own title and the ordinance text support. The control identifiers will go up when we have read them, not before.

What to do this week

Find out your assigned risk level, in writing, before anyone scopes a gap analysis. Then check the date of your last self-assessment against the annual cycle, and check whether a remediation plan was owed thirty days after it. Those two dates are the ones a supervisor can verify without visiting you.