Why European compliance starts at the service desk: what IT managers need to do now

The NIS2 Directive on cybersecurity has been in force across Europe for several years. It is a directive that does not simply ask European organizations to purchase new security tools. It requires that cyber risk be governed through verifiable technical, operational, and organizational processes: from incident management to operational continuity, from change control to supply chain security. The key point is: many of these processes already exist within IT Service Management. The problem is that, in numerous organizations, NIS2 compliance is still treated as an isolated project, entrusted almost exclusively to cybersecurity, risk management, or legal teams.

Meanwhile, a considerable portion of the evidence required by regulators continues to be produced every day by the service desk, incident management workflows, change management processes, and supplier management systems. Consequently, the real challenge facing many companies is not about creating new controls from scratch. It consists of linking regulatory obligations (such as the NIS2 Directive) and compliance requirements to existing ITSM processes, increasing their maturity, and transforming operational data into reliable compliance evidence.

This is what we will focus on in this article.

From regulatory requirement to operational governance

It’s worth stepping back to frame the issue properly with a concrete case study. The NIS2 Directive, formally EU Directive 2022/2555, entered into force on January 16, 2023. Member States were required to transpose it by October 17, 2024, and the new European rules began to apply from October 18, 2024 through their respective national legislation. For organizations operating in multiple European countries, it is therefore also necessary to verify the specific transposition arrangements in each jurisdiction.

The scope is much broader than the previous NIS. It includes public and private organizations belonging to 18 critical sectors, including energy, transport, healthcare, digital infrastructure, cloud services, data centres, managed ICT services, public administration, industrial manufacturing, and research. But the most important change does not concern only the number of entities involved. The NIS2 Directive, in fact, brings cybersecurity into corporate governance. Management bodies must approve and oversee cyber risk management measures and may be held accountable for the organisation’s shortcomings. Security, therefore, can no longer be confined to the SOC or delegated to a small group of specialists. It must become part of the ordinary functioning of the company.

And this is precisely where ITSM comes into play.

Why compliance goes through IT Service Management

A mature ITSM environment is built around certain principles that align with the expectations of a directive such as NIS2:

• defined responsibilities
• classification and prioritization of events
• rule-based escalation
• SLAs and time thresholds
• change approval and tracking
• knowledge of the assets and services involved
• supplier performance monitoring
• complete documentation of activities
• continuous improvement.

A correctly managed ticket is not merely an operational request. It is a documented sequence of decisions, responsibilities, communications, and actions. Likewise, a change record is not simply authorization to install a new software version. It can become evidence that the organisation has assessed risks, analyzed impacts, defined a rollback plan, and obtained the necessary approvals.

This is the same principle already addressed in our previous article dedicated to AI integration in ITSM in light of the EU AI Act: the more technology enters business processes, the more owners, controls, documentation, and audit trails are needed.

In both cases, the ITSM platform can become the connecting point between policy and operations. And this is where compliance stops being a set of documents and becomes an operational process.

Incident management: meeting deadlines starts with the first ticket

Let us go into more detail, with another example from the NIS2 Directive. This introduces a multi-phase reporting process for significant incidents. In general terms, the following are envisaged:

• an early warning within 24 hours of becoming aware of the incident
• a notification within 72 hours, including an initial assessment
• a final report within one month, with details on the impact, causes and corrective measures adopted.

Meeting these timelines does not depend solely on the capability of the security team. It depends on what happens in the first few minutes within the service desk.

The incident management workflow must first reliably distinguish a normal technical problem from a potential security incident. It must then immediately collect the necessary information: service involved, impacted assets, affected users, source of the report, criticality level, possible propagation, dependencies, and business impact.

Classification cannot remain solely dependent on the intuition of the individual operator. Shared categories, priority matrices, and escalation rules are needed. A ticket potentially relevant for NIS2 purposes should automatically trigger:

• notification to the cybersecurity manager
• involvement of the incident manager
• creation of a verifiable timeline
• application of SLAs consistent with regulatory deadlines
• preservation of technical and decision-making evidence
• initiation of the communication workflow towards management, legal, and compliance

