Back to Terminology

Key NIS2 Requirements for Secure Business Communications

NIS2 did not arrive as a routine policy update. It restructured who is responsible for cybersecurity failures, what counts as adequate protection, and what happens when organizations fall short. Communication platforms, long treated as productivity tools sitting outside the security perimeter, are now firmly inside it. Video conferencing systems, corporate messengers, email infrastructure, unified communications environments: each of these carries the same compliance weight as any other critical system in scope.

This guide covers what NIS2 actually demands, how those demands translate into specific obligations for communication infrastructure, and where most organizations currently have gaps worth closing.

Why Communication Platforms Fall Under NIS2 Risk Management?

Reading NIS2 as a directive about firewalls and data centers is a mistake that compliance teams are making less often, but still making. The directive governs any digital system whose disruption or compromise would materially affect an organization’s ability to operate. By that measure, communication platforms are not peripheral. They are central.

Think about what actually travels through a corporate communication stack on a normal working day. Negotiations happen over messaging. Strategic decisions get made on video calls. Client data moves through email threads. Operational instructions flow across team channels. None of this is incidental to how organizations function — it is how organizations function. A breach or sustained outage affecting these channels does not create a communication problem. It creates an operational crisis that spreads into client relationships, regulatory standing, and financial performance before most incident response teams have finished their first call.

NIS2 is built around this understanding. The directive requires that every digital system essential to operational continuity be incorporated into an organization’s risk management framework. For covered entities, that pulls the following into scope:

Corporate messaging platforms — including Microsoft Teams, self-hosted solutions, and on-premise deployments
Email infrastructure — cloud-hosted and internally managed
Video conferencing systems — including those running on private networks or dedicated hardware
VoIP and telephony infrastructure
Unified communications environments that bring voice, video, messaging, and collaboration into a single platform

Once an organization qualifies as an essential or important entity, and the directive’s sector and size coverage is broader than many initially expect, the entire communication stack comes into scope. There is no exception for tools that feel less technical than network equipment. If it carries business-critical communications, it carries compliance obligations.

Risk Management and Security Measures

NIS2 Article 21 sets out the technical and organizational measures covered entities must implement. These are not recommendations to work toward, they are the minimum standard regulators will measure organizations against. For communication platforms, each measure translates into something concrete and auditable.

Encryption

Both transit and at-rest encryption are required, and the regulatory direction of travel is clear: end-to-end encryption is becoming the expected baseline for sensitive business communications, not a feature reserved for classified environments. The question auditors will ask is not whether a platform supports encryption somewhere in its configuration. It is whether encryption is enforced by default, applied uniformly across all communication types, and verifiable through your own systems rather than a vendor’s assurances.

For organizations running their own communication infrastructure, encryption key management is a separate and important consideration. When key management sits entirely with a third-party vendor, independent verification of your encryption posture becomes difficult, and that difficulty will be visible to regulators and auditors evaluating your compliance.

Access Controls

Compromised credentials are consistently among the most common entry points into corporate systems, and communication platforms are a frequent target precisely because access to them often carries access to sensitive conversations and data. NIS2 requires a systematic response:

Multi-factor authentication applied to every user account, without carve-outs for senior staff or legacy systems
Role-based access controls built around current operational reality, not the accumulated permission state that results from years of provisioning without corresponding deprovisioning
Regular, documented access reviews with particular attention to accounts held by former employees, contractors, or partners whose engagement with your organization has ended or changed

The practical test is whether your organization can demonstrate, at any given moment, that every account with access to your communication systems belongs to someone with a current and legitimate need for that access at the level they hold.

Data Minimization and Retention

Holding communication data indefinitely creates two compounding problems. Operationally, every historical archive represents an expanded attack surface — more data to exfiltrate, more exposure in the event of a breach. From a compliance perspective, unmanaged retention generates GDPR exposure that sits alongside and intersects with NIS2 obligations.

Retention policies need to be technically enforced, not documented intentions. The gap between a policy that says data is deleted after a defined period and a system that retains everything indefinitely is the kind of discrepancy that creates significant regulatory exposure when scrutinized. Define periods, implement technical enforcement, and verify that deletion processes actually purge data rather than removing it from visible interfaces while leaving it in underlying storage.

Vulnerability Management

Every unpatched vulnerability in a communication platform is an open door that organizations leave available to adversaries through inaction. NIS2 requires a structured approach: an accurate inventory of all communication tools in use, active tracking of vendor patch releases against that inventory, and update processes that operate on timelines tied to vulnerability severity rather than administrative scheduling convenience.

