How Research Institutions Classify IP Theft as a NIS2 Significant Incident — Art. 23 Notification, GÉANT CERT Routing, and the 72-Hour Clock

European research institutions are among the most valuable targets for state-sponsored cyber espionage — and, under NIS2, increasingly among the most exposed when incidents go unreported. When an advanced persistent threat exfiltrates three years of pharmaceutical research data, the question for your compliance team is not whether the attack was serious. It is whether Art. 23 of Directive (EU) 2022/2555 requires notification to your national competent authority within 72 hours — and what the IP theft means for your Art. 21(2)(d) supply chain obligations to consortium partners who shared that data.

This guide addresses three questions that existing NIS2 guidance leaves unanswered for the academic and research sector: how to classify IP theft as a significant incident under Art. 23; how to route the technical incident response through GÉANT CERT and national NREN CSIRTs while the regulatory clock runs; and what data sharing agreements with research partners actually require under Art. 21(2)(d).

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

Which Research Institutions Fall Under NIS2 — and How They Are Classified

The first source of confusion in the research sector is that NIS2 distinguishes between two categories of institutions that universities often treat as interchangeable.

Research organisations — entities whose primary goal is conducting applied research or experimental development with results used for commercial purposes — may fall under the directive’s standard scope provisions when they meet the size thresholds. The baseline rule in Art. 2(1) applies to medium-sized and larger entities with at least 50 employees or annual turnover exceeding €10 million. A research spin-out, technology transfer office, or contract research organisation meeting these thresholds is almost certainly in scope [3].

Educational institutions, including universities, are handled differently. Art. 2(5)(b) gives member states discretion to apply the directive to “education institutions, in particular where they carry out critical research activities” [3]. This is an optional extension, not a mandatory classification. Several member states have exercised this option in their national transposition laws; others have not. Your obligation depends on your jurisdiction’s implementation.

Practical scope triggers that operate alongside size thresholds:

• Participation in Horizon Europe or other EU-funded research consortia with cross-border data flows
• Research activities touching critical infrastructure sectors (health, energy, defence)
• Operation of shared research infrastructure accessible to external partner institutions

Research organisations classified under NIS2 most commonly fall into the Important entity category. The practical difference from Essential entities: national authorities supervise Important entities primarily through reactive enforcement rather than proactive inspections.

Institution type	Scope basis	Likely classification
Commercial R&D organisation (50+ staff / €10M+ turnover)	Art. 2(1) standard threshold	Important entity
University — member state has extended NIS2 scope	Art. 2(5)(b) national transposition	Important entity (typically)
University — member state has NOT extended scope	Outside mandatory scope	Voluntary compliance only
Research consortium participant (EU-funded, cross-border)	Art. 2(1) per participating entity	Important entity per entity
Small research spin-out (under 50 staff / €10M)	Outside threshold	Out of scope unless MS extends

EU-funded research participation and cross-institutional data sharing virtually guarantee scrutiny from national competent authorities, regardless of formal entity size [6]. If your institution’s NIS2 status is uncertain, your national cybersecurity authority is the definitive source.

State-Sponsored IP Theft as a Significant Incident Under Art. 23

Most research security teams understand that Art. 23 imposes a notification obligation for significant incidents. The harder question — and the one almost no published guidance answers directly for the research sector — is whether intellectual property theft triggers it.

Art. 23(3) defines significance through two independent tests [1]:

(a) the incident “has caused or is capable of causing severe operational disruption” to the entity, OR

(b) the incident “has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.”

IP theft typically reaches the reporting threshold through prong (b), not prong (a). State-sponsored actors exfiltrating research data rarely cause visible service disruption. The research group continues publishing; the network stays operational. But the harm flows downstream: funding bodies whose investment is devalued, partner institutions whose research integrity depends on the stolen dataset, and research subjects when the exfiltrated data includes personal health records.

Commission Implementing Regulation 2024/2690 (CIR) adds a concrete significance criterion that directly applies here: Art. 3 lists “exfiltration of trade secrets” as a standalone significance indicator [5]. While CIR 2024/2690 formally applies its sector-specific thresholds to nine named entity types (cloud providers, managed security services, DNS registries, and others), research institutions can use Art. 3 as the most authoritative available benchmark for calibrating their own significance determinations. Proprietary research data qualifies as trade secrets when it carries commercial value, is not publicly known, and the institution takes reasonable steps to maintain its confidentiality — a funded drug discovery dataset or unpublished engineering methodology fits this definition in most EU jurisdictions.

