Article 23(4)(a) early warning within 24 hours

What the NIS2 Article 23(4)(a) early warning asks for in its first 24 hours

The early warning is due without undue delay and in any event within 24 hours of the entity becoming aware of a significant incident, so the clock starts when someone in the organization has enough information to conclude the incident is significant. That makes the first decision the hard one. Teams need a documented way to classify an event as significant, with a named person who can make that call at any hour, a record of the time awareness was established, and a check against the significant incident criteria that apply to the entity's sector or digital service type. Confirm with your national CSIRT or competent authority which submission channel and form they use, since notifications go to the national CSIRT or, where the Member State provides, to the competent authority that forwards them.

Where applicable, the early warning must say whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact. Those two points are the only substantive content the Directive asks for at this stage. Recital 102 explains the restraint: the early warning should carry only what the authority needs to become aware of the incident and let the entity ask for help, and it should not pull people away from containment. In practice, the incident response lead should prepare a short template with fields for detection time, awareness time, affected service, suspected malicious or accidental origin, and whether other Member States or users in them may be affected. Illustratively, a ransomware alert on a hosting platform serving customers in several countries would need a cross-border answer within the same first submission.

The response you can expect is set out in Article 23(5): the CSIRT or competent authority should reply without undue delay and, where possible, within 24 hours with initial feedback, and on request with guidance on mitigation. For suspected criminal incidents it should also advise on reporting to law enforcement. Plan for that reply to arrive while you are still containing the incident, and assign someone to track the authority's requests so they do not compete with forensic work. Because the 72-hour notification follows, the early warning should be written so its facts can be updated rather than replaced, and the case record in your incident management system should hold the timestamps that justify both submissions.

Which incidents start the NIS2 early warning clock

The 24-hour early warning only starts when three things line up: the entity is in scope, the event meets the significance test, and someone in the organization or a third party has become aware of it. Each card below covers one decision that determines whether that clock is running, and who needs to be reachable when it starts.

Essential or important classification

Article 23 applies to both essential and important entities, so the early warning duty does not depend on classification. Classification still changes how supervisors treat you afterward, so confirm it with your national competent authority and record the reasoning. Check whether your sector annex and size cap place you in scope at all, because an out-of-scope entity has no NIS2 clock to run.

The significance test as trigger

The 24-hour clock applies only to a significant incident, so the first decision is whether the event meets the Article 23(3) criteria. Document the assessment as it happens, including the time you first had enough information to judge it. Where the implementing regulation adds quantified thresholds for your entity type, apply those thresholds rather than a general judgment.

Systems and services in scope

Map which systems, networks, cloud tenants and customer-facing services belong to the entity's NIS2 scope, since an incident affecting them can be significant. Include identity providers, backup systems and management planes, because an attacker who compromises them can affect many services at once. An inventory that is out of date will hide the systems that matter during an incident.

Detection pipelines that surface events

The clock starts on awareness, so alerts from SIEM, EDR and cloud logs must reach a triage queue that can classify them quickly. Confirm that the detection rules cover the in-scope systems and that a suspicious event does not sit unreviewed in a dashboard. Define which alert severities escalate to the incident response lead and who can decide that an event is significant.

On-call routing and after-hours cover

Incidents often become known outside office hours, and the 24-hour period keeps running through nights and weekends. Confirm that a named person can be reached at any time to make the significance call and submit the early warning. Test the paging path, the escalation order and the backup contact, so a single missed phone call does not stop the report.

Managed SOC, cloud and MSP awareness

A managed SOC, cloud provider or managed service provider may detect an event before your own staff do, and awareness can then be attributed to the entity. Write these obligations into contracts: require prompt notice of suspected significant incidents, a named contact and a defined hand-off. Ask each provider how quickly it notifies you and how its alerts reach your on-call team.

How an assessor tests the 24-hour early warning

This table sets out how a national competent authority or security auditor typically tests the early warning step, the evidence each test asks for, and the findings that appear most often. Use it to check your own file before a supervisor asks for it, noting that the exact request depends on the Member State and the supervisor.

