NIS2 Directive: Threat Intelligence Requirements for Compliance

NIS2 Overview: Scope and Timeline

Essential vs. Important Entities

NIS2 replaces the original NIS Directive’s binary classification of operators of essential services (OES) and digital service providers (DSP) with a dual-tier system of essential entities and important entities. The distinction is significant: both tiers face identical cybersecurity risk-management obligations under Article 21, but essential entities are subject to proactive supervisory oversight (audits, inspections, and on-site assessments by competent authorities), while important entities face only reactive supervision triggered by evidence of non-compliance. The administrative fine ceilings also differ: up to €10 million or 2% of total worldwide annual turnover for essential entities, and up to €7 million or 1.4% of turnover for important entities.

Essential entities span 11 sectors of high criticality defined in Annex I: energy (electricity, oil, gas, hydrogen, district heating and cooling), transport (air, rail, water, road), banking, financial market infrastructures, health (including EU reference laboratories, medical device manufacturers, and pharmaceutical companies), drinking water, waste water, digital infrastructure (IXPs, DNS providers, TLD registries, cloud computing, data centres, CDNs, trust service providers, public electronic communications networks), ICT service management (managed service providers and managed security service providers), public administration (central government entities, excluding the judiciary, parliament, and central banks), and space (ground-based infrastructure operators). These entities are subject to size thresholds—generally medium-sized or larger enterprises—though certain categories (qualified trust service providers, TLD registries, DNS service providers, and public electronic communications networks) are captured regardless of size.

Important entities encompass seven additional sectors defined in Annex II: postal and courier services, waste management, manufacture/production/distribution of chemicals, food production/processing/distribution, manufacturing of medical devices, computers, electronics, optical equipment, electrical equipment, machinery, motor vehicles, and other transport equipment, digital providers (online marketplaces, search engines, social networking platforms), and research organizations. Member states may also designate additional entities as essential or important based on national risk assessments.

Transposition Timeline and Member State Progress

NIS2 entered into force on 16 January 2023 and set a transposition deadline of 17 October 2024 for all 27 EU member states. National measures were required to apply from 18 October 2024. As of February 2025, the transposition landscape remains fragmented. Dark Angel’s monitoring of national legislative processes across all member states identifies three tiers of progress.

Completed transposition (8 member states as of January 2025): Belgium, Croatia, Hungary, Italy, Latvia, Lithuania, Luxembourg, and Slovenia have enacted national legislation implementing NIS2’s requirements. Italy’s Legislative Decree 138/2024, adopted in October 2024, is among the most comprehensive implementations, establishing the Agenzia per la Cybersicurezza Nazionale (ACN) as the sole competent authority and implementing a risk-based approach to entity identification. Belgium’s transposition through the Law of 26 April 2024 is notable for its early adoption and integration with the existing CCB (Centre for Cybersecurity Belgium) framework.

Advanced proceedings (11 member states): Austria, Czech Republic, Denmark, Finland, France, Ireland, Netherlands, Poland, Portugal, Romania, and Slovakia have legislation in parliamentary proceedings or final ministerial review. France’s transposition through amendments to the Code de la défense is expected in Q1 2025 and will designate ANSSI as the primary competent authority. The Netherlands’ Cyberbeveiligingswet (Cybersecurity Act) was published in draft form in June 2024 and is progressing through the Tweede Kamer.

Early stages or stalled (8 member states): Germany, Spain, Greece, Cyprus, Estonia, Malta, Bulgaria, and Sweden have not progressed beyond initial legislative drafting. Germany’s situation is particularly significant given the country’s economic weight: the NIS2 Implementation and Cybersecurity Strengthening Act (NIS2UmsuCG) was derailed by the collapse of the Ampel coalition government in November 2024 and will require reintroduction to the Bundestag following the February 2025 elections. Spain’s transposition is complicated by the distribution of cybersecurity competences between national and regional authorities.

