IR 2024/2690 significant incident thresholds by entity type

Which significant incident thresholds apply to your digital service?

If you run a digital service in scope of NIS2, the first question after an outage is whether it is reportable at all. Articles 5 to 14 of Commission Implementing Regulation (EU) 2024/2690 answer that question with quantified thresholds for each entity type, from DNS and TLD registries to cloud, data center, CDN, managed service, online platform and trust service providers. The thresholds exist so that authorities receive reports on incidents with real effect on users and on the integrity of services, not on every fault. Each threshold combines a duration, a degree of unavailability and, for most types, a share of EU users or a fixed user count. For example, a cloud or managed service outage that is completely unavailable for more than 30 minutes can be significant on its own, while a limited outage counts only when it lasts beyond one hour and crosses the user limit. A compromise of data integrity, confidentiality or authenticity caused by a suspected malicious action is significant for those provider types regardless of user numbers.

Three points usually make the decision hard. The first is measuring user counts. The regulation counts customers whose contracts give access to the service, plus the people associated with business customers who use it, so your user base may be larger than your active account data suggests. Confirm now which identity, tenant or licensing records give you that figure, and whether you can produce it within hours. The second is defining the service boundary. Thresholds apply to a specific service, so you need a written inventory that maps each customer-facing service to its entity type and to the components whose failure makes it unavailable. The third is proving the clock start, since reporting deadlines run from the moment you become aware of a significant incident. Your monitoring, alert routing and on-call logs should show when awareness occurred. Agree these three elements with your supervisor-facing team before an incident, and test them in an exercise.

Before you rely on any threshold, check the exact article for your entity type in the regulation text, and confirm the interpretation with your national competent authority or CSIRT, since the reporting mechanics are set nationally. Treat the thresholds as the minimum test your incident process must run, not as a substitute for judgment about incidents that fall below them but still compromise your services.

Which entity types carry their own thresholds under IR 2024/2690

Implementing Regulation (EU) 2024/2690 sets separate significant incident thresholds for each digital entity type it covers, and the articles differ in their time limits, user measures and whether a compromise counts regardless of scale. Organizations should first confirm which entity type each service falls under, then apply every relevant threshold rather than a single generic one.

DNS service providers

Article 5 sets the threshold for recursive and authoritative resolution services. An incident is significant if a service is completely unavailable for more than 30 minutes, or if average response time exceeds 10 seconds for more than one hour. Check each resolver and authoritative service separately, because a partial outage of one service can still cross the response-time line while others stay up.

TLD name registries

Article 6 applies a stricter test to top-level domain registries. Any complete unavailability of an authoritative resolution service is significant, with no duration threshold, and so is an average response time above 10 seconds for more than one hour. Registries should confirm that monitoring alerts on the first minute of a full outage, not only after a sustained window.

Cloud computing providers

Articles 7 and 9 apply to cloud and to managed service providers. A complete outage over 30 minutes is significant, as is a limited outage affecting more than 5% or more than 1 million EU users for over one hour, whichever figure is smaller. Providers running several services with different availability definitions must measure each service on its own terms.

Data center service providers

Article 8 covers data center services and adds a physical dimension. Complete unavailability of a data center service, limited availability for more than one hour, or compromised physical access to a facility is significant. Operators should confirm that physical access events are logged and routed into the same incident process as network outages.

CDN and managed security providers

Articles 7 and 10 set the same user-based test for content delivery networks, managed service providers and managed security service providers. A complete outage over 30 minutes or a limited outage affecting the smaller of 5% or 1 million EU users for more than one hour is significant. Managed security providers serving many customers should count users across all contracted tenants, since those figures decide significance.

Online platforms and trust services

Articles 11 to 14 cover online marketplaces, search engines, social networks and trust service providers, with trust services held to the tightest limits. Trust service providers face a complete outage over 20 minutes and more than one hour of unavailability per calendar week. A group that operates a cloud service and a marketplace must apply both the cloud and the platform sets.

