Your API Breach Is Reportable Under NIS2 Before You Count a Single Record

When an API leaks data, the first question in almost every incident channel is “how many records?” For an entity in scope of NIS2, that is the wrong question to ask first, and in one important case it is not a question the law asks at all.

Neither the NIS2 Directive nor its implementing regulation contains the word “API”. Both are silent on rate limiting and throttling. What they do contain is a set of general criteria, and an API breach lands on them counter-intuitively: for the eleven categories of digital provider bound by Commission Implementing Regulation (EU) 2024/2690, a data compromise caused by a suspectedly malicious action is a significant incident with no user threshold attached to it at all. The 5% and one-million-user figures that dominate every guide on this topic sit in a different limb — the one for accidents.

ENISA’s Threat Landscape 2025 records vulnerability exploitation as 21.3% of initial access vectors, with 68% of those leading on to malware deployment, against a dataset in which essential entities account for 53.7% of recorded incidents [5]. This article maps an API incident onto the provisions that actually decide it.

NIS2 Never Says “API” — and That Is the Whole Problem

In plain terms: there is no API rule to look up. You have to map what happened to your interface onto general definitions written to be technology-neutral, and the mapping is not obvious.

Searched programmatically against the full Official Journal text of both instruments, “application programming interface” and “API” return zero hits, as do “rate limit” and “throttling” [1][2]. That is design, not oversight. Article 6(1) of the Directive defines a network and information system to include “any device or group of interconnected or related devices, one or more of which, pursuant to a programme, carry out automatic processing of digital data” and the “digital data stored, processed, retrieved or transmitted” by them [1]. An API endpoint, the service behind it, and the records it returns all sit inside that definition. Nothing narrower was needed.

Article 6(6) then defines an incident as “an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems” [1]. Note “confidentiality” sitting level with “availability”. An API that returns other customers’ records while uptime stays at 100% is squarely an incident. So is one that accepts writes it should have rejected, because that engages integrity.

Two consequences follow. A vulnerability in an interface is not an incident: Article 6(15) defines a vulnerability as a flaw that “can be exploited”, a capability, while Article 6(6) requires “an event compromising” something [1]. An unexploited flaw creates no Article 23 duty on its own — covered in more depth in our guide to zero-day disclosure under Article 12. And an attempt your gateway actually blocked is a “near miss” under Article 6(5), an event “successfully prevented from materialising”, which is voluntarily notifiable under Article 30 rather than mandatory.

Which Test Applies to You: The Eleven-Category Fork

In plain terms: two different significance tests exist. Which one you use depends on what kind of entity you are, not on what kind of API broke.

Article 1 of CIR 2024/2690 names eleven categories of entity in total — 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, of online search engines and of social networking services platforms, and trust service providers [2]. For those, the CIR criteria are binding law. For a hospital, a manufacturer, a water utility or an energy operator, they are not.

Your entity	Significance test that applies	Where the numbers live
One of the eleven CIR categories (cloud, MSP/MSSP, marketplace, CDN, DNS, TLD, data centre, search, social, trust services)	CIR 2024/2690 Article 3(1), criteria (a) to (g)	Article 3(1)(a) money; Articles 5 to 14 for your specific category
Any other essential or important entity	Directive Article 23(3), two limbs, plus your national transposition	Nowhere in the Directive — Article 23(3) contains no figure of any kind

That second row is the uncomfortable one, and it is why national guidance matters. Germany’s BSI states that for entities in other sectors it can be assumed a significant incident has occurred where at least one of the Article 3(1) criteria of CIR 2024/2690 is met, adding that a significant incident is always to be assumed where the provision of critical services has failed or been impaired [6]. That is national guidance, not Directive text, and it runs one way only: meeting a CIR criterion is sufficient, but failing to meet one is not a defence, because Article 23(3) still sits underneath.

The Counting Trap: Why Limb (c) and Limb (d) Are Not the Same Test

In plain terms: if an attacker caused it, you do not count users. You count users only when nobody attacked you.

This is where nearly every published guide, and a great many internal runbooks, get the sequence backwards. Take Article 7, the cloud computing criteria, verbatim [2]:

(c) the integrity, confidentiality or authenticity of stored, transmitted or processed data related to the provision of a cloud computing service is compromised as a result of a suspectedly malicious action,

(d) the integrity, confidentiality or authenticity of stored, transmitted or processed data related to the provision of a cloud computing service is compromised with an impact on more than 5 % of that cloud computing service’s users in the Union, or on more than 1 million of that cloud computing service’s users in the Union, whichever number is smaller.