Vendors who are slow to release patches, who lack a responsible disclosure program, or who fail to communicate vulnerabilities to customers in a timely way represent a supply chain risk that reflects directly on your own compliance posture, an issue addressed in detail in the supply chain section below.

Network Security

Communication platforms require integration into your broader network security architecture. Treating them as standalone applications with their own security perimeter creates gaps that adversaries will find. The integration should include:

Network segmentation that contains the potential spread of a breach originating in or through a communication system
Traffic monitoring capable of identifying anomalies, unexpected data volumes, unusual external connections, access patterns inconsistent with normal operational behavior
Remote access secured through zero-trust architecture or VPN, applied consistently without exceptions made for convenience or seniority

Business Continuity

Communication infrastructure qualifies as critical for most covered entities, which means NIS2’s continuity requirements apply directly. The question your organization needs to answer — in writing, with evidence of having tested the answer — is what happens when your primary communication system fails. How do teams coordinate? How long does recovery take? What is the fallback while recovery proceeds?

Redundancy and failover capabilities are not optional enhancements to pursue when resources allow. They are part of the baseline. A continuity plan that exists as a document but has never been exercised provides limited assurance. Testing is the mechanism through which plans become reliable.

Incident Reporting and Monitoring

The incident reporting requirements in NIS2 impose operational pressure that most organizations underestimate until they try to meet the timelines in practice.

Reporting Timeline

Timeframe	Required Action
Within 24 hours	Early warning submitted to the relevant national authority
Within 72 hours	Incident notification with initial severity assessment, estimated impact, and probable cause
Within one month	Final report with complete incident description, confirmed root cause, and remediation measures taken

Communication platform incidents that trigger these obligations include unauthorized access to corporate messaging systems, large-scale data exfiltration from email archives, ransomware disabling unified communications infrastructure, or attacks that materially prevent an organization from coordinating its operations.

Building the Capability Before It Is Needed

The 24-hour early warning deadline cannot be met through improvisation after the fact. Detection, internal escalation, preliminary assessment, and regulatory notification all have to happen within that window — which is only possible if the detection infrastructure was already in place and functioning before the incident began.

For communication platforms, the necessary foundations are:

Centralized logging that captures access events, authentication activity, configuration changes, and administrative actions across every communication system in scope
Real-time alerting set up to surface specific anomalous behaviors: bulk message history exports, authentication from unexpected geographic locations, sudden shifts in data transfer patterns
Escalation procedures with defined paths from detection to the decision-makers authorized to assess severity and initiate regulatory notification
SIEM integration that incorporates communication platform events into your organization’s broader security monitoring picture

These capabilities should be tested through exercises that include realistic communication platform failure scenarios. The objective is to find gaps in detection coverage or escalation procedures while the stakes are low enough to fix them.

Monitoring as a Continuous Obligation

NIS2 treats security monitoring as an ongoing operational requirement, not a box to check at defined intervals. Communication infrastructure should be under continuous monitoring. Formal audits and penetration testing add structured checkpoints, but they are supplements to continuous visibility, not replacements for it.

Management Accountability

The governance shift embedded in NIS2 has not yet fully registered in many organizations. The directive does not allow leadership to treat cybersecurity as a technical matter that IT handles while executives focus on business outcomes. Accountability is placed explicitly at the management level, with consequences that extend to individuals.

What the Directive Requires?

Governing bodies — boards, executive leadership, or equivalent structures — must formally approve cybersecurity risk management measures, actively oversee their implementation, and complete training that delivers genuine understanding of cybersecurity risks. Superficial familiarity is not sufficient. The oversight obligation is substantive.

The accountability provision is direct: individual management body members can be held personally liable for negligent failures to implement required security measures. Member states are required to equip their national authorities to enforce this. Personal liability for cybersecurity governance failures is not a theoretical risk inserted into the directive’s text, it is an enforcement mechanism that regulators are expected to use.

What This Means for Communication Platforms Specifically?

Every decision about which communication tools an organization deploys, and what security standards govern their use, now carries management-level accountability. Choosing a consumer-grade messaging application for sensitive business communications because it is cheaper or more familiar than a secure alternative is a governance decision. If a breach follows, that decision, and the risk assessment (or absence of one) behind it, will be part of what regulators examine.

Organizations need governance structures that treat communication platform selection, configuration standards, and periodic security review as decisions requiring formal risk assessment and documented approval at the appropriate level. Security teams need genuine escalation paths to leadership for concerns about communication infrastructure, not paths that end in delegation back to the team that raised the concern.

