Article 23(1) and (2) NIS2 notifying service recipients

What NIS2 Article 23(1) and (2) require when customers must be told

Article 23(1) requires entities to notify the recipients of their services of significant incidents that are likely to adversely affect the provision of those services, and Article 23(2) requires them to tell potentially affected recipients about a significant cyber threat, along with the measures or remedies those recipients can take and, where appropriate, the threat itself. This duty runs alongside the reports to the CSIRT or competent authority, not instead of them, so a compliance lead needs a second track that serves customers and users in parallel. The provisions are conditioned by the words where appropriate and where applicable, and the notice must go out without undue delay, so the entity must decide, and be able to justify, when those conditions are met.

The hard parts are operational. First, the team must decide which recipients are actually affected, which requires mapping services to customer tenants, user groups and data flows before an incident happens. Second, the notice must be written in plain language quickly, while facts are still changing. Third, the entity must keep a record showing when it became aware, who it judged affected, what it sent and when. A practical check is to ask whether the incident case record can produce a recipient list, the notice text and its send timestamps without manual reconstruction. Illustratively, a hosted service whose customer list lives in a separate billing system will struggle to answer that question during an incident.

Recital 103 adds that threat information for recipients should be free of charge and in easily comprehensible language, given on a best efforts basis, and that it does not relieve the entity of its own remedial measures at its own expense. Confirm with counsel how these notices interact with contract terms, the GDPR breach notification timing for personal data, and any national transposition rules, since Member States implement the Directive through their own laws. The tooling that holds the case timeline and evidence, such as the open-source case management platform DFIR-IRIS documentation, can support the audit trail, but the notice content and the decision to send it remain the entity's responsibility.

Which entities, incidents and recipients fall under the notification duty

Article 23(1) and (2) apply to a narrower set of situations than the full reporting regime, so the first job is to confirm who carries the duty and what triggers it. The cards below separate entity status, incident significance, threat significance and the recipients who must actually be told, since each one changes who receives a message and when.

Essential and important entities alike

Both essential and important entities carry the recipient-notification duty under Article 23, even though they face different supervision regimes. Essential entities are supervised ex ante and important entities ex post, but that difference does not remove the duty to tell service recipients. Confirm your classification under your national transposition law, because the duty applies to whichever category your Member State assigns you. Record the classification decision in your reporting procedure so staff know the duty applies on day one.

Significant incident likely to affect service

The notification trigger under Article 23(1) is a significant incident that is likely to adversely affect the provision of the entity's services. The incident must have effect on the service a recipient receives, not merely on internal systems. A compromise of a back-office server with no service impact usually does not reach this trigger, while an outage of a customer-facing portal does. Document the link between each incident and the service it touches, because this link decides whether recipients must be informed.

Significant cyber threat under Article 6(11)

Article 23(2) applies when a significant cyber threat exists, defined in Article 6(11) as one that can be assumed, based on technical characteristics, to have the potential to severely affect systems or service users through considerable material or non-material damage. This trigger is not tied to an incident having already occurred. Threat monitoring teams should record the technical indicators that led to a significance assessment, so the decision to warn recipients can be explained later. The significance test itself is covered on the Article 23(3) page.

Recipients actually at risk

The notice goes to the recipients whose service is actually affected or potentially affected, not to every customer by default. For an incident, this means users whose access, data or availability is impaired. For a threat, it means users who could be exposed to the threat based on the technical characteristics identified. Maintain a current mapping from each service to its user groups and contact channels, because a list built after the incident usually takes too long to produce. Confirm with counsel how this list relates to your GDPR notification obligations.

Mapping services to recipient lists

Recipient notices depend on a service inventory that links each product or service to its customer segments, contact records and communication channels. Without this map, teams tend to notify the wrong group or miss a group entirely. Keep the mapping under change control, assign an owner, and test it during tabletop exercises. Confirm where contact data is stored and who may access it during an incident, since this data is also personal data under GDPR.

How the incident duty and the threat duty differ for recipients