Test step	What the assessor does	Evidence requested	Common finding
Awareness time	Compares the incident log timestamps with the time the entity first became aware of a significant incident	Incident register with a recorded awareness time, detection alerts and triage notes	No documented awareness time, so the 24-hour clock cannot be verified
Decision to classify	Walks through how the team decided the incident was significant under the applicable criteria	Classification record, criteria applied, approver and date of the decision	Classification decided informally or after the deadline without a record of why
Timeliness sampling	Samples reported incidents and checks each early warning against the 24-hour limit	Timestamped early warning submissions and the submission channel used	Early warning submitted after 24 hours, or no submission found for a classified incident
Content check	Reads the early warning for an indication of suspected unlawful or malicious cause and any cross-border impact, where applicable	Copy of the submitted early warning showing those indications	Malicious-cause or cross-border indication missing or left blank without explanation
Authority response	Confirms the CSIRT or competent authority acknowledged the report and whether feedback or guidance followed	Acknowledgement receipt, feedback received and actions taken in response	No acknowledgement on file, so the entity cannot show the authority received the report
Scope of content	Checks that the early warning holds only the information needed to alert the authority, without delaying incident handling	Early warning text and the follow-up plan for the 72-hour notification	Early warning used as a full investigation report, or incident handling stalled while drafting it

How to build a 24-hour early warning process that holds up

The sequence below turns the Article 23(4)(a) early warning from a deadline on paper into a tested routine: a defined awareness point, a documented significance decision, a short template, an agreed channel, internal escalation that protects responders, and a rehearsal before a real incident arrives. Each step ends with an artifact you can show a supervisor.

Define the awareness point and who records it
The 24-hour clock starts when the entity becomes aware of a significant incident, so the first task is to write down what counts as awareness in your environment: for example, a validated alert from the SIEM, a report from a staff member, or a notice from a supplier or customer. Name the roles allowed to record awareness, typically the on-call security lead and a backup, and require a timestamp in the incident record at the moment of recording. The output is a one-page awareness standard and a field in your case tool that stores the time of awareness. Confirm with counsel how your national transposition law phrases this trigger.
Set the significance decision path and its owner
Document how the team decides whether an incident is significant, using the criteria your national authority and Implementing Regulation (EU) 2024/2690 apply to your entity type. Assign one named decision owner with a deputy, and state what they must check first, such as service impact, cross-border effect and signs of unlawful or malicious activity. The output is a decision flowchart attached to the response plan, plus a log entry for each decision that records the reasoning and the time it was made. Where the criteria are unclear for your sector, ask the authority for guidance before you need it.
Prepare a short early warning template
Build a template limited to the information Recital 102 describes: enough to make the CSIRT or competent authority aware of the incident and to let you ask for help, without diverting people from handling it. Include fields for the awareness time, a short factual description, whether unlawful or malicious activity is suspected, whether cross-border impact is possible, and the contact for follow-up. The output is a template of roughly one page, with a note that details come later in the notification step. Keep the template in version control so changes are tracked.
Agree the submission channel with the authority
Confirm with your national CSIRT or competent authority how early warnings are submitted, whether through a portal, a secure email address or a designated form, and whether the competent authority forwards reports to the CSIRT. Ask which identity and account setup is required and who on your side holds it, and test that credentials work before they are needed. The output is a written channel record with the submission address or portal, the named contacts, and the backup route if the primary channel is unavailable. Article 13(6) requires Member States to simplify reporting through technical means, so ask what tools are offered.
Set internal escalation that protects responders
Create an escalation path so the compliance or legal lead drafts and submits the early warning while the technical team keeps working on containment. Define who is paged at each severity level, who approves the submission, and who speaks to the authority, so that no engineer is asked to write the report during an active incident. Store the contact list and the approval chain in a runbook that survives an outage of your main tooling. The output is an escalation matrix and a signed-off role assignment, reviewed by management and kept with the response plan.
Run a dry run of the full path
Rehearse the sequence with a tabletop scenario that starts with an alert and runs through awareness, significance decision, template completion, submission and internal approval, timing each handover against your own deadline. Record where the path stalled, such as an unreachable approver, a missing portal login or an unclear criterion, and fix each gap in the documents. Repeat the exercise after significant changes to staff, tools or suppliers. The output is an exercise report with dated findings, owners and corrective actions, which doubles as evidence that the process has been tested rather than only written.

Evidence that proves the early warning met the 24-hour deadline

