Deploying an AI voice agent under NIS2

The NIS2 Directive establishes a common cybersecurity framework for organisations operating across critical sectors in the European Union.

Unlike DORA, NIS2 is a directive rather than a directly applicable regulation. Member States were required to transpose it into national law by 17 October 2024, but implementation has not progressed uniformly. In July 2026, the European Commission referred France, Ireland, the Netherlands and Spain to the Court of Justice of the European Union for failing to notify complete transposition.

The core requirements originate in the same EU directive, but the precise scope, registration process, competent authority, supervision, penalties and procedural requirements depend on the applicable national law.

For organisations operating across several Member States, that distinction matters. The cybersecurity framework is European. The paperwork remains reassuringly national.

This article explains how an Elba deployment fits into that framework and what Kolsetu provides to support the customer’s assessment.

Does NIS2 apply to your organisation?

NIS2 applies to public and private entities operating in the sectors listed in Annexes I and II of the Directive. These include energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space, postal services, waste management, certain manufacturing activities, food production and distribution, chemicals, research and specified digital services.

Whether an organisation falls within scope depends on its sector, activities, size and the applicable national transposition law.

As a general rule, NIS2 covers entities in the listed sectors that qualify as medium-sized enterprises or exceed the thresholds for medium-sized enterprises. Micro and small enterprises are generally excluded, although important exceptions bring certain organisations within scope regardless of size, including some providers of public electronic communications networks, trust services, domain-name services and other particularly critical services.

The distinction between an essential entity and an important entity primarily affects supervision and enforcement. Both categories must implement appropriate and proportionate cybersecurity risk-management measures and comply with the relevant incident-reporting requirements.

Financial entities must also consider the relationship between NIS2 and DORA. Under Article 4 of NIS2, corresponding NIS2 risk-management and incident-reporting requirements do not apply where sector-specific EU legislation imposes requirements that are at least equivalent in effect. DORA is the principal example for regulated financial entities. This interaction should be assessed before applying both frameworks independently to the same Elba deployment.

For organisations within scope, three areas are particularly relevant to Elba: cybersecurity risk management under Article 21, supply-chain security under Article 21(2)(d), and significant-incident reporting under Article 23.

Where Kolsetu sits under NIS2

Supplying technology to a NIS2-regulated customer does not, by itself, make the supplier an essential or important entity.

Whether Kolsetu is independently within scope must be assessed based on its activities, size, place of establishment and the national law implementing NIS2. In particular, the assessment must consider whether any services supplied by Kolsetu fall within a listed category such as cloud computing, managed services or managed security services.

Kolsetu should therefore not make an unconditional statement that it can never be directly subject to NIS2. Based on the Elba supplier relationship alone, however, Kolsetu does not inherit the customer’s status as an essential or important entity.

For customers within scope, Kolsetu forms part of the supply chain that the customer must assess and secure. Article 21(2)(d) requires essential and important entities to address security-related aspects of their relationships with direct suppliers and service providers. The assessment must consider vulnerabilities specific to each supplier, the overall quality and resilience of the products and services, and the cybersecurity practices of suppliers and service providers.

Kolsetu does not claim that Elba is independently “NIS2 compliant”. NIS2 compliance belongs to the organisation in scope and depends on how Elba is selected, configured, integrated, contracted, governed and monitored. Elba is designed to operate within that organisation’s cybersecurity framework.

The first question: what function does Elba support?

The starting point is to identify the function supported by Elba and the effect that disruption, compromise or loss of availability could have on the organisation’s services and network and information systems.

Elba may be used for first-contact handling of insurance claims, patient communications, emergency or roadside assistance, payment and account support, fraud intake, customer authentication, collections or communications during a service disruption. Depending on the organisation and deployment, those workflows may have direct relevance to the continuity, security or availability of services covered by NIS2. An Elba deployment handling routine internal scheduling may present a different level of risk.

Unlike DORA, NIS2 does not establish a formal classification of individual supplier arrangements according to whether they support a “critical or important function”. The organisation must instead assess the risks associated with the deployment and implement measures that are appropriate and proportionate to those risks.

Kolsetu provides the technical and operational information needed to support that assessment. The assessment and resulting treatment remain the customer’s responsibility.

Cybersecurity risk management under Article 21

Article 21 requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage risks to their network and information systems and to prevent or minimise the effects of incidents.

Those measures must follow an all-hazards approach and cover at least ten areas: risk analysis and information-system security policies; incident handling; business continuity, backup management, disaster recovery and crisis management; supply-chain security; security in system acquisition, development and maintenance, including vulnerability handling and disclosure; assessment of the effectiveness of cybersecurity measures; cyber hygiene and training; cryptography and encryption; human-resources security, access control and asset management; and, where appropriate, multi-factor or continuous authentication, secure communications and secured emergency communications.