The two duties in Article 23 are triggered by different events, so they call for different messages. Article 23(1) applies when a significant incident is already affecting, or is likely to affect, the provision of a service. The notice to recipients should therefore focus on impact: which services are degraded, what users may notice, what the entity is doing to restore them, and when it expects to give the next update. The entity should decide in advance who writes this notice, who approves it, and which channels reach every affected service recipient, because the duty applies where appropriate and must be met without undue delay.

Article 23(2) is triggered by a significant cyber threat, meaning a threat that, on its technical characteristics, can be assumed to have the potential to severely impact systems or service users. Here the notice should center on what recipients can do now, such as applying a vendor patch, rotating credentials, or watching for a specific phishing pattern. Naming the threat itself is required only where appropriate, so the team should set criteria for when disclosure of the threat details would help recipients and when it would only add risk. Recital 103 adds that this information should be free of charge, written in easily comprehensible language, and given on a best efforts basis. It also states that the notice does not relieve the entity of its own remedial measures, which it must carry out at its own expense.

Competent authorities can also act on this duty. Articles 32(4)(e) and 33(4)(e) allow a supervisor to order essential and important entities to inform persons potentially affected by a significant cyber threat about its nature and the protective measures they can take. Organizations should confirm with their national competent authority how that power is used in their Member State and keep a notice template ready that covers both duties, so that a supervisory order can be met quickly without drafting from scratch during an incident.

How an assessor tests recipient notification

This table lists the test points an assessor is likely to use when checking whether an entity told its service recipients about significant incidents and significant cyber threats. Read each row as a question the assessor will ask, the sample they will pull, and the gaps that most often come up in practice.

Test point	Test approach	Evidence requested	Common findings
Documented trigger criteria	Read the policy and procedure to see whether they define when an incident affects service recipients and when a threat becomes significant under Article 6(11).	Notification procedure, decision criteria, approval roles, and any link to the significant incident criteria in Implementing Regulation 2024/2690.	Procedure refers to recipients but gives no test for recipient impact, or the threat definition is copied without local interpretation.
Recipient-impact decision in incident records	Select incident tickets and check whether a recorded decision says whether recipients were affected and who made it.	Incident record fields for affected services, recipient impact assessment, decision owner and timestamp.	Tickets close without any recipient-impact entry, so the assessor cannot tell whether the question was considered.
Sample of past significant incidents	Pull a sample of significant incidents and confirm either that notices were sent or that a reasoned no-notice decision exists.	Copies of notices sent, distribution lists, and signed no-notice rationales for each sampled incident.	Notices missing for incidents that affected services, or no-notice decisions written without reasons.
Timing without undue delay	Compare the time of the decision to notify with the time notices were sent, and check whether any delay has a documented reason.	Timestamps from the incident log, message delivery logs, and approval records.	Notices sent only after the final report, or delays with no explanation in the record.
Content in plain language	Read a sample of notices to check that they describe the incident or threat and state the measures recipients can take.	Template notices, sent copies, and the recipient guidance used to draft them.	Notices give technical detail but no practical steps, or they omit the threat itself where it was appropriate to share it.
Free-of-charge handling	Check that notices and threat information were not billed, and that no fee was attached to recipient guidance.	Billing records, contract terms for notices, and communication channel terms.	Threat information offered only as a paid service, or charges applied to notice delivery.
Remedial measures at the entity's expense	Check that the entity carried out its own remedial work and did not shift that duty onto recipients through the notice.	Remediation tickets linked to the incident, and cost records for corrective work.	Notices place the full remedy burden on recipients with no entity-led fix recorded.
Compliance with authority orders	Where a competent authority ordered notification under Article 32(4)(e) or Article 33(4)(e), confirm the order was followed in scope and timing.	The authority order, the notice issued in response, and the record of follow-up actions.	Orders received but not logged, or notices sent to a narrower group than the authority required.

How to build the notification process step by step