State-sponsored targeting context: APT31, linked to Chinese state intelligence, has repeatedly targeted European universities and research institutes for IP exfiltration. APT41 conducts ongoing supply chain compromises against research-adjacent sectors. These actors operate patient, low-noise campaigns specifically designed to avoid operational disruption — which is precisely why the Art. 23(3)(b) analysis, not Art. 23(3)(a), is the relevant threshold for research IP theft.

The recurring incident aggregation rule in CIR Art. 4 [5] is particularly relevant for research environments: individual phishing successes or minor data access events that each fall below the significance threshold may collectively meet it when reviewed across a six-month window.

Scenario	Art. 23 test	Significant?
Exfiltration of unpublished research with commercial licensing potential	CIR Art. 3: trade secret exfiltration	Yes
Exfiltration of EU-funded consortium dataset used by partner institutions	Art. 23(3)(b): damage to other persons	Yes
Exfiltration of personal health data from research trial	Art. 23(3)(b): considerable non-material damage	Yes
Credential compromise without confirmed data access	Neither threshold clearly met	Investigate; probably not
Multiple low-level phishing incidents over six months	CIR Art. 4: recurring incidents aggregate	Potentially — review aggregate impact
Research repository unavailable for 4 hours (non-critical period)	Art. 23(3)(a): depends on downstream impact	Assess on facts

The 24-Hour, 72-Hour, and 30-Day Notification Clock

Once you determine an incident is significant, Art. 23(4) imposes a three-stage notification obligation with non-negotiable timelines [1]. All three windows run from the moment the organisation becomes aware of the significant incident, not from the time the breach occurred.

Stage 1 — Early Warning (within 24 hours): Submit an initial notification to your national CSIRT or competent authority. At this stage, you are not expected to have a complete picture. Required content: whether you suspect unlawful or malicious causation, and whether there is cross-border potential (affecting institutions in more than one member state).

Stage 2 — Incident Notification (within 72 hours): The full regulatory notification, updating the early warning with severity and impact assessment, compromise indicators (IOCs where available), initial assessment of root cause, and mitigation measures already applied. This is not the final investigation report.

Stage 3 — Final Report (within 30 days): A detailed description of the incident, its threat category, root cause analysis, cross-border impact assessment, and the complete set of corrective measures. If the incident is ongoing at 30 days, submit an interim progress report and follow with the final report within one month of resolution.

Stage	Timeline	Required content	Receiver
Early warning	Within 24h of awareness	Suspected malicious causation; cross-border potential	National CSIRT or competent authority
Incident notification	Within 72h of awareness	Severity; IOCs; initial assessment; mitigations applied	National CSIRT or competent authority
Final report	Within 30 days of notification	Root cause; full impact; mitigation; cross-border detail	National CSIRT or competent authority

Two practical pitfalls specific to research environments:

Discovery lag. Many research institutions run lean IT security functions with limited endpoint detection. A state-sponsored intrusion may persist for weeks before detection. The 24-hour and 72-hour clocks run from awareness, not from initial compromise — but awareness requires adequate monitoring to generate it. Institutions that lack central log aggregation routinely discover breaches weeks late, compressing the notification window to a matter of hours.

Informal containment. Research culture tends toward self-sufficiency: when a network anomaly appears, a departmental IT coordinator may reset credentials and consider the matter closed. If that event meets the significance threshold, the failure to notify is itself a regulatory breach. Under NIS2, Important entities face maximum administrative fines of up to €7 million or 1.4% of global annual turnover, whichever is higher. Essential entities face up to €10 million or 2% of global annual turnover. Directive 2022/2555 also establishes personal accountability for management bodies — the institution’s director who approved security investment below the level required for Art. 23 compliance cannot claim the incident was purely a technical matter.

Routing Incidents Through GÉANT CERT and National NREN CSIRTs

NIS2 Art. 23 requires you to notify your national CSIRT or competent authority. Research institutions have an additional layer of technical incident support that most compliance guides ignore: the European Research and Education Network (NREN) CSIRT hierarchy, coordinated at the European level by GÉANT CERT.