These requirements form a cybersecurity programme rather than ten independent boxes to tick.

For an Elba deployment, the customer must determine how the service fits into that programme, which controls apply and what evidence is required to demonstrate that the risks have been assessed and treated proportionately.

Access to Elba should, for example, be configured consistently with the customer’s identity and access-management requirements. Depending on the architecture and sensitivity of the connected systems, this may involve role-based access, privileged-access controls, multi-factor authentication, user lifecycle management, logging and periodic access reviews.

Kolsetu supports the assessment through security documentation, architecture information, certification evidence, access-control capabilities, incident cooperation and information about material technical dependencies. Certification supports the assessment, but it does not replace it.

NIS2 also places responsibility above the operational security function. Under Article 20, the management body must approve the cybersecurity risk-management measures, oversee their implementation and undertake appropriate training. For an Elba deployment, this means the risk assessment, supply-chain treatment and contractual safeguards should fit within the organisation’s approved cybersecurity framework. Procurement may run the process and the CISO may assess the controls, but accountability does not disappear into the vendor file.

Supply-chain security

Supply-chain security is one of the clearest points of contact between NIS2 and an Elba deployment. Unfortunately, recognising this fact does not count as implementing it.

The customer must assess the security-related aspects of its relationship with Kolsetu. That assessment should consider the service being supplied, the data and systems involved, the consequences of disruption, Kolsetu’s security controls, known dependencies and the measures available to manage the resulting risk.

The assessment should not stop at confirming that Kolsetu holds an ISO 27001 certificate. Relevant evidence may include the scope of the certification, security policies, architecture documentation, vulnerability-management processes, incident-management arrangements, business-continuity controls, access-management measures, data locations and material third-party dependencies.

The customer should also consider the parts of the delivery chain on which the deployment materially depends. Depending on the agreed architecture, these may include cloud infrastructure, telephony, AI models, speech-to-text services, text-to-speech services and customer integrations.

NIS2 does not expressly require every organisation to audit every subcontractor used by every supplier. The depth of the assessment must remain appropriate and proportionate to the risk. For a deployment supporting a sensitive or operationally important service, however, ignoring material dependencies behind the direct supplier would leave the assessment incomplete.

For enterprise deployments, Kolsetu identifies the material providers and services used in the agreed architecture and provides relevant information about their role and location.

Elba is also designed to reduce avoidable dependency. Its model layer is not tied to one AI model provider and can be changed without replacing the complete workflow, integration and orchestration layer. This will reduce one source of supplier dependency, although it does not remove the need to assess the remaining delivery chain.

Depending on the agreed architecture and customer requirements, Elba supports cloud, private-cloud and on-premises deployment models. EU data processing and storage can be contractually agreed, and the relevant service and infrastructure locations can be documented.

What the contract should address

NIS2 does not prescribe a universal set of mandatory supplier-contract clauses equivalent to Article 30 of DORA. It does, however, require organisations to address security in their relationships with direct suppliers and service providers. In practice, a meaningful supply-chain security programme normally requires the relevant obligations to be reflected in the contract rather than left to mutual optimism.

For an Elba deployment, the contract and related documentation should clearly define the service, supported workflows, delivery architecture, integrations, responsibilities, support arrangements and service levels. Descriptions such as “AI services” are unlikely to provide enough information for a serious risk assessment. They may, however, keep a marketing department occupied.

The agreement should establish the applicable security requirements. Depending on the risk and deployment, these may address security certification, access control, vulnerability management, patching, secure change management, testing, incident cooperation and notification of material changes to the security posture.

Incident-notification obligations, escalation routes, information requirements and cooperation during and after an incident should be defined. A 24-hour provider-notification commitment can be contractually agreed for material incidents affecting the customer’s service. This is a Kolsetu commitment, not a universal supplier-notification deadline imposed by NIS2.

Appropriate audit and assurance arrangements should also be established according to risk. These may include security certifications, independent reports, customer assessments, audits by an appointed third party or direct audit rights. NIS2 does not state that every supplier agreement must contain unrestricted audit rights, but the chosen assurance model must allow the customer to obtain sufficient evidence that the relevant controls exist and remain effective.

The agreement should address material subcontractors and technical dependencies, including what information Kolsetu will provide and how the customer will be notified of relevant changes to the delivery architecture.

Data-processing and storage locations should be documented where they are relevant to the deployment and risk assessment. Any agreed residency commitment must be stated contractually rather than inferred from an architecture diagram shown during procurement.

Termination provisions should address data access, export, retention and deletion, together with any required transition assistance and continuity arrangements.

Business continuity and incident reporting

Article 21 requires organisations within scope to address business continuity, including backup management, disaster recovery and crisis management. For an Elba deployment, this means understanding how the supported function would continue or recover if the platform, an integration, a communications provider or another material dependency became unavailable.