The European Commission initiated infringement proceedings against 23 member states in November 2024 for failing to meet the transposition deadline. While these proceedings apply political pressure, they do not accelerate the practical timeline for legislative adoption. Organizations operating across multiple member states face the challenge of complying with a directive whose national implementations differ in scope, designated authorities, and enforcement mechanisms.

Key Differences from NIS1

Understanding NIS2’s evolution from its predecessor is essential for calibrating compliance efforts. The original NIS Directive (2016/1148) left substantial discretion to member states in identifying operators of essential services, defining incident reporting thresholds, and establishing supervisory frameworks. This produced a patchwork of 27 distinct national implementations with limited harmonization. NIS2 addresses these shortcomings through several structural changes: size-based entity identification replaces member state discretion for most sectors, ensuring consistent scope; harmonized incident reporting timelines (24-hour early warning, 72-hour notification, one-month final report) replace nationally defined thresholds; management body accountability under Article 20 introduces personal responsibility for senior leadership to approve and oversee cybersecurity risk-management measures; supply chain security is explicitly mandated under Article 21(2)(d), moving beyond NIS1’s limited vendor management provisions; and enforcement powers are substantially strengthened, with administrative fines modeled on GDPR’s percentage-of-turnover approach rather than NIS1’s inconsistent national penalty frameworks.

Mapping NIS2 Articles to Threat Intelligence Capabilities

The NIS2 Directive does not explicitly mandate “threat intelligence” as a named capability. However, multiple articles implicitly or explicitly require capabilities that can only be fulfilled through systematic threat intelligence operations. This section maps the directive’s key requirements to specific TI capabilities and identifies how Dark Angel’s platform modules address each obligation.

Article 21: Cybersecurity Risk-Management Measures

Article 21 constitutes the directive’s operational core, requiring entities to implement measures that are “appropriate and proportionate” to the risks they face. The article specifies minimum measures including risk analysis and information system security policies, incident handling, business continuity and crisis management, supply chain security, vulnerability handling and disclosure, and policies for the use of cryptography and encryption. Each of these measures requires threat intelligence to be effective. A risk analysis that does not account for the specific threat actors, TTPs, and campaign patterns targeting the entity’s sector and geography is performative rather than functional. Incident handling without contextual intelligence—indicators of compromise, adversary behavioral patterns, and attribution context—reduces response to reactive containment rather than informed remediation.

Article 23: Reporting Obligations

Article 23’s structured reporting cascade demands that entities detect, classify, and report significant incidents within compressed timelines. The 24-hour early warning requirement necessitates automated detection capabilities fed by current threat intelligence: organizations must determine whether an incident is “likely caused by unlawful or malicious acts” and whether it “could have a cross-border impact” within hours of detection. This determination requires contextual intelligence about active campaigns, known threat actor infrastructure, and indicators linked to coordinated attacks against multiple entities. Without current TI, organizations risk either over-reporting (consuming CSIRT resources with false positives) or under-reporting (failing to recognize incidents that meet notification thresholds).

Article 24: European Cybersecurity Certification Schemes

Article 24 empowers competent authorities to require essential and important entities to use certified ICT products, services, or processes. While the article does not directly mandate TI, the forthcoming European cybersecurity certification schemes under the EU Cybersecurity Act (Regulation 2019/881) will establish quality standards for security products and services—including, prospectively, threat intelligence feeds and platforms. Organizations should anticipate that TI procurement will increasingly require demonstrated adherence to European certification frameworks, particularly for TI used in regulatory reporting and risk assessment.

Incident Reporting Requirements and Threat Intelligence

NIS2’s incident reporting framework represents the most operationally demanding compliance obligation for most entities. Article 23 establishes a three-stage reporting cascade for “significant incidents”—defined as incidents that have caused or are capable of causing severe operational disruption or financial loss, or that have affected or are capable of affecting other natural or legal persons by causing considerable material or non-material damage. Each stage of the cascade creates distinct intelligence requirements.

24-Hour Early Warning