This sequence turns Article 23(1) and (2) into a working process: decide what counts as significant for your services, know who must hear about it, pre-approve the notices, and prove the path works before a real incident forces it. Each step ends in a record an assessor can inspect.

Define significance and recipient impact criteria
Start by writing down which incidents and cyber threats are significant for your services, and which of them are likely to adversely affect the provision of those services to recipients. Use the Article 23(3) criteria and any thresholds in Implementing Regulation 2024/2690 that apply to your entity type, then add internal impact tests for availability, data integrity and user harm. Confirm the criteria with the management body or the delegated owner. The output is a signed criteria document that states, for each service, what triggers a recipient notice under Article 23(1) and what triggers a threat notice under Article 23(2).
Map recipient groups and contact channels per service
For each service, list the recipient groups that could be affected, such as enterprise customers, consumers, partners and public bodies that rely on you, and record how you can reach each group quickly. Confirm the channels that remain available during an outage, such as status pages, account-level email, in-product banners or a named account contact, and identify a backup channel for each. Note where contact data is held and who keeps it current. The output is a recipient register with a channel and an owner per service, reviewed on a set schedule and dated.
Draft notice templates in plain language
Write separate templates for a significant incident notice and a significant cyber threat notice. The incident template should cover what happened in general terms, which services and recipients are affected, the likely impact, and the status of containment. The threat template should describe the threat in understandable terms, the measures or remedies recipients can take, and, where appropriate, the nature of the threat itself. Recital 103 expects this information to be free of charge and easy to understand, so test each draft with someone outside security. The output is an approved template set with fill-in fields and a version number.
Set approval roles so notices can go out without undue delay
Assign who drafts, who approves and who sends each notice, with a named deputy for every role. Keep approval short and pre-authorized for the cases defined in step one, so that the operational owner can issue a notice without waiting for a full committee meeting. Record legal, communications and privacy review as parallel checks rather than sequential gates, and make sure a notice does not wait on the outcome of the investigation. The output is a RACI or approval matrix showing who can authorize each notice type, with contact details and an out-of-hours path.
Link the process to the incident response plan and reporting workflow
Connect the notification steps to the incident response plan so that the decision to notify recipients is taken at the same point as the Article 23(4) reporting decisions to the CSIRT or competent authority. Define the triggers, the information each step needs, and where the recipient notice sits relative to the early warning and the incident notification. Make sure any recipient notice is consistent with what is told to authorities and, where personal data is involved, with GDPR breach notification. The output is a workflow diagram and a cross-reference section in the incident response plan that names the owner of each handoff.
Run a tabletop exercise that includes a recipient notice
Test the process with a tabletop exercise built around a hypothetical incident that is significant for at least one service. Include a moment where the team must decide whether to notify recipients, draft the notice from the template, obtain approval through the defined roles, and send it through the recorded channel. Include a threat scenario as well, so the team practices a Article 23(2) notice with remedies. Record decisions, timing observations and gaps. The output is an exercise report with dated actions, and updates to the criteria, templates or contact register that the exercise revealed.

Evidence that shows recipients were notified and informed

Article 23(1) and (2) only work if an entity can show, after the fact, that it decided who was affected, told them in time and gave them usable measures. The cards below cover the artifacts that carry that proof, from the written procedure through to the exercise reports that show the process runs under pressure.

Written notification procedure with triggers

The procedure states which incidents and significant cyber threats trigger notice to service recipients, who decides, who approves the wording and which channels are used. Assessors look for trigger criteria that link back to the significant incident test, not a general promise to inform customers. Check that the procedure names the decision owner and the fallback when that person is unavailable. Confirm that it is approved by management and reviewed after each real incident.

Recipient contact registers per service

A register maps each service to the recipients who use it, the contact route for each group and the data owner who keeps the list current. Without it, an entity cannot show that it could reach the users potentially affected, and a notice may go to the wrong group. Check that the register covers customers, end users and integrators where they exist, and that changes to contacts are logged with dates. Confirm how the register is protected, since it holds personal data.

Notice templates and approved sent copies

