September 8, 2025
The context: why finance cannot afford fragility Operational continuity is now one of the essential conditions for the banking, financial, and insurance world. A prolonged downtime […]
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 compliant. Policies to update, procedures to formalize, roles to assign, documentation to prepare for potential inspections. It’s understandable, because for years regulatory security has largely been a matter of documentation.
The point is that NIS2 was born in a completely different context. It doesn’t simply ask that rules exist; it wants those rules to work when the environment becomes unstable. It shifts attention from structure to behavior, from description to the ability to respond. In that sense, the directive introduces a paradigm shift that many companies are underestimating.
The most delicate part of NIS2 stems from its underlying assumption, which runs through the entire directive: security is assessed by the ability to react effectively when an incident occurs.
For a long time, cyber risk processes were built to create order. Periodic assessments, scheduled audits, incident response procedures that were well structured on paper. Everything had its internal logic and a reassuring function. In a relatively stable context, this approach worked.
NIS2 challenges this setup because it focuses on the moment when processes are actually used. Not when we review them in a quarterly meeting, but when we have to activate them under pressure. That’s when weaknesses surface: procedures that no one has ever followed end to end, decision-making steps that are too slow, dependencies across teams that generate friction in practice.
Many organizations will discover that their processes are formally correct, but operationally fragile. They were designed to work under ideal conditions, not under real stress. NIS2 doesn’t create this fragility, but it makes it visible. And visible fragility becomes a risk that can no longer be ignored.
It is in this context that the role of the CSIRT Point of Contact takes on a meaning that goes far beyond regulatory compliance. Many companies are treating it as someone to appoint, a contact to register, a responsibility to assign formally. But the deeper meaning of the role is different.
During a real incident, the CSIRT Point of Contact sits at the center of a complex convergence. On one side, they must understand what is happening technically; on the other, they must enable decisions with operational, communication, and often legal consequences. They have to operate in a context where information is incomplete, time is limited, and expectations are high.
The real issue is whether this role can actually operate in practice. In many organizations, responsibilities are formally defined, while operational delegations remain unclear. Decisions therefore tend to move up the hierarchy precisely when time becomes critical. The result is a slower decision chain, greater uncertainty, and an incident impact that grows.
NIS2 makes this dynamic observable. It implicitly requires a point of synthesis—someone who can coordinate and steer action. Where this role is clear and integrated into company processes, the response tends to be faster and more coherent. Where it is only formal, it becomes a point of friction. In this sense, the CSIRT Point of Contact is one of the most reliable indicators of an organization’s real maturity in cyber risk management.
Another aspect NIS2 brings to the forefront is the organizational dimension of an incident. Too often, incidents are still thought of as predominantly technical events. In reality, the technical component is only part of the problem.
When an incident is underway, complex organizational dynamics come into play. Who communicates with whom? What information is shared, and at what level of detail? Who decides to isolate a critical system, accepting a service interruption? Who determines when to inform customers, partners, or authorities?
These decisions cannot be made solely on the basis of written procedures. They require clarity of roles, trust in processes, and a shared view of priorities. By pushing incident management as an observable process, NIS2 forces organizations to confront this often overlooked dimension.
|
Decision
|
Who must be involved immediately
|
What must already be in place
|
|---|---|---|
|
Isolate a critical system
|
IT + Security + Business owner
|
Prioritization criteria, acceptable impacts
|
|
External communication
|
Legal + CSIRT/CISO
|
Pre-aligned messages, channels
|
|
Notifications/authorities (NIS2)
|
CSIRT Point of Contact + Legal + Executive leadership
|
Roles, timing, minimum required information
|
|
Recovery and continuity
|
IT + Business + Security
|
recovery sequence, dependencies
|
The sanctions provided for by NIS2 exist and must be taken seriously. It would be a mistake to treat them as a detail or as a remote possibility, because the directive makes responsibilities and expectations more explicit and reduces the space for grey areas. That said, stopping at the “fine or no fine” logic means reading only part of the story.
Insurance providers—who are supposed to protect and step in when an incident occurs—are paying increasing attention to real risk management capability. It’s not enough to declare that a security program exists; it must be demonstrated that the program is operational. Third-party audits are changing tone, focusing less on the presence of documents and more on their applicability. Critical partners are beginning to treat resilience as a prerequisite for maintaining a relationship.
In this context, formal compliance loses value if it is not paired with demonstrable capability. The risk is not an administrative penalty, but a loss of trust. And that loss of trust translates into higher costs, missed opportunities, and more fragile commercial relationships.
The greatest risk NIS2 brings is that many organizations will discover the gap between what they thought they controlled and what they actually control at the worst possible moment: during an incident, when there is no time to rethink processes, clarify roles, or improve visibility.
In those moments, all the ambiguities that have accumulated over time emerge: processes never tested, overlapping responsibilities, unmapped dependencies. The difficulty becomes cognitive—understanding what is happening and what to do while the event evolves.
NIS2 doesn’t eliminate this risk, but it makes it more visible and harder to justify. After an incident, it will not be enough to prove that a procedure existed. What will be observed is whether that procedure helped or hindered the response.
NIS2 is not a regulation to “pass” like an exam. It is a reality check. It asks organizations to measure themselves against their ability to manage risk over time, going beyond mere formal description in documents. It shifts attention toward security that must be practicable, exercised, and verified in real terms. What is often perceived as the most complex part of NIS2 primarily requires understanding. It is an invitation to rethink how security is interpreted, moving beyond the equation of formal control with an effective ability to respond to incidents. Documentation remains necessary, but it is not sufficient unless it is backed by processes and decisions that can truly be activated in critical moments.
Organizations that manage to close this gap will go beyond meeting a regulatory obligation. They will have built clearer decision structures, genuinely operational responsibilities, and a stronger awareness of their role in risk management. In this scenario, compliance becomes the natural consequence of a system that works, not its ultimate goal. The result is a more resilient and more credible company in the eyes of customers, partners, and authorities—able to operate with greater awareness in a context where cyber risk is a structural and permanent variable of the business.
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