Limb (c) requires a suspectedly malicious action and attaches no user threshold, no percentage and no duration. Limb (d) attaches the 5% and one-million-user test and requires no malicious action at all. They are alternatives, not a two-part test — Article 3(1)(g) makes an incident significant where it “meets one or more of the criteria set out in Articles 5 to 14” [2].

So a BOLA flaw exploited by an attacker who enumerated object IDs and pulled four records from one tenant satisfies limb (c) on the day it is confirmed. The same four records exposed by a misconfigured cache with no adversary behind it goes to limb (d), and four records will not get near 5% of your Union user base. The volume test is the route for accidental exposure; counting first, as a reflex, systematically delays the harder call.

The identical (c)/(d) structure appears in Article 9 (CDNs), Article 10 (managed and managed security services), Article 11 (online marketplaces), Article 12 (online search engines) and Article 13 (social networking platforms) [2]. Data centre providers under Article 8 have the malicious-action limb but no volume limb at all. Trust service providers under Article 14(e) face the strictest bar in the instrument: 0,1% of users or relying parties, or 100 of them, whichever is smaller.

Two further criteria are worth knowing before an incident rather than during one. Article 3(1)(e) makes an incident significant where “a successful, suspectedly malicious and unauthorised access to network and information systems occurred, which is capable of causing severe operational disruption” [2] — access alone, with no data movement measured. And Article 3(1)(b) fires on the exfiltration of trade secrets, catching an attacker who scrapes a proprietary pricing or ranking API rather than a personal-data store.

One correction is worth making explicitly, because the error is near-universal in vendor content: Article 3(1) itself contains no duration and no user-percentage figure. Article 3(1)(g) merely imports Articles 5 to 14, and Article 3(3) confirms it from the other direction by limiting user-counting to “the purpose of Articles 7 and 9 to 14” [2]. Any source presenting “5% or one million users” as an Article 3 threshold has not read Article 3. The same pattern of invented figures affects availability thresholds for DDoS incidents, where a widely-cited 99.9% DNS availability bar does not exist in the text either.

Four API Failure Modes, Mapped to the Provisions That Bind

In plain terms: the provisions that catch API weaknesses are spread across access control and network security, and the most useful ones are not where you would look.

The instinct is to file everything under Article 21(2)(i), “human resources security, access control policies and asset management” [1]. That is right but incomplete. The CIR Annex heads Section 11 “Access control (Article 21(2), points (i) and (j))”, and point 11.1.2 requires access control policies to “(a) address access by persons… (b) address access by network and information systems; (c) ensure that access is only granted to users that have been adequately authenticated” [2].

Point 11.1.2(b) is the clause to know. It is the only place in either instrument that puts machine-to-machine access inside the access control policy, and an API is exactly that. Note the honest limit: sub-point (c) is written in terms of “users”, so whether a calling system counts as a user is an arguable reading rather than a settled one, and we found no published authority guidance resolving it. Sub-point (b) needs no such argument — if your access control policy addresses staff, contractors and visitors but says nothing about the services calling your endpoints, it does not do what 11.1.2(b) requires.

Failure mode	What it looks like	Binding provision (CIR Annex)
Broken object level authorization (BOLA)	Attackers manipulate “the ID of an object that is sent within the request”; OWASP rates exploitability Easy, prevalence Widespread [3]	11.2.2(a) need-to-know and least privilege; 11.1.2(b) access by systems
Missing or weak authentication	Unauthenticated endpoint, unsigned or weakly signed JWTs, no lockout on credential stuffing [4]	11.1.2(b) and (c); 6.7.2(i) trusted channels with “assured identification of their end points”
Shadow and deprecated endpoints	An old version still answering, absent from the inventory and therefore never tested	6.7.2(f) “explicitly forbid or deactivate unneeded connections and services”; 6.7.2(a) documented architecture; 12.1.2(b) asset classification
Non-production endpoint reachable in production	A staging interface with real data and relaxed auth on a public route	6.8.2(h) separate production systems from development and testing “including backups”

One scope caveat on that table: the CIR Annex is directly binding only on the eleven categories in CIR Article 1. For every other essential or important entity the same points are an interpretive benchmark for Article 21(2), not a rule you can be fined against — the obligation there runs through Article 21 itself and your national transposition. The mapping is our own analysis; the provisions quoted are verbatim.

Annex 6.7.2(i) deserves more attention than it gets. It requires entities to “establish communication between distinct systems only through trusted channels that are isolated using logical, cryptographic or physical separation from other communication channels and provide assured identification of their end points and protection of the channel data from modification or disclosure” [2]. That is a mutual-authentication requirement for service-to-service traffic, expressed without naming a technology — and it sits under network security, not access control, which is why API programmes mapping only to Section 11 miss it. Our overview of access control obligations under NIS2 covers the Section 11 duties in full.

