Ahead of my doctoral thesis¹ defense on September 4, 2026, I have thought a lot about the daily paradox surrounding us: we are world-class in Estonia regarding the use of digital solutions, but sometimes quite beginners when it comes to understanding and dealing with cyber threats. This creates a situation where legislation requires the implementation of security measures and consideration of risks, but a lack of background knowledge causes avoidance, uncertainty, and resistance, leaving the actual level of security in the state ambiguous.

To protect the continuous operation of the digital state, democracy, and the economy, several legal acts have been adopted – for example, the European Union’s directive for ensuring a high common level of cybersecurity (NIS2), for the transposition of which Estonia has in turn enacted the Cybersecurity Act (K ̈uTS). Legal requirements are indeed necessary, but inevitably, resistance arises in obligated organizations when things are not fully understood, and it seems that security measures are somehow the smallest problem compared to everything else.

Resistance does not stem from malice, but from a lack of knowledge, skills, and resources
Studies conducted in the European Union, for example, in Germany², Sweden³, and Finland⁴, have identified that many institutions subject to NIS2 operate at a low maturity level. The resistance to implementing security measures is primarily due to a shortage of knowledge, expertise, time, and money. Terminological confusion and complexity also play a role, especially regarding risk management, for example:

-risk vs. threat: these are not synonyms in the world of security, although after the awkward translation errors of the General Data Protection Regulation (GDPR), they are often used as such in everyday language. A threat describes what bad things can happen. A risk, however, provides concrete context, showing the potential harm to someone’s assets. Threats can be generally cataloged (fire, water, war, sabotage, human error, technical failure, etc.). Risks, however, are measurable depending on the specific context: the value of the asset, the size of the potential damage, the probability of the threat materializing, and the impact of already
implemented measures;

– fear of complexity: the recommendation to ”use computer hard drive encryption” often evokes an incomprehensible fear of something technically unimaginable, although in reality it mostly means checking just one box during the initial setup of the computer.

Evaluation creates clarity: the F4SLE framework
Merely an abstract warning that ”an attacker can penetrate the network and cause damage” does not motivate action and the taking of measures if the organization lacks prior painful personal experience and an understanding of how vulnerable it actually is. My research showed that when an organization gets a sense of its security level and sees how it relates to standardized expectations – and that something has already been done – resistance to the ”must” requirement decreases and curiosity arises: ”How can it be done?”

I proposed a simple instrument, F4SLE (Framework for Security Level Evaluation), for organizations to initially evaluate the implementation of security measures across ten security dimensions (e.g., infrastructure, industrial automation, applications, human management, etc.) through selfassessment^5,6. The number of questions for security evaluation tools ranges from 20 to 3000, but since my goal was not to check all measures, but to get a comprehensive picture across ten security dimensions, we limited the number of questions to 200. Thus, an organization using F4SLE gained a comprehensive picture of the ten dimensions of security (see figure). The expectation was that security had been addressed equally in all these dimensions. If there were shortcomings, i.e., the result was very close to the center, these organizations could be helped, for example, by using the
measure catalog of the Estonian Information Security Standard.

Comparability of security evaluation results amidst constant change
Since technology and threats are constantly evolving, the content of the framework we use to evaluate security needs to be updated periodically. Relying on outdated security measures provides only a false sense of security and can therefore shift focus away from actual risks. At the same time, it is important that institutions can regularly evaluate their security level and see if they have developed over the years. But if we change the questions used in the evaluation, we might lose the ability to compare the results with the past. For this purpose, the MUSE (Method to update Security Level Evaluation Instrument) method was developed to update security evaluation metrics⁷. This method is suitable for security metrics that have a structural layout – multiple security dimensions and levels. Thus, one does not have to compare individual measures, but can
give an assessment block by block. Within a whole instrument, a single change does not have a major impact, and thus, the comparability of collected data over the years is ensured, but only if the rules of the MUSE method are followed.

