NIS2 Business Email Compromise: Why Losing the Money Doesn’t Always Start the 24-Hour Clock

Europol’s Internet Organised Crime Threat Assessment 2025 describes business email compromise in one clause: criminals “impersonate company executives or employees to trick others into transferring funds or revealing sensitive information” [5]. That word — impersonate — is why BEC sits awkwardly inside NIS2, and why the guidance you will find elsewhere is close to useless on it.

Every incident-reporting guide checked for this article jumps straight to Article 23(3) and asks whether the loss was big enough. That is the second question. The first is whether a BEC is an “incident” under the Directive at all — and for one common variant of BEC, the honest answer is arguably no, no matter how much money left the account.

Two Gates, and Most Guides Only Check the Second

Article 23(1) requires Member States to ensure that essential and important entities notify “any incident that has a significant impact on the provision of their services as referred to in paragraph 3 (significant incident)” [1]. That sentence contains two separate conditions, and they are assessed in order.

Gate 1 — is it an incident? Article 6(6) 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]. The protected properties are attached to your network and information systems. An event that compromises nothing on your systems does not clear this gate.

Gate 2 — is it significant? Only then does Article 23(3) apply: the incident must have caused or be capable of causing “severe operational disruption of the services or financial loss for the entity concerned”, or have affected other natural or legal persons through “considerable material or non-material damage” [1].

The Centre for Cybersecurity Belgium (CCB) sets out the same two-step structure explicitly in its NIS2 Notification Guide, and adds a scoping rule worth committing to memory: “The mandatory notifications therefore only concern the networks and information systems on which the entity concerned depends to provide the service(s) listed in the annexes of the law. An incident only affecting an isolated information system unrelated to the provision of the aforementioned services therefore does not have to be notified” [4].

Which of the Three BECs Did You Actually Have?

“BEC” is a single label covering three attacks with different technical footprints. The reporting analysis turns almost entirely on which one you had — not on the size of the transfer.

Variant	What was actually compromised	Clears Gate 1 (Art. 6(6))?
1. External impersonation — a lookalike domain or spoofed display name, no access to your estate	Nothing on your systems. Your mail server accepted and delivered a message exactly as designed.	Arguably not. The strongest reading is that no property of your systems was compromised. Treat as contested, not settled — see the caveat below.
2. Mailbox account takeover — stolen or phished credentials used to log into a real mailbox, often with a hidden forwarding rule	Confidentiality of stored and transmitted mail; authenticity of messages sent from the account; integrity of mailbox rules.	Yes, clearly. This is a textbook Article 6(6) compromise.
3. Supplier’s mailbox compromised — the fraudulent invoice is genuinely sent from your vendor’s real, hijacked account	Nothing of yours. The compromise sits inside the supplier’s estate.	Not for you under Art. 6(6) on these facts, though it is an incident for the supplier and a supply-chain risk-management matter for you.

Variant 2 is the one that reliably creates reporting exposure, and it does so through a route most BEC discussions never reach. For the eleven categories of entity bound directly by Commission Implementing Regulation (EU) 2024/2690 — DNS providers, TLD registries, cloud, data centres, CDNs, managed service and managed security providers, online marketplaces, search engines, social platforms and trust service providers — 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]. A hijacked mailbox is unauthorised access. Whether it is capable of causing severe operational disruption is a separate judgement, and a mailbox used only to redirect an invoice may well not be.

A necessary caveat on variant 1. The reading above is textual analysis, not settled law. No case law or national-authority guidance squarely on the point was found in preparing this article, and a regulator could reasonably argue that a forged message is itself “transmitted or processed data” whose authenticity was compromised the moment your systems handled it. If your national authority reads it that way, variant 1 clears Gate 1 too. Document the reasoning you applied rather than assuming your reading is the only available one.

Financial Loss Is a Reporting Trigger — the Directive Says So

A claim circulating in NIS2 commentary holds that the Directive tests service impact and not financial loss, so a fraud that moves money without taking anything offline falls outside Article 23. That is wrong on the face of the text.

Article 23(3)(a) is disjunctive: an incident is significant if it has caused or is capable of causing “severe operational disruption of the services or financial loss for the entity concerned” [1]. Financial loss is an independent limb. Germany’s BSI reproduces exactly that structure in its own reporting guidance, defining a significant incident as one leading to “schwerwiegenden Betriebsstörungen der Dienste oder zu finanziellen Verlusten der Einrichtung” — severe operational disruption of services or financial losses to the entity [3]. The CCB goes further and gives financial loss its own numbered category of significant incident, sitting alongside availability and third-party damage [4].

