23/09/2026
The adoption of Decision No 3/2026 of the National Cyber Security Directorate (DNSC) brings an important clarification for essential and important entities that form part of a group of undertakings: the fact that cybersecurity policies, strategies and mechanisms are set at group level does not mean that the local entity is relieved of its responsibility for applying and demonstrating compliance.
The Decision, published in the Official Gazette of Romania, Part I, No 798 of 21 September 2026, approves the Rules on the applicability of cybersecurity requirements to entities forming part of a group of undertakings. The Rules explain how the requirements laid down in DNSC Order No 1/2026 apply where cybersecurity governance, strategy and risk management are defined at group level and cascaded down to the member entities.
One of the most important rules laid down by the new Rules is that an entity may use cybersecurity controls established and administered at group level.
The Rules identify three models for applying controls:
The difference between these models matters from the perspective of audit and the demonstration of compliance. Whichever model is chosen, the entity remains responsible for demonstrating the effective implementation of the controls applicable to its own scope.
Consequently, the argument that “the policy is set at group level” is not, in itself, sufficient.
The relevant question becomes: how does the entity demonstrate that the group policy is applicable to, and effectively implemented in, its own environment?
As regards governance, the Rules allow the main policies, risk management frameworks and oversight mechanisms to be defined at group level.
The entity must, however, demonstrate compliance by:
Liability may also be examined in situations involving failure to comply with obligations relating to:
A key point is that the entity does not need to artificially recreate a parallel governance structure if one is already established at group level.
It must nevertheless be able to demonstrate that those mechanisms actually work within its own scope.
In the area of identification, responsibility lies mainly with the entity.
Even where methods and tools established by the group are used, the entity must maintain accurate inventories of:
It must also carry out risk assessments using the group's methodology and ensure that changes in its own environment are reflected in its inventories, risk assessments and improvement activities.
This rule has an important practical consequence: a risk assessment carried out at group level cannot automatically replace the operational reality of the local entity.
The technological environment, assets, suppliers, services and actual risks of each entity must be properly reflected.
As regards protection, the Rules provide for a model that is generally shared.
Security policies, standards and technologies may be defined at group level, but they must be implemented locally.
The entity must be able to demonstrate, among other things:
Consequently, the existence of a centralised security platform or a corporate policy is not, in itself, equivalent to demonstrating compliance.
There must be a documented link between the control established by the group and its effective implementation within the entity.
A model frequently encountered in groups of undertakings is the centralisation of security monitoring.
The Rules allow the detection function to be operated centrally. However, the entity must ensure that its own systems and services fall within the scope of the group's monitoring capabilities.
In addition, there must be local responsibilities for handling and escalating alerts, and the entity must take the necessary action on the basis of the detection results relevant to its own environment.
A centralised SOC (Security Operations Centre) therefore does not mean the absence of local responsibilities.
In incident management, too, coordination may take place at group level.
The entity must, however, take part in the response processes, carry out local response and containment actions and provide the information needed to analyse incidents and subsequently improve security measures.
In practice, this requires the entity to know very clearly:
who identifies the incident → who notifies it → who decides on escalation → who intervenes locally → what information must be sent to the group → how the incident is documented.
The lack of a clear allocation of these responsibilities may become a vulnerability not only in operational terms but also in terms of compliance.
As regards recovery, the framework may be set at group level, but the entity must align its own continuity and recovery arrangements with the group's frameworks.
In addition, it must meet the recovery objectives set for its critical services and take part in recovery testing and communications.
In other words, the existence of a group-level continuity plan must translate into an effective recovery capability for each entity within its scope.
One of the most useful aspects of Decision No 3/2026 is the clarification regarding the maturity of controls.
The entity is not required to create its own documentation from scratch for each control if it can use the group's documentation.
However, the documentation must be formally applicable to the entity, and there must be evidence at entity level of implementation and, where appropriate, of the relevant metrics.
This rule rules out a possible misinterpretation:
“We do not have a local policy, so we automatically have minimum maturity.”
The Rules actually give an example of such an error. If the entity formally adopts a group policy, the maturity level of the documentation must be assessed by reference to approval, applicability, review and the handling of exceptions, and not merely on the basis that the document was drafted centrally.
Perhaps the most important practical consequence is that the maturity level does not automatically follow from the maturity of the group.
The Rules provide that the maturity level reflects the extent to which the control is documented, implemented, measured and improved for the entity, regardless of whether that control is defined at group level or locally.
Thus, even if the group has sophisticated policies, mature procedures and centralised tools, the entity must be able to demonstrate that they are applied within its own perimeter.
At the higher maturity levels, the requirements become even more specific: consistent implementation, evidence of activities, the collection and reporting of metrics, target values and, at the optimised level, demonstration of continuous improvement.
From a practical perspective, an essential or important entity should ask itself at least the following questions:
These are, in essence, the elements that turn a corporate policy into demonstrable compliance at entity level.
DNSC Decision No 3/2026 introduces a simple principle with significant implications for groups of undertakings: centralising cybersecurity does not mean fully centralising responsibility for compliance.
The group may set the strategy, policies, standards and methodologies, and may even operate certain controls. The local entity, however, must demonstrate that these apply to it, that they are implemented within its own scope and that there is sufficient evidence to support the maturity level it declares.
In any audit, the question will not merely be “is there a group-level policy?”, but, in essence, “how do you demonstrate that this policy and the related controls actually work in your entity?”
And this difference between the existence of a control and the demonstration of its effective application is one of the most important practical consequences of the new DNSC Rules.
Author: P.A.
