Insider Threat Reporting Under NIS2: The Two-Limb Test for Internal Actors, the 24-Hour Clock, and What to Revoke First

NIS2 never uses the word “insider.” Neither does Commission Implementing Regulation (EU) 2024/2690. That silence is why insider cases get mishandled: teams look for an insider-threat obligation, find none, and quietly file the problem under HR.

The obligations attach to the incident, not to the actor. An employee who copies the customer database in their notice period triggers the same Article 23 machinery as a ransomware crew, with three differences that change how you run it. There is usually no downtime to measure. The access used was legitimate when it was granted. And the person under investigation can often read the investigation.

The exposure is not marginal in Europe: Verizon’s 2025 Data Breach Investigations Report found that “nearly a third (29%) of breaches originated from within the organisation” in EMEA — 19% unintentional error, 8% misuse — against 5% in North America and 1% in APAC [7]. That is vendor telemetry rather than a regulatory statistic, but the regional skew is large enough to plan around — and it lands on a regulated population. ENISA’s Threat Landscape 2025, covering 4,875 incidents between 1 July 2024 and 30 June 2025, found that “53.7% of the total number of incidents concern essential entities, as defined by the NIS 2 Directive” [6].

Which Significance Test Actually Binds You

Two rulebooks exist, and which one applies decides whether a quiet data theft with no outage is reportable at all.

Article 23(3) is the Directive’s own test and binds every essential and important entity through national transposition. CIR 2024/2690 adds a sharper seven-criterion test at Article 3(1) — but its Article 1 binds only eleven categories: DNS service providers, TLD name registries, cloud computing providers, data centre providers, CDN providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers [1].

Most guidance stops there, and that is the mistake. Germany’s BSI states on its own reporting-duty page that for entities in other sectors it can be assumed a significant incident exists where at least one of the Article 3(1) criteria is met [4]. Belgium’s Centre for Cybersecurity Belgium published a Guide for NIS2 notifications applicable from 18 October 2024 which, as summarised by the industry association Beltug, treats one-off events as reportable where they cause serious operational disruption, significant financial losses or physical harm, “such as unauthorised access to critical systems or the theft of trade secrets” [8]. Two national authorities have converged on the Implementing Regulation’s list as the working benchmark for sectors it does not formally bind.

This is national guidance, not the Directive, and it travels no further than the border it was issued at — Beltug’s summary notes the Belgian guide “applies solely to Belgium” and that other member states “may adopt slightly different rules” [8]. Check your own competent authority before borrowing either reading.

Your situation	Significance test that governs	Where insider exfiltration lands
One of the eleven CIR-bound categories (DNS, TLD, cloud, data centre, CDN, MSP, MSSP, marketplace, search, social, trust services)	CIR 2024/2690 Article 3(1) — seven criteria, any one is sufficient	Directly, via 3(1)(b) or 3(1)(e). No downtime and no euro calculation required.
Any other essential or important entity in Germany	§ 2 Nr. 11 BSIG, mirroring Article 23(3); BSI names CIR Article 3(1) as the assumption benchmark	Same two criteria — but by authority guidance, not by binding regulation
Any other entity in Belgium	Article 23(3) as transposed, read through the CCB’s Guide for NIS2 notifications	Trade-secret theft and unauthorised access are named in the guidance
Everywhere else	Article 23(3)’s two limbs as transposed nationally	You build the argument yourself under limb (a) or limb (b)

Getting this wrong is a reporting failure, and it carries the same penalty band as a missing control: Article 34(4) and 34(5) put infringements of Article 21 or Article 23 at a maximum of at least EUR 10 000 000 or 2% of worldwide annual turnover for essential entities, and EUR 7 000 000 or 1,4% for important entities, “whichever is higher” [9].

The Two-Limb Test, Applied to Someone Who Already Had Access

Article 23(3) is short enough to quote in full. An incident is significant if “(a) it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned” or “(b) it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage” [2]. Either limb alone is enough.

Insider exfiltration usually fails limb (a) on first reading — nothing went down, and the financial loss is speculative on day one. Two words rescue the analysis: “capable of causing.” The test is forward-looking, so a fully contained incident can still be significant on the harm it was capable of producing. Limb (b) is what most often catches a data theft, because the people damaged are the customers or employees whose data left, not you. Our walkthrough of the Article 23(3) significance test covers the general mechanics; what follows is what changes when the actor is internal.