Note what the Directive does not do. On the natural reading of the sentence, the adjective “severe” attaches to operational disruption rather than to financial loss, and Article 23 puts no figure on financial loss anywhere. That gap is precisely why the Implementing Regulation and national authorities have supplied numbers of their own — and why those numbers do not agree.

The Threshold Moves With Your Jurisdiction

There is no single euro figure at which a BEC becomes reportable across the EU. Which number applies to you depends on your sector and your member state.

Who you are	Direct financial loss threshold	Source
One of the eleven entity categories bound by CIR 2024/2690	Above EUR 500,000 or 5% of total annual turnover in the preceding financial year, whichever is lower	CIR 2024/2690, Art. 3(1)(a) [2]
A NIS2 entity in Belgium (any sector)	Above EUR 250,000 or 5% of total annual turnover, whichever is lower	CCB NIS2 Notification Guide, v1.2 [4]
A German entity in a sector the CIR does not bind	The CIR Art. 3(1) criteria apply as a working presumption — so EUR 500,000 in practice	BSI #nis2know [3]
Everyone else	No figure. The bare Art. 23(3) test governs, interpreted by your national authority	Directive (EU) 2022/2555, Art. 23(3) [1]

The practical consequence is that the same EUR 300,000 invoice fraud clears the Belgian threshold while falling short of the EUR 500,000 figure a German entity would be measured against — provided the 5%-of-turnover alternative sits higher than the euro figure in both cases, which it does for any entity turning over more than EUR 10 million. Below that, the percentage bites first and the effective threshold falls in both countries. Two caveats on the Belgian figure: it comes from version 10.2024 – 1.2 of the CCB guide, and the CCB has since issued version 08.2025 – 1.3, which could not be independently retrieved because the CCB’s own domain blocks automated access. The EUR 250,000 figure is corroborated verbatim by CMS’s Belgian legal update. Confirm the current version before relying on it.

The CCB also specifies what feeds the calculation: replacement of software, hardware and infrastructure, staff and overtime costs, “fees due to non-compliance with contractual obligations”, redress and compensation to customers, forgone revenue, communication costs, legal advisory costs, and forensic and remediation services. Administrative fines, routine running costs and insurance premiums are expressly excluded [4]. For a BEC, that means the diverted payment is rarely the whole number — the forensic engagement and the legal advice count toward the same threshold.

When the 24-Hour Clock Starts in a BEC

BEC has an awareness problem that ransomware does not. Nobody in the security team detects it. It surfaces when a supplier chases an unpaid invoice, or when the bank calls, or when a finance clerk notices the account number changed — days or weeks after the event.

Two national authorities have addressed when awareness crystallises, and they set the bar low. The BSI states that “Kenntniserlangung” means the moment at which an employee of the entity, during working hours, learns of a significant incident [3]. The CCB frames it as the point at which, after an initial assessment, the entity “has a reasonable degree of certainty that a significant incident has occurred” — and says expressly that this covers an incident “brought to its attention by a third party, such as an individual, a customer, an entity, an authority, a media organisation” [4]. A supplier’s phone call can therefore start the clock before your security team has opened a ticket.

Because BEC is discovered outside the security function, the first 24 hours cross departments that rarely rehearse together:

Role	What this specific incident asks of them
Finance / AP clerk	The de facto detector. Must know that a changed bank detail is a security escalation, not just a payments query — their phone call is what starts the clock.
CISO / IT security	Establish which variant occurred: pull sign-in logs, look for mailbox forwarding and inbox rules. This determines Gate 1, and it is the single most decision-relevant technical task.
Compliance officer / legal	Run the two gates, calculate direct loss against the applicable threshold, and record the reasoning — including a decision not to notify.
Board / management	Decide on the Art. 23(4)(a) flag, which asks whether the incident is “suspected of being caused by unlawful or malicious acts”. In a BEC the answer is plainly yes, and it is due within 24 hours.

Two points reduce the cost of filing when the call is genuinely marginal. Article 23(1) states that “the mere act of notification shall not subject the notifying entity to increased liability”, and Article 23(5) obliges the CSIRT to respond without undue delay and, where possible, within 24 hours — including, where the incident is suspected to be criminal, with guidance on reporting it to law enforcement [1]. For a fraud where recovering the funds depends on speed, that is a practical reason to file rather than deliberate. The BSI’s own instruction is blunt: “Schnelligkeit vor Vollständigkeit” — speed before completeness [3].