Supply Chain Security

Supply chain security is treated in NIS2 as a primary obligation, not an afterthought. For organizations using third-party communication platforms, the implications are direct.

When your organization deploys a cloud-based communication platform, the vendor’s infrastructure decisions, security practices, and operational choices become part of your risk profile. A vulnerability in their systems or a failure in their access controls does not stay within their perimeter. It reaches into yours. The incident reporting obligations, regulatory accountability, and reputational damage that follow land with your organization, regardless of where the failure originated.

Vendor Due Diligence

NIS2 requires covered entities to assess the cybersecurity practices of their suppliers. For communication platforms, a credible assessment addresses:

Security certifications: ISO 27001, SOC 2 Type II, or equivalent. Are they current? Are they independently audited? Do they cover the specific infrastructure and services your organization relies on?
Encryption practices: What standards does the vendor implement? Is end-to-end encryption enforced by default, or is it an option users must activate?
Data residency: Where is data stored and processed? Can the vendor provide contractual guarantees of EU data residency where your regulatory or operational context requires it?
Incident notification: What are the vendor’s contractual obligations to notify customers of security incidents? What does their track record look like in practice?
Subprocessor chain: Who else handles your data, and under what security requirements?
Patch and disclosure practices: Does the vendor operate a responsible disclosure program? How quickly do they patch disclosed vulnerabilities, and how do they communicate vulnerability information to customers?

The Case for Infrastructure Ownership

A structural alternative to managing third-party supply chain risk is deploying communication infrastructure within your own environment. On-premise or privately hosted video conferencing and unified communications platforms give organizations direct control over where data resides, how encryption is configured, how access is managed, and what is logged, independent of a vendor’s operational decisions.

This does not eliminate supply chain considerations entirely. The software still originates with vendors and requires its own diligence. But it removes the dependency on a third party’s security posture for core communication capabilities and gives organizations substantially more control over the elements of NIS2 compliance that regulators will examine most closely.

Contractual Requirements

Vendor contracts should be built around security requirements, not just commercial terms. For communication platform vendors, effective contracts include:

Defined minimum security requirements with criteria that can be verified
Breach notification obligations with specific timeframes aligned to your own NIS2 reporting deadlines
Rights to audit or request compliance evidence on a defined schedule or following a material incident
Defined consequences for security failures that materially affect your organization

Contractual protections do not transfer NIS2 obligations to vendors. Your organization remains accountable to regulators regardless of what contracts say. But strong contracts create enforceable accountability within vendor relationships and produce the documented evidence of due diligence that regulators will look for.

Ongoing Vendor Oversight

Vendor security postures are not static. Organizations should maintain ongoing awareness of developments affecting vendors whose platforms they rely on — disclosed vulnerabilities, reported incidents, regulatory actions, changes in ownership or infrastructure. When a vendor’s posture deteriorates in ways that affect your risk profile, there should be a defined process for responding, not an improvised reaction after the fact.

NIS2 Security Checklist for Communication Platforms

The following checklist covers the core NIS2 obligations for communication infrastructure. Treat it as a structured starting point for gap assessment, not a substitute for a formal compliance review with appropriate legal and technical expertise.

Encryption

Communications in transit are encrypted using TLS 1.2 or higher
Data at rest is encrypted with AES-256 or equivalent
End-to-end encryption is enforced for sensitive communications
Encryption configuration is verified at the platform level, not assumed from vendor defaults

Access Management

MFA is enforced for all users without exception
Role-based access controls reflect current operational roles and are formally documented
Access rights are reviewed at least quarterly
Offboarding procedures include immediate revocation across all communication systems
Administrative access is restricted and logged separately

Monitoring and Logging

Centralized logging covers access events, authentication activity, and administrative changes
Log retention meets a minimum of 12 months
Real-time alerts are configured for defined anomalous behaviors
Communication platform logs feed into your SIEM
Log integrity is protected against modification or deletion

Incident Response

Your incident response plan explicitly addresses communication platform scenarios
Escalation procedures for communication incidents are documented and tested
NIS2 reporting timelines — 24 hours, 72 hours, one month — are incorporated into response playbooks
Incident exercises have included scenarios affecting communication infrastructure

Vendor and Supply Chain

All communication platform vendors have been assessed against defined security criteria
Vendor certifications are current and independently audited
Contracts include enforceable security requirements and breach notification obligations with specific timeframes
Data residency requirements are contractually confirmed
Vendor security posture is reviewed at least annually

Governance