Where CIR Article 3(1) applies — directly or as national benchmark — two criteria do the work.

Criterion 3(1)(b) makes an incident significant where it “has caused or is capable of causing the exfiltration of trade secrets as set out in Article 2 point (1), of Directive (EU) 2016/943” [1]. That cross-reference is not decorative. Under Article 2(1) of the Trade Secrets Directive, information qualifies only if it is secret, “has commercial value because it is secret”, and “has been subject to reasonable steps under the circumstances, by the person lawfully in control of the information, to keep it secret” [5]. Read that third limb again: the access controls you can evidence partly determine whether the file your employee took is legally a trade secret at all. The same access control documentation that evidences Article 21(2)(i) — “human resources security, access control policies and asset management” [3] — is what makes this criterion available to you.

Criterion 3(1)(e) covers “a successful, suspectedly malicious and unauthorised access to network and information systems occurred, which is capable of causing severe operational disruption” [1]. It requires no downtime, no loss figure and no user count — but it does require the access to be unauthorised, and a credentialed employee opening a system they were granted is not obviously that. The criterion reads most naturally on access beyond what was granted: privilege escalation, a dormant or shared account, an administrator reaching into a system outside their remit. An employee copying data they were entitled to read sits better under 3(1)(b) or the Article 23(3) limbs. No court has ruled on this and we found no competent-authority guidance on the point, so treat the boundary as unsettled and document which reading you applied.

Scenario	Criterion that fits	Practical call
Departing sales manager forwards the client list to a personal address	Art. 23(3)(b); CIR 3(1)(b) if the list meets the three-part trade-secret test	Reportable in most readings. Do not wait for the loss to crystallise.
Administrator grants themselves rights to an HR file share	CIR 3(1)(e) — access beyond what was granted	Reportable without any downtime or euro figure
Contractor’s account used two weeks after the contract ended	CIR 3(1)(e), plus an Annex 11.2.2(b) control failure	Reportable, and the control gap belongs in the final report’s root cause
Employee emails a payroll spreadsheet to the wrong external recipient	Art. 23(3)(b), assessed on damage to those individuals	Assess both regimes; often a GDPR notification with a NIS2 assessment recorded
Employee deletes production data before leaving	Art. 23(3)(a) — severe operational disruption	Reportable on the classic limb; the insider angle changes containment, not significance

Detection Is Annex Section 3.2, Not Section 10

A correction first, because the wrong number circulates widely. Annex Section 10 of CIR 2024/2690 is “Human resources security (Article 21(2), point (i))” and has exactly four sub-sections: 10.1 human resources security, 10.2 verification of background, 10.3 termination or change of employment procedures, 10.4 disciplinary process [1]. None is a detection requirement. Detection lives in Section 3.2, “Monitoring and logging.”

Three items in the 3.2.3 log list carry the insider signal and are rarely singled out. Point (b): “creation, modification or deletion of users of the relevant entities’ network and information systems and extension of the permissions” — privilege escalation, logged at source. Point (e): “all privileged access to systems and applications, and activities performed by administrative accounts.” Point (k): “activation, stopping and pausing of the various logs” [1].

Point (k) repays the most attention. A privileged insider can stop logging; what they cannot easily do is stop the stopping from being recorded, so the gap in the record becomes the signal. That only holds if 3.2.5 is implemented properly — logs backed up for a predefined period and protected “from unauthorised access or changes” — because the threat model for log integrity here is a person with legitimate administrative rights. Our guide to the NIS2 logging and monitoring requirements works through the full list.

Tooling is only half of it. Section 3.3.1 requires a “simple mechanism allowing their employees, suppliers, and customers to report suspicious events”, with 3.3.2 requiring regular training on how to use it [1]. Colleagues notice behaviour a detection rule does not — and that channel carries a timing consequence covered further below.

Scope caveat throughout: the Annex binds the eleven categories directly and is an interpretive benchmark for everyone else. Where you apply it and decline a requirement qualified by “where appropriate”, “where applicable” or “to the extent feasible”, CIR Article 2(2) requires you to “in a comprehensible manner document its reasoning to that effect” [1] — the declined item becomes its own deliverable.