Article 23(4)(a) turns on one question: when did the entity become aware of a significant incident, and when did the early warning leave its systems? The six artifacts below answer that question in sequence, so an assessor or authority can rebuild the clock from primary records rather than from memory. Keep each one current between incidents, not only when an audit is announced.

Awareness record with timestamp

This is the record that starts the 24-hour clock: the first alert, report or notice that made a named responsible person aware of a possible significant incident, with its time in a single stated time zone (UTC is the usual choice). Check that the timestamp comes from the source system, such as the SIEM alert or the ticketing entry, and that it is not typed in afterwards. Confirm with your counsel how your national transposition law defines awareness, because the deadline depends on that reading.

Significance decision record

Record who decided that the incident was significant, when, and why, referencing the applicable criteria under Article 23(3) and any sector thresholds that apply to your entity type. A short rationale is enough if it names the criteria checked and the facts relied on. Also record a decision if you concluded the incident was not significant, because assessors test that judgment too.

Early warning as submitted

Keep the exact copy of the early warning as sent, with the submission timestamp and the channel used, such as the national portal or the authority's stated form. The copy should show whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have cross-border impact, where that applies. Store it in a version-controlled template so that you can show which template version was in force on the date of submission.

Authority or CSIRT acknowledgement

Retain the receipt, reference number or automated acknowledgement returned by the national CSIRT or competent authority. Compare its timestamp with your own submission record, since a gap between them can raise questions about the submission channel. If no acknowledgement arrives, keep the failed attempts and the follow-up you made, because a silent channel is itself a fact that must be documented.

Case timeline

Export the consolidated timeline from your case management tool, showing each event from first detection through to the submission of the early warning. Confirm that the timeline is generated from logged events with their own timestamps and that edits are recorded in an audit trail. Gaps in the timeline between awareness and submission are where assessors focus, so explain each one in the record.

Procedure showing who may submit

Maintain a written reporting procedure that names the roles authorized to submit an early warning, the deputies for each, and the escalation path when the primary contact is unavailable. Review the named roles against your current staff list at each drill. A procedure that names people who have left the organization will not show that the deadline could be met in practice.

What entities can expect from the CSIRT or authority after the early warning

When the early warning indicates that an incident may be caused by unlawful or malicious acts, the CSIRT or competent authority must respond without undue delay and, where possible, within 24 hours with initial feedback. On request, it can also give guidance on mitigation measures. The early warning itself should carry only what is needed to make the authority aware and to let the entity ask for help, so the entity should not expect a detailed technical analysis at this stage.

Initial feedback window: Expect a first acknowledgement or response within 24 hours where the authority can provide it, not a full assessment.
Mitigation guidance on request: Prepare a short list of specific questions, such as containment steps or affected systems to isolate, before you call or write to the authority.
Named contact: Record the point of contact and the channel the authority uses, so that follow-up messages reach people who can act.
Ongoing incident work: Keep the response team working on containment and evidence preservation while waiting, since the authority's feedback does not replace internal handling.
Evidence preservation: Keep logs, alerts and system images from the affected environment intact so that later reports can cite them.

Confirm with your national CSIRT or competent authority which channel, template and response times apply to your entity and which mitigation support it offers.

Which self-hosted open-source tools produce the early warning evidence

The early warning is a short notice, but the entity needs a record it can stand behind: when it became aware, what it saw and whether the activity looks malicious. The four tools below each produce part of that trail, from detection and alerting through case tracking and response automation. None of them decides whether an incident is significant, and each needs confirmation against your own environment before you rely on it.

DFIR-IRIS for the case record

DFIR-IRIS keeps each incident as one case with its assets, indicators of compromise, tasks and evidence, and it triages alerts from SIEM, EDR and REST sources into that case. For Article 23(4)(a), the case is where the awareness time and first triage notes are recorded, so the 24-hour clock has a dated starting point. Check that your alert intake covers the sources you would actually use and that the audit trail shows who recorded what and when. The project is licensed under LGPL-3.0-or-later, so confirm how your distribution and any modifications are handled with counsel.

OpenSearch Security Analytics detections

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against Sigma rules, then records each match as a finding with its rule, log type and severity. Correlation links findings across log types, which helps show whether an event is part of a wider pattern that may be malicious. Confirm that your log sources are onboarded, that rules are tuned to your environment, and that alert channels such as email or chat reach a staffed on-call rota. The project is licensed under Apache-2.0, a permissive license with fewer copyleft obligations.