How the outage and user-count thresholds differ by entity type

DNS service providers and TLD name registries face different triggers under Implementing Regulation (EU) 2024/2690. For a DNS service provider, the regulation looks at recursive and authoritative resolution services. A complete outage of either service lasting more than 30 minutes is significant under Article 5, and so is an average response time above 10 seconds lasting more than one hour. The regulation does not set a limited-availability percentage for DNS providers in the supplied criteria, so teams should confirm how their own degraded states map to these triggers.

TLD name registries are held to a stricter test under Article 6. Any complete unavailability of an authoritative resolution service is significant, with no minimum duration. The response time trigger is the same as for DNS providers: an average above 10 seconds for more than one hour.

Complete unavailability, DNS (Article 5): a recursive or authoritative resolution service down for more than 30 minutes.
Response time, DNS (Article 5): average response time above 10 seconds for more than one hour.
Complete unavailability, TLD (Article 6): any complete unavailability of an authoritative resolution service, with no duration threshold.
Response time, TLD (Article 6): average response time above 10 seconds for more than one hour.
User condition: the Article 6 TLD trigger is not tied to a user count, so a registry should not wait for user numbers before deciding whether to assess reportability.

Check whether your authoritative and recursive services are monitored separately, because each has its own clock.

How to count affected users and when integrity compromise is always significant

For the percentage-or-absolute thresholds that apply to cloud, CDN, managed service and online platform providers, the count that matters is the number of EU users affected, and the Implementing Regulation's test takes the smaller of two figures: a share of users or an absolute number. The user base for this purpose is wider than the paying customer list. Under Article 3(3) of NIS2, it includes customers whose contracts give them access to the services and the persons associated with business customers who use them. In practice, your count must cover the contracted tenants, the named and unnamed users inside those tenants, and any downstream users reaching the service through them. Confirm with counsel how your contracts define access, because a narrow definition can understate the base and misplace you against the threshold.

Compromise of integrity, confidentiality or authenticity is treated differently. For cloud, data center, CDN, managed service and online platform providers, a compromise caused by a suspected malicious action is significant regardless of the number of users affected, so the user count does not settle the question. The decision you need to make early is whether the trigger is suspicion, not proof. Your incident runbook should record who can declare a suspected malicious compromise, on what evidence, and how quickly that declaration is escalated to the reporting owner, so that the 24-hour clock is not lost while the team waits for forensic confirmation.

Records decide how defensible a count is. A figure reconstructed weeks later from billing exports and recollection is weaker than one taken from telemetry captured during the incident, because the auditor or supervisor can test it against logs. Keep per-tenant and per-user session counts, authentication and API access logs, and service health data with timestamps, retained long enough to cover the reporting window and the final report. Metrics platforms such as Prometheus and Grafana Alerting can hold the availability and error-rate series that show duration and scope, and a case management tool such as DFIR-IRIS can store the evidence trail. Confirm your log retention settings and whether they can reproduce user-level scope before an incident forces you to rely on them.

How an assessor tests significant incident thresholds

This table sets out what a competent authority or independent auditor examines for each threshold test, what evidence it asks for, and where entities most often fall short. Read it as a checklist of the records you need before an assessment starts. The entity owns the significance decision, so the file must show how that decision was reached, including for incidents judged not significant.