An Incident Management Automation solution such as EasyVista’s allows the centralization of incident recording, classification, assignment, and monitoring, reducing the risk that a serious event remains trapped in an email, a chat, or a generic queue. Here is a first concrete step in the direction of compliance.

Change management: no change without a risk assessment

Not all incidents stem from an external attack. A significant portion of problems arise from poorly planned changes, incorrect configurations, incomplete updates, or changes introduced without an adequate assessment of dependencies.

This is why change management is one of the most important links between the NIS2 Directive, ITSM compliance, and the day-to-day management of services. A compliance-ready workflow should document at least:

• reason and objective of the change
• services, assets and configurations involved
• assessment of operational and security impact
• technical dependencies
• approvals received
• test plan
• implementation window
• rollback plan
• outcome of the change
• any subsequent incidents or vulnerabilities

Standard and low-risk changes can be automated. Those involving essential services, privileged access, security configurations, or exposed components must instead include more robust controls and, where necessary, the involvement of security managers.

Supplier management: the supply chain must enter ITSM workflows

Supply chain security is one of the pillars of the NIS2 Directive. Organizations must consider not only the risks present in their own systems, but also those associated with direct suppliers of ICT products and services. Cloud providers, managed service providers, software vendors, support partners,  and outsourcers can represent essential dependencies for service delivery. Simply inserting a generic clause in the contract is no longer sufficient.

Consequently, supplier management should include:

• an up-to-date inventory of suppliers and services provided
• classification of vendors by criticality
• mapping between supplier, contract, service and asset
• minimum security requirements
• mandatory incident notification timelines
• verification and audit rights
• escalation procedures
• periodic risk assessments

So, what does it mean to be “compliance-ready” in ITSM?

The answer to this question is not straightforward. Being ready for compliance does not mean being able to declare that a platform, on its own, “makes an organisation compliant with the NIS2 Directive.”

Compliance depends on the interaction between people, processes, technologies, governance, and security measures. ITSM software, however, can provide the operational architecture needed to apply controls and produce the related evidence. A compliance-ready ITSM environment should be able to quickly answer very concrete questions:

• Who classified this incident and on the basis of what criteria?
• When did the 24-hour countdown begin?
• Which services and assets were involved?
• Who authorized a critical change?
• What risk assessment was carried out?
• Which supplier was responsible for the component?
• What corrective actions have been completed?
• How were they verified?
• What changed after the post-incident review?

The ability to answer must not depend on the memory of individuals. It must emerge from workflows, records, and audit trails.

This is why products such as EV Service Manager make it possible to structure service management processes, centralize information, automate assignment, escalation, approval and reporting activities.

Conclusions

The NIS2 Directive, like other European regulations, should not create a second infrastructure of processes running parallel to that of IT.

Incident management, change management, problem management, asset management, and supplier management are already the connective tissue through which services are managed. Separating compliance from these processes means duplicating activities, increasing costs, and producing fragmented evidence.

Integrating it into IT Service Management means, instead, transforming every ticket, approval, escalation, and verification into a coherent part of governance.

This yields a dual benefit. On one hand, the organization improves its ability to demonstrate its own compliance. On the other hand, it genuinely becomes more resilient: it detects incidents earlier, coordinates responses more effectively, controls changes, understands dependencies, and governs suppliers with greater care.

FAQ

What is the NIS2 Directive?

NIS2 is the European directive that has strengthened and expanded cybersecurity obligations for organizations operating in critical sectors. It introduces requirements relating to risk management, incident response and reporting, operational continuity, supply chain security, and the accountability of management bodies.

How does ITSM support European compliance?

ITSM offers structured processes for recording, classifying, assigning, monitoring and documenting incidents, changes, problems, assets, and supplier activities. These processes help apply NIS2 controls, for example, and produce verifiable audit trails and evidence.

Does an ITSM platform automatically guarantee European compliance?

No. No software guarantees compliance on its own. An ITSM platform can, however, support the application of processes, the automation of controls, the collection of information, collaboration between teams and the production of the required evidence.