GÉANT operates a Security Operations Centre that secures the logical and physical infrastructure of the GÉANT network and all data traversing it [4]. Its constituency is the national NREN organisations across Europe: DFN-CERT in Germany, JISC CSIRT in the UK, GARR-CERT in Italy, SURF-CERT in the Netherlands, and CESNET/CSIRT.CZ in the Czech Republic, among others. When an incident affects the GÉANT network itself or originates from a connected NREN, GÉANT CERT coordinates the technical response alongside the affected national CSIRT [4].

Routing hierarchy for a research institution incident:

1. Internal triage (hours 0–2): Your IT security team or CISO determines that an incident has occurred and conducts initial scoping.
2. National NREN CSIRT notification (parallel with Art. 23 clock): Contact your national NREN security team. They carry existing threat intelligence relationships with peer NRENs and with GÉANT CERT.
3. GÉANT CERT escalation (cross-network incidents): If the incident involves infrastructure or attacker routing through the GÉANT backbone, or if the attacker appears to be targeting multiple NRENs simultaneously, your NREN CSIRT escalates to GÉANT CERT [4].
4. NIS2 competent authority notification (within 24h): The Art. 23 early warning goes to your national cybersecurity competent authority simultaneously with steps 1–3 — not after technical containment is complete.

The critical distinction: GÉANT CERT routing handles technical incident response. Art. 23 notification is a separate, parallel regulatory obligation. Technical escalation through your NREN CSIRT does not satisfy the Art. 23 requirement to notify the competent authority. Both tracks run from hour one.

GÉANT CERT maintains membership in TF-CSIRT, Trusted Introducer, and FIRST [4], giving it direct access to international threat intelligence that national-level CSIRTs may lack. For state-sponsored campaigns targeting multiple European institutions simultaneously, this network is often the fastest route to actionable indicators of compromise.

Cross-border research incidents and Art. 23(7): When a significant incident affects institutions in more than one member state — routine in Horizon Europe consortia — Art. 23(7) requires member states to ensure their single points of contact share relevant information [1]. Your 72-hour notification should flag cross-border potential at the early warning stage so this coordination begins before the final report is due.

For institutions uncertain which national competent authority to notify, your NREN CSIRT can advise on the routing. National authority designations for NIS2 are also maintained in the ENISA CSIRTs Network registry at csirtsnetwork.eu.

Research Collaboration Data Sharing and Art. 21(2)(d) Supply Chain Security

Research institutions almost universally treat data-sharing agreements as administrative paperwork. Under NIS2, they are supply chain security documents.

Art. 21(2)(d) requires essential and important entities to address “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers” [2]. In a research context, direct suppliers and service providers include:

• Partner institutions in a funded consortium providing access to shared datasets or analysis pipelines
• Cloud compute providers hosting research data (HPC clusters, federated learning platforms)
• Third-party software tools embedded in research workflows
• Federated identity infrastructure providers — eduGAIN and eduroam underpin authentication for millions of research users across Europe and constitute supply chain relationships in the Art. 21(2)(d) sense

Art. 21(3) extends the obligation: institutions must assess “vulnerabilities specific to each direct supplier and service provider,” the “overall quality of products and cybersecurity practices” of suppliers, and their “secure development procedures” [2]. For a research institution with 200 open-access data sharing partners, applied literally this creates 200 assessment obligations. The practical resolution is proportionality: Art. 21(1) requires measures “proportionate to the risks posed” [2].

Collaboration type	Supply chain risk tier	Required action under Art. 21(2)(d)
EU consortium partner with shared compute infrastructure	High	Security clauses in consortium agreement; periodic review
External researcher with read-only dataset access	Medium	Access management policy; access logging
Global open-access repository (institutional contribution only)	Low	Acceptable use policy; output sanitisation before upload
Commercial cloud HPC provider	High	Due diligence on security certifications; contractual security clauses
Non-EU partner institution with bidirectional data access	High	Security practice assessment; data transfer impact assessment

Consortium breach notification: A single significant incident affecting a shared consortium platform does not generate a single reporting obligation. Each in-scope institution must independently evaluate whether the incident triggers their own Art. 23 obligation — because Art. 23(3)(b) frames significance around damage to “other natural or legal persons,” and each partner institution is such a person [1, 6]. A consortium agreement that assigns incident reporting to a single lead institution, without individual members conducting their own Art. 23 assessment, may leave multiple members in non-compliance.