What Article 21 Requires Whether or Not You Report

Even where a BEC never becomes reportable, it remains a risk-management failure the Directive expects you to have addressed — and the scope of Article 21 is deliberately wider than the scope of Article 23.

Article 21(1) applies to “network and information systems which those entities use for their operations or for the provision of their services” [1]. Article 23(1) is limited to incidents with a significant impact “on the provision of their services” [1]. Corporate email is unambiguously used for operations. So the asymmetry is structural: a BEC is always an Article 21 matter, and only sometimes an Article 23 one. A supervisor reviewing your controls is not bound by the reporting threshold you applied.

The most specific obligation is one that appears in no competing article on this topic. CIR 2024/2690’s Annex, at point 6.7.2(k) under Network security, requires relevant entities to “adopt an implementation plan for the deployment of internationally agreed and interoperable modern e-mail communications standards to secure e-mail communications to mitigate vulnerabilities linked to e-mail-related threats and establish measures to accelerate such deployment” [2]. The deliverable is a documented, time-bound plan — not merely a configured mail gateway. The Regulation names no specific standard, so the choice of protocols is yours to justify.

Three further hooks apply. Article 21(2)(g) requires “basic cyber hygiene practices and cybersecurity training”; Article 21(2)(j) requires multi-factor authentication “where appropriate”, which is the direct control against variant 2; and Article 21(2)(i) covers access control policies [1]. The CIR’s recitals — interpretive aids that create no obligations of their own — indicate that hygiene for users should extend to “safe email use and web browsing, protection from phishing and social engineering”, and that entities should consider deploying email and web filters [2].

Frequently Asked Questions

We lost money but nothing went down. Do we report? Possibly. Financial loss is an independent limb of Article 23(3)(a), so no downtime is required. First confirm the event clears Article 6(6) at all, then measure direct loss against whichever threshold binds you.

Does a blocked BEC attempt need reporting? No. Article 6(5) defines a near miss as an event that “was successfully prevented from materialising or that did not materialise” [1]. A phishing mail your filter quarantined is not an Article 23 incident, though Article 30 allows voluntary notification.

Does a BEC also trigger GDPR? It can, on a separate test. If mailbox contents holding personal data were accessed, that is a personal data breach under its own regime and is assessed independently of NIS2. See our guide to why a GDPR breach does not always trigger NIS2.

Do repeated small frauds add up? Yes, but only on money. CIR Article 4 aggregates incidents that occur at least twice in six months with the same apparent root cause, and only where they collectively meet the financial criterion in Article 3(1)(a) [2]. A recurring invoice-fraud pattern is exactly the case that provision contemplates.

What to Do Next

Decide the variant before you debate the threshold. Pull the sign-in and mailbox-rule logs first, because that single technical question settles Gate 1 and everything downstream depends on it. Then measure direct loss — including forensics and legal fees, not just the transfer — against the figure that actually binds you, which is EUR 250,000 in Belgium, EUR 500,000 under the Implementing Regulation, and an unquantified judgement everywhere else.

Whichever way the reporting call goes, write down how you reached it. And treat the Annex 6.7.2(k) e-mail standards plan as the item to close this quarter: it is the only provision in the entire Implementing Regulation aimed squarely at e-mail-borne threats, and it is the one an auditor can ask for by name.

For the surrounding reporting mechanics, see our guides to Article 23 incident notification, where to report a NIS2 incident in 24 hours, and insider-threat reporting, which applies the same two-limb test to internal actors.

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. Directive (EU) 2022/2555 (NIS2), Articles 6, 21 and 23 — EUR-Lex
2. Commission Implementing Regulation (EU) 2024/2690, Articles 1, 3 and 4 and the Annex — EUR-Lex
3. “#nis2know: NIS-2-Meldepflicht” — Bundesamt für Sicherheit in der Informationstechnik (BSI), Germany
4. “NIS2 Notification Guide, Version 10.2024 – 1.2” — Centre for Cybersecurity Belgium (ccb.belgium.be). Cited de-linked: the CCB domain blocks automated access. The EUR 250,000 figure is corroborated verbatim by CMS Belgium, “Belgian NIS 2 cybersecurity authority releases guidelines on incident reporting obligations” (cms.law).
5. Internet Organised Crime Threat Assessment (IOCTA) 2025 — “Steal, Deal and Repeat” — Europol