Containment: What to Revoke, and in What Order

Revoke too fast and you destroy evidence and tip off the subject; revoke too slowly and the exfiltration continues while you deliberate. The Annex sets the sequence only at a high level — 3.5.2 lists “(a) incident containment, to prevent the consequences of the incident from spreading”, then eradication, then recovery — while 3.5.4 requires entities to log response activities and “record evidence” [1]. In an insider case those two obligations pull against each other, and the Regulation does not resolve the tension for you. The ordering below is our own practical synthesis, built to satisfy both.

#	Action	Effort	Why this position
1	Preserve: image the endpoint, snapshot the mailbox, export the account’s authentication and privileged-activity logs to a store the subject cannot reach	Medium	Everything after this is destructive to volatile evidence. Satisfies 3.5.4 and depends on 3.2.5 having been done in advance.
2	Cut the outbound paths for that identity only — personal webmail, removable media, cloud sync, external sharing links	Medium	Stops the spread under 3.5.2(a) while the account still looks normal to its user
3	Revoke privileged and administrative rights; leave standard access in place	Low	Removes the capability to alter logs (3.2.3(k)) before removing the account itself
4	Full revocation and credential reset — including shared accounts, API keys, tokens, VPN certificates	Low	Annex 11.2.2 requires access rights to be modified on termination or change of employment; the 11.2.2(e) register of access rights granted is what makes this completable in hours
5	Third-party and physical: SaaS tenants, supplier portals, badge access	Medium	The systems most often missed, because they sit outside the identity provider

Most organisations build the Annex 11.2.2(e) register as an audit artefact and discover its operational purpose during an insider case: without it, step 4 becomes archaeology across a dozen consoles while the clock in the next section is already running.

Role	Owns
CISO / SOC	Steps 1–4, evidence chain, the technical facts behind the significance call
Compliance officer	The significance decision, the notification timeline, the documented reasoning behind both
HR	The disciplinary process required by Annex 10.4, and the post-termination duties defined under 10.3
Legal	Criminal complaint decision, trade-secret assessment, evidence admissibility, works-council consultation
Management body	Article 20 approval and oversight of the measures being relied on here

The 24/72/30 Clock, Read for an Insider Case

Two fields in the standard reporting flow behave differently when the suspect is on the payroll.

The 24-hour early warning asks you to name it. Article 23(4)(a) requires an early warning within 24 hours of becoming aware which “shall indicate whether the significant incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact” [2]. A preliminary attribution call is therefore legally expected on day one — before the forensic image is processed and long before any HR interview. Germany’s BSI renders the corresponding field as a suspicion rather than a finding: the Erstmeldung asks whether there is a suspicion that the incident is attributable to malicious acts, alongside the presumed cause [4]. Write it as suspicion. Article 23(1) is explicit that “the mere act of notification shall not subject the notifying entity to increased liability” [2]. Two further BSI points settle the risk calculus for German entities: a submitted report cannot be cancelled or withdrawn, only corrected or supplemented by a follow-up report, and the stated operating principle is speed before completeness [4]. File fast with hedged language rather than holding the report until attribution firms up.

The 72-hour notification asks about the police. Article 23(4)(b) requires an updated notification with an initial assessment of severity and impact and, where available, indicators of compromise [2]. BSI’s Folgemeldung content list adds information on criminal prosecution and cooperation with authorities [4] — so by day three, a German entity is telling its authority whether it has gone to the police about its own employee. That decision belongs on the day-one agenda, not deferred into the disciplinary process. The Directive pushes the same way: under Article 23(5) the CSIRT must respond within 24 hours where possible and, “[w]here the significant incident is suspected to be of criminal nature”, must also “provide guidance on reporting the significant incident to law enforcement authorities” [2].

One widely misreported detail: Article 23(4)(d) sets the final report at “not later than one month after the submission of the incident notification under point (b)” [2] — one month from your 72-hour filing, not from the incident, so filing early shortens your own window. Our Article 23 notification walkthrough covers all three stages.