Wazuh alerts and ATT&CK mapping

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules. Matching alerts are written to alerts.log and alerts.json and mapped to MITRE ATT&CK, which gives the early warning a timestamped source event and a technique reference. Confirm that agents are deployed on the systems in scope, that custom rules cover your critical assets, and that alert volume does not bury high-severity events. Wazuh is licensed under GPL-2.0-only, so review the obligations that apply if you distribute or modify it.

Shuffle workflows for handoffs

Shuffle runs event-driven workflows started by a webhook, a schedule or a manual run, and its app nodes can connect a SIEM, ticketing system and firewall without custom code. In practice, a workflow can open a case, notify the responsible person and log each step, which shortens the path from detection to a dated internal record. Confirm which actions are automated and which need human approval before any change is made to a firewall, and test the workflow with sample alerts. Shuffle is licensed under AGPL-3.0-only, and running it as a network service can trigger source-availability duties, so check this with counsel.

What meeting the early warning requirement costs

This table breaks the early warning obligation into its cost components, showing who is paid for each, whether the cost is one-time or recurring, and what pushes it up or down. The main takeaway is that the license line is usually the smallest item, while staff time, integration work and keeping evidence current carry most of the effort.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Significance decision staff time	Internal incident response, legal and management staff	Recurring	Number of incidents, on-call coverage hours, and how many people must sign off within the 24-hour window
Drills and tabletop exercises	Internal staff, plus any external facilitator you engage	Recurring	Frequency of exercises, number of entities in a group, and whether reviewers from outside the organization join
Log collection and detection hosting	Infrastructure team or hosting provider	Recurring	Number of log sources, retention period and storage volume; confirm sizing with the platform documentation
Platform licenses	Vendor or community project, where a license applies	Recurring	Self-hosted licenses in the supplied facts carry no license fee to the vendor, but confirm any paid add-ons or support plans
Workflow and integration engineering	Internal engineers or an implementation partner under a written scope	One-time, with later updates	Number of tools to connect (SIEM, ticketing, firewall, chat), custom rules and the number of notification paths
Notification template and playbook build	Internal compliance and incident response leads, or an outside adviser	One-time, reviewed periodically	Number of Member States where you operate and the national CSIRT or authority requirements that apply
Evidence upkeep	Internal compliance staff, auditors or advisers if asked to review	Recurring	Frequency of reviews, changes to systems and contacts, and how much of the evidence is generated automatically
External review or independent testing	Outside consultant, testing firm or cyber range provider	Recurring, when engaged	Scope agreed in writing, number of exercise scenarios, and whether results are reviewed by a third party

Who does what for the early warning: your team, a partner and the auditor

Your organization owns the early warning. The management body, which Article 20 makes responsible for the Article 21 measures, is accountable for the reporting process, and the incident team is accountable for making the significance call within the deadline. Nobody outside the organization can decide that an incident is significant or approve what is sent to the CSIRT or competent authority. The clock starts when the entity becomes aware of a significant incident, so the team must be able to record that moment accurately.

Significance decision: A named role decides, documents the basis for the decision and records who was consulted.
Submission approval: A named approver signs off the content, including whether the incident may be malicious and whether it may have cross-border impact.
Awareness record: The team keeps timestamps for detection, triage and escalation so the 24-hour window can be shown.
Contacts and channels: The team confirms the national CSIRT or competent authority, the submission channel and the fallback route before an incident happens.
Drills: Management takes part in exercises so the approval path works under time pressure.

Before relying on this split, confirm with your national CSIRT or competent authority which channel and form they accept.

Questions buyers ask about the 24-hour early warning

How much effort does the 24-hour early warning take?

The early warning is deliberately short, so the effort is mainly in being ready to send it, not in writing a long report. Recital 102 says it should contain only the information needed to make the CSIRT or authority aware and let the entity seek help, and should not divert resources from handling the incident. The effort that drives the work is how quickly your team can establish that a significant incident exists, who has authority to submit, and which submission channel your national CSIRT uses. Those decisions are easier to make in advance than during an incident.

Can we meet the 24-hour deadline with in-house staff?

