Cyber Threat Notification: When and How to Warn Service Recipients

Who should read this: Communications teams, legal officers, incident response managers, customer service leaders, compliance teams, regulated entities.

The duty to warn is a fundamental principle of modern cybersecurity. When an organisation detects a significant cyber threat targeting its customers or users, that organisation has a moral and increasingly legal obligation to communicate the threat and protective measures. The NIS2 Directive codifies this principle in Article 23(2), which requires that “essential and important entities communicate, without undue delay, to the recipients of their services that are potentially affected by a significant cyber threat any measures or remedies that those recipients are able to take in response to that threat. Where appropriate, the entities shall also inform those recipients of the significant cyber threat itself.”

This obligation is straightforward in principle but complex in practice. When exactly must an entity notify? What constitutes a “significant” threat? How much detail should the warning contain? Who should send it: the compliance team, the communications team, or the technical team? How should the organisation balance transparency with avoiding panic or misinformation? This post unpacks Article 23(2) and explains how essential and important entities should approach cyber threat notification.

The Directive’s approach to threat notification differs from incident notification. An incident is an actual security event that has already occurred and caused or could cause harm. A threat is a potential attack or adversarial activity that has not yet materialised into an incident, or has materialised for one entity but creates risk for others. For example, if a telecommunications provider discovers that an adversary is scanning the network looking for vulnerabilities, that is a threat, not yet an incident. If the scanning leads to a breach, then it becomes an incident. The provider must warn service recipients of both the threat and the incident, but the timing, content and delivery method differ.

Significant Cyber Threats Under Article 23(2)

The Directive does not define “significant cyber threat” with mathematical precision. Instead, it establishes principles. A threat is significant if it is “likely to adversely affect the provision of those services” or if it creates risk to service recipients. This is intentionally flexible because threats vary enormously by sector, by the vulnerability exploited, and by the adversary’s capabilities.

Some threats are obvious. If a cloud service provider detects a known ransomware variant actively scanning for unpatched servers in its environment, and if those servers could contain customer data, that is clearly a significant threat. The provider should warn customers immediately. Some threats are more ambiguous. If the provider detects automated scanning that matches the pattern of a worm that is spreading indiscriminately, but the provider’s security controls prevent exploitation, is it still significant? The Directive would say: assess the likelihood and potential impact. If the scanning pattern suggests the worm is evolving to bypass those controls, the threat is significant. If the scanning is old news and your controls are proven, it may not be.

In practice, significant cyber threats tend to fall into categories:

• Zero-day vulnerabilities: A software vulnerability that is unknown to the vendor and for which no patch exists. If an entity discovers that an adversary is exploiting a zero-day in software widely used by its customers, service recipients need to know so they can apply workarounds.
• Ransomware campaigns: Evidence that a specific ransomware variant is targeting the entity’s sector or customer base. This is significant because ransomware can cause severe operational disruption and financial loss.
• Botnet infections: Detection that customer devices or systems are compromised and participating in botnets or other malicious activity. This is significant because it can lead to further compromise or legal liability for the customer.
• Credential compromise: Evidence that usernames and passwords for the entity’s services have been stolen or are circulating on dark web markets. Recipients need to change passwords and monitor for account abuse.
• Supply chain attacks: Evidence that a supplier used by the entity or its customers has been compromised and is distributing malicious updates or products. Service recipients need to know which products or versions are affected and how to protect themselves.
• Distributed denial of service threats: Intelligence that a specific customer or sector is targeted by attackers preparing a major DDoS campaign. Recipients can prepare by enabling DDoS protection, adjusting ingress filters, or alerting their own customers.

Timing: “Without Undue Delay”

The Directive requires notification “without undue delay.” This is a legal standard that means “as soon as practicable.” It is not identical to “immediately”, since an entity cannot notify before it has assessed that a threat is real and significant. But once that assessment is made, delay is not acceptable.

In practice, this means:

Once a credible threat is identified and assessed, the communications process should begin within hours, not days. An internal email from the security team to the communications team at 10 AM should result in a customer notification by late afternoon, barring unforeseen complications.

If notifying hundreds of thousands of customers, the entity needs a system to do so efficiently: email, SMS, in-app notifications, or portal alerts. Manually calling each customer is not feasible. The entity should have pre-planned notification channels and templates so that the mechanics of notification do not delay the message.

If the entity is still assessing whether a threat is truly significant, it should say so explicitly to customers: “We have identified a potential threat and are investigating. We will update you within X hours.” This maintains transparency while avoiding false alarms.

The “without undue delay” standard recognises that perfect information is impossible. Entities are not expected to wait for complete investigation before notifying. A preliminary warning is better than a delayed, comprehensive one if the threat requires immediate action from service recipients.

Content: What to Tell Service Recipients