Templates set out plain, free-of-charge language that explains the incident or threat, its likely effect and the steps recipients can take. Keep the approved version of each template, plus a copy of every notice actually sent, with the send time and the distribution list. Recital 103 expects comprehensible wording, so check that a non-specialist reader can act on the notice. Store sent copies in a tamper-evident location.

Incident records with recipient-impact decisions

Each incident record should show whether service recipients were likely to be adversely affected, who made that call, the reasoning and the timestamps for detection, decision and notice. Gaps between these times are the first thing reviewers question. Record a decision not to notify as well, with the reason, because that decision also needs to be defended. Confirm that the record reflects the decision taken, not a later reconstruction.

DFIR-IRIS case records and timeline

DFIR-IRIS, an open-source incident response platform licensed under LGPL-3.0-or-later, keeps each case as one record of assets, indicators of compromise, tasks and evidence, with a full audit trail. Its consolidated timeline and report generation help show when the recipient-impact decision was made and what it rested on. The tool records the case, but the organization still owns the decision and the notice. Confirm that your deployment's audit trail is retained and exported with the case.

Threat advisories and exercise reports

For significant cyber threats, keep the advisories sent to recipients, the protective measures they describe and any remedies the entity provided at its own cost. Exercise reports from tabletop or live tests show whether the notification steps work within the required timeframes and where they fail. Competent authorities can order notice of a threat, so keep advisories ready to produce. Check that each exercise produces actions with owners and that the fixes are tracked to closure.

What meeting Article 23(1) and (2) costs in money and effort

This table compares the cost components of notifying service recipients under Article 23(1) and (2), who is paid for each, whether it is one-time or recurring, and what moves it up or down. No fees are published here, so use the drivers and quote questions to compare written proposals on the same scope.

Cost component	One-time or recurring	What drives it	How to keep it down
Process design and legal review of notice wording	One-time, then reviewed on change	Number of recipient groups, sector rules, and how many notice templates are needed for different threat types	Keep a short set of templates covering threat notices and incident notices, and agree the review path with counsel once
Recipient contact data upkeep	Recurring	Size of the customer base, how often contacts change, and whether contact data sits in systems tied to the incident tooling	Assign an owner, set a review cadence, and test that contact lists can be exported within the incident process
Engineering effort to connect customer messaging to incident tooling	One-time build, then recurring maintenance	Number of channels (email, portal, status page), integration with case records, and access controls on the messaging path	Reuse existing notification channels and limit the first version to the channels recipients already use
Staff time for drafting and approving notices during incidents	Recurring, incurred per incident	Approval chain length, number of affected recipients, and whether drafts must be prepared while the response is still running	Pre-approve notice templates and name approvers with a deputy for each role
Tooling and hosting for the case record	Hosting recurring, software license one-time or none	DFIR-IRIS is licensed under LGPL-3.0-or-later, so self-hosting avoids license spend, but hosting, backups, access management and staff time still apply	Confirm the hosting footprint with the implementation partner and reuse existing infrastructure where the security team approves it
Exercises that test recipient notices	Recurring, usually annual or after major change	Number of scenarios, participants from communications and legal, and whether recipients are simulated or real	Combine the notice test with the broader incident exercise instead of running it separately
External review or assessor sampling	Recurring, tied to supervisory or audit cycles	Whether an independent reviewer checks the notice process, how much sampling the assessor performs, and how evidence is packaged	Keep evidence of each notice (timestamp, content, recipients) in one place so sampling takes less time

Where organizations usually fall short on recipient notice

Article 23(1) and (2) only work when an entity can decide quickly who is affected, reach those people, and explain what they should do. The gaps below tend to surface during exercises or after a real incident, when the notice path turns out to depend on memory, stale spreadsheets and judgment calls nobody recorded.

No written impact trigger

Many entities have no written rule for when an incident is likely to adversely affect service provision, so the decision to notify recipients is made ad hoc under pressure. Define the conditions in the incident response plan, such as loss of a customer-facing service or exposure of recipient data, and name who makes the call. Check that the trigger is tested against recent incidents.

