NIS2 Compliance for Communication Platforms
NIS2 (Network and Information Security Directive 2) is the EU’s updated cybersecurity framework, which entered into force on 16 January 2023 replacing the original NIS Directive from 2016. Member states had until 17 October 2024 to transpose it into national legislation, with the rules applying from 18 October 2024, and many organizations are still working out what it means for their day-to-day operations.
Quick Answer
NIS2 compliance is an organizational outcome, not a product certification. Communication platforms can support risk-management measures such as access control, cryptography, incident handling, supply-chain security, and business continuity, but no single platform makes an organization NIS2 compliant on its own. Compliance depends on how the organization assesses risk, configures and operates its systems, documents controls, monitors effectiveness, and meets the requirements of the relevant national transposition.
NIS2 Compliance at a Glance
|
Question |
Practical Answer |
|---|---|
|
What does NIS2 regulate? |
Cybersecurity risk management, incident handling, business continuity, supply-chain security, secure system maintenance, access control, cryptography, governance, and related measures |
|
Who is covered? |
Essential and important entities determined by sector, entity type, applicable size thresholds, and national implementation rules |
|
Can a communication platform be “NIS2 compliant”? |
A product can support relevant technical controls, but organizational compliance cannot be achieved through a product alone |
|
Why do communication tools matter? |
They can process sensitive meetings, messages, files, recordings, identities, and incident-response communications |
|
Does self-hosting guarantee compliance? |
No. It can increase infrastructure and data-location control while shifting more operational security responsibility to the organization |
|
Where does TrueConf Server fit? |
It provides self-hosted communication capabilities that can support access control, encryption, auditability, business continuity, and infrastructure-control requirements |
NIS2 distinguishes essential and important entities primarily by sector, entity type, and applicable size thresholds. The exact classification should be checked against the Directive and the relevant national transposition.
Essential entities and important entities are classified by sector, entity type, and size rules rather than by a simple large-versus-mid-sized split. Essential entities are generally subject to more proactive supervision, while important entities are typically supervised ex post, but both categories are subject to the core cybersecurity risk-management obligations in Article 21.
Essential vs. Important Entities
|
Area |
Essential Entities |
Important Entities |
|---|---|---|
|
Classification |
Based on sector, entity type, size rules, and special inclusion provisions |
Also based on sector, entity type, size rules, and applicable national provisions |
|
Article 21 cybersecurity measures |
Apply |
Apply |
|
Supervisory approach |
Generally includes more proactive supervision |
Generally more focused on ex-post supervision |
|
Management responsibility |
Management bodies have explicit cybersecurity governance duties |
Management bodies also have explicit cybersecurity governance duties |
What NIS2 actually requires organizations to do:
- Maintain risk analysis and information security policies
- Handle and report incidents within defined timeframes
- Plan for business continuity and crisis scenarios
- Assess supply-chain security
- Ensure secure acquisition, development, and maintenance of systems
- Run cybersecurity training and awareness programs
- Apply cryptography and encryption where appropriate
- Enforce access controls and manage assets properly
- Use multi-factor authentication or continuous authentication where appropriate, particularly for privileged, remote, and sensitive access
How Article 21 Measures Fit Together?
|
Category |
NIS2 Focus |
Communication Platform Relevance |
|---|---|---|
|
Governance |
Risk analysis, policies, management accountability |
Defines approved communication systems, administrators, security settings, and responsibilities |
|
Prevention |
Secure acquisition, maintenance, vulnerability handling, cyber hygiene |
Platform hardening, updates, secure configuration, integration review |
|
Identity and access |
Access control, asset management, MFA where appropriate |
User lifecycle, administrator permissions, guest access, authentication |
|
Cryptography and encryption |
Protection of meetings, messages, files, signaling, recordings, and administrative traffic |
|
|
Detection and response |
Incident handling and effectiveness assessment |
Logs, alerts, investigation evidence, configuration history |
|
Continuity |
Backup, disaster recovery, crisis management |
Availability of communications during outages and alternative communication paths |
|
Supply chain |
Supplier and service-provider security |
Hosting, identity, integrations, support, updates, transcription, storage, and connected services |
|
People |
Cybersecurity training and awareness |
Secure meeting practices, external sharing, administrator behavior, credential handling |
NIS2 requires Member States to provide maximum administrative fines of at least €10 million or 2% of worldwide annual turnover for essential entities, and at least €7 million or 1.4% for important entities, whichever is higher.
NIS2 also places explicit cybersecurity governance duties on management bodies; the precise individual liability and enforcement mechanisms depend on national transposition.
Insight 1. Entity classification and platform criticality are separate decisions.
Being an essential or important entity does not automatically make every collaboration tool critical. Organizations still need to assess each platform by the data it processes, the workflows it supports, its dependencies, and the operational impact of compromise or failure.
What NIS2 Does Not Require?
NIS2 establishes risk-management and governance requirements, but it does not prescribe one universal technical architecture for every organization.
- NIS2 does not require every organization to use on-premises or self-hosted software. Deployment should reflect the organization’s own risk assessment and applicable national requirements.
- NIS2 does not certify individual communication products as compliant. Product capabilities can support controls, but organizational compliance depends on governance and implementation.
- NIS2 does not automatically classify every communication platform as critical. The role and risk of each system must be assessed within the organization’s operations.
- NIS2 does not eliminate supplier risk through self-hosting. Software vendors, updates, support providers, identity systems, and integrations can remain part of the supply chain.
- NIS2 does not prescribe one encryption protocol or communication product. Measures should be appropriate and proportionate to the risks involved.
- NIS2 does not make a security feature effective merely because it exists. MFA, logging, encryption, and access controls need to be configured, governed, monitored, and reviewed.
Why Your Communication Stack Is a Compliance Risk?
Here’s something that often gets overlooked: NIS2 risk-management obligations apply to the network and information systems organizations use to store, process, and transmit data, including communication tools that carry sensitive organizational information.
These systems touch strategic decisions, client communications, and internal data that organizations genuinely cannot afford to expose.
Where standard communication tools tend to fall short:
- Unauthorized access to live meetings or archived message histories
- Video, audio, and file transfers sent without adequate encryption in transit
- Data-location and supplier-dependency risks when organizations lack visibility or contractual control over where and how communication data is processed
- Weak access controls that let unauthorized participants into calls or file repositories
- Absent or insufficient audit trails that can significantly hinder incident investigation and reduce the evidence available for NIS2 reporting
- Uncontrolled third-party integrations that quietly expand the attack surface
NIS2 requires organizations to address supply-chain security, including security-related aspects of relationships with direct suppliers and service providers. A cloud provider incident can therefore affect the organization’s own risk and reporting obligations.
Deploying on your own infrastructure can reduce dependency on vendor-operated cloud infrastructure, while software supply-chain, support, update, and integration risks still require assessment.
Insight 2. Self-hosting changes the dependency model rather than removing risk.
A vendor-operated cloud shifts more infrastructure responsibility to the provider but creates greater reliance on an external service. Self-hosting reduces that infrastructure dependency while increasing the organization’s responsibility for patching, monitoring, backup, recovery, configuration, and capacity planning.
Security Risks Broken Down by Communication Channel
Video Conferencing
|
Risk |
What It Means in Practice? |
|---|---|
|
Unauthorized meeting access |
Weak guest controls, exposed meeting links, or insufficient authentication can allow unauthorized participants into live sessions |
|
Inadequately protected media or signaling |
Weak or misconfigured transport protection can expose meeting traffic or control data to interception or manipulation |
|
Uncontrolled recording access |
Recordings can contain sensitive discussions and require defined access, retention, and deletion controls |
|
Insufficient meeting and admin audit trails |
Limited visibility into joins, authentication events, configuration changes, and administrative actions can hinder incident investigation |
|
Third-party cloud and integration dependencies |
External hosting, identity, recording, transcription, or integration services add supplier dependencies that should be included in the organization’s risk assessment |
Messaging
|
Risk |
What It Means in Practice? |
|---|---|
|
Plaintext storage |
Messages stored without appropriate protection at rest can be exposed in a breach scenario |
|
No transit encryption |
Weak or absent transport encryption can expose messages to interception, while provider access depends on the platform’s encryption architecture and key-management model |
|
Uncontrolled retention |
Without configurable policies, sensitive conversations can accumulate without clear retention limits |
|
Missing audit logs |
Limited audit logging can make incident reconstruction significantly more difficult and reduce the evidence available for regulatory reporting |
File Sharing
|
Risk |
What It Means in Practice? |
|---|---|
|
Uncontrolled external sharing |
Consumer-grade or unmanaged file tools can bypass corporate security policies |
|
Missing access controls |
Files without role-based permissions create broad, unnecessary data exposure |
|
No integrity verification |
Without appropriate versioning or audit controls, spotting unauthorized modifications can become difficult |
|
Insecure sync integrations |
Tools that connect to personal or unmanaged cloud storage can create persistent data-leakage risks |
How Communication Functions Map to NIS2 Risk Areas
|
Communication Function |
Primary Risk Area |
What to Assess |
|---|---|---|
|
Access control, cryptography, incident handling |
Authentication, guest access, meeting permissions, recordings, transport protection, audit information |
|
|
Persistent messaging |
Data protection, access control, retention |
Storage, administrator access, retention rules, message permissions, auditability |
|
Information protection and supply-chain risk |
Storage, sharing permissions, external services, retention, access control |
|
|
Access control and asset management |
Provisioning, deprovisioning, directory synchronization, MFA, privileged access |
|
|
Administration |
Secure maintenance, governance, incident investigation |
Administrator roles, configuration history, updates, logs, change control |
|
Supply-chain security |
Identity, storage, streaming, notifications, federation, APIs, and connected applications |
Insight 3. Communication platforms can be both an affected system and an incident-response tool.
A cloud outage, identity-provider failure, compromised collaboration account, or network isolation event can remove the same communication channel the organization expected to use for crisis coordination. Business continuity planning should therefore include an alternative communication path.
NIS2 Incident Reporting Timeline
For significant incidents, NIS2 establishes a staged reporting process. The communication platform may provide logs and evidence needed for these reports, but the reporting obligation belongs to the affected organization.
|
Stage |
General Timing |
Purpose |
|---|---|---|
|
Early warning |
Without undue delay and within 24 hours of becoming aware of a significant incident |
Signals the incident and, where applicable, whether malicious activity or cross-border impact is suspected |
|
Incident notification |
Without undue delay and within 72 hours of awareness |
Provides an initial assessment of severity, impact, and available indicators of compromise |
|
Intermediate report |
When requested by the competent authority or CSIRT |
Provides relevant status updates during investigation or response |
|
Final report |
No later than one month after the incident notification |
Describes the incident, impact, likely cause, mitigation measures, and relevant cross-border effects |
|
Ongoing incident |
Progress report at the one-month point, followed by a final report within one month after the incident is handled |
Keeps authorities informed when investigation or remediation is still ongoing |
These are the Directive-level reporting stages for significant incidents. Organizations should also account for national implementation, sector-specific requirements, and any additional instructions from their competent authority or CSIRT.
How to Assess NIS2 Compliance for a Communication Platform?
- Confirm scope and national rules. Determine whether the organization is in scope and which Member State transposition and sector-specific requirements apply.
- Map communication systems and data flows. Identify platforms, integrations, external dependencies, administrators, stored data, and critical workflows.
- Assess Article 21 risk-management measures. Review access control, cryptography, incident handling, supply-chain security, business continuity, secure maintenance, and effectiveness testing.
- Close configuration and architectural gaps. Separate issues that can be fixed through settings or policy from gaps that require new infrastructure or a platform change.
- Document evidence. Maintain policies, risk assessments, logs, approvals, supplier reviews, incident procedures, and test results that demonstrate how controls operate in practice.
- Monitor and review. Reassess controls after incidents, major platform changes, significant vulnerabilities, regulatory updates, and other material changes in risk.
Cloud vs. Self-Hosted Communication Platforms
|
Assessment Area |
Vendor-Operated Cloud |
|
|---|---|---|
|
Infrastructure |
Operated primarily by the provider |
Operated or directly controlled by the organization |
|
Data-location control |
Depends on provider architecture and contractual options |
Can be defined through the organization’s own infrastructure design |
|
Operational responsibility |
More infrastructure responsibility stays with the provider |
More responsibility moves to internal IT and security teams |
|
Supplier dependency |
Hosting, software, operations, and support may depend on the external service |
Hosting dependency can be reduced, while software, support, updates, and integrations remain relevant |
|
Incident visibility |
Depends partly on provider logs and cooperation |
Can provide direct access to locally operated infrastructure and platform logs |
|
Business continuity |
Depends partly on provider resilience and external connectivity |
Can be designed around internal redundancy and recovery architecture |
How TrueConf Server Supports NIS2 Risk-Management Measures?
TrueConf Server is a self-hosted unified communications platform that organizations deploy on their own infrastructure, whether that’s on-site servers, a private cloud environment, or a fully air-gapped network. The organization controls the deployment environment, security configuration, data flows, and integration choices, which can make the communications layer easier to align with internal security and compliance policies.
TrueConf Server does not by itself make an organization NIS2 compliant. Its role is to provide technical capabilities that can support relevant risk-management measures when those capabilities are configured, governed, monitored, and documented as part of the organization’s wider cybersecurity program.
Best for: organizations that need self-hosted communications, local control over infrastructure and data flows, centralized identity integration, isolated-network operation, or tighter alignment with internal security architecture.
Strengths: self-hosted deployment, centralized identity integration, access controls, encryption mechanisms, reports and logs, browser-based guest access, isolated deployment, and organization-controlled maintenance.
Limitations: self-hosting increases internal responsibility for operating-system security, network architecture, patching, backup, monitoring, disaster recovery, administrator security, and capacity planning. Software supply-chain and integration risks still require assessment.
Data Sovereignty
In an on-premises or isolated deployment, video conferences, chats, files, and recordings can remain within the organization’s own infrastructure. External integrations, federation, streaming, SMTP, and push-notification flows should still be reviewed because they can introduce additional data paths and dependencies.
Encryption
TrueConf Server protects communications traffic with encryption mechanisms built into its architecture:
These protections are part of the platform’s communications architecture. For stored recordings, chat files, and other data at rest, organizations should also apply appropriate infrastructure-level controls, such as disk or partition encryption, retention policies, and access restrictions.
Access Control and Multi-Factor Authentication
- Integration with Active Directory and LDAP for centralized enterprise identity management
- Role-based access controls applied consistently across platform functions
- MFA support that organizations can apply according to their risk assessment and access-control policy
- Administrator-defined permissions governing who can schedule meetings, access recordings, share files, and manage the system
Centralized identity management also helps organizations align communication access with account provisioning, role changes, privileged access, and account removal procedures.
Audit Logging
TrueConf Server provides reports and logs covering user connections, calls, messages, conference recordings, server events, and settings-change history:
- Ongoing internal security monitoring
- Supporting incident investigation and evidence collection for NIS2 reporting workflows
- Providing the evidentiary record needed for post-incident forensic reconstruction
Logging does not replace incident-management procedures. Organizations still need processes for identifying significant incidents, escalation, evidence handling, regulatory reporting decisions, and notification within applicable timelines.
Isolated and Air-Gapped Deployment
TrueConf Server can operate in completely isolated environments with zero internet connectivity. For organizations in defense, critical infrastructure, government, and other high-assurance environments, this capability can support architectures that require strict network segregation.
Isolation does not eliminate the need for cybersecurity controls. Administrator access, patching procedures, software updates, removable media, internal segmentation, backups, and monitoring still need to be governed.
Insight 4. Isolation reduces some attack paths but increases the importance of internal operational controls.
An air-gapped network removes certain external dependencies, but security still depends on controlled updates, administrator accountability, segmentation, monitoring, backup protection, and physical access. Isolation is an architectural measure, not a substitute for cybersecurity governance.
Secure External Collaboration
Guests and external participants can join TrueConf meetings through a browser-based WebRTC client, without installing a dedicated conferencing application or creating accounts on external conferencing platforms. Access is controlled through:
- Guest permissions
- Conference-level access restrictions
- Registration and approval settings
- Administrator-defined policies for external users
External participants can join without requiring accounts on a third-party conferencing service; identity and access architecture remains under the organization’s chosen configuration.
Business Continuity
TrueConf Server can support business continuity planning by giving organizations control over the deployment environment and operational procedures:
- Backup and restore of server settings
- Real-time and historical server monitoring
- Organization-controlled maintenance windows
- Disaster recovery planning based on the organization’s own infrastructure architecture
Organizations should also plan for the possibility that their primary communication platform itself becomes unavailable. If one system is used for both everyday collaboration and incident coordination, an alternative channel should be defined and tested.
Boost your team’s productivity with TrueConf Server Free!
NIS2 Risk-Management Measure Mapping
|
NIS2 Requirement |
TrueConf Server Capability |
Organization’s Responsibility |
|---|---|---|
|
Cryptography and encryption |
TLS-based protection for signaling/control data, AES-256 for TrueConf media traffic, DTLS/SRTP for WebRTC, and H.235 for H.323 scenarios |
Define cryptography policy, verify configuration, secure stored data, and manage supporting infrastructure |
|
Access control and MFA |
AD/LDAP integration, group-based permissions, role-based administration, and MFA support depending on configuration |
Define account lifecycle, MFA scope, privileged-access policy, and review procedures |
|
Incident handling and audit |
Reports and logs for connections, calls, messages, recordings, server events, and settings-change history |
Operate incident classification, escalation, response, evidence retention, and reporting procedures |
|
Supply-chain security |
On-premises or isolated deployment can reduce third-party cloud processing |
Assess software supply chain, updates, support, integrations, identity services, and other suppliers |
|
Business continuity |
Backup and restore, monitoring, organization-controlled maintenance, and infrastructure-level disaster recovery planning |
Define recovery objectives, redundancy, fallback communications, testing, and crisis procedures |
|
Data protection |
Communications data can remain within the organization’s infrastructure in properly configured on-premises or isolated deployments |
Define retention, backup, access, deletion, and infrastructure-protection policies |
|
Secure communications policy |
Security settings, access rules, authentication options, and user permissions can be configured and enforced at platform level |
Define approved communication channels, operating procedures, monitoring, and review |
Insight 5. A product feature is not automatically an operational security control.
Encryption, MFA, logging, and role-based access only contribute to NIS2 risk management when they are configured correctly, governed by policy, monitored, reviewed, and tested. Procurement should therefore evaluate not only whether a feature exists, but how it will be operated after deployment.
Communication Platform Checklist for NIS2
- Where are meetings, chats, files, recordings, logs, and backups processed and stored?
- Which hosting, identity, notification, storage, federation, transcription, and integration dependencies exist?
- Can user accounts be centrally provisioned, changed, revoked, and reviewed?
- Can MFA be applied according to the organization’s risk assessment?
- Are communication traffic and administrative access appropriately protected?
- Are sufficient logs available for incident investigation and evidence collection?
- Can guest access, recordings, external sharing, and user permissions be governed centrally?
- How does the platform behave during network, identity, infrastructure, or provider failures?
- Is there an alternative communication channel if the primary platform is unavailable?
- How are vulnerabilities, updates, support relationships, and third-party integrations assessed?
Conclusion
NIS2 does not prescribe one communication platform or one deployment architecture. It requires organizations to manage cybersecurity risks through technical measures, governance, incident handling, supply-chain security, business continuity, secure maintenance, access control, training, monitoring, and documented processes.
Communication systems matter because they can carry sensitive organizational information, support critical workflows, introduce third-party dependencies, and become part of incident-response procedures.
TrueConf Server can support organizations that prefer self-hosted communication infrastructure and direct administrative control. Its capabilities can contribute to relevant NIS2 risk-management measures, but overall compliance remains dependent on how the organization assesses risk, configures the platform, governs access, operates its infrastructure, documents controls, and meets applicable national requirements.
Empower your video conferencing experience with TrueConf!
FAQ
Does TrueConf Server guarantee NIS2 compliance?
No single product can guarantee NIS2 compliance. Compliance depends on how an organization implements, configures, and operates its systems alongside broader policies, governance, risk management, and national requirements. TrueConf Server provides technical controls that can support relevant measures at the communications layer.
Is TrueConf Server appropriate for NIS2 essential entities?
TrueConf Server can be evaluated by essential entities as part of a broader NIS2 compliance program. Its self-hosted deployment model, encryption, MFA support, role-based access controls, audit logging, and isolated deployment options can support relevant technical measures when configured according to the organization’s risk assessment.
Does NIS2 require self-hosted communication platforms?
No. NIS2 does not require every organization to use a self-hosted communication platform. TrueConf Server becomes relevant when an organization decides that customer-controlled infrastructure, local data handling, or isolated-network operation better fits its own risk-management strategy.
Does TrueConf Server work with existing security infrastructure?
TrueConf Server integrates with enterprise identity systems through LDAP and Active Directory and can operate behind existing firewalls and network-security controls. Its logs and reports can also support monitoring and investigation workflows depending on how TrueConf is integrated into the organization’s security architecture.
How does TrueConf Server support NIS2 incident reporting?
TrueConf Server provides reports and logs covering connections, calls, messages, recordings, server events, and settings changes, which can help security teams investigate communications-layer activity. TrueConf does not replace the organization’s incident-reporting process, which must handle classification, escalation, evidence, notification, and regulatory deadlines.
Can TrueConf Server reduce NIS2 supply-chain risk?
A self-hosted TrueConf Server deployment can reduce dependency on vendor-operated communication cloud infrastructure and give the organization greater control over where communication data is processed. TrueConf does not eliminate software supply-chain, support, update, identity, or integration risks, which still need to be assessed.
How should organizations evaluate TrueConf Server for NIS2 requirements?
Organizations should map how TrueConf Server would be used, what information it would process, who would administer it, and which integrations or dependencies would remain. The proposed TrueConf deployment can then be assessed against Article 21 measures, business-continuity requirements, incident procedures, supplier risk, and applicable national NIS2 rules.
About the Author
Diana Shtapova is a product specialist and technology writer with three years of experience in the unified communications industry. At TrueConf, she leverages her deep product expertise to create clear and practical content on video conferencing platforms, collaboration tools, and enterprise communication solutions. With a strong background in product research and user-focused content development, Diana helps professionals and businesses understand core product features, adopt new technologies, and unlock the full potential of modern collaboration software.
Follow us on social networks