Within 24 hours of becoming aware of a significant incident, entities must submit an early warning to the relevant CSIRT or competent authority. The early warning must indicate whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact. This determination requires real-time threat intelligence capabilities that most organizations currently lack.

To assess whether an incident involves “unlawful or malicious acts,” responders must correlate observed indicators—network traffic patterns, malware artifacts, compromised credentials, lateral movement indicators—against current threat intelligence. Is the observed command-and-control infrastructure associated with known threat actor groups? Does the malware signature match variants deployed in other campaigns? Are the initial access vectors consistent with active exploitation campaigns? Without access to continuously updated intelligence feeds covering adversary infrastructure, malware families, and active campaigns, organizations cannot make these determinations with the speed and confidence the directive requires.

The cross-border impact assessment is equally intelligence-dependent. An organization must determine whether the incident could affect entities in other member states—a determination that requires understanding the threat actor’s campaign scope, identifying shared infrastructure or supply chain dependencies that could serve as attack propagation vectors, and assessing whether the same vulnerability or access vector is being exploited against entities in other jurisdictions. Dark Angel’s cross-border campaign tracking provides this context, correlating incident indicators against our intelligence holdings to identify whether an entity’s incident is part of a broader campaign affecting multiple European organizations.

72-Hour Incident Notification

The 72-hour incident notification expands on the early warning with an initial assessment of the incident including its severity and impact, and where available, indicators of compromise. This stage requires deeper intelligence analysis: correlating observed TTPs against adversary playbooks, mapping the incident to the MITRE ATT&CK framework, identifying the likely threat actor or campaign, and assessing the full scope of compromise. The notification must include an assessment of cross-border impact—not merely a suspicion as in the early warning, but a considered evaluation based on 48 additional hours of investigation enriched by threat intelligence.

At this stage, threat intelligence serves three critical functions. First, acceleration of scoping: understanding the threat actor’s known playbook allows responders to predict lateral movement paths, identify likely persistence mechanisms, and focus forensic analysis on the most probable compromise vectors rather than conducting exhaustive environment-wide searches. Second, impact assessment enrichment: intelligence about the threat actor’s historical behavior—whether they exfiltrate data before encryption, whether they target specific data types, whether they have sold access to other groups—informs the severity classification that the notification must include. Third, IOC generation and sharing: the notification should include indicators of compromise, which requires the ability to distinguish entity-specific indicators from broader campaign indicators that may benefit other organizations and the receiving CSIRT.

One-Month Final Report

The final report, due within one month of the incident notification (or sooner if the incident has concluded), must include a detailed description of the incident including its severity and impact, the type of threat or root cause that likely triggered the incident, applied and ongoing mitigation measures, and the cross-border impact where applicable. This is the most analytically demanding reporting stage and requires comprehensive threat intelligence integration.

The “type of threat or root cause” requirement effectively demands attribution—at minimum to a threat category (ransomware-as-a-service operation, state-sponsored espionage campaign, hacktivist DDoS) and ideally to a specific threat actor group or campaign. Accurate attribution at this stage requires the full intelligence lifecycle: collection of technical indicators during incident response, analysis of adversary infrastructure and malware against known threat actor profiles, and correlation with intelligence community reporting. Organizations that lack in-house attribution capability will need to procure this analysis from threat intelligence providers or rely on the receiving CSIRT’s assessment—which may not be available within the reporting timeline.

Supply Chain Security Under NIS2

Article 22: Coordinated Supply Chain Risk Assessments

Article 22 establishes a framework for coordinated security risk assessments of critical supply chains at the EU level, conducted by the Cooperation Group in cooperation with the Commission and ENISA. While these assessments are conducted at the institutional level rather than by individual entities, they generate risk intelligence that downstream organizations must incorporate into their own supply chain security programs. The first coordinated assessment under this provision, covering 5G supply chains, established a precedent that subsequent assessments are expected to follow for cloud services, semiconductor supply chains, and critical software dependencies.