For international partners outside the EU, there is no extraterritorial mandate. However, Art. 21(3) requires assessing “the overall quality of cybersecurity practices” of each direct supplier [2] — which means a research institution cannot simply exclude non-EU partners from its supply chain security review on jurisdictional grounds. See our guide on NIS2 supply chain security obligations for the full due diligence framework.

Incident Response Documentation: What Research Institutions Need Before the First Incident

The gap between NIS2 obligations and research sector readiness is most visible in documentation. Art. 23 requires completed, accurate notifications with specific required content at 24 hours, 72 hours, and 30 days. Completing a notification form for the first time under incident pressure is the most reliable way to miss a deadline.

The documents research institutions need pre-staged:

• Incident handling policy — who declares a significant incident, the approval chain for Art. 23 notifications, escalation path from departmental IT to central CISO or DPO
• Minor incident procedure — distinguishes sub-threshold events requiring documentation but not Art. 23 notification, preventing over-reporting while maintaining an audit trail
• Art. 23 notification forms — pre-structured templates for the 24-hour early warning, 72-hour notification, and 30-day final report, with placeholders for each content requirement
• Incident log — chronological event log that generates the audit trail underpinning the final report and any subsequent regulatory inspection
• Corrective actions register — tracks remediation commitments made to the authority and provides evidence of follow-through at the next supervisory review

Requirement	Owner	Effort	Priority
NIS2 scope determination	Legal / Compliance Officer	Medium (4–8h)	Immediate
Incident handling policy	CISO	Medium (6–10h)	Before next assessment
Minor incident procedure	IT Security	Low (2–4h)	Before next assessment
Art. 23 notification forms (24h / 72h / 30-day)	Compliance Officer	Low (2–3h per form)	Pre-stage; never draft ad hoc
Incident log template	IT Security	Low (1–2h)	Immediate
Corrective actions register	CISO	Low (1–2h)	Immediate
Supply chain security clauses for consortium agreements	Legal	Medium (4–6h per agreement)	At next agreement renewal
NREN CSIRT contact and escalation procedure	IT Security	Low (1–2h)	Immediate

A documented incident response capability simultaneously satisfies part of the Art. 21(2)(b) business continuity requirements that run parallel to Art. 23 notification obligations. See our detailed guidance on Art. 23 incident notification procedures and the NIS2 risk assessment framework that determines which incidents your institution must evaluate for significance.

Frequently Asked Questions

Does a ransomware attack that encrypts research data (but not personal data) require Art. 23 notification?

Yes, if it meets the significance threshold. Encryption of research data constitutes severe operational disruption under Art. 23(3)(a) if it prevents service delivery to funding bodies or consortium partners. The absence of personal data is relevant to GDPR notification but does not affect the NIS2 obligation [1].

Our university is outside NIS2 scope because our member state has not extended it to education institutions. Do we still need an incident response plan?

The Art. 23 notification obligation applies only to in-scope entities. However, Horizon Europe and other EU-funded grant agreements increasingly impose contractual security obligations that mirror NIS2 requirements regardless of formal NIS2 scope. Reviewing your grant agreement conditions is advisable before concluding no obligations exist.

Who is the competent authority for NIS2 incident notification in our country?

This depends on your member state’s transposition. Most EU member states have designated their national cybersecurity agency (BSI in Germany, NCSC-NL in the Netherlands, ACN in Italy, CERT-FR in France) as the competent authority for NIS2 notifications. Your national NREN CSIRT can advise on routing. The ENISA CSIRTs Network maintains a current registry of designated authorities.

Can we route our Art. 23 notification through GÉANT CERT instead of the national competent authority?

No. GÉANT CERT handles technical incident coordination within the research and education network community [4]. Art. 23 notification must go to your national CSIRT or competent authority as designated by your member state. GÉANT CERT and the national competent authority notification are parallel tracks, not alternatives.

Sources

1. European Parliament and Council, Directive (EU) 2022/2555, Article 23 — Reporting Obligations
2. European Parliament and Council, Directive (EU) 2022/2555, Article 21 — Cybersecurity Risk-Management Measures
3. European Parliament and Council, Directive (EU) 2022/2555, Article 2 — Scope
4. GÉANT, “GÉANT CERT,” GÉANT Security
5. Commission Implementing Regulation (EU) 2024/2690 — NIS2 Technical Measures (commentary and analysis)
6. ISMS.online, “NIS 2 for Research: Who’s In Scope, What Changes, and Why Evidence Matters”