Depending on the deployment, the continuity arrangements may cover service availability, recovery procedures, escalation routes, human handover, alternative communication channels, integration failures and temporary return to manual processing.

A 99.95% availability commitment can be contractually agreed for qualifying Elba deployments. This is a Kolsetu service commitment, not an availability level prescribed by NIS2.

The appropriate fallback arrangement depends on the use case. An agent handling routine enquiries does not necessarily require the same continuity design as one supporting emergency assistance, healthcare communications or payment operations. The customer and Kolsetu should therefore identify the relevant dependencies, responsibilities, fallback paths and recovery expectations during implementation.

Where an incident involves Elba or a material dependency, the customer needs sufficient information from Kolsetu to understand its scope, operational effect, likely duration and remediation status. The contractual provisions should define what constitutes a service incident, notification and escalation timeframes, points of contact, the information included in the initial notification, update frequency, technical support, root-cause reporting and cooperation with customer or authority investigations.

Article 23 establishes a staged reporting process for significant incidents. An entity must generally submit an early warning without undue delay and, in any event, within 24 hours of becoming aware of a significant incident. An incident notification must follow without undue delay and, in any event, within 72 hours. A final report is generally required within one month after the incident notification. Where the incident remains ongoing, the entity must instead submit a progress report and provide the final report within one month after the incident has been handled.

An incident is significant where it has caused or is capable of causing severe operational disruption or financial loss for the entity, or where it has affected or is capable of affecting other persons by causing considerable material or non-material damage.

Kolsetu’s role is to provide the information the customer reasonably needs to make that assessment and meet any resulting reporting obligations. The customer remains responsible for determining whether an incident is significant and for submitting the required notifications through the competent national reporting channel.

The role of the NIS2 Implementing Regulation

Commission Implementing Regulation (EU) 2024/2690 provides detailed technical and methodological requirements for specified categories of digital entities, including cloud computing providers, data-centre providers, content-delivery network providers, managed service providers, managed security service providers, online marketplaces, search engines, social-networking platforms, DNS providers, top-level domain registries and trust-service providers.

It does not establish the detailed control requirements for every organisation in every NIS2 sector. Entities covered by the Regulation must apply its more specific requirements, while other NIS2 entities remain subject to the applicable national transposition law and sector-specific framework.

ENISA published technical implementation guidance in June 2025 to help the specified digital entities apply the Regulation and identify suitable evidence of implementation. Other organisations may find that guidance useful as a reference, but it does not replace the legal requirements applicable to their own sector and jurisdiction.

Documenting the assessment and completing procurement

NIS2 does not create a central supplier register equivalent to DORA’s Register of Information. The organisation must nevertheless be able to demonstrate that it has implemented appropriate and proportionate cybersecurity measures, including supply-chain security.

For an Elba deployment, the evidence may include the documented risk assessment, security due-diligence records, the agreed architecture and dependency analysis, security and continuity documentation, contractual security provisions, assurance evidence, incident procedures, records of periodic review and remediation actions arising from identified risks.

Competent authorities have supervisory and enforcement powers that may include information requests, off-site supervision, on-site inspections and targeted security audits, subject to the entity’s classification and applicable national law.

Before entering into the arrangement, procurement must therefore establish more than whether Kolsetu holds a security certificate. The organisation must confirm the scope of the service, the function Elba will support, the consequences of disruption or compromise, the agreed architecture, relevant service and data locations, material technical dependencies, available security evidence, incident-notification and cooperation arrangements, continuity expectations, access requirements, assurance arrangements, data access and deletion provisions, and termination and transition support.

The required depth of the assessment must reflect the deployment’s risk and operational significance. Kolsetu can provide a structured enterprise due-diligence pack containing relevant company details, ISO 27001 evidence, security and architecture documentation, service and data locations, material dependency information and available assurance documentation. The customer remains responsible for completing and maintaining its own assessment.

A supplier review that was completed at onboarding and never revisited remains evidence that somebody once completed a supplier review.

The practical position

NIS2 does not prevent essential and important entities from using AI voice agents. It requires them to understand and manage the associated cybersecurity and supply-chain risks.

Kolsetu does not claim that Elba is independently “NIS2 compliant”. Elba is designed to operate within the customer’s NIS2 framework by supporting the customer with architectural transparency, documented dependencies, appropriate deployment options, security evidence, contractual protections, incident cooperation, assurance support, data portability and transition planning.

The customer remains responsible for determining whether it falls within scope and for complying with the national law applicable to it. Kolsetu’s role is to ensure that an Elba deployment does not leave the customer’s CISO, procurement or compliance team without the information, controls and contractual support needed to assess and govern it properly.

At the end of the day, we do not want to be just another supplier in the chain. We want to be the partner your security, procurement and compliance teams can rely on throughout the deployment, because that is the only realistic way to support NIS2 compliance over time.