The Directive states that entities should communicate “measures or remedies that those recipients are able to take in response to that threat” and “where appropriate, the entities shall also inform those recipients of the significant cyber threat itself.”

This creates two tiers of information:

• Tier 1 (always): Protective measures that service recipients can take. These are the practical steps that reduce risk. Examples include: change your password, update your software, enable two-factor authentication, disconnect the affected device from the network, monitor your account for unauthorised access, contact our support team if you notice suspicious activity.
• Tier 2 (where appropriate): Information about the threat itself. This might include the name of the malware, the type of vulnerability being exploited, the target sector, the estimated number of affected customers, or the threat actor believed to be responsible.

The distinction reflects the Directive’s recognition that service recipients do not always need detailed threat intelligence to protect themselves. Often, they need actionable guidance. A customer who does not understand the technical details of a zero-day vulnerability still benefits from knowing “update your software immediately.” Conversely, some service recipients, particularly organisations with their own security teams, want threat intelligence so they can assess risk and take defensive measures.

An entity should provide both tiers where feasible, but prioritise Tier 1. A customer who receives only the protective measures is better served than one who receives detailed threat analysis but no clear guidance on what to do. The Directive’s phrase “where appropriate” gives entities flexibility to assess their audience and tailor the message.

Balancing Transparency with Responsibility

Cyber threat notifications walk a fine line between transparency and responsibility. Tell too much, and customers panic, leave the service, or take inappropriate actions. Tell too little, and customers do not understand the severity and do not take precautions. Tell the wrong thing, and misinformation spreads.

Several practices help strike this balance:

• Use clear language. Avoid jargon. If you must use technical terms, explain them. Many service recipients do not have security expertise. A notification saying “a credential compromise has exposed your username and password hash” should instead say “your login credentials may have been stolen. Change your password immediately.”
• Quantify where you can. “A vulnerability affecting some customers” is vague and frightening. “A vulnerability affecting 0.5% of customers in France” is concrete and helps recipients assess whether they are likely affected.
• Distinguish between “confirmed” and “suspected.” If you have confirmed that a customer’s account was compromised, say so. If you suspect a customer may be affected based on the threat actor’s targets, say “may be.” Precision in language builds trust.
• Avoid blaming customers (even if they made mistakes). A notification saying “customers who failed to enable two-factor authentication are at risk” sounds accusatory. Instead: “We strongly recommend enabling two-factor authentication. Here is how.”
• Provide support. After notifying customers of a threat, make support resources available. This might include a temporary helpline, a FAQ on your website, or dedicated support tickets for customers who believe they are affected.
• Test your notification in advance. Run a drill where you draft a threat notification and share it with a small group, including non-technical people, to see whether it is clear, actionable, and appropriate.

Channels and Accessibility

The Directive does not prescribe the communication channel, but it implicitly requires that service recipients actually receive the notification. This means:

• Use multiple channels. Not all customers check email regularly. Some prefer SMS, others use in-app notifications, others check their account portal. Use multiple channels to maximise reach.
• Ensure accessibility. If you notify in writing, consider providing the information in multiple languages if your service is international, or in formats accessible to people with disabilities (large text, screen reader compatible, etc.).
• Do not hide in fine print. A threat notification buried in a terms of service update will not be effective. It should be prominent and easy to find.
• Document the notification. Record who was notified, when, through which channel, and what they were told. This is useful if regulators later ask whether you met your obligations.

When Notification is Not Appropriate

The Directive includes a judgment call: entities should inform recipients of the threat “where appropriate.” This allows for situations where notification itself creates greater risk. For example:

If notification would tip off an attacker that you have detected their presence, allowing them to cover tracks or escalate the attack before you can respond, it may be appropriate to delay notification until you have contained the threat.

If the threat is to a small number of high-value targets (for example, executives targeted by spear-phishing), broad notification to all customers may be inappropriate; instead, notify only those at risk.

If the threat has already been exploited and customers have already been harmed, notification should acknowledge this and provide guidance on recovery, not create additional alarm.

In all cases, the default presumption should be notification. These exceptions are narrow. If you are unsure whether notification is appropriate, notify.

Key Takeaways

• NIS2 Article 23(2) requires essential and important entities to notify service recipients of significant cyber threats that could adversely affect service provision.
• A significant threat is one that is likely to harm service recipients, damage the entity, or allow exploitation of vulnerabilities. Threats include zero-day vulnerabilities, ransomware campaigns, botnet infections, credential compromise, supply chain attacks and DDoS campaigns.
• Notification must occur “without undue delay,” meaning as soon as an entity assesses that a threat is real and significant, usually within hours.
• Entities should communicate protective measures that recipients can take (mandatory) and information about the threat itself (where appropriate).
• Notifications should use clear language, quantify information where possible, distinguish between confirmed and suspected threats, and provide support resources.
• Multiple communication channels and accessible formats should be used to ensure recipients actually receive notifications.