Management has formally approved security measures applied to communication platforms
Accountability for communication platform security is assigned to named roles
A formal evaluation process governs the adoption of new communication tools
Security requirements are documented, consistent, and enforced across all platforms in use

Resilience

Redundancy and failover capabilities are in place for critical communication systems
Business continuity plans address communication outages with specific procedures and owners
Recovery objectives are defined and have been validated through testing

Empower your video conferencing experience with TrueConf!

Learn more

FAQ

Which organizations fall within NIS2 scope?

Applicability under NIS2 comes down to two concrete factors: the sector your organization operates in, and its size. The directive draws a structural line between two categories of covered entities:

Essential entities are drawn from sectors such as energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, and space.

Important entities encompass postal and courier services, waste management, chemicals, food production and distribution, manufacturing, digital providers, and research organizations.

Sector classification alone does not determine scope — size thresholds apply in parallel. The baseline criteria are 50 or more employees, or annual turnover exceeding 10 million euros. That baseline is not absolute: national competent authorities retain discretion to bring smaller organizations into scope where those organizations are considered individually critical to essential service delivery, irrespective of headcount or revenue figures.

One structural complexity deserves explicit attention. NIS2 is a directive, not a directly applicable regulation. Every EU member state has enacted its own transposing legislation, and the resulting obligations and enforcement frameworks differ across jurisdictions in ways the directive text itself does not capture. Organizations with genuine uncertainty about their scope status should obtain legal advice from counsel experienced in the specific member state involved; a general reading of the directive is an unreliable substitute.

Do NIS2 obligations apply to cloud-hosted communication tools?

Yes, categorically. The physical location of vendor infrastructure is irrelevant to where compliance responsibility sits. That responsibility belongs to your organization and extends across every communication tool in active operational use, regardless of how or where it is hosted.

In practice, this shapes what vendor due diligence must actually involve. Reviewing a vendor’s security marketing page or verifying a certification is not sufficient. Due diligence needs to reach the underlying controls, what is actually protecting your data and your users, not what the vendor claims in general terms. Where the vendor’s controls fall short of what NIS2 demands, your organization carries the obligation to address that shortfall, whether through compensating controls, additional configuration, or replacing the vendor.

Contractual arrangements with platform vendors require the same scrutiny. Standard commercial terms do not satisfy NIS2’s requirements. Security obligations, breach notification timelines, and audit rights need to be explicitly stated in the contract, not inferred from vendor marketing or assumed on the basis of existing certifications.

What qualifies as a significant incident requiring notification?

NIS2 defines the threshold by reference to incidents that cause, or that have the realistic potential to cause, severe operational disruption, substantial financial loss, or material harm to other parties. Actual damage does not need to have occurred. Credible potential for serious impact is sufficient to trigger notification obligations.

For communication platforms specifically, incidents that typically meet this threshold include unauthorized access to corporate messaging systems, large-scale data exfiltration from email infrastructure, ransomware attacks rendering unified communications inoperable, and prolonged outages that materially impair an organization’s ability to coordinate its operations.

The practical difficulty is time. The notification clock starts running from the moment your organization becomes aware of a potentially significant incident, and the first reporting deadline falls 24 hours after that point. Determining whether a given incident crosses the threshold cannot be improvised within that window. It requires documented internal criteria, established in advance, so that the classification process follows a defined procedure rather than being reconstructed under operational pressure when it matters most.

What are the financial consequences of non-compliance?

Penalties are calibrated to entity classification. Essential entities are exposed to fines reaching 10 million euros or 2% of total global annual turnover, whichever of the two figures is higher. Important entities face a ceiling of 7 million euros or 1.4% of global annual turnover, again applying the higher of the two.

The financial exposure is compounded by a personal liability mechanism. NIS2 empowers national authorities to impose temporary bans prohibiting specific named individuals from holding management positions. This is not a theoretical provision, it is an integral part of the directive’s accountability architecture, and regulators are expected to deploy it in cases of serious or repeated non-compliance.

Framed against those figures, the cost of properly securing communication infrastructure occupies a different order of magnitude. The more productive analytical question for most organizations is not whether compliance carries a cost, it does, but whether the full cost of non-compliance has been realistically assessed. That calculation should factor in financial penalties, personal management liability, reputational damage, and the operational consequences of a breach, and weigh that total honestly against the investment required to build security from the outset.

How should organizations manage communication tools accessed on personal devices?

Written policy does not produce technical enforcement. A documented requirement for employees to apply security practices on personal devices does not activate MFA, does not enforce encryption, and does not enable remote data removal if a device is lost or compromised. NIS2 requires technical controls, and in BYOD environments, those controls must be implemented at the application layer, not simply described in a policy document.

