Significant incident at a data centre: the threshold is one hour

In most specifications, a service disruption is “significant” whenever someone judges it to be: the client complains, the supplier plays it down, and the gap between the two stays contractual. Commission Implementing Regulation (EU) 2024/2690, for anyone running a data centre, closes that discretion with a measure: one hour. Not “a prolonged disruption” — a number you read off a clock, from the start of the limitation to its end. Above that threshold, the disruption stops being a matter between supplier and client and becomes an obligation towards the authority.

A directly applicable regulation, for a precise list of entities

Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 gives effect to Directive (EU) 2022/2555 — NIS2 — as regards the technical and methodological requirements of cybersecurity risk-management measures and the further specification of when an incident is significant. It addresses a precise list: DNS service providers, top-level domain name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers. It is signed by Commission President Ursula von der Leyen, enters into force twenty days after publication in the Official Journal, and is “binding in its entirety and directly applicable in all Member States”. It repeals Regulation (EU) 2018/151.

Whether an entity falls within these categories, and which bodies in Italy count as essential or important, must be checked against NIS2 and its transposition — not assumed from running a server room. From that qualification follow notification obligations, with tight deadlines set by the directive, not this regulation.

Article 8: four criteria, and one is enough

It is worth quoting in full, because every letter carries weight (our translation from the verified Italian text): “Article 8 — Significant incidents regarding data centre service providers. As regards data centre service providers, an incident shall be considered significant pursuant to Article 3(1), point (g), where it meets one or more of the following criteria: (a) a data centre service of a data centre operated by the provider is completely unavailable; (b) the availability of a data centre service of a data centre operated by the provider is limited for a period exceeding one hour; (c) the integrity, confidentiality or authenticity of data stored, transmitted or processed in connection with the provision of a data centre service is compromised due to an action suspected to be malicious; (d) physical access to a data centre operated by the provider is compromised.” Four independent criteria: one is enough.

(a) Complete unavailability — the total blackout of a data centre service.
(b) Availability limited beyond one hour — this is the letter that really shifts the perimeter: degradation counts too, not only total outage. Seventy minutes of degraded service meets this criterion; a fifty-minute complete blackout does not, under this letter.
(c) Integrity, confidentiality or authenticity compromised — a suspicious data access is significant while the service keeps running.
(d) Physical access compromised — a forced door, a gate left open, a badge used by the wrong person: cybersecurity without a single byte touched.

The criteria that apply regardless, and the maintenance that does not count

Article 8 does not replace the general criteria of Article 3, which apply regardless. Among the most direct for anyone counting the cost of a facility: a financial loss “exceeding EUR 500 000 or, where that amount is lower, 5% of its total annual turnover in the preceding financial year”; “the exfiltration of trade secrets, as defined in Article 2, point (1), of Directive (EU) 2016/943”; the death of a natural person, or “considerable damage to the health of a natural person”; or “unauthorised access to network and information systems has occurred, which is suspected to be malicious and is capable of causing severe operational disruption”. Added to these are the references to Article 4 and to Articles 5 to 14 — Article 8 among them.

One clarification heads off a false alarm, written into the same Article 3: “Planned interruptions of services and the expected consequences of planned maintenance operations carried out by or on behalf of relevant entities shall not be considered significant incidents.” A properly agreed maintenance window, however long, triggers nothing, provided it really is planned.

How we check it

When we write or review a specification for a data hall, the one-hour threshold does not stay an abstract reference: we turn it into a contractual definition, naming the triggering event and the instrument that measures it. We check that physical access is logged in a traceable way — who, when, with what authorisation — and that a fault log with root cause already exists from day one: it is the only way to apply Article 4. At acceptance we check the declared measurement tools exist, not left as a promise on paper.

See the service · Talk to an engineer

Article 4: when two minor incidents make one significant one

What remains are incidents that, taken individually, do not cross any threshold: “Incidents which are not individually considered to be a significant incident pursuant to Article 3 shall be considered collectively as a single significant incident where they meet all of the following criteria: (a) they have occurred at least twice within a period of six months; (b) they have the same apparent root cause; (c) they collectively meet the criterion referred to in Article 3(1), point (a).”

Three cumulative conditions, not alternative ones: all three are needed together. The practical point sits in letter (b): noticing two events share “the same apparent root cause” requires a log that records that cause, not just the date. Without one, three micro-events over six months stay disconnected lines — and no one notices they have become one significant incident.

Where the hour starts counting, and who decides it is “limited”

The regulation leaves open questions the specification has to close. Where does the hour start counting: from the moment the alarm triggers, from when monitoring detects the degradation, or from the first user ticket? If the hour is reconstructed after the fact from tickets, that is not a measurement, it is a guess made later — the same flaw sits inside an availability clause with no declared MTTR. Who decides availability is “limited”, and at what threshold: the regulation does not say — the specification has to, with a measurable threshold agreed in advance, not judged afterwards by whoever is affected. A compromised physical access leaves a trace only if the access-control system logs it, not if someone notices on a patrol.

Checklist: what to write into the specification, what to check at acceptance

define contractually which event starts the hour counting, and with what instrument it is measured;
set a measurable, agreed threshold for “limited availability”, not left to the judgement of whoever is affected;
require physical access to be logged so that, months later, it can be shown who entered, when, and with what authorisation;
keep a fault log with root cause and date — it is the only way to actually apply Article 4;
at acceptance, check the declared measurement tools exist and are the ones promised, and the log is already populated from day one.

Both axes matter here more than elsewhere. Comply: thresholds, measurement points and access logging stop being general principles and become verifiable lines in the specification and acceptance-test points, with the evidence to produce. Decide: traces, measurements and as-built records stop being scattered files and become a single map on which an AI makes the diagnosis and the team acts, together with CSIDIA, the group’s other company — the same logic as the EN 50600 availability classes applies to cabling and to physical access. The root-cause fault log is not only for Article 4: the same data shows whether a degradation is repeating on the same branch, before the sum crosses the threshold. Always on-premise, on autonomous machines needing no deep integration into the client’s network, or dedicated cloud with a data centre in Italy; always shared management, across the data centres we work with.

Do you need to check whether your data centre falls within the regulation’s scope, or turn the one-hour threshold into a line in a specification? Talk to an engineer: the first session is free of charge.