There is also a quieter trigger. BSI defines “Kenntniserlangung” — the moment awareness begins — as the point at which an employee of the entity, during working hours, becomes aware of a significant incident [4]. Combine that with the Section 3.3.1 reporting channel and the consequence is uncomfortable: in Germany, a colleague’s report that someone is bulk-downloading files can start the 24-hour clock before the security team has confirmed anything. Timestamp every submission to that channel and route it to whoever owns the significance decision the same day.

Where This Collides with GDPR and Employment Law

If the exfiltrated data is personal data, two clocks run with different starting conditions: NIS2’s 24-hour early warning from awareness of a significant incident, and GDPR Article 33’s 72 hours from awareness of a personal data breach. They are parallel, not sequential. Article 35(1) then requires competent authorities to inform the GDPR supervisory authority without undue delay where the infringement can entail a notifiable personal data breach; Article 35(2) adds that where the data protection authority has already fined under Article 58(2)(i) GDPR, the NIS2 authority “shall not impose an administrative fine pursuant to Article 34 of this Directive” for an infringement arising from the same conduct, though non-financial enforcement measures remain available [10]. Our NIS2 versus GDPR comparison maps both regimes.

On the employment side, two Annex Section 10 obligations must exist before the incident to be usable during it: 10.4 requires entities to “establish, communicate and maintain a disciplinary process for handling violations of network and information system security policies”, and 10.3.1 requires that security responsibilities surviving termination or change of employment are “contractually defined and enforced” [1]. A disciplinary process improvised mid-investigation is both an employment-law risk and a documented control gap.

How far you may lawfully monitor employees, and what works-council consultation that needs, is national law and varies substantially. Our companion guide on the HR side of insider threat under Article 21(2)(i) covers background verification, access-review cadence and works-council constraints.

The Documentation an Auditor Will Ask For

• The significance assessment itself — which criterion you applied, the facts behind it, and the reasoning where you decided an incident was not significant
• Timestamped record of first awareness, including reports arriving through the Section 3.3.1 employee channel
• Evidence-preservation record: what was imaged, when, by whom, and where it is held
• Access-revocation log with times per system, reconciled against the Annex 11.2.2(e) register
• Copies of the 24-hour, 72-hour and final submissions, plus any follow-up corrections
• Documented reasoning under CIR Article 2(2) for any qualified requirement you declined to apply
• The disciplinary process as it stood on the incident date, not as later revised

Key Takeaways

• NIS2 has no insider-threat regime. It has an incident regime that internal actors trigger like anyone else — the difference is evidentiary and procedural, not legal.
• Insider exfiltration usually fails Article 23(3) limb (a) and passes limb (b). “Capable of causing” means containment does not make an incident insignificant.
• CIR Article 3(1)(b) and 3(1)(e) let a data theft be reportable with no downtime and no euro calculation — binding for eleven digital-service categories, and treated as the working benchmark for other sectors by BSI in Germany and reflected in the CCB’s guidance in Belgium.
• Detection sits in Annex 3.2, not Section 10. Points 3.2.3(b), (e) and (k) are the insider-relevant log sources.
• Preserve before you revoke, then remove privileged rights before the account itself.
• The 24-hour early warning requires a suspicion-level attribution call; the final report runs one month from the 72-hour notification, not from the incident.

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.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex, Official Journal (Articles 1–4 and full Annex)
2. Directive (EU) 2022/2555, Article 23 — Reporting obligations
3. Directive (EU) 2022/2555, Article 21 — Cybersecurity risk-management measures
4. #nis2know: NIS-2-Meldepflicht — Bundesamt für Sicherheit in der Informationstechnik (BSI), Germany
5. Directive (EU) 2016/943, Article 2 — Definitions (trade secret)
6. ENISA Threat Landscape 2025 — ENISA (4,875 incidents analysed, 1 July 2024 – 30 June 2025)
7. 2025 Data Breach Investigations Report — EMEA findings, Verizon
8. “Significant incidents — new NIS2 guidance from the EU and Belgium”, Beltug (beltug.be), summarising the Centre for Cybersecurity Belgium’s Guide for NIS2 notifications
9. Directive (EU) 2022/2555, Article 34 — General conditions for imposing administrative fines
10. Directive (EU) 2022/2555, Article 35 — Infringements entailing a personal data breach