NIS2 Digital Infrastructure: The 30-Minute Incident Rule Nobody Configured For

An RMM platform goes down at 09:14 on a Tuesday. The provider restores it at 09:48. Thirty-four minutes, a handful of annoyed customers, a credit note, done.

Except it isn't done. Under Commission Implementing Regulation (EU) 2024/2690, that outage is a significant incident, and the 24-hour early warning clock started the moment the provider knew.

This is the part of NIS2 digital infrastructure compliance that consultants keep underestimating. For the entity types covered by CIR 2024/2690, the vague language of Article 21 has already been replaced with numbers. Minutes. Percentages. Your client does not get to argue about what "appropriate and proportionate" means when the regulation has told them exactly what it means.

Digital infrastructure is the one NIS2 sector that does not negotiate Article 21

NIS2 is a directive. It needed 27 national transposition laws, and those laws arrived late, uneven, and in some cases still have not arrived at all.

CIR 2024/2690 is a regulation. It was published in the Official Journal on 18 October 2024 and applies directly in every member state. No transposition. No national interpretation layer. Where it specifies a requirement, that requirement applies — regardless of what the local NIS2 act does or does not say.

Its Annex breaks Article 21(2) into 13 requirement groups with numbered sub-requirements. Point 11 alone splits access control into access rights management, privileged accounts, administration systems, unique identification, authentication, and multi-factor authentication. The drafters leaned on ISO/IEC 27001, ISO/IEC 27002, ETSI EN 319 401 and CEN/TS 18026:2024, so an existing ISMS gets you part of the way — but the mapping is not one to one, and the gaps are where audits land.

Article 21 — 10 NIS2 Cybersecurity Measures
🛡️
Article 21
10 Cybersecurity Measures
📊
Governance & Strategy
1Risk analysis & information security policies
6Effectiveness assessment of security measures
🚨
Incident & Continuity
2Incident handling & notification
3Business continuity & disaster recovery
🔗
Supply Chain & Systems
4Supply chain security
5Security in network & information systems development
🔐
Technical Controls
8Cryptography & encryption
10Multi-factor authentication & secure communications
👥
People & Assets
7Cyber hygiene & training
9HR security & access control

If your client is not one of the covered entity types, this still matters. CIR 2024/2690 is the most granular official statement of what the Commission thinks Article 21 compliance looks like. Supervisory authorities assessing an energy or healthcare client will read it. So should you. See our breakdown of the ten Article 21 measures for the directive-level view.

Eleven entity types are covered, and size thresholds do not rescue most of them

The regulation names its subjects in Article 1:

• DNS service providers
• TLD name registries
• Cloud computing service providers
• Data centre service providers
• Content delivery network providers
• Managed service providers
• Managed security service providers
• Providers of online marketplaces
• Providers of online search engines
• Providers of social networking services platforms
• Trust service providers

Two things consultants get wrong here.

First, DNS service providers, TLD name registries and trust service providers are in scope under NIS2 Article 2(2) regardless of headcount or turnover. A four-person DNS operator is in scope. The size-cap rule that saves small companies in most sectors does not apply to them.

Second, "managed service provider" is defined broadly in Article 6(39) of the directive: an entity providing services related to the installation, management, operation or maintenance of ICT products, networks, infrastructure, applications or any other network and information systems, delivered on customer premises or remotely. That is most of the MSP market, and a good number of firms that describe themselves as "IT support" or "development partners" without ever using the word managed. If you are reading this as a consultant, check whether it describes you before you check whether it describes your clients — our guide to NIS2 for MSPs covers the double obligation in detail.

Jurisdiction is the next trap. Digital infrastructure entities are generally supervised where their main establishment sits, not where their customers are. If you are not certain which regulator supervises your client, read our piece on Article 26 before you assume.

The significance thresholds are clocks, not judgement calls

This is where CIR 2024/2690 diverges hardest from how most organisations currently run incident triage.

Article 3 sets horizontal criteria that apply to every covered entity. An incident is significant if it has caused or is capable of causing direct financial loss above EUR 500,000 or 5% of the entity's total annual turnover in the preceding financial year, whichever is lower. Also if it can cause exfiltration of trade secrets. Also if successful, suspectedly malicious and unauthorised access occurred that is capable of causing severe operational disruption — and Recital 39 makes clear that a threat actor pre-positioning itself for later disruption counts, even with no disruption yet.

Then come the entity-specific criteria:

Cloud computing providers (Article 7) — complete unavailability for more than 30 minutes. Limited availability for more than an hour affecting more than 5% of Union users or more than 1 million Union users, whichever number is smaller. Any compromise of data integrity, confidentiality or authenticity from suspected malicious action, with no user-count floor at all.