Test area	What the assessor examines	Evidence requested	Common findings
Documented threshold mapping per service	Whether each service in scope is matched to the threshold article that applies to its entity type, such as DNS, TLD, cloud, data center, CDN, managed services, online platforms or trust services	Threshold mapping document per service, with entity type, applicable article and named owner, approved by the management body	Single generic incident definition used for all services, or a service catalog that does not match the mapping
Measurement method for outage duration and response time	How outages and response times are detected, timed and calculated, and whether the method matches the duration tests in the implementing regulation	Monitoring configuration, alert rules, query definitions, and samples of raw metrics showing start and end of unavailability	Outages timed from ticket creation rather than from the first failed check, or response time averaged over a window that does not match the rule
User count derivation	How affected EU users are counted, including customers with contract access and persons linked to business customers, and whether the smaller of the percentage or absolute figure was applied	Method note, user population extract for the affected period, and calculation worksheet with timestamps	No stored count for the affected period, or counts that omit business users and their associated persons
Decision record for a sample of incidents	Whether each sampled event was assessed against the criteria, with reasons recorded for both significant and not significant outcomes	Decision log entries with date, assessor, criteria tested, data used and sign-off, for incidents judged significant and not significant	Only reportable incidents are documented, so the assessor cannot test the negative decisions
Integrity compromise classification	Whether a suspected malicious compromise of integrity, confidentiality or authenticity was identified and classified as significant regardless of user numbers for in-scope provider types	Classification procedure, triage records, forensic notes and the reasoning that separates malicious action from accidental fault	Compromises classified only by user impact, or suspected malicious events left unclassified while the investigation is open
Clock start recording	When the entity records becoming aware of a significant incident, and whether that time is consistent across tickets, logs and reports	Timeline showing first detection, triage and awareness times, with source system timestamps and time zone handling	Clock started at the moment a report was filed, or timestamps that differ between the ticketing tool and the SIEM

Implementing the thresholds in your monitoring and incident process

This sequence turns the Article 5 to 14 thresholds into a service register, measurable alert rules and a signed significance decision that your team can apply within the reporting clock. Each step leaves a written output that an assessor or national authority can inspect.

Inventory each digital service and its entity type
Start by listing every digital service your organization operates or provides to others, such as DNS resolution, cloud hosting, a CDN, a managed service, an online marketplace or a trust service. For each one, record which entity type it falls under in Implementing Regulation 2024/2690 and who owns it. The output is a service inventory with an entity type field and a named service owner for each line. Confirm the entity classification with your legal or compliance lead before moving on, because the thresholds differ by type.
Map each service to its threshold articles
For each inventoried service, identify the threshold articles that apply to its entity type, such as the cloud and managed service criteria, the DNS or TLD criteria, the data center criteria or the trust service criteria. Record the complete unavailability, limited availability, response time and integrity conditions that apply, and note where one service falls under more than one article. The output is a service-to-threshold register that a reviewer can trace from each service to the exact criterion. Have the register reviewed against the regulation text, not against summaries.
Define how each measurement is taken
Translate each threshold into a measurement your systems can produce. Define what counts as complete unavailability, how limited availability is calculated, how the average response time is measured and over which window, and how EU user counts are derived, including business customers and the persons associated with them under Article 3(3). Decide where the counting data comes from and who signs off the method. The output is a measurement specification per service, reviewed by the service owner and the incident lead, with the user-count source documented.
Set up telemetry and alert rules over time
Build the telemetry that captures those measurements continuously, then write alert rules that fire when a threshold condition is met over the required duration. Open-source options such as Prometheus, which stores metrics as time series and queries them with PromQL, and Grafana Alerting, which builds rules across multiple data sources, can produce this evidence in a self-hosted setup. Test that each rule evaluates the duration conditions correctly and that the time series retains enough history to reconstruct the event. The output is an alert rule specification and a test record for each rule. Confirm with your platform team that the chosen tools meet your retention and data residency needs.
Document the significance decision procedure with a named owner
Write a procedure that describes how an alert becomes a significance decision: who receives it, who checks the measurement against the register, who decides whether the incident is significant, how the decision is recorded, and how the clock for reporting is started. Name one accountable owner and a deputy, and state how the decision is escalated when the owner is unavailable. The output is a signed decision procedure, approved by the management body or by the delegate it designates, with the decision record template attached. Keep the signature and version history so you can show when the procedure was in force.
Test the procedure against a past or simulated outage
Run the full chain once against a real past outage where logs allow, or against a simulated outage in a controlled environment. Check that the alert fires, the measurement matches the threshold definition, the decision record is complete and the reporting clock starts at the right point. Record gaps, such as missing metrics or unclear ownership, and fix them before the next review. The output is a test report with findings, owners and closure dates, which you can present to a supervisor as evidence that the thresholds work in practice. Ask a qualified tester or your security provider to review the test design if you lack internal capacity.

