How Do We Define Cybersecurity Maturity?
The launch event for the findings of the State of Cybersecurity market study began with a definition of cybersecurity maturity. Delia Necula, CEO of Fort, explained that the index is calculated based on five equally weighted factors. On a scale from 0 to 100, a score of 0 indicates no maturity, while 100 represents the highest level of maturity.
First, we look at theoretical measures — what can be put down on paper:
- Governance – are there written rules and procedures? Does everyone know who is responsible for what?
- System monitoring – are there rules AND monitoring systems in place? Is it clear who monitors them, and are incidents being tracked?
We then move on to practical measures:
- Incident response capability – what do you do when an incident occurs?
- Technical security – systems, antivirus, and security solutions, with the important caveat that having solutions in place is not the same as actually using them.
- Security culture – where everyone knows what they are responsible for, and the company invests accordingly.
All of these dimensions are covered, to varying degrees, by legislation, and were applied comparatively to the study results:
- 45% of responding organizations consider themselves mature (based on self-assessment)
- 27% of them have implemented the full set of three practical measures
Although the report is not exhaustive, it is certainly relevant to the current state of cybersecurity in Romania.
Based on its findings, a panel discussion was held featuring Gabriel Dinu (Deputy Director @DNSC), Cristina Crețu (Partner @MPR Partners), Ilie Voinea (Data Protection Officer @Fildas Catena Group), Mihai Petrov (Chief Information Security Officer), and Tudor Cristea (Regional Sales Manager @CrowdStrike).
Many Organizations Are Well Below the Acceptable Level Given Existing Requirements
In relation to Order 1/2026, we put the figure that concerned us most from the barometer on the table: 45% of organizations consider themselves mature, but only 27% pass the practical test, while 39% declare themselves mature without meeting any of the basic criteria.
Asked how this looks from the authorities’ perspective, within a framework based entirely on management-led self-assessment, and how the process unfolds, Gabriel Dinu does not dispute the diagnosis. He acknowledges that many organizations are well below the acceptable level given the existing requirements and that a realistic assessment is needed.
He does, however, make an important distinction: overestimation comes from two different directions — a lack of understanding of the requirements, on the one hand, and a deliberate attempt to appear better than reality, on the other.
He also points out that the authority consciously decided not to begin with an audit. The first self-assessment is not a compliance test: the legislation is new, and organizations have time to adapt. The expectation, he says, is to see the reality on the ground, especially at this first stage.
The assessment tool does not simply ask organizations to state a maturity level; it also requires them to justify it from two perspectives: implementation and documentation.
As for how an overly generous self-assessment becomes visible, Gabriel Dinu describes three mechanisms.
The first is statistical: after a serious audit, anything above 4–4.5 is surprising, while a realistic level of compliance is around 2.5.
The second is correlation: many controls are interconnected. The authority is building a map of these connections and will look for situations where a claim is not supported by the response to another control.
The third is retrospective: the data is retained for many years, and when an incident occurs, the analysis can be revisited.
Gabriel Dinu concludes with an unequivocal warning: do not rely on an advantageous assessment on paper, signed and submitted, because verification will come at some point, and dishonesty in the relationship with the authority is an aggravating circumstance when determining sanctions.
Does an Honest Self-Assessment Become Evidence Against the Entity: Self-Incrimination or Opportunity?
Continuing with an aspect that Order 1/2026 leaves open, we discussed with Cristina Crețu the fact that the document submitted to DNSC has an unusual legal profile: a self-assessment endorsed by executive management, followed by an action plan that explicitly lists the organization’s own deficiencies.
Article 3(4) excludes this information from the category of information of public interest, but says nothing about its status as evidence in litigation. So, does an honest self-assessment become evidence that the authority can use against the entity? Self-incrimination or opportunity?
Cristina Crețu starts from the nature of the document: it produces legal effects because, by signing it, you are effectively assuming responsibility for the information submitted.
For precisely this reason, she says, it should not be treated as a paper-compliance exercise, but assessed against the measures you actually have in place and are able to implement at the time of the response.
It is, indeed, your statement. But she does not see it as self-incrimination, and the argument lies in the structure of the Order: step two is the remediation plan. You identify the problems, commit to an action plan with a timeline, and submit it to the authority.
As long as this is done honestly, the document does not have an incriminating purpose.
There is only one red line: do not select a maturity level that differs from reality. That is when it becomes a false declaration, and that is where the incriminating element emerges.
Cristina Crețu also points to the logic behind sanctions, which clarifies the entire discussion: DNSC does not come in to sanction the situation at T0. It sanctions the fact that you made a false declaration or failed to take the necessary measures to bring yourself to a compliant level.
The Least Frequently Implemented Measure in the Entire Study: 31% Have Designated Security Representatives Outside IT
Law 124/2025 explicitly added divisions 4646, wholesale trade of pharmaceutical products, and 4773, retail sale of pharmaceutical products in specialized stores, to the healthcare sector in Annex 1.
Article 14(4) requires essential entities to appoint a security representative with managerial authority, reporting directly to management and operating independently from IT and OT structures, with an accredited course to be completed within 12 months.
In practice, this is a DPO for security.
The question put to Ilie, who already holds a statutory data protection mandate, concerned how independence from IT works in the reality of a pharmacy network. His answer brought an uncomfortable truth to the surface: in Romania, the concept of a group does not exist.
It is an aspect worth highlighting, he says, because the same issue already arose under NIS1: when multiple entities within a group share infrastructure, treating them separately becomes complicated. In practice, 30 entities meant 30 declarations, 30 audits, and so on.
Which leads to the obvious question: does the Order therefore require 30 security representatives, each with managerial authority and access to budgets? And if there is a single person, how does that work?
Ilie brings the discussion back to the actual role. Contracts between entities are necessary, and the declarations cover both the entity and the person who maintains the relationship with the authorities and the designated security representative.
As for combining roles, he frames it as a governance issue rather than an operational one.
Both the CISO and the DPO are responsible for operational oversight, but they are not the people who actually implement security measures, monitor systems, or directly manage any security tool. They receive the information, build the governance framework, verify it, and can request data from their IT colleagues.
Which also means, he adds, that it is their responsibility to ensure that the self-assessment is accurate.
And this is where the three panelists’ answers come together: the security representative outside IT is not an additional administrative position; it is the mechanism that makes the self-assessment credible.
Yet it is also the least frequently implemented measure in the entire study: 31% — the designation of security representatives outside IT.
The costs are significant, and the need for an ISO and CISO is becoming increasingly real, but group structures make the situation more complicated and further regulation is still needed.
What Happens When the Organization Being Assessed Changes?
The discussion with Mihai Petrov, CISO, brought up the only scenario that Order 1/2026 assumes but does not describe: what happens when the organization being assessed is no longer the same organization?
The context: he is in the middle of a carve-out. The entity where he serves as CISO is moving from French ownership to Romanian ownership. Until recently, part of its security capabilities were provided at group level.
Now, alongside the draft rules concerning groups, the question becomes very concrete: what are the real challenges of the process when things do not change overnight — different vendors, different processes, different systems?
Mihai Petrov’s answer shifts the focus to what happens before the transaction.
A carve-out is prepared in advance, sometimes even before there is any indication that one will take place. And the real work continues long after Day 1: the security team’s responsibility is to prepare everything as thoroughly as possible before that day, so that the remaining dependencies are minimal and those that do remain can be dealt with as easily as possible afterwards.
This leaves an open question for the authority: the entity completed a self-assessment at T0 and then begins a carve-out. When, and in what form, should a new classification and a new declaration be made?
Gabriel Dinu responded that any organizational change that affects how an entity falls under the legal provisions must be reported within a defined timeframe.
This includes a change of name, legal form, registered office, responsible person, as well as changes that move the entity from one size category to another.
Reporting, he explains, serves two distinct purposes. Changes relating to identity are necessary for the entity to operate within the register. The rest enables verification of what happens to the infrastructure as a result of the change.
And that closes the loop opened by the first question: a self-assessment is not a snapshot that you submit and forget. It is a declaration that must remain true, including when the company around it changes.
Zero Reported Incidents Does Not Mean Zero Incidents
The final part of the discussion started from an observation in the barometer that looks good on paper but is, in reality, the most concerning finding in the entire study: companies with a single IT employee reported no incidents at all.
The methodological context matters.
Detection, as a distinct function, has two components: continuous monitoring and analysis of adverse events when they are detected.
The resource model in the market, however, varies significantly: from fully outsourced operations to a single IT employee. And a significant share of entities falling under NIS will never build an internal SOC.
Which leads to the question put directly to Tudor Cristea: can we simply buy an MDR (Managed Detection and Response) solution to pass the assessment quickly and without complications?
His answer was, essentially, no.
An MDR means having a specialized team of certified incident responders working on behalf of the organization. But it is an extension of the company’s own efforts, not a substitute for them.
The evidence comes from a counterintuitive part of the market: among the MDR clients of a global vendor, approximately 25–30% are organizations with mature SOCs and hundreds of employees that still need the additional expertise of a dedicated MDR provider.
The more deeply you engage with cybersecurity, the more you realize that you need help.
This also explains the figure mentioned at the beginning. The approximately 10% of companies with a single IT employee are not in a position to detect incidents.
If you have no detection measures and no sensors, you have no way of reporting incidents.
And when everything appears to be perfect, there is usually a problem beneath the surface.
The practical conclusion: the discussion around MDR is a discussion for organizations with a high level of maturity.
When you have the budget, you can invest it in growing your internal team, work with a local partner, or engage a global vendor.
What matters is investing by complementing existing gaps or augmenting existing capabilities, depending on the entity’s actual level of maturity.
Cybersecurity Has a Marketing Problem
Andrei Resmeriță, CRO at Fort, closed the event with an observation that probably explains half of the figures in the barometer: cybersecurity has a marketing problem.
We are forced to use fear as an argument for investment, budget, and action. And if fear is the only language available, then the paradigm needs to change.
Based on what he sees in the market, there are four challenges companies encounter most frequently:
- AI governance and AI security
- cybersecurity budget allocation
- implementing the Zero Trust principle
- Business Continuity
And three conclusions worth taking away:
1. Compliance does not mean security.
Paper compliance is free, but free does not mean secure.
It is the same gap measured by the barometer between the 45% who consider themselves mature and the 27% who pass the practical test.
2. You need a tribe.
To raise your maturity level enough to pass a NIS2 audit, working alone is not enough.
Cybersecurity maturity is an industry-wide effort — a shared effort to genuinely identify the gaps that need to be addressed within each company.
3. The love story between IT and management
IT used to be responsible; now, accountability for security sits with management.
But we should not fall into the illusion that it is only management’s responsibility. It is a shared responsibility.
And security is not merely a compliance cost: it is a feature in the sales and scaling process, and it will soon become a driver that determines whether you can sell and whether your solution is viable for the industries you serve.
We started the discussion with a scale from 0 to 100 and five equally weighted factors.
Through five interventions, we arrived at the same point, expressed in five different ways: the gap between what we declare and what we can demonstrate is not a reporting problem. It is a security problem in its own right.
You can download the full report here.