Data reuse and privacy
One of the fundamental principles of e-Estonia is that data once collected must be reused. The state, supervision, supply chain partners, and consultants all benefit from the same information. We only need to determine each stakeholder’s expectations. We mapped these expectations⁸ and tested them⁹ based on NIS2.
Different organizations tested the metric 284 times. The provided multilingualism allowed testing in Estonia, the Czech Republic, and in small enterprises in Central America. To ensure privacy and avoid the so-called pillory, we collected data in a generalized manner: from the institution’s 200 data points, 40 averaged data points were calculated on the evaluator’s device. These moved to the central server in numerical form along with metadata describing the institution. However, raw data with descriptions of security measures were never left on the respondent’s computer. We published the aggregated results collected centrally only if there were at least five organizations in the group, or we published them anonymously.
In addition to organizations, the pilot project involved cybersecurity personnel at an Estonian ministry and consultants who, with state funding, advised organizations on implementing security measures. I also conducted an interview with a representative of the national supervision. In summary of the pilot project, it can be said that all identified stakeholders need a standardized framework for assessing the security level, and F4SLE fulfilled these expectations. It is crucial here to motivate organizations to share their data centrally. To do this, they must be offered real added value – for example, a competitive advantage achievable with security measurement results, additional funding, the opportunity to participate in training, or a quick assessment of the security situation of their supply chain partners.
For the state’s primary needs – comparing sectors and groups of institutions – the accuracy of the pilot project data was sufficient. From the perspective of the supervisory authority, however, the reliability of the data emerged as a concern. Namely, we decided to keep the entry barrier low and focus on testing the F4SLE framework. Therefore, we abandoned authentication solutions that add complexity and relied on the information provided by the institutions themselves. Because we collected data during short-term campaigns and were often in direct contact with institutions at seminars, the data’s origin did not pose problems in the pilot project.
In the future, especially with centralized data collection in long-term studies, authentication will become important, but this will be left to the specific application layer to resolve. During our study, however, we considered it important to preserve the opportunity for institutions to measure their security level without having to share the results with anyone. In the case of private self-assessment, requiring a login is not justified – the need for authentic data only arises when it is collected centrally to create benchmarks. During the pilot project, we had no overview of how much F4SLE was used for internal purposes only, but from private conversations and inquiries during outages, we received confirmation of such use. As a saddening fact, however, I must also mention a generally weak statistical literacy. I left the potential of the metadata unused because almost all stakeholders wanted only radar charts. Showing box and scatter plots alone often caused indifference and alienation.

Lawyers vs. engineers: why do we talk past each other?
As a side effect of the doctoral project, it became clearer to me why the worlds of lawyers and engineers often clash rather than find harmony^10,11.

–Lawyers see regulations as static sets of rules that focus on compliance and are enforced through sanctions (e.g., fines). In legal texts, the order of clauses and connections with other legal norms are important (e.g., an institution must simultaneously comply with several laws that are not even mentioned in the specific legal norm). From a lawyer’s perspective, optimization is achieving compliance with minimum requirements, not starting from actual needs.

–Engineers, however, have to build and keep continuously changing systems running. If a flaw is detected, a fix must be made. Engineers seek solutions for optimization, from
patterns and automation to ensure usability and fault tolerance. An engineer needs a single and unambiguous interpretation. Simplified: when a lawyer sees a traffic rule, they say that if you cross an intersection on a red light, the police have the right to fine you (sanction). An engineer looks at the same rule and tries to optimize patterns to create a smart traffic light system or car sensors that would prevent driving
into the intersection at the wrong time. And if it still happens, the system must be improved, whether due to a technical failure, a configuration error, or malicious manipulation. But then the lawyer announces that the data protection regulation has been violated because the people caught on the sensor cameras can be identified. These two different interpretation patterns can be united by human-readable User Stories that
are understandable to both sides12. A user story gives a technical solution a human- and legally understandable goal and allows different sections of the law to be tied together into a single user story. For example, a user story could be formulated like this: ”As a driver, I want the car’s security system to prevent me from accidentally driving into an intersection on a red light without the sensors recording the faces of other road users, so that I can drive safely and the privacy of other road users is guaranteed.” Exactly such constructions of user stories have helped me find a common language with lawyers.

The future and the manager’s responsibility
Speaking of the future of the F4SLE framework, its structure must evolve over time, but the structural layout and the multidimensionality of security evaluation should be preserved. The development of AI solutions has made them manageable even for organizations with a low maturity level. Therefore, now is the right time to involve AI in profiling and security analysis of institutions¹³. AI integrated into the F4SLE framework would allow for the offering of personalized improvement plans for every organization and the consolidation of data centrally. The solution should rely on a solid structure, ensure comparability upon updates, and be tailored to the specific institution, the applicable laws, and, for example, the Estonian Information Security Standard¹⁴. Additionally, to reduce the administrative burden, automated controls that collect data in real time should be used15. Centrally collected data could be combined with other security metrics, e.g., scanner results or incident and service outage statistics. Certainly, institutions must not be burdened with excessive data collection if they do not offer real value to the data provider. Likewise, security does not have to be standalone, but rather a natural part of business processes.