Three technical components define a defensible approach. First, authentication enforcement must operate at the account level, independent of device type: MFA cannot be waived for personal devices. Second, application-level security policies should be enforced through mobile application management solutions, which govern how specific applications operate on a device without requiring full device enrollment or management. Third, remote data removal must be both configured and operationally tested: the capacity to wipe corporate data from a lost or compromised device cannot be contingent on the employee’s cooperation or availability at that moment.

Where communications regularly carry sensitive, regulated, or confidential content, limiting access to organizationally managed devices is the stronger compliance position. That restriction introduces friction. Friction is manageable. A breach traceable to an unmanaged personal device carrying confidential business communications is considerably harder to defend before a regulator.

How frequently should communication platform security be reviewed?

Annual review is the minimum acceptable cadence, not a sufficient one in isolation. It provides structural regularity, but communication technology evolves faster than yearly cycles, and the threat environment does not observe scheduled intervals.

Specific events should trigger additional reviews independently of the calendar. A significant platform update or a publicly disclosed vulnerability affecting tools your organization relies on warrants immediate targeted assessment. Internal changes, restructuring, acquisitions, shifts in access privileges or working patterns, alter the underlying risk profile and may invalidate previously adequate controls. Updated guidance from national authorities or ENISA can redefine what compliant implementation looks like. Significant developments in the threat landscape targeting communication infrastructure specifically should prompt a focused reassessment of current defenses.

The operational model NIS2 implies is one of continuous monitoring as the baseline state, with formal periodic assessments functioning as structured points for deeper analysis. Scheduled reviews contribute to that picture, they do not substitute for ongoing visibility into what is actually happening across your communication environment.

What should an organization do when its current platform does not meet NIS2 requirements?

The necessary starting point is precision. A gap assessment that concludes a platform “needs improvement” is analytically useless. A gap assessment that establishes, for example, that log retention is configured to 30 days rather than the required 12 months, that MFA enforcement excludes a defined user population, or that the vendor’s incident notification SLA is incompatible with the 24-hour early warning deadline, that level of specificity produces something an organization can actually act on.

The appropriate response to each gap depends on its nature. Configuration gaps, features that exist within the platform but are disabled by default, retention settings that need adjustment, access controls that need tightening, can frequently be resolved without significant resource expenditure. Architectural gaps, where the platform structurally lacks capabilities necessary for compliance, point toward migration. Migration decisions carry more organizational weight and longer timelines, which makes early identification of architectural deficiencies correspondingly more valuable.

Where remediation extends over a period of time, formal documentation of identified gaps and the concrete steps being taken to close them serves a genuine compliance function. Regulators weigh demonstrated good-faith effort when determining enforcement responses. An organization that has identified a specific gap, documented it formally, and is executing a structured remediation plan occupies a materially different regulatory position from one that has made no engagement with the problem.

Sequencing remediation priorities should involve legal and compliance counsel. The relative severity of individual gaps, realistic closure timelines, and the enforcement posture of the relevant national authority all bear on how remediation should be ordered and resourced.

Does deploying communication infrastructure on-premise simplify NIS2 compliance?

For a defined subset of obligations, yes, and that simplification is substantive enough to warrant clear articulation.

On-premise or privately hosted infrastructure gives your organization direct, unmediated control over the variables NIS2 examines most closely: where data resides and is processed, how encryption is configured and who controls the keys, how access is administered and recorded, and what audit evidence can be independently produced. When regulators or auditors request compliance evidence, organizations running their own infrastructure can respond from their own systems (configuration records, access logs, encryption specifications) without relying on vendor-generated attestations, third-party audit summaries, or certifications whose scope may not map cleanly onto the services being used.

The reduction in external dependency carries weight for supply chain security obligations as well. A substantial portion of NIS2’s supply chain requirements exist because organizations using third-party infrastructure cannot fully determine or control a vendor’s security posture. Bringing communication infrastructure in-house removes that dependency at the core capability level.

The countervailing considerations deserve equal clarity. On-premise deployment transfers direct responsibility for infrastructure security, patch management, physical security, and operational resilience to your internal team. These are not minor obligations, cloud providers absorb them on their customers’ behalf, and organizations that move to on-premise take them on in full. The compliance burden does not decrease; it relocates. Managing it competently requires demonstrated operational capability, appropriate staffing levels, and sustained investment in maintaining the infrastructure, not merely the initial decision to deploy it.