December 17, 2025
We are seeing many organizations approach NIS2 in the same way they approached other regulations: as a list of things to fix in order to be […]
When Compliance Stops Being a Project and Becomes a Continuous Operating Condition
In 2026, with the formal transition marked by the date of October 1st, the NIS2 Directive enters its full implementation phase.
The real change, however, is primarily linked to what the directive imposes from that moment onwards: when NIS2 stops being addressed as a one-time adjustment to be completed and becomes a permanent condition of operation.
The new NIS2 requirements, highlighted in the Security Measures issued by ACN, are not built to be satisfied only once, but to be maintained, reviewed, and adapted over time. The security measures repeatedly emphasize references to periodic reviews, updates linked to changes in context, and plans that must remain operational and consistent with the evolution of the organization.
This approach, however, conflicts with a still widespread working method: considering compliance with a “one-shot” logic, oriented towards achieving only an initial state of conformity. This model, often focused on document production and closing initial actions, is sustainable only in ideal contexts where everything remains static over time.
The framework of NIS2 is instead built on domains that presuppose continuity. Governance requires explicit responsibilities and decisions that must be reviewed over time. The identification of assets, services, and dependencies cannot be static if the perimeter is constantly evolving; protection measures must remain consistent while the infrastructure changes; detection capabilities must be constant, not episodic; response and recovery presuppose continuous preparation, testing, and updating.
In this framework, treating compliance as a project to be closed means working against the very logic of the directive. NIS2 does not only ask to implement controls but to demonstrate the ability to govern them over time, while the technical and organizational context constantly modifies itself.
At this point, the directive changes its nature and stops being a regulation to be interpreted. The phase of reading and framing the requirements is substantially behind us, and the focus shifts to a different, much more concrete level: the stability of the operating model that supports compliance becomes central, rather than formal adherence to individual requirements.
This transition is less visible than a deadline but has a much deeper impact on the daily functioning of organizations. In this new scenario, compliance stops being an exercise in regulatory interpretation and becomes a problem of continuous execution, bringing to light the real line of separation introduced by the NIS2 implementation phase.
On one side, there are organizations that have built compliance as a set of activities that are correct on a formal level but poorly integrated into actual operations. On the other, those that have started to treat it as part of risk governance and strategic decisions.
In this sense, NIS2 affects how resources are allocated, how trade-offs are managed, and how decisions are made that have direct effects on operational continuity. This is the point where the directive truly changes nature, paving the way for compliance that becomes part of operational normality.
When compliance stably enters operations, the work stops being organized by phases and begins to follow the rhythm of the organization. There is no longer a dedicated moment where one “does compliance” and others where one deals with something else. Compliance work becomes daily life, integrating with the rest of activities because it concerns the way assets, services, and decisions are kept consistent over time.
This work arises from the need for alignment between what has been defined and what is actually in operation, between assessments built at a certain moment and operational conditions that change, between decisions taken and contexts that evolve. Part of the work consists precisely in keeping these elements together, reviewing them when they lose adherence to reality.
Over time, the work is also activated reactively. Technical changes, evolution of services, or new dependencies introduce elements that must be understood and absorbed into the existing model. These dynamics are not exceptions but part of operational normality, and this is why compliance work tends to intertwine with IT initiatives, audit activities, and ordinary service management.
Organizing the work then means building continuity and stability, not adding new activities. It means giving a structure to what already happens, preventing work from being managed only when an emergency occurs or when something does not work. When this continuity is lacking, the workload grows in a disorderly fashion and it becomes difficult to maintain an overall vision, even if individual actions are correct.
When, instead, the work is held together consciously, compliance finds a stable placement. It becomes clearer when a change requires attention, how to distribute work over time, and where to intervene to maintain overall stability. It is in this transition that NIS2 begins to truly impact the organization of work, making visible the difference between a model that holds up and one that struggles to sustain itself.
When compliance becomes part of the ordinary functioning of the organization, the issue of responsibility becomes inevitable. NIS2 brings to the fore a simple and often postponed question: who is involved in risk management and where are the decisions regarding it made?
For a long time, compliance was concentrated within a single function, often for reasons of organizational efficiency and simplification of oversight. This setup tends to hold as long as compliance remains confined to a technical or documentary scope. However, when it begins to affect services, priorities, and choices involving the entire organization, the limits of this model emerge more clearly. In this scenario, some key roles introduced or strengthened by NIS2 assume importance. The Point of Contact becomes the junction between the various functions involved, ensuring continuity and coherence in the management of information and decisions. Similarly, the CSIRT contact person does not just represent an operational contact, but a function that must be inserted into a clear decisional context, especially when events and incidents require rapid and coordinated evaluations.
The central point remains the decision-making process. In an evolving context, decisions must be able to be reviewed in an orderly manner, based on updated information and clear responsibilities. This requires a stable involvement of multiple functions and an active role of management, called to ensure continuity of choices over time. It is on this ability to make explicit who decides, how they decide, and with what responsibilities that a significant part of the stability of NIS2 compliance is played.
At this stage, it appears clear that a change in mindset, but above all an organizational one, is the key to effectively managing compliance with the regulation over time and transforming it from an “imposed requirement” into an opportunity for improvement. All this certainly has a cost, potentially high, and above all, continuous.
Is it possible to estimate this cost for both the adjustment phase and the maintenance phase?
The answer is certainly yes, and the GAP analysis is the fundamental starting point for building a solid economic framework that supports the budget requirements generated by regulatory adjustment and its adoption. Conversely, it is more complex to estimate what the recurring costs arising from maintaining regulatory compliance over time might be; it is even more complex to have an optimized plan that ensures an efficient allocation of resources as the organization evolves and transforms over the years to follow its business needs.
Speaking of optimization, we must introduce a concept that we believe is crucial, which breaks down this often generic or even “fuzzy” term into something extremely practical: while it is true that NIS2 does not contemplate the concept of a partial perimeter, it is equally true that the legislator has taken the responsibility of clearly indicating, in the “Baseline Security Measures for NIS entities“, several Control Points that are applicable not always and in every case, but only upon the occurrence of certain conditions or on specific perimeters. Within the scope of essential entities, by appropriately classifying the controls proposed by the legislator, one notices that over 30% of these should not be applied indiscriminately and without a critical evaluation, but rather in areas or perimeters defined by:
The contradiction regarding the absence of a partial perimeter is only apparent.
An organization cannot be subject to NIS2 only for a part of its processes, systems, or networks. If it is included, it is included in its entirety. This principle leaves no room for interpretation. The legislator, however, introduces an element that significantly affects the concrete application of the rule: namely, that some control points (almost a third) can be applied exclusively in contexts where there is real relevance to the provided obligations.
This passage deeply affects the setup of the adjustment. The organization is involved in its entirety, but controls must be applied where they find a real foundation in the operational context. Every measure must be linked to processes and systems that generate concrete exposure. Without a clear reading of internal interdependencies, this evaluation remains abstract. When, instead, the infrastructure is mapped objectively, it becomes possible to calibrate the intervention with precision and consistency.
To further simplify with a practical example: if an organization is subject to NIS2 to ensure the continuity of the wholesale food transformation and distribution chain (Important Entity ex Annex II – point 4), the systems, networks, and processes dealing with retail sales will not be included in the scope of applicability of these specific control points.
It is therefore logical to think that the more complex, extensive, and diversified an organization is across different sectors and markets, the more the effect of simplification and focus introduced by this set of control points can positively impact the total cost of the compliance model over time. But there is a “but.” Perhaps more than one.
The legislator has effectively taken responsibility by indicating the applicability criteria for a consistent portion of control points, but it is up to the NIS2 entity to find the correct way to apply these criteria in reality, in a continuous, demonstrable, and data-driven manner. The responsibility in this sense falls solely on the NIS2 entity.
The time has come to identify the essential ingredients for the recipe that will lead us to success in this new challenge. To find them, we once again rely on the regulator’s provisions, and in particular on some specific control points that clearly suggest where to start.
Control point GV.OC-04 states: An updated list of relevant information and network systems is maintained.
Satisfying this control point means having a reliable inventory of systems, networks, and resources, but above all an objective driver to define them, somehow, as relevant. Therefore, the application and network inventory must be traced back—or rather, mapped—to business processes, for which, in optimal circumstances, a form of contribution level or criticality should be calculated. Anyone who has performed a Business Impact Analysis at least once is probably already noticing how this requirement is covered by this very important document, which we could therefore “baptize” as the first essential ingredient.
Points ID.AM-01, 02, 03, and 04, however, require us to take a further step—actually, several. They require that updated inventories be maintained:
This layer of mapping is more technical and profound and immediately conveys the regulator’s desire to push the NIS2 entity to know its technical and systemic infrastructure in detail; not as a one-off but continuously. This is the second “ingredient” in the recipe for success.
Implementing and maintaining such a system may seem like a gargantuan, complex, and expensive undertaking: it certainly is if approached with a traditional method, whereas it can become significantly simpler and more agile if the right tools are adopted. A platform like ai.esra, capable of creating and maintaining a digital twin of systems, applications, network flows, devices, and IT, OT, and IoT hardware, can transform a costly, labor-intensive, and error-prone process into an activity as simple as consulting a dashboard.
The third and final ingredient of the success recipe we are composing is based on the indications and clues found in the Security Measures.
To put it simply, one could define the risk approach as pervasive to the regulation, but to get down to practical terms, let’s try one last time to analyze the control points.
GV.RM-03 requires that a cybersecurity risk management plan be defined, implemented, updated, and documented to identify, analyze, evaluate, treat, and monitor risks.
Being a matter of governance, nothing less is to be expected, but again, the issue on the implementation level becomes complicated because in the Identify domain, point ID.RA-05 mandates that the risk assessment posed to the security of information and network systems be performed and documented, […] including at least: risk identification; risk analysis, and risk weighting. Following this, ID.RA-06 closes the loop by establishing that: a risk treatment plan is defined, documented, performed, and monitored […].
The key to making this highly structured—and therefore likely burdensome—risk management system sustainable over time is not relying on the minimum update criterion of 2 years (ID.RA-05.2), but evaluating the adoption of processes and tools that combine the semantics of risk assessment in a continuous perspective with the possibility of automating, as much as possible, its quantitative calculation starting from reliable and equally continuous data sources. Farewell to interview campaigns and questionnaire administrations: technical and technological risk are not opinions, but rather information that must be drawn from the compelling reality of the company, modeled according to precise algorithms starting, as mentioned, from real data.
In conclusion, combining knowledge of business processes with the technological and digital layer that supports them—descending to the detail of individual hardware components and network flows—and crossing everything with a manageable and governable risk analysis to make effective decisions, is not a result achievable (or at least sustainable) by working in a traditional way.
Adopting a digital solution like ai.esra can allow for a consistent resolution of the complexity that NIS2 entities find themselves managing, offering the opportunity not only to achieve more effective and precise results but to transform the adoption of technology itself into an opportunity for saving resources, both economic and time-related.
To paraphrase a well-known proverb: “saving both the goat and the cabbage” (having it both ways) seems truly possible today.
ai.esra SpA – strada del Lionetto 6 Torino, Italy, 10146
Tel +39 011 234 4611
CAP. SOC. € 50.000,00 i.v. – REA TO1339590 CF e PI 13107650015
“This website is committed to ensuring digital accessibility in accordance with European regulations (EAA). To report accessibility issues, please write to: ai.esra@ai-esra.com”
ai.esra SpA – strada del Lionetto 6 Torino, Italy, 10146
Tel +39 011 234 4611
CAP. SOC. € 50.000,00 i.v. – REA TO1339590
CF e PI 13107650015
© 2024 Esra – All Rights Reserved