Yes, in principle, if your staff can detect and classify an incident quickly and have a documented submission route. The 24-hour clock starts when the entity becomes aware of a significant incident, so the practical risk is slow detection, slow escalation or unclear criteria for deciding significance. Test this with a tabletop exercise that starts at a realistic alert and times how long it takes to reach a submission decision. If that test shows gaps in out-of-hours coverage, close them with an on-call rota before you rely on in-house staff alone.

What does the early warning need from management and the incident team?

Management needs to approve who may make the submission and to accept that an early warning can be filed on partial information. The incident team needs to tell management promptly when an incident may meet the significance criteria, and to hold the facts needed for a short statement. In practice this means:

A named decision maker with authority to submit outside business hours
A written trigger describing when an incident is treated as potentially significant
A short template covering whether the incident may be caused by unlawful or malicious acts and whether it may have cross-border impact
Records that show when the entity became aware of the incident

What can a managed SOC take on, and what must stay with us?

A managed SOC can detect, triage and escalate alerts, and it can run the first steps of the timeline needed to support a submission. It cannot decide that an incident is significant on your behalf or accept legal responsibility for the report, because those decisions sit with the entity under NIS2. Agree in the contract who receives the escalation, how quickly the SOC must call your decision maker, and who holds the submission channel credentials. Ask the provider to show how its alerts map to your reporting trigger.

How does the early warning relate to the 72-hour notification and GDPR breach notice?

The early warning is the first of three steps, and the 72-hour incident notification updates it with an initial assessment of severity, impact and any indicators of compromise. A single incident can also be a personal data breach, which may trigger a separate notice under GDPR. Keep one incident record from the start so each submission uses the same facts, and check the dates for each regime separately because the clocks do not run from the same events. Where the same incident is reportable under more than one law, confirm with your counsel and the authority how the submissions should be coordinated.

What should we confirm with the national CSIRT or competent authority?

Confirm the reporting channel, the required format, which body receives the notice, and whether your Member State routes reports through the CSIRT or through a competent authority. Under Article 23(1), notifications go to the national CSIRT or, where the Member State provides, to the competent authority, which forwards them to the CSIRT. Ask whether a technical reporting tool exists, what identifiers the authority expects, and what feedback you should expect in return. Because national transposition laws differ, treat these answers as the authoritative detail for your organization.

Which open-source tools help us spot and record a significant incident in time?

Wazuh and OpenSearch Security Analytics can generate alerts from collected logs, and Shuffle can automate parts of the first response. DFIR-IRIS keeps the case record, including assets, indicators, tasks and a timeline with an audit trail, so the facts behind the early warning are in one place. These tools produce the evidence and timing records, but they do not decide significance or submit the report. Confirm the detection rules and alert routing in your own environment before relying on them, and test them against a sample incident.

How DeployOpen prepares the early warning process and its evidence

DeployOpen helps regulated entities prepare the systems, runbooks and evidence needed to submit an early warning within 24 hours of becoming aware of a significant incident. The organization keeps ownership of the reporting decision and the submission, while DeployOpen builds and documents the self-hosted tooling and records that make the early warning fast and defensible.

How we scope

Engagements are fixed-scope, with the early warning use cases, systems and log sources agreed in writing before work starts.
The written scope names who decides that an incident is significant and who submits the early warning to the CSIRT or authority.
Ongoing support, upgrades and continuous testing are available as a retainer after the initial build is delivered.

How we build

We deploy self-hosted case management, detection and workflow platforms inside your own cloud accounts, data centers or air-gapped networks.
We write an early warning template covering suspected malicious activity and possible cross-border impact, kept to the minimum information needed.
We configure alert routing and case creation so that the 24-hour clock start is recorded and visible to the responsible person.

How we hand over

We deliver the runbook, contact lists and reporting templates, and test each step in a tabletop exercise with your team.
We document how each case record, timeline and audit trail supports the early warning and the later notification.
We confirm with your legal and compliance teams which national CSIRT or competent authority channel applies before handover.

How we support

We can run the early warning process in live exercises and review the evidence each drill produces with your incident team.
Retainers cover platform upgrades, rule tuning and periodic testing of the reporting path against changes in your environment.
Your auditors or supervisors assess the process and its evidence independently, and DeployOpen does not issue reports or certificates.

Article 23(4)(a) Early warning within 24 hours