It is worth reminding that amid all this automation, the responsibility remains with the organization’s manager. The manager’s task is to ensure compliance with the law and the operation of critical services from a business perspective, even when damage has already occurred. Cybersecurity has long ceased to be the domain of IT experts alone; every manager must know the ”bloodstream” of their organization – processes, the data needed for work and where it is stored, the assets that ensure business continuity, and supply chain partners – and know who to contact quickly for help in an emergency. This applies especially to small businesses. A security-level evaluation simply gives the manager, first and foremost, an idea of whether the organization they manage is ready to cope with security problems or whether an identified vulnerability exceeds the pain threshold. Furthermore, the manager learns more precisely from the assessment in which security dimension improvements need to be undertaken. So go ahead and test it out: https://mass.cloud.ut.ee/massui/.

References

1. Mari Seeba. “A Multi-stakeholder Framework for Comparable and Repeatable Security Level Evaluation in Organizations”. Doktoritöö. Tartu Ülikool, 2026. isbn: 978-9908-57-238-3. url: https://dspace.ut.ee/items/8697a889-67eb-4980-bc67-ac253319e42b.
2. Thomas Joswig and Walter Kurz. “Regulatory and Compliance Requirements for SMEs Operating AI Systems through Data Centers in the EU, With a Focus on Data Protection Chal-
   lenges in Germany”. In: (2025). doi: 10.70792/jngr5.0.v1i2.89.
3. Ebba Rehnstam, Wera Winquist, and Simon Hacks. “NIS2 Directive in Sweden: A Report on the Readiness of Swedish Critical Infrastructure”. In: (2025).
4. Huoltovarmuuskeskus. Kyberkypsyys toimialoilla 2025: Kansallinen raportti. Tech. rep. Helsinki, 2025. url: https://www.huoltovarmuuskeskus.fi/files/31c81e6d4cf1e2f64f 96742932d1ad0e549abb2b/kyberkypsyys- toimialoilla- 2025- kansallinen- raportti-final-suomeksi.pdf.

5. Mari Seeba, Sten Mases, and Raimundas Matulevicius. “Method for Evaluating Information Security Level in Organisations”. In: (2022). doi: 10.1007/978-3-031-05760-1_39.
6. Mari Seeba et al. “Security Level Evaluation with F4SLE”. In: (2023). doi: 10.1145/3600160.
7. Mari Seeba et al. “Create your own MUSE: A method for updating security level evaluation instruments”. In: (2024). doi: 10.1016/j.csi.2023.103776.
8. Mari Seeba, Magnus Valgre, and Raimundas Matuleviˇcius. “Evaluating Organization Security: User Stories of European Union NIS2 Directive”. In: (2025). doi: 10.1007/978-3-031-94569-4_4.
9. Mari Seeba et al. “Toward NIS2 Compliance for Multiple Stakeholders with Security Level Evaluation Framework”. In: (2025). doi: 10.7250/csimq.2025-45.07.
10. Nadzeya Kiyavitskaya, Alzbeta Krausova, and Nicola Zannone. “Why Eliciting and Managing Legal Requirements is Hard”. In: (2008). doi: 10.1109/RELAW.2008.10.
11. Shareeful Islam, Haralambos Mouratidis, and Stefan Wagner. “Towards a Framework to Elicit and Manage Security and Privacy Requirements from Laws and Regulations”. In: (2010). doi: 10.1007/978-3-642-14192-8_23.
12. Fatemeh Zarrabi Jorshari, Haralambos Mouratidis, and Shareeful Islam. “Extracting Security Requirements from Relevant Laws and Regulations”. In: (2012). doi: 10.1109/RCIS.2012.
13. Vjatšeslav Antipenko and Raimundas Matulevicius. “Agentic Architecture for Formalising Security Risk Elicitation”. In: (2026).
14. RIA. E-ITS. Eesti Infoturbestandardi portaal. url: https://eits.ria.ee/.

15. Thomas Lepik. “Eesti Infoturbestandardi turvameetmete rakendatuse automaatkontrolli põhimõtted”. Juhendajad: M. Seeba, T. Oja. Magistritöö. Tallinna Ülikool, 2024. url: https:
    //www.etera.ee/zoom/199404/view?page=1&p=separate&tool=info.