Evidence that proves a significance decision

An assessor who sees an entity decide that an incident was not significant will ask how that decision was reached and whether the thresholds were current on the day. The six records below connect the service inventory, the monitoring data, the user counts, the case file and the review cycle, so each decision can be traced from the threshold to the evidence.

Service-to-threshold register

This register lists each service in scope, its entity type under Implementing Regulation 2024/2690, the threshold article that applies (such as Article 7 for cloud or Article 14 for trust services), and the owner of the measurement. It proves the entity knew which numeric test applied to each service before any incident happened. Check it against the current service catalog every time a service is launched, retired or moved to a new region, and confirm that each row names the metric that will be used to measure the threshold.

Metric and log records

Availability and response time decisions rest on time-stamped measurements. Keep exported alert history, query results and log extracts showing when a service became unavailable, when response time crossed the limit and when it recovered. Prometheus and Grafana Alerting can hold the alert rules and firing history, but the entity must confirm retention is long enough to cover the period an assessor may ask about. Test the export procedure during routine exercises, not first during an incident.

User count derivation

The percentage and one-million-user limits depend on a count of EU users, which must include customers with contract access and the persons associated with business customers who use the service (Article 3(3)). Record the query or report that produced the figure, the data source, the date and the method for counting shared or indirect accounts. Without this derivation, a limited-availability decision cannot be defended. Refresh the count on a fixed schedule so the baseline matches the period in which the outage occurred.

Incident case record and timeline

The case file holds the detection source, the chronology, the affected assets, the threshold test applied and the reasoning for the significance decision. DFIR-IRIS keeps assets, tasks, evidence and an audit trail in one case record and builds a consolidated timeline from alerts. Ask the case owner to record the decision rationale at the time it is made, including why an event was judged not significant. Late edits to the timeline should be logged, not overwritten.

Integrity compromise classification

For cloud, data center, CDN, managed service and online platform providers, a suspected malicious compromise of integrity, confidentiality or authenticity is significant regardless of user numbers. The classification record should show what was compromised, the indicators that pointed to a malicious action, the analysis that ruled out or confirmed it and the reviewer who signed off. Keep the forensic analysis and evidence hashes with the record so the reasoning can be checked later. Confirm with counsel how this record interacts with GDPR breach files.

Threshold review record

Thresholds stay valid only while the service design they measure stays the same. The review record shows the date each threshold was checked, who checked it, which services changed and whether the metric, user count or reporting path was updated as a result. Schedule reviews after material architecture changes, new regions, new customers and any amendment to the regulation or national transposition law. An assessor will expect to see dated entries, not a single approval at go-live.

What meeting the incident threshold requirements costs

This table compares the main cost components of measuring the Implementing Regulation 2024/2690 significant incident thresholds, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. The regulation sets the thresholds but no price, so the costs depend on how many services, entity types and user populations an organization runs. Use the table to build a quote request, and note that open-source tools remove license spend while staff time remains.