Data centre providers (Article 8) — complete unavailability of a data centre service, full stop, with no duration qualifier. Limited availability for more than an hour. Compromise of data from suspected malicious action. And compromised physical access to the facility, which means a tailgating incident at the mantrap is a reportable event.

MSPs and MSSPs (Article 10) — complete unavailability for more than 30 minutes. Limited availability for more than an hour affecting more than 5% or 1 million Union users, whichever is smaller. Data compromise from suspected malicious action.

Note how the user counts work. Under Article 3(3), you count contracted customers and the natural and legal persons associated with business customers who use the service. An MSP with 60 client companies is not counting 60 users. It is counting every employee at those 60 companies who touches the managed service.

Article 4 closes the last gap: recurring incidents that individually fall below threshold are aggregated and treated as a single significant incident where they collectively meet the criteria within a six-month window. Three separate 20-minute outages from the same root cause are not three non-events.

NIS2 Incident Reporting Timeline
24h
⚡
Early Warning
Notify the competent authority (CSIRT/NCA) within 24 hours of becoming aware of a significant incident.
Step 1
72h
📋
Incident Notification
Submit a detailed notification within 72 hours with an initial assessment of severity, impact and indicators of compromise.
Step 2
1mo
📊
Final Report
Deliver a comprehensive final report within one month covering root cause, remediation taken and cross-border impact.
Step 3
24h
⚡
Early Warning
Notify the competent authority (CSIRT/NCA) within 24 hours of becoming aware of a significant incident.
72h
📋
Incident Notification
Submit a detailed notification within 72 hours with an initial assessment of severity, impact and indicators of compromise.
1mo
📊
Final Report
Deliver a comprehensive final report within one month covering root cause, remediation taken and cross-border impact.

The reporting deadlines themselves have not changed — 24 hours for the early warning, 72 hours for the incident notification, one month for the final report. What has changed is how often the clock starts. We cover the mechanics in NIS2 incident reporting deadlines.

Scheduled maintenance is exempt, but only if you can prove it was scheduled

Article 3(2) excludes scheduled interruptions and the planned consequences of scheduled maintenance. Recital 33 extends that to non-availability based on pre-agreed contractual arrangements.

That exemption is only as good as your records. Recital 34 says the duration of an availability incident runs from the disruption of proper service provision to recovery — and where the entity cannot determine when the disruption began, duration is measured from the moment it was detected, or from the moment it was recorded in logs, whichever is earlier.

Read that again from an auditor's seat. Poor logging does not produce the benefit of the doubt. It produces the earliest defensible start time. An entity with weak monitoring will systematically report longer incidents than one with good monitoring, for exactly the same outage.

So the practical control here is not a policy document. It is a maintenance calendar that is timestamped, approved in advance, and retained — plus monitoring that can establish a start time to the minute.

"Not applicable" is allowed, but it has to be written down

Recital 6 gives entities room to conclude that a specific Annex requirement is not appropriate, not applicable, or not feasible for them. Recital 5 allows compensating measures where size makes a requirement impractical — a micro entity that cannot segregate conflicting duties can substitute targeted management oversight or increased monitoring and logging.

Both carry a condition: the entity must document its reasoning in a comprehensible manner.

This is the single highest-value deliverable a consultant can produce for a digital infrastructure client this quarter. Not another policy template. A written, dated, management-approved applicability statement that walks the 13 Annex points, records which sub-requirements are implemented, which are not, and why — with the compensating measure named where one is used.

Authorities do not expect a 12-person MSSP to look like a hyperscaler. They do expect the entity to have thought about it on paper before the audit, not during it. Our evidence checklist for supervisory audits covers what else regulators ask to see.

What to do in the next 30 days

1. Classify. Determine whether each client — and your own firm — falls into one of the eleven Article 1 entity types. Apply the Article 2(2) size-cap exemptions before you apply headcount thresholds.
2. Recalculate user counts. Rebuild the Union user figure for every covered service, including end users at business customers. Most entities are working from a number that is an order of magnitude too low.
3. Reset the triage rules. Put the 30-minute and one-hour thresholds into the monitoring platform as alert conditions, not as after-the-fact review criteria. If a human has to notice the threshold was crossed, it will be noticed late.
4. Fix the maintenance record. Scheduled windows approved and timestamped in advance, retained for at least the supervisory period.
5. Write the applicability statement. Thirteen Annex points, sub-requirement by sub-requirement, with reasoning for every exclusion.

The entities covered by CIR 2024/2690 sit upstream of everyone else's compliance. When an MSP or a cloud provider fails an audit, the finding travels down the supply chain into every client contract that named them as a critical supplier — which is the other reason to get this right now rather than after the first enforcement decision lands.

If you want a structured picture of where a client stands against Article 21 and the implementing regulation before you commit to a remediation plan, run a NIS2 quick scan. It takes a few minutes and gives you a defensible starting point for the conversation.