Stale or single-owner contact lists

Recipient contact details often sit in one account manager's spreadsheet or in a CRM field nobody maintains. When an incident occurs, notices go to outdated addresses or no one can find the list at all. Hold the list in a controlled system with a named owner, a review cycle, and a copy the incident team can reach without the owner present.

Notices too technical to act on

Recipients need to understand what happened to them and what to do, yet notices frequently repeat internal ticket language, indicator hashes or CVE jargon. Write a short template per service that states the impact in plain language, the time window, and the actions the recipient should take. Recital 103 expects this information to be easily comprehensible and free of charge.

Threat advisories without remedy steps

A significant cyber threat notice that only says a threat exists does not meet the purpose of Article 23(2). Recipients need concrete measures they can apply, such as rotating credentials, disabling a feature, or checking a configuration. Keep a library of approved remedy steps per threat type so the advisory can name actions the entity has already validated.

No record of why notice was withheld

When an entity decides not to notify recipients, supervisors may later ask why. Without a recorded rationale, the decision looks arbitrary, even when it was sound. Log the assessment, the people involved, the time of the decision, and the facts relied on, then store the record with the incident case so it can be produced on request.

Notice path never exercised

Notification steps often appear in plans but are never run, so approvals, template access and sending tools fail when first used. Include a recipient notice step in tabletop exercises and run a periodic test that sends a dummy notice to internal addresses. Record what broke and assign a fix with a due date.

Who owns the notification duty and what can be outsourced

The entity owns the notification duty in full. Under Article 23(1) and (2), it decides whether an incident is significant, whether affected service recipients must be told, and what they should be told to do. The decision, the notice and the records of both sit with the organization, and the management body remains accountable for the Article 21 measures that make notification workable at all. Outsourcing a function does not transfer this liability.

Significance decision: Named staff decide whether an incident is likely to adversely affect service provision and record the reasoning at the time.
Recipient notice: The organization sends the notice itself, without undue delay, in plain language.
Records: The organization keeps the decision log, copies of notices sent and the timestamps that show when awareness arose.
Management oversight: Leadership reviews notification performance and approves the procedure, consistent with its Article 20 duties.
Contract alignment: Customer terms and supplier contracts state who notifies whom and how quickly.

Check that every decision-maker named in the procedure is someone the organization can hold accountable without an external intermediary.

Questions buyers ask about notifying service recipients under NIS2

Can we notify our service recipients about incidents ourselves, without outside help?

Yes, the duty sits with your organization, and many teams can run it in-house if they already have an incident response process and a current list of who uses which service. Article 23(1) requires entities to notify recipients of significant incidents that are likely to adversely affect the service, where appropriate, without undue delay. The hard parts are not the wording of the notice. They are knowing quickly which recipients are affected, having contact data that is current, and agreeing internally who approves the message. Organizations without these capabilities often bring in a partner to prepare the process, templates and tooling, while management keeps decision rights over what is sent and when.

How much effort does notifying service recipients take, and what drives it?

The effort scales with the number of recipients, how quickly your systems can map an incident to affected customers, and how many channels you must reach them through. Recipients may be a handful of enterprise clients or millions of end users, and the work differs greatly between the two. Effort also rises when services are shared across customers, when contact data is spread across CRM, billing and ticketing systems, or when an incident hits a supplier you depend on. Ask any provider for a written breakdown of the work by step, so you can see which parts are yours and which are theirs. No figure for effort is supplied here, so treat any estimate you receive as a question to test against your own environment.

What skills and inputs does the team need to send these notices?

You need four things: a service catalog that links each service to its recipients, a way to query those recipients quickly, people authorized to approve external messages, and staff who can explain the threat and remedies in plain terms. Technical staff must determine whether recipients are actually affected and what they can do, such as rotating credentials or applying a patch. Legal, communications and customer support usually need a defined role in the approval path. Some organizations also need a way to notify through channels that still work during an outage, such as a status page or an out-of-band email list. Confirm each input exists before the first real incident, because building them during one is slow.