Cost component	One-time or recurring	What drives it up	How to keep it down
Monitoring and alerting capacity to measure outage and response time	Recurring (hosting, storage, retention, staff on-call)	Number of services measured, metric and log volume, retention periods, number of data sources	Measure only the services in scope, set retention to what the reporting clock needs, and reuse existing monitoring stacks
Engineering time to map services and build measurement	One-time, with periodic updates	Number of entity types and service lines, legacy systems without instrumentation, unclear service boundaries	Map services to the Annex categories first, then instrument the highest-exposure services before the rest
User count instrumentation for the 5%, 1 million and 200 000 user tests	One-time build, recurring upkeep	Number of user populations, multiple identity systems, business customers whose associated persons must be counted	Use one authoritative identity source, document counting rules once, and automate the daily count
Incident case tooling for timelines, evidence and reporting	Recurring licence or hosting, plus one-time configuration	Number of alert sources, case volume, integration work with SIEM and EDR, evidence handling requirements	Self-hosted open-source case tools remove licence spend, but configuration and staff training remain
Tabletop and decision testing of threshold calls	Recurring (scheduled exercises), one-time scenario design	Number of entity types, number of threshold scenarios, external facilitation, participant count	Run one scenario per threshold family and reuse the same scenario library each cycle
External review of the threshold method	One-time review, optional periodic re-review	Number of services assessed, method complexity, whether the reviewer must test measurements against logs	Ask the reviewer for a fixed-scope written method check, and confirm whether independent auditors or consultants are needed
Staff time for ongoing threshold ownership	Recurring	Number of on-call rotations, number of entity types, frequency of service changes	Assign a named owner for each threshold family and review measurements after major changes

Which open-source tools can produce the threshold evidence

Each significant incident threshold depends on a measured fact: how long a service was down, how many users were affected, or whether data integrity was compromised. The tools below can capture and preserve that evidence, but they do not decide whether an incident is significant. That decision stays with the entity, applying the criteria in Articles 5 to 14 of Implementing Regulation (EU) 2024/2690.

Prometheus for outage and response time records

Prometheus scrapes metrics from instrumented jobs over HTTP and stores them as time series identified by metric name and labels. PromQL queries can express the durations behind the outage and response time tests, such as how long a resolver or service stayed unavailable or how long average response time stayed above a limit. Your team must confirm which metrics each service exposes, how often they are scraped, and whether the retained history covers the full window a regulator may ask about.

Grafana Alerting for threshold detection

Grafana Alerting builds alert rules from queries and expressions across several data sources, so one rule can combine metrics and logs. This lets teams set alerts that match the thresholds in your entity's category, such as complete unavailability beyond 30 minutes or response time above 10 seconds for more than one hour. Grafana is licensed under AGPL-3.0-only, so confirm with counsel how that license applies if you modify and distribute the software or offer it to third parties.

DFIR-IRIS for case records

DFIR-IRIS keeps each incident as one case record that holds assets, indicators of compromise, tasks and evidence, with a full audit trail. It can take alerts from SIEM, EDR and REST sources into cases and build a timeline of the investigation. For reporting, the case record is where the start time, the affected services and the user-impact estimates are kept, so confirm that your team fills these fields consistently at each reporting stage.

DFIR-IRIS evidence integrity controls

DFIR-IRIS logs evidence with SHA-256 verification and maintains a chain of custody. These controls matter when a suspected malicious action compromises integrity, confidentiality or authenticity, because that condition is significant regardless of user numbers. Confirm with your counsel and forensic providers that the hashing and custody records meet the standard your supervisor or litigation team expects.

DFIR-IRIS licensing and deployment

DFIR-IRIS is licensed under LGPL-3.0-or-later, which allows use inside a self-hosted environment, subject to the license terms for any changes you distribute. Because the case store holds sensitive incident data, it should run inside your own infrastructure with access limited to the incident response team. Ask your implementation partner to document backup, retention and access review procedures so the case history remains available for the final report.

Questions buyers ask about significant incident thresholds

How much work does it take to map our services to the significant incident thresholds?

The work scales with the number of services you run, how well each one is instrumented, and how clearly you can measure user impact. For each service in scope, you need a documented availability baseline, a way to count affected EU users or relying parties, and a record of how long any outage lasted. Teams that already have service catalogs, uptime metrics and customer account data usually spend the effort on validating definitions and filling gaps. Teams without those inputs spend most of the effort building them. Ask any partner to list the services, data sources and approval steps in the written scope before pricing the review.

Can a small provider map incident thresholds in-house?