For individual entities, Article 21(2)(d) imposes direct supply chain security obligations, requiring organizations to address “security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” This language is deliberately broad: it encompasses not only traditional IT vendor relationships but also cloud service dependencies, managed service provider arrangements, open source software components, and hardware supply chains. The directive further specifies that entities must take into account “the vulnerabilities specific to each direct supplier and service provider” and “the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures.”

Third-Party Vendor Monitoring

Compliance with these supply chain requirements demands continuous intelligence on the security posture, compromise status, and threat exposure of an entity’s vendor ecosystem. Static point-in-time vendor assessments—the predominant approach in current enterprise practice—are insufficient for NIS2 compliance. The directive’s emphasis on ongoing risk management requires dynamic monitoring capabilities that can detect vendor compromises, track threat actor campaigns targeting supplier industries, and identify concentration risks where multiple critical services depend on shared infrastructure.

Dark Angel’s approach to NIS2 supply chain compliance integrates three intelligence streams. Compromise detection monitors dark web forums, initial access broker marketplaces, and ransomware data leak sites for evidence that an entity’s suppliers have been compromised or are being targeted. Exposure monitoring tracks supplier credential leaks, misconfigured assets, and externally visible security weaknesses that indicate degraded security posture. Campaign intelligence identifies active threat campaigns targeting supplier industries—such as the Cl0p exploitation of managed file transfer appliances that cascaded through thousands of downstream organizations—enabling proactive risk assessment before compromise occurs.

TI Role in Supply Chain Risk Assessment

Effective supply chain risk assessment under NIS2 requires threat intelligence at three levels of analysis. At the strategic level, organizations need intelligence on geopolitical risks affecting supply chains—sanctions exposure, state-sponsored compromise of vendors headquartered in adversarial jurisdictions, and regulatory fragmentation risks where suppliers operate across jurisdictions with divergent NIS2 implementations. At the operational level, TI must track active campaigns targeting the specific technologies, platforms, and service categories within the entity’s supply chain: ongoing exploitation campaigns against Ivanti, Fortinet, or Citrix appliances used by MSPs; ransomware affiliate recruitment specifically targeting access to managed service provider networks; and zero-day vulnerabilities in widely deployed enterprise software. At the tactical level, organizations require real-time IOC feeds that include indicators associated with supply chain compromise techniques—trojanized software updates, compromised code signing certificates, and malicious modifications to open source libraries.

Sector-Specific Requirements

Essential Entities: Sectors of High Criticality

Each essential entity sector under NIS2 Annex I presents distinct threat intelligence requirements driven by sector-specific threat landscapes, regulatory overlaps, and operational characteristics.

Energy (electricity, oil, gas, hydrogen, district heating/cooling): Energy entities face the highest-consequence threat environment among NIS2 sectors, with confirmed Russian state-sponsored pre-positioning in European energy OT networks and a history of destructive attacks against Ukrainian energy infrastructure that could serve as templates for Western European operations. TI requirements include OT-specific threat intelligence covering ICS/SCADA-targeting malware families (Industroyer2, CosmicEnergy, FrostyGoop), geopolitical risk intelligence linked to energy policy decisions, and physical-cyber convergence analysis for assets with both IT and OT exposure. Energy entities should note the regulatory overlap with the EU Critical Entities Resilience Directive (CER), which imposes physical security obligations that complement NIS2’s cyber requirements.

Transport (air, rail, water, road): European transport operators face combined ransomware, hacktivist, and state-sponsored threats. Rail operators have been particularly targeted—the 2023 attacks on Polish railway systems and sustained NoName057(16) DDoS campaigns against European aviation and rail websites demonstrate the sector’s exposure. TI requirements include OT intelligence for signalling and control systems, real-time DDoS campaign tracking, and geopolitical risk analysis for transport corridors affected by the Russia-Ukraine conflict.