On rate limiting: no provision mandates it, and the word never appears. The nearest binding text is Annex 6.7.2(c), “configure controls to prevent accesses and network communication not required for the operation of the relevant entities” [2]. That supports a rate-limiting control as a reasonable implementation; it does not give you a rule number to cite. Anyone claiming NIS2 requires rate limiting is extrapolating, and should say so.

One provision quietly raises the cost of skipping any of this. CIR Article 2(2) states that where the Annex qualifies a requirement with “where appropriate”, “where applicable” or “to the extent feasible” and the entity considers it does not apply, the entity “shall in a comprehensible manner document its reasoning to that effect” [2]. Declining a qualified requirement is not an opt-out but a written deliverable — and the qualified requirements include the vulnerability scans at Annex 6.10.2(b) that would have found the endpoint.

The First 24 Hours, by Role

In plain terms: the clock starts when you have reasonable certainty, not when forensics finish. Decide the significance question early and file — filing carries little downside.

Article 23(4) sets the cadence: an early warning “within 24 hours of becoming aware of the significant incident”, indicating where applicable whether it is suspected of being caused by unlawful or malicious acts; a fuller notification within 72 hours; and a final report “not later than one month after the submission of the incident notification” [1]. Trust service providers file the second step at 24 hours rather than 72, by express derogation. The final-report clock runs from your own filing, so an early 72-hour submission shortens your own window — the full sequence is set out in our guide to Article 23 incident notification, and the end-to-end process in our NIS2 incident reporting guide.

Role	First 24 hours	Why it matters
CISO / security lead	Establish whether a malicious action is suspected, and preserve gateway, authentication and object-access logs before rotation	The malicious-action finding is what moves you from limb (d) to limb (c), and from a counting exercise to an immediate filing
Compliance officer / legal	Confirm which test applies to your entity, record the awareness timestamp, and check whether a parallel GDPR notification is triggered	A NIS2 filing does not discharge a personal data breach notification; the two run separately
SME owner / non-technical	Ask one question of the engineering team: was this someone attacking us, or our own mistake? Then ask who your national CSIRT is	That single answer decides which route above you are on, before anyone counts anything

Two protections make early filing the rational choice. Article 23(1) states that “the mere act of notification shall not subject the notifying entity to increased liability” [1]. And Article 23(5) obliges the CSIRT to respond where possible within 24 hours of the early warning with initial feedback and, on request, guidance on mitigation. The early warning opens a support channel rather than merely starting a file.

The exposure for getting it wrong is symmetrical in a way many boards miss. Article 34(4) and (5) apply to infringements of Article 21 or 23, so a reporting failure carries the same ceiling as a risk-management failure. The phrasing matters too: the Directive requires member states to provide for fines of “a maximum of at least” EUR 10 000 000 or 2% of total worldwide annual turnover for essential entities, and EUR 7 000 000 or 1,4% for important entities, whichever is higher [1]. That is a floor for the national maximum, not a cap.

Frequently Asked Questions

Our API was scanned and probed, but the gateway blocked everything. Do we report?
Not under Article 23. Article 6(5) classes an event “successfully prevented from materialising” as a near miss, outside the mandatory duty. Article 30 allows voluntary notification, and states that voluntary reporting “shall not result in the imposition of any additional obligations upon the notifying entity” [1].

A researcher found an unauthenticated endpoint before anyone exploited it. Is that reportable?
On the Directive’s own definitions, no — that is a vulnerability under Article 6(15), not an incident under Article 6(6) [1]. It remains an Article 21(2)(e) vulnerability-handling matter, and you should check your logs for prior exploitation before concluding nothing happened.

We are a manufacturer, not a cloud provider. Do the CIR criteria bind us?
No — CIR Article 1 binds eleven named categories and manufacturing is not among them [2]. Your test is Article 23(3) plus your national transposition, with the CIR criteria available as a benchmark where your authority says so [6].

Does the 5% user threshold apply to a breach caused by an attacker?
Not as a gate. For the categories covered by Articles 7 and 9 to 13, a data compromise resulting from a suspectedly malicious action satisfies limb (c) independently; limb (d)’s user test is a separate alternative route [2]. You can still meet (d) as well — you just do not have to.

Sources

1. Directive (EU) 2022/2555 (NIS2) — EUR-Lex, Articles 6, 21, 23 and 34
2. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex, Articles 1 to 14 and the Annex
3. API1:2023 Broken Object Level Authorization — OWASP API Security Top 10
4. API2:2023 Broken Authentication — OWASP API Security Top 10
5. ENISA Threat Landscape 2025 — ENISA
6. "NIS-2-Meldepflicht" (#nis2know) — Bundesamt für Sicherheit in der Informationstechnik (bsi.bund.de)

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.