NIS2's 24-Hour Early Warning Requirement: How to Actually Meet It
The 24-hour early warning obligation in NIS2 is the requirement most security teams are least prepared to meet. Many have read the directive, however few have pressure-tested their detection capability against it.
Under Article 23 of EU Directive 2022/2555, organizations in scope have 24 hours from the moment they become “aware” of a significant incident to file an early warning with their national competent authority. They have 72 hours to submit a full incident notification. And within one month, a final report is due.
That first 24-hour window is where most organizations are going to run into trouble. Filing a credible early warning requires infrastructure context that traditional threat intelligence was never designed to provide.
NIS2 covers more than you think
NIS2 applies to a significantly wider range of sectors than its predecessor. Energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, public administration, and space are all in scope. If you operate critical infrastructure or essential services anywhere in the EU, the directive applies to you.
The “significant incident” threshold is defined broadly. An incident qualifies if it has caused or is capable of causing severe operational disruption, financial loss, or material or immaterial damage to other entities. That is a low bar. Most organizations will cross it before they realize they have.
The phrase “becoming aware” is doing a lot of work in that 24-hour obligation. In practice, security teams become aware of an incident when an alert fires in their SIEM. By that point, the attacker has already been operational for some time.
The personal liability piece is worth flagging separately. Under NIS2, management bodies can be held personally liable for infringements. Senior executives are required to approve cybersecurity risk management measures and can face sanctions if their organization fails to comply. For most security leaders, that changes the conversation with the board significantly.
Assess your readiness across all three NIS2 windows
The NIS2 Incident Reporting Readiness Checklist covers detection capability, the 24-hour early warning, the 72-hour full notification, and the 30-day final report. Use it to find the gaps before an incident opens the clock.
The problem with reactive detection
Most security teams are running on IOCs: fragmented, point-in-time indicators that document what an attacker used, pulled from third-party feeds, and often stale by the time they arrive. A domain hash from a breach last month. An IP address that has since rotated. A file signature from a campaign that has already moved on.
IOCs tell you what happened. They rarely tell you who built the infrastructure, when they built it, what else they registered at the same time, or what is sitting dormant waiting to be activated. For day-to-day detection that gap is manageable. For NIS2 incident reporting, it creates a real problem.
Regulators expect your early warning to contain meaningful initial information: the nature of the incident, the systems affected, and a preliminary assessment of scope. That requires you to understand the full infrastructure picture, not just the indicator that fired the alert. Third-party IOC feeds were built for a different job.
What the NIS2 24-hour window actually requires from your detection capability
In practice, filing a complete early warning within 24 hours requires your team to already have infrastructure context assembled before the investigation begins. Most incident investigations start from a single indicator and expand outward from there, which takes time the regulation does not give you.
To file accurately, your team needs to answer three questions quickly.
- What infrastructure is involved? The attacker’s staging environment is a cluster of assets: domains registered in the same batch, IPs sharing hosting patterns, certificates rotating on the same schedule. A single IOC shows you one node. NIS2 requires you to account for the cluster.
- How long has this been active? Regulators will want to know when the incident began, not just when you detected it. If you cannot reconstruct the timeline from your own data, your notification will be incomplete.
- What else is connected? Campaign infrastructure is built with redundancy. If you report on what you found and miss the rest, you risk having to revise or resubmit as more surfaces, which carries its own regulatory exposure.
How preemptive detection changes the compliance picture
The Silent Push Context Graph aggregates DNS, WHOIS, certificate data, host scans, traffic sensor data and behavioral fingerprints across the full IPv4 and IPv6 range, every day. It maps the relationships between internet assets continuously, so when an incident indicator surfaces, the infrastructure connected to it is already correlated.
Your analyst is not starting from a single stale IOC and manually pivoting across fragmented tools trying to reconstruct a picture under a 24-hour deadline. The related infrastructure cluster is already mapped. DNS history and WHOIS records show when it was first stood up. Dormant assets connected to the same campaign are visible.
At T+24, your notification goes in with an infrastructure map and a preliminary timeline attached. At T+72, the full footprint is documented with an accurate start date confirmed. At 30 days, the report reflects what actually happened, with TTPs logged and management sign-off recorded.
The average detection lead time across Silent Push customers is 104 days. For NIS2 purposes, that means the infrastructure behind a significant incident is often visible and already correlated long before an alert fires.
NIS2, agentic workflows, and the data quality problem
A lot of teams are now looking at automating parts of incident response, and the 24-hour window is an obvious candidate. The problem is that automation is only as good as the data it runs on. An AI agent triaging an incident or drafting an early warning needs infrastructure context it can act on with real confidence. Feed it fragmented, stale IOC data and you get unreliable outputs at exactly the moment reliability matters most.
The Context Graph was built to be machine-consumable from day one: 250+ API endpoints, deterministic attribution, and clear confidence signals that give automated workflows something solid to act on. For teams building agentic pipelines, that matters a lot.
The EU AI Act (Regulation 2024/1689) adds a separate obligation for organizations deploying AI-assisted security systems. High-quality, verifiable inference data is an explicit requirement. Silent Push infrastructure data carries full provenance, which directly supports that for teams building automated detection and response into their stack.
What good looks like
When an incident is confirmed, your team should be able to pull up a correlated infrastructure map, establish when the staging environment was first built, identify connected assets including dormant ones, and have a credible draft early warning ready well within the 24-hour window. The investigation is not starting from scratch. It is starting from a picture that has been building continuously in the background.
At the 72-hour mark, the full cluster is documented, the timeline is accurate, and containment covers everything the attacker built, not just the subset that surfaced during the active incident. At 30 days, the final report has no gaps that require explanation.
Security teams that get there consistently have one thing in common: the underlying infrastructure data is correlated, current, and complete before the incident ever surfaces. Talk with our team to learn more.
What sectors does NIS2 apply to?
NIS2 applies to essential and important entities across energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, and space. It also covers a wider range of digital service providers than NIS1, including managed service providers and cloud platforms.
What counts as a “significant incident” under NIS2?
An incident is significant if it has caused or is capable of causing severe operational disruption to the provision of services, financial loss to the entity, or material or immaterial damage to other natural or legal persons. Organizations should assess whether the threshold is met as early as possible, rather than waiting for confirmed damage.
How does Silent Push help meet the 24-hour early warning obligation?
The Silent Push Context Graph pre-correlates attacker infrastructure data across DNS, WHOIS, certificate records, and host scan data continuously. When an incident indicator surfaces, the related infrastructure cluster is already mapped. Investigation that would otherwise take hours of manual pivoting across tools completes in minutes, giving teams the context they need to file a credible early warning within the required window.
Does Silent Push cover third-party ICT risk monitoring for NIS2?
Yes. The Discover Shadow IT query surfaces unmanaged third-party services connected to your domain. Active tracking monitors providers like Mailchimp, SendGrid, and similar platforms for signs of weaponization. Brand impersonation detection identifies lookalike domains and fake login pages at registration. These capabilities directly support the supply chain risk monitoring obligations under NIS2.