Banking and financial market infrastructures: Financial entities subject to NIS2 face concurrent obligations under DORA (Regulation 2022/2554), which imposes more granular requirements including threat-led penetration testing. TI requirements must satisfy both frameworks: DORA’s TLPT requirement demands entity-specific threat intelligence for red team scenario design, while NIS2’s broader risk management obligations require financial sector threat landscape assessments and supply chain intelligence covering ICT service providers. Organizations should consolidate TI procurement across both regulatory frameworks to avoid duplication.

Health: Healthcare entities face an acute tension between NIS2 compliance obligations and operational constraints. Hospital IT environments are characterized by legacy medical devices that cannot be patched, complex integration requirements between clinical systems, and limited cybersecurity budgets relative to the sector’s critical importance. The Synnovis (Qilin) attack demonstrated the cascading impact of supply chain compromise in healthcare. TI requirements include ransomware targeting intelligence specific to healthcare, medical device vulnerability tracking, and supply chain intelligence covering healthcare IT vendors and managed service providers serving the sector.

Digital infrastructure and ICT service management: The inclusion of MSPs and MSSPs as essential entities is one of NIS2’s most consequential provisions. These entities serve as force multipliers for threat actors: a single MSP compromise can cascade to dozens or hundreds of downstream organizations. TI requirements include monitoring for initial access broker listings targeting MSP platforms (ConnectWise, Kaseya, Datto), ransomware affiliate recruitment specifically targeting MSP access, and continuous assessment of the MSP’s own attack surface exposure.

Public administration and space: Central government entities face the most diverse threat landscape, encompassing state-sponsored espionage (APT28, APT29, APT31 campaigns against EU government networks), hacktivism (sustained DDoS campaigns against government portals), and ransomware targeting municipal and regional government entities. Space sector ground infrastructure operators face niche but high-consequence threats from state-sponsored actors with anti-satellite and signals intelligence objectives.

Important Entities: Other Critical Sectors

Important entities under NIS2 Annex II face identical risk management obligations but lighter supervisory oversight. However, several of these sectors present significant threat intelligence challenges.

Manufacturing (medical devices, computers, electronics, electrical equipment, machinery, motor vehicles): Manufacturing is Europe’s most ransomware-targeted sector, accounting for 22% of all European ransomware incidents in 2024. The sector’s combination of OT exposure, intellectual property value, and operational disruption sensitivity makes it a high-priority target for both ransomware operators and state-sponsored espionage groups (particularly APT41/Winnti targeting semiconductor and automotive IP). TI requirements include industrial sector ransomware intelligence, OT threat monitoring, and IP theft campaign tracking.

Food production and distribution: Food supply chain security has gained prominence following pandemic-era disruptions and ongoing geopolitical supply chain fragility. While direct cyber targeting of food production is less frequent than other sectors, the industry’s reliance on logistics technology, ERP systems, and just-in-time inventory management creates vulnerability to ransomware and supply chain compromise.

Digital providers (online marketplaces, search engines, social networking platforms): These entities face unique obligations given their scale and cross-border nature. Threat intelligence requirements include platform abuse monitoring, coordinated inauthentic behavior detection, and vulnerability intelligence for the complex technology stacks underlying these services.

Building a NIS2-Compliant Threat Intelligence Program

Maturity Assessment Framework

Dark Angel recommends organizations assess their TI program maturity against a five-level framework aligned with NIS2’s risk-based approach. This framework is adapted from the CREST Cyber Threat Intelligence Maturity Model and calibrated for European regulatory requirements.

Required Capabilities Checklist

Based on Dark Angel’s analysis of NIS2’s TI-dependent requirements, organizations should ensure the following capabilities are operational or under procurement.