Often yes, if the provider has one or two services, a named owner for availability data and someone who understands the regulation's user-count rules. The main risk is misreading how the thresholds combine, for example the 'whichever is smaller' comparison or the counting of users linked to business customers. A small team can work through the Implementing Regulation article by article for its own sector and record each decision with its reasoning. External help is most useful for checking that reasoning against the regulation and the supervisor's expectations, not for doing the arithmetic. Confirm the exact entity type and sector scope with your national authority or legal counsel first.

What does a threshold review need from management and engineering?

Management needs to approve the criteria, accept the decision rules and own the outcome, because the management body is accountable for the NIS2 risk-management measures. Engineering needs to supply reliable availability and response-time data, explain how services fail and recover, and show how incidents touching data integrity or authenticity would be detected. Customer or product teams need to confirm how many users each service reaches and how contracts grant access. A review stalls when one of these three groups is missing, so name a responsible person in each group before work begins.

How long does a significant incident threshold review take?

No duration is fixed by the regulation for this review, so the timeline depends on the number of services, the quality of existing monitoring data and how quickly decisions are approved. Ask for a timeline in the written scope with named milestones: data collection, threshold mapping, validation by management and a sign-off record. Confirm with your national competent authority whether it expects a specific format or evidence. Any partner that quotes a fixed duration before reviewing your services is guessing, so ask what assumptions sit behind it.

Can an implementation partner decide whether an incident is significant?

No. The entity owns the decision about whether an incident is significant and must make it within the reporting process it operates. An implementation partner can prepare the thresholds as documented criteria, configure monitoring and alerting that produces the measurements those criteria need, and test that the workflow records decisions. Only the organization and its national authority determine reportability in practice. DeployOpen prepares systems and evidence for these assessments; it does not issue reports or certifications, and independent assessors or the competent authority make judgments about compliance.

What should a written scope for a threshold review include?

A written scope should list each entity type and service covered, the thresholds applied to each, the data sources used to measure availability, response time and user impact, and the decision record that management signs. It should also state exclusions, such as services outside the Implementing Regulation, and name who approves each deliverable. Ask for the following in writing:

The inventory of in-scope services and their entity classification
The measurement method and data source for each threshold
The monitoring configuration changes, such as alert rules, and how they will be tested
The management review and sign-off steps
The handover package, with the reasons behind each decision

Ask the partner to confirm which items it will not perform.

How DeployOpen scopes threshold mapping and evidence for NIS2 providers

DeployOpen works with DNS, cloud, data center, CDN, managed service and online platform providers to turn the Article 5 to 14 thresholds into monitoring, alerting and case records that can be tested. We prepare the systems and evidence, while the entity keeps ownership of its reporting decisions and any assessment is performed by the competent authority or an independent assessor.

How we scope

Each engagement starts with a written scope that lists the entity types and services covered by the thresholds.
We map each service to its applicable threshold, including the user-count and duration conditions in Articles 5 to 14.
The scope records which systems hold the availability, user and integrity data needed to test each threshold.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure open-source monitoring, such as Prometheus metrics and Grafana Alerting rules, to detect the thresholds your scope defines.
Alert rules are built to show duration and affected-user counts so that the time-based criteria can be evidenced after the fact.
Case handling in DFIR-IRIS is set up so each suspected significant incident has one record with timeline and audit trail.
Every build is deployed inside your own cloud accounts, data centers or air-gapped networks.

How we hand over

You receive documented threshold mappings that link each service, measurement source and alert rule together.
Test records show how alerts behave against simulated outage and degradation scenarios agreed in the scope.
Runbooks explain who decides whether a threshold is met and how the decision is recorded for the authority.
Your team is trained to operate the tooling, and the documentation stays in your environment.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer for changes to services or thresholds.
When Implementing Regulation 2024/2690 guidance or national rules change, we can review the mappings against the new text.
Ask for the evidence list, test plan and handover package in any quote, and confirm with your authority which records it expects.