How long does it take to set up notification of service recipients?

No duration is supplied for this work, so do not rely on a generic timeline. Setup depends on how much of the recipient data and approval process already exists, how many services are in scope, and whether templates and channels must be built from scratch. Ask any partner or internal team for a written scope and timeline that lists each deliverable, the systems touched, the people who must review the output and the point at which the process is tested. A fixed-scope agreement makes it easier to compare proposals, because deliverables and dates are agreed in writing before work starts.

Must notices to service recipients be free of charge and in plain language?

Yes, the threat information you give recipients should be free of charge and written in easily comprehensible language. Recital 103 of NIS2 says this information is provided on a best efforts basis and does not relieve you of taking remedial measures at your own expense. Plain language means avoiding internal jargon, naming the affected service, stating what the recipient should check or change, and giving a contact route for questions. Recipients should not have to pay for the notice or for the fix that a significant incident requires from you. Have legal review the wording template in advance so that the urgent message is not drafted from scratch under pressure.

Does one notice to service recipients also satisfy the incident reporting to the authority?

No, a notice to recipients and a report to the competent authority or CSIRT are separate duties with different content and recipients. Article 23(1) and (2) concern the people who use your services, while Article 23(4) sets out the early warning, notification and follow-up reports to authorities. The two messages must be consistent, so the facts you give customers match what you report, but they are not interchangeable. Where personal data is involved, GDPR breach notification may also apply, which is a further track. Build the process so one incident record feeds all three outputs, and have the authority reporting timeline checked against the notice timeline by whoever owns compliance.

What does a partner do for notifications, and what must our organization keep?

A partner can prepare the incident record, recipient mapping, templates, channel setup, and test exercises, and can run the tooling that keeps a single case of the incident with its timeline and evidence. DeployOpen, for example, implements and hardens self-hosted platforms in your own infrastructure, including case management tools such as DFIR-IRIS, which keeps assets, indicators, tasks and evidence in one audit trail. Your organization keeps ownership of the decision to notify, the content approved for release, the contact data and the legal judgment about significance. Only an independent auditor or assessor issues reports or certificates, and no partner can certify your notification process on your behalf.

Which recipient notices can the authority order us to send?

Competent authorities can order essential and important entities to inform persons potentially affected by a significant cyber threat about its nature and the protective measures they can take. Articles 32(4)(e) and 33(4)(e) give this power, so a regulator may require notices even when you would not have chosen to send them. Plan for this by keeping templates ready and recording who received what and when. Ask counsel how the national transposition law in your Member State applies these powers, because the detailed rules are set nationally.

How DeployOpen scopes and prepares recipient notification for NIS2

DeployOpen helps entities prepare the systems, contact records and procedures needed to notify service recipients of significant incidents and significant cyber threats. We build these inside your own infrastructure, and your organization keeps ownership of the decisions on what to tell recipients and when.

How we scope

Engagements are fixed-scope, with the recipient groups, services and notification channels agreed in writing before work starts.
We map which customer and user populations could be adversely affected by an incident on each in-scope service.
The written scope states which parts are configuration, which are documentation and which remain with your legal or communications teams.

How we build

We configure self-hosted case management, such as DFIR-IRIS, to link affected services and recipient records to each incident case.
We prepare notification templates in plain language, with fields for the threat, the recipient action and the remedy steps.
We set up audit trails so each notice, its timestamp and its approver are recorded alongside the incident evidence.

How we hand over

We deliver the notification procedure, templates, contact lists and case configuration as documented, versioned artifacts.
We run a walkthrough with your incident response and communications owners to test the notice workflow end to end.
We document the evidence a supervisor would ask to see, so your team can show how recipient notices were prepared and sent.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, which can keep templates and contact lists current.
We can review notification templates after changes to services, customer segments or contractual terms.
Confirm with your legal counsel which recipients and thresholds apply under your national transposition law before we build.