1. Automated IOC ingestion and correlation—continuous integration of tactical threat intelligence (IP addresses, domains, file hashes, URLs) into detection platforms (SIEM, EDR, NDR, firewalls) with automated correlation against observed network activity and endpoint telemetry.
2. Incident classification engine—automated or semi-automated capability to classify detected incidents against NIS2 significance thresholds, assess cross-border impact potential, and generate preliminary notification content within the 24-hour early warning timeline.
3. Sector-specific threat landscape reporting—regular strategic intelligence assessments covering the threat actors, campaigns, and TTPs specifically targeting the entity’s sector and geographic operating environment, supporting the Article 21 risk analysis requirement.
4. Supply chain intelligence monitoring—continuous monitoring of the entity’s critical supplier ecosystem for compromise indicators, credential exposures, vulnerability disclosures, and threat actor targeting, supporting Article 21(2)(d) supply chain security obligations.
5. Vulnerability intelligence with prioritization—enriched vulnerability feeds that contextualize CVEs with exploitation status, threat actor adoption, and relevance to the entity’s specific technology stack, supporting Article 21(2)(e) vulnerability handling requirements.
6. Attribution and campaign tracking—capability to associate observed indicators with known threat actor groups and active campaigns, supporting the Article 23 final report requirement to identify the “type of threat or root cause.”
7. Regulatory reporting templates and workflows—pre-configured notification templates aligned with the national implementation of NIS2 in each jurisdiction where the entity operates, integrated into incident response playbooks to ensure reporting timelines are met under operational pressure.
8. Intelligence sharing capability—technical and procedural readiness to participate in sectoral information sharing and analysis centres (ISACs), the CSIRT network, and Article 29 voluntary information sharing arrangements, using standardized formats (STIX/TAXII) and appropriate handling markings (TLP).

Integration with Existing Security Operations

NIS2 compliance does not require organizations to build a standalone threat intelligence program from scratch. For most entities, the optimal approach integrates external threat intelligence services into existing security operations workflows. The key integration points are: SIEM/SOAR platforms (for automated IOC correlation and incident classification), vulnerability management programs (for threat-informed prioritization), risk management frameworks (for strategic threat context), incident response procedures (for attribution support and regulatory reporting), and board-level reporting (for translating technical threat intelligence into governance-ready risk assessments that satisfy Article 20’s management body accountability requirements).

Defensive Recommendations

Dark Angel recommends the following prioritized actions for organizations navigating NIS2 compliance with a focus on threat intelligence readiness.

1. Conduct a NIS2 scope assessment immediately. Determine whether your organization qualifies as an essential or important entity under the directive, considering both the sector classifications in Annexes I and II and the size thresholds. If your organization operates across multiple member states, identify the applicable national implementations and designated competent authorities for each jurisdiction. Do not wait for completed national transposition—the directive’s requirements are sufficiently clear to begin compliance programs now.
2. Assess TI maturity against NIS2 requirements. Use the five-level maturity framework in this report to identify gaps between your current threat intelligence capabilities and the capabilities required for NIS2 compliance. Prioritize closing gaps in automated incident classification (required for the 24-hour early warning), supply chain monitoring (required under Article 21(2)(d)), and attribution capability (required for the one-month final report).
3. Integrate threat intelligence into incident response playbooks. Map the NIS2 reporting cascade into your IR procedures, with specific decision points for determining incident significance, assessing cross-border impact, and generating regulatory notifications. Pre-draft notification templates for each applicable national authority. Conduct tabletop exercises that incorporate the reporting cascade under realistic time pressure.
4. Establish supply chain intelligence monitoring. Identify your critical suppliers and service providers as defined by Article 21(2)(d). Implement continuous monitoring for compromise indicators, credential exposures, and threat actor targeting of your vendor ecosystem. Ensure that vendor contracts include cybersecurity obligations, incident notification provisions, and audit rights consistent with NIS2’s requirements.
5. Procure European-focused threat intelligence. NIS2 is a European regulation addressing threats to European entities. Generic global TI feeds lack the granularity needed for compliance: you need intelligence that covers European threat actors, European victim sectors, European regulatory developments, and European CSIRT reporting requirements. Evaluate TI providers against their European coverage depth, including language capabilities across member states, relationships with national CSIRTs, and understanding of the European regulatory landscape.
6. Prepare for Article 20 management accountability. Establish board-level threat intelligence reporting that translates technical TI into governance-ready risk assessments. Ensure that management bodies receive regular briefings on the threat landscape facing the organization, the effectiveness of risk-management measures assessed against threat intelligence, and the organization’s readiness to meet incident reporting obligations. Document these briefings to demonstrate compliance with the management body approval and training requirements.
7. Engage with sectoral ISACs and the CSIRT network. NIS2’s emphasis on information sharing (Articles 14, 15, and 29) creates both obligations and opportunities. Active participation in sectoral information sharing arrangements provides access to peer intelligence, amplifies your organization’s detection capabilities through shared indicators, and demonstrates compliance with the directive’s cooperative intent. Ensure your TI platform supports standardized sharing formats (STIX 2.1, TAXII 2.1) and handling markings (TLP 2.0).
8. Plan for regulatory convergence. Organizations subject to both NIS2 and DORA should consolidate TI procurement and reporting processes. Entities in sectors covered by sector-specific cybersecurity requirements (such as the European Health Data Space regulation for healthcare or the CER Directive for critical entities) should map these overlapping obligations to identify synergies and avoid duplicative compliance workstreams. The European Commission’s implementing acts under NIS2, expected throughout 2025, will further specify technical and methodological requirements that should be monitored and incorporated into compliance programs.

Methodology

This report is based on Dark Angel’s systematic analysis of the NIS2 Directive’s threat intelligence implications, drawing on the following sources and methodologies.

Legislative Analysis: Direct textual analysis of Directive (EU) 2022/2555 (NIS2), its recitals, and annexes, with cross-referencing against the original NIS Directive (2016/1148), DORA (Regulation 2022/2554), the EU Cybersecurity Act (Regulation 2019/881), and the CER Directive (2022/2557). National transposition legislation was analyzed for all eight member states that had completed transposition by January 2025, with draft legislation reviewed for an additional six member states.

Regulatory Engagement: Dark Angel participated in consultations with national competent authorities and CSIRTs in 14 EU member states during 2024, providing input on threat intelligence requirements for incident classification, reporting procedures, and supervisory frameworks. These engagements informed our understanding of how national authorities interpret the directive’s TI-dependent requirements in practice.

Compliance Readiness Assessment: Dark Angel conducted NIS2 readiness assessments with 120 European organizations across 9 sectors during Q3–Q4 2024. These assessments evaluated organizations’ threat intelligence capabilities against the directive’s requirements using the maturity framework presented in this report. Aggregate findings are reported; individual organizational data is not disclosed.

Threat Landscape Correlation: The TI capability requirements identified in this report are validated against Dark Angel’s operational threat intelligence, including analysis of 1,694 European ransomware incidents in 2024, tracking of 23 state-sponsored threat actor groups targeting European entities, and monitoring of underground marketplaces for initial access broker listings affecting NIS2-scoped sectors. This correlation ensures that compliance recommendations are grounded in the actual threat environment rather than theoretical risk constructs.

Confidence Framework: Compliance mapping assessments in this report carry high confidence where based on explicit directive text and completed national transposition. Assessments of forthcoming implementing acts, member state implementation timelines, and enforcement approaches carry moderate confidence based on publicly available legislative proceedings and regulatory consultations. Threat intelligence capability assessments are validated against operational experience and carry high confidence.

Related Reports

• European Cyber Threat Landscape 2025 — Strategic assessment of state-sponsored, ransomware, hacktivist, and supply chain threats facing European organizations.
• DORA ICT Risk & Threat Intelligence: Financial Sector Compliance — Deep-dive into DORA’s threat intelligence, TLPT, and ICT risk management requirements for financial entities.
• Supply Chain & Third-Party Risk Intelligence — Comprehensive analysis of supply chain compromise trends, vendor risk monitoring, and TI-driven third-party risk management.