DORA ICT Risk Management: A Threat Intelligence Approach

DORA Overview: Purpose and Scope

Regulatory Context and Objectives

DORA emerged from the European Commission’s recognition that the financial sector’s digital transformation had outpaced its regulatory resilience framework. The September 2020 Digital Finance Package proposed DORA as a response to three interrelated challenges: the growing dependence of financial services on ICT systems and third-party providers, the increasing sophistication of cyber threats targeting financial infrastructure, and the fragmented national approaches to ICT risk management that left systemic vulnerabilities unaddressed. The regulation’s legislative journey through the European Parliament and Council concluded with adoption in November 2022, followed by a two-year implementation period that ended on 17 January 2025.

DORA’s objectives are explicitly forward-looking. Rather than mandating compliance with a static set of security controls, the regulation establishes a dynamic resilience framework that requires entities to continuously assess, test, and adapt their ICT risk management capabilities against an evolving threat landscape. This threat-adaptive approach is precisely what makes threat intelligence not merely useful but structurally essential for compliance—without systematic intelligence on the threats facing the financial sector, entities cannot demonstrate the proportionate and risk-based approach that DORA demands.

Applicable Entities

DORA’s scope is deliberately comprehensive. Article 2 defines 21 categories of in-scope financial entities: credit institutions, payment institutions (including those exempt under PSD2), account information service providers, electronic money institutions, investment firms, crypto-asset service providers and issuers of asset-referenced tokens, central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds and management companies, data reporting service providers, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, and securitisation repositories. Crucially, DORA also brings ICT third-party service providers within regulatory scope—those designated as “critical” by the European Supervisory Authorities face direct oversight, while all ICT providers serving financial entities must comply with contractual requirements mandated by the regulation.

The Five Pillars of Digital Operational Resilience

DORA is structured around five interconnected pillars, each addressing a distinct dimension of digital operational resilience. Together, they form a comprehensive framework that extends from internal risk governance to external testing, vendor oversight, and cross-sector intelligence sharing. The following section examines each pillar in detail and maps the specific threat intelligence capabilities required for compliance.

DORA’s Five Pillars and Threat Intelligence

Pillar 1: ICT Risk Management Framework

Articles 5–16 establish DORA’s ICT risk management framework, requiring financial entities to maintain a comprehensive, documented, and continuously updated ICT risk management process. Article 6 mandates an ICT risk management framework that includes strategies, policies, procedures, and tools necessary to protect all information assets and ICT assets, including computer software, hardware, and servers. The framework must be reviewed at least annually and updated following major ICT-related incidents or TLPT findings.

Threat intelligence is structurally embedded in this pillar. Article 7 requires entities to “identify, classify and adequately document all ICT supported business functions, roles and responsibilities” and “identify all sources of ICT risk.” Identifying sources of ICT risk without understanding the threat landscape—which actors target financial entities, what techniques they employ, what vulnerabilities they exploit, and what assets they prioritize—is a fundamentally incomplete exercise. Article 9’s protection and prevention requirements demand that entities implement security measures that are “up to date” and capable of protecting against “reasonably identifiable” threats, language that implicitly requires current threat intelligence to define the boundary of what is “reasonably identifiable.”

Article 10 mandates detection capabilities that can “promptly detect anomalous activities” including network performance issues and ICT-related incidents. Effective detection requires threat intelligence integration at the tactical level: current indicators of compromise, behavioral detection rules derived from adversary TTP analysis, and contextual intelligence that enables analysts to distinguish true positive detections from benign anomalies. The RTS on ICT risk management framework (published by the ESAs in January 2024) further specifies that entities must consider “the threat landscape and cyber threat intelligence” in their risk assessments, making the intelligence requirement explicit in the implementing technical standards.

Pillar 2: ICT-Related Incident Management

Articles 17–23 establish a harmonized incident management and reporting framework. Financial entities must implement an incident management process to detect, manage, and notify ICT-related incidents, with a classification taxonomy based on criteria including the number of clients affected, the duration of the incident, the geographic spread, data losses, the criticality of services affected, and the economic impact. Major incidents must be reported to competent authorities through a structured cascade: an initial notification within 4 hours of classifying the incident as major (or within 24 hours of detection), an intermediate report within 72 hours, and a final report within one month.

Threat intelligence serves three critical functions within this pillar. First, detection acceleration: integration of current TI feeds into detection platforms (SIEM, EDR, network detection) enables entities to identify adversary activity earlier in the kill chain, reducing dwell time and limiting the scope of incidents before they escalate to major classification. Second, classification support: determining whether an incident meets DORA’s major incident thresholds requires understanding the threat actor’s likely objectives, capability, and historical patterns. A credential theft campaign by a financially motivated access broker has different escalation trajectories than a state-sponsored espionage operation targeting SWIFT-connected systems. Intelligence context enables accurate severity classification. Third, root cause analysis: the final report must identify the root cause and describe remediation actions—a requirement that implicitly demands attribution capability and understanding of the adversary’s access methodology.

Pillar 3: Digital Operational Resilience Testing

Articles 24–27 establish a tiered testing framework. All in-scope entities must conduct basic resilience testing—including vulnerability assessments, network security assessments, physical security reviews, and open-source intelligence analysis—at least annually. Entities identified as significant (based on systemic importance, ICT risk profile, and scale) must additionally conduct threat-led penetration testing (TLPT) at least every three years. TLPT is examined in detail in the dedicated section below.

Threat intelligence is explicitly required for TLPT under Article 26, which mandates that tests be based on “real and current threat intelligence” covering “a range of scenarios, including the most severe but plausible scenarios.” Even for basic testing, threat intelligence enhances the value and relevance of assessments: vulnerability scans prioritized by actively exploited CVEs, penetration tests guided by TTPs relevant to the financial sector, and open-source intelligence assessments that reflect actual adversary reconnaissance techniques.

Pillar 4: ICT Third-Party Risk Management

Articles 28–44 establish the most granular ICT third-party risk management framework in European regulation. Financial entities must maintain a register of all contractual arrangements with ICT third-party service providers, conduct risk assessments before entering into arrangements, ensure contracts contain minimum security provisions (including incident notification obligations, audit rights, and exit strategies), and manage concentration risk arising from dependency on critical ICT providers. The ESAs may designate ICT providers as “critical” under Article 31, subjecting them to a direct EU-level oversight framework administered by a Lead Overseer. This pillar is examined in detail in the dedicated section below.

Pillar 5: Information Sharing

Article 45 establishes a voluntary framework for financial entities to exchange cyber threat intelligence among themselves and with competent authorities. The article explicitly names “indicators of compromise, tactics, techniques and procedures, cybersecurity alerts and configuration tools” as shareable intelligence types. While participation is voluntary, the regulatory intent is clear: entities that actively participate in intelligence sharing communities demonstrate a more mature approach to digital operational resilience. In practice, entities that consume but do not contribute to intelligence sharing ecosystems receive less value from participation and may face supervisory scrutiny regarding the adequacy of their threat awareness.

Threat-Led Penetration Testing (TLPT)

TIBER-EU Framework Alignment

DORA’s TLPT requirements (Article 26) are explicitly aligned with the Threat Intelligence-Based Ethical Red Teaming (TIBER-EU) framework, which the ECB originally developed in 2018 for voluntary adoption by significant financial institutions. DORA elevates TIBER-EU from a voluntary best practice to a regulatory mandate for entities deemed significant by their competent authorities. The RTS on TLPT (published in July 2024) specifies that tests must follow the TIBER-EU methodology unless national frameworks meeting equivalent standards exist.

A TIBER-EU engagement involves three distinct phases, each with specific threat intelligence requirements. The preparation phase establishes the scope, identifies critical functions, and commissions the threat intelligence provider. The testing phase encompasses the production of a Targeted Threat Intelligence (TTI) report by the TI provider and the execution of the red team engagement based on that intelligence. The closure phase includes the production of a test summary report, a remediation plan, and supervisor review.

The Role of Threat Intelligence Providers in TLPT

The TI provider’s role in TIBER-EU/DORA TLPT is structurally distinct from standard threat intelligence delivery. The provider must produce a Targeted Threat Intelligence Report that identifies the specific threat actors most likely to target the tested entity, analyzes their capabilities and intent, maps their known TTPs to the MITRE ATT&CK framework, and develops realistic attack scenarios that the red team will execute. This requires intelligence that is entity-specific rather than generic: understanding the target’s business profile, technology stack, geographic footprint, and position within the broader financial ecosystem to determine which adversaries have the motivation, capability, and access to attack the specific entity.

The TTI report must cover three intelligence dimensions. Strategic intelligence provides the geopolitical and threat landscape context: which nation-state actors target the entity’s sub-sector, what financially motivated groups are actively campaigning against similar institutions, and what hacktivist collectives may target the entity for ideological reasons. Operational intelligence maps the adversaries’ known operational patterns: infrastructure preferences, initial access techniques, lateral movement playbooks, persistence mechanisms, and data exfiltration methods. Tactical intelligence provides the specific technical indicators and tool signatures that the red team may emulate: malware families, C2 frameworks, phishing templates, and exploitation techniques currently in active use by the identified threat actors.

Threat Landscape Scenario Development

DORA Article 26(2) requires TLPT to cover “several or all critical or important functions of a financial entity” and be performed on “live production systems.” The attack scenarios derived from the TTI report must therefore be operationally realistic: they must reflect how actual adversaries would approach the entity, not theoretical attack paths. This demands intelligence-driven scenario development that considers the entity’s actual attack surface (externally exposed infrastructure, employee credentials available on dark web marketplaces, social engineering vectors derived from open-source reconnaissance), the current tool availability of identified threat actors (which initial access brokers sell access to the entity’s sector, which ransomware affiliates target financial institutions), and the entity’s specific defensive posture (which controls must the red team bypass, which detection capabilities must the scenarios test).

Dark Angel’s TLPT intelligence packages integrate these dimensions into scenario matrices that map each identified threat actor to a set of attack chains aligned with the entity’s critical functions. Each scenario includes specific MITRE ATT&CK technique sequences, recommended tool emulations, and success criteria that allow the red team to produce findings directly relevant to DORA’s resilience testing objectives.

ICT Third-Party Risk Management

Critical ICT Service Provider Oversight

DORA establishes the first EU-level direct oversight framework for critical ICT service providers. Under Articles 31–44, the European Supervisory Authorities (EBA, ESMA, EIOPA) may designate an ICT third-party service provider as “critical” based on the systemic impact that a widespread operational failure or inability to provide services would have on the financial entities it serves. Designation criteria include the number and systemic importance of financial entities relying on the provider, the degree of substitutability, and the provider’s importance for the performance of critical or important functions.

Designated critical ICT providers are subject to an oversight framework administered by a Lead Overseer (one of the three ESAs), which has powers to request information, conduct general investigations and inspections, issue recommendations, and—if recommendations are not followed—issue public notices or request competent authorities to take action against financial entities that continue using the non-compliant provider. As of early 2025, the ESAs have initiated the designation process for major cloud service providers (including hyperscalers offering financial services infrastructure), global market data providers, and core banking platform vendors.

Concentration Risk Analysis

Article 29 requires financial entities to assess and manage concentration risk arising from ICT third-party dependencies. This includes concentration at the entity level (excessive reliance on a single provider for multiple critical functions), the sub-group or group level (where multiple group entities depend on the same provider), and the sectoral level (where a significant proportion of the financial sector depends on a single provider). The European Systemic Risk Board’s January 2024 analysis identified cloud infrastructure as the primary concentration risk vector: three hyperscale providers (AWS, Azure, and Google Cloud) collectively serve an estimated 72% of European financial entities that have adopted cloud services, creating single points of failure at the systemic level.

Threat intelligence directly supports concentration risk assessment by providing empirical evidence of the consequences of provider compromise. When CrowdStrike’s faulty channel update in July 2024 caused global disruptions affecting an estimated 8.5 million Windows systems, financial entities with concentration risk in CrowdStrike-dependent infrastructure experienced cascading service outages. TI-informed concentration risk analysis would have identified the systemic exposure: the same EDR agent deployed across critical infrastructure, the same update channel trusted without staged deployment, the same vendor dependency across business continuity and primary systems. Intelligence on provider-specific risks—historical incidents, vulnerability exposure, threat actor targeting of specific platforms—enables entities to quantify concentration risk with empirical grounding rather than theoretical models.

Sub-Outsourcing Monitoring

DORA’s third-party risk framework extends beyond direct contractual relationships. Article 29(2) requires entities to take into account “the risks which may arise from sub-outsourcing arrangements,” where an ICT provider further delegates services to its own sub-contractors. This creates a supply chain depth problem that traditional vendor assessments cannot address: an entity may have contractual visibility into its direct cloud provider, but limited insight into the cloud provider’s dependencies on specific hardware manufacturers, DNS providers, certificate authorities, or managed infrastructure services.

Threat intelligence addresses this visibility gap through infrastructure reconnaissance and dependency mapping. Dark Angel’s Supply Chain Monitor continuously maps the sub-outsourcing chains of major ICT providers serving the financial sector, identifying fourth- and fifth-party dependencies that entities may not be aware of through contractual disclosure alone. When a sub-outsourced component is compromised—as occurred in the 2020 SolarWinds supply chain attack, which affected multiple financial sector entities through downstream provider dependencies—intelligence-driven monitoring enables early detection and risk assessment.

How Threat Intelligence Identifies Vendor Compromise Early

The operational value of threat intelligence for ICT third-party risk management lies in its ability to detect provider compromise or degraded security posture before the provider self-reports or the compromise cascades to the financial entity. Dark Angel monitors multiple intelligence streams for early warning indicators: dark web marketplace activity where initial access brokers sell credentials or VPN access to ICT provider networks; ransomware leak site monitoring for claims against ICT providers; credential exposure tracking that identifies leaked employee credentials from ICT providers in infostealer logs; vulnerability exposure scanning that detects unpatched externally-facing infrastructure at provider organisations; and code repository monitoring for exposed API keys, internal infrastructure details, or customer data inadvertently committed to public repositories by provider employees.

Financial Sector Threat Landscape Context

DORA’s requirements do not exist in a regulatory vacuum—they respond to a demonstrable and escalating threat environment targeting European financial services. Dark Angel’s operational intelligence identifies several principal threat categories that DORA-obligated entities must address.

Banking Trojans and Credential Harvesting

The European financial sector faces sustained campaigns from banking trojan operators that have evolved significantly beyond their original browser manipulation techniques. Modern variants—including Grandoreiro, which expanded from Latin America to European targets in 2024, and the persistent Emotet/IcedID ecosystem serving as initial access for deeper intrusions—employ overlay attacks, session hijacking, and MFA interception to compromise both retail and corporate banking platforms. Infostealer malware (Raccoon, RedLine, Lumma, Vidar) operating as malware-as-a-service platforms harvest banking credentials at industrial scale: Dark Angel’s analysis of infostealer logs in 2024 identified 2.3 million compromised European banking credentials across 847 financial institutions, with corporate treasury and trade finance platforms disproportionately represented.

SWIFT and Payment System Targeting

State-sponsored threat actors, particularly those attributed to the DPRK (Lazarus Group/APT38), continue to target interbank payment systems and SWIFT-connected infrastructure. While the Bangladesh Bank attack in 2016 remains the most high-profile SWIFT compromise, Dark Angel tracks ongoing reconnaissance and pre-positioning activity against European correspondent banking networks. The introduction of ISO 20022 messaging standards and the migration of payment systems to API-based architectures creates new attack surfaces that adversaries are actively researching. DORA’s requirement for entities to identify and protect critical ICT assets is directly relevant: SWIFT infrastructure, payment processing systems, and real-time gross settlement connections represent the highest-consequence targets within financial entities.

Ransomware Impact on Financial Services

While financial services is not the most frequently targeted sector for ransomware (manufacturing, healthcare, and professional services see higher volumes), the sector faces disproportionate consequences from successful attacks due to regulatory reporting obligations, reputational sensitivity, and the real-time nature of financial operations. The LockBit ransomware affiliate attack on ICBC Financial Services (the US subsidiary of the Industrial and Commercial Bank of China) in November 2023 disrupted US Treasury market operations and required ICBC to route trades through an alternative broker. In Europe, multiple banking institutions and payment processors experienced ransomware incidents in 2024, with DORA’s incident reporting timelines adding compliance pressure to already stressful operational recovery processes.

Building a DORA-Compliant Threat Intelligence Program

Gap Analysis Framework

Financial entities approaching DORA compliance should conduct a structured gap analysis that maps their existing threat intelligence capabilities against each pillar’s requirements. Dark Angel’s DORA TI Readiness Assessment evaluates organizations across four dimensions: Intelligence Collection (breadth and depth of sources, including dark web, technical feeds, OSINT, HUMINT, and commercial intelligence services); Analysis and Production (ability to produce strategic, operational, and tactical intelligence products relevant to the entity’s risk profile); Dissemination and Integration (automation of intelligence delivery into security operations, risk management, and governance processes); and Feedback and Measurement (mechanisms to evaluate intelligence utility, coverage gaps, and continuous improvement).

Across 78 DORA readiness assessments conducted by Dark Angel in 2024, the most common gaps were: insufficient entity-specific threat intelligence for TLPT (83% of assessed entities relied on generic threat profiles), absence of automated incident classification against DORA thresholds (71%), inadequate supply chain intelligence covering ICT third-party providers (68%), and no structured intelligence sharing participation (62%). Smaller entities—particularly payment institutions, insurance intermediaries, and crypto-asset service providers—exhibited the most significant gaps, reflecting both resource constraints and the novelty of DORA’s requirements for entities that were previously outside the scope of sectoral cybersecurity regulation.

Required TI Capabilities

A DORA-compliant threat intelligence program must deliver capabilities across three horizons. At the tactical horizon (hours to days), entities need automated IOC feeds integrated with detection infrastructure, covering adversary infrastructure, malware signatures, phishing domains, and credential compromise indicators specific to the financial sector. At the operational horizon (days to weeks), entities require campaign tracking and TTP analysis that informs defensive posture adjustments—such as reconfiguring detection rules when a new ransomware affiliate begins targeting European banks, or updating phishing detection when a new banking trojan campaign launches. At the strategic horizon (weeks to months), entities need threat landscape assessments that inform risk management decisions, TLPT scenario design, and board-level risk reporting required under DORA’s governance provisions.

Regulatory Reporting Integration

DORA’s incident reporting cascade (initial notification within 4 hours of major incident classification, intermediate report within 72 hours, final report within one month) demands that threat intelligence be integrated directly into incident response workflows. The initial notification must include a preliminary classification of the incident type—a determination that requires intelligence context to distinguish between, for example, a commodity ransomware attack and a targeted intrusion by a state-sponsored actor. The intermediate report must include indicators of compromise—which should be enriched with intelligence context on associated campaigns and threat actors. The final report must identify the root cause—a requirement that often demands attribution analysis drawing on strategic and operational intelligence.

Dark Angel recommends that financial entities pre-integrate their threat intelligence platform with their incident reporting workflow, creating automated enrichment pipelines that populate reporting templates with relevant intelligence context as an incident progresses through the response lifecycle. This integration reduces the manual analytical burden during incidents and ensures that reporting timelines are achievable without sacrificing intelligence quality.

Defensive Recommendations

Dark Angel recommends the following prioritized actions for financial entities and ICT service providers subject to DORA.

1. Establish an ICT risk management framework with embedded threat intelligence. Ensure that your Article 6 ICT risk management framework explicitly incorporates threat intelligence as an input to risk identification, assessment, and mitigation. The framework should reference specific intelligence sources, define how threat landscape changes trigger risk reassessment, and establish governance mechanisms for escalating intelligence-derived risks to the management body. Document the intelligence lifecycle within the framework to demonstrate compliance with the RTS requirement to consider “the threat landscape and cyber threat intelligence.”
2. Implement automated incident classification against DORA thresholds. Map DORA’s major incident classification criteria (Article 18) into your SIEM/SOAR workflows. Pre-configure detection rules that flag incidents potentially meeting major classification thresholds, trigger automated enrichment with threat intelligence context, and generate preliminary notification content. Conduct monthly exercises to validate that the 4-hour initial notification timeline is achievable under realistic incident conditions.
3. Procure entity-specific threat intelligence for TLPT. If your entity is likely to be designated for TLPT by your competent authority, begin procuring threat intelligence now. Select a TI provider with demonstrated capability in producing entity-specific Targeted Threat Intelligence reports—not merely repackaged open-source analysis. Evaluate providers against their financial sector domain expertise, proprietary intelligence collection capabilities, TIBER-EU experience, and ability to produce MITRE ATT&CK-mapped attack scenarios.
4. Build a comprehensive ICT third-party provider register with intelligence enrichment. Establish the register of all ICT contractual arrangements required by Article 28(3). Enrich this register with threat intelligence on each provider’s security posture: credential exposures, dark web mentions, vulnerability exposure, ransomware targeting, and concentration risk indicators. Implement continuous monitoring so that the register reflects current risk rather than point-in-time assessment data.
5. Map sub-outsourcing chains for critical ICT providers. For providers supporting critical or important functions, conduct intelligence-driven mapping of sub-outsourcing dependencies to identify fourth- and fifth-party risks that contractual disclosure alone may not reveal. Assess concentration risk at each level of the outsourcing chain and develop contingency plans for scenarios where a sub-outsourced component fails or is compromised.
6. Participate actively in financial sector intelligence sharing. Join the European FS-ISAC chapter and relevant national financial sector CERTs. Implement STIX/TAXII integration for automated intelligence sharing. Establish internal policies for TLP-compliant intelligence dissemination. Active participation not only enhances your intelligence coverage but demonstrates the “mature and responsible” approach to information sharing that DORA Article 45 envisions and that supervisors will increasingly expect.
7. Prepare board-level reporting on ICT risk and threat intelligence. DORA Article 5(2) requires the management body to bear “ultimate responsibility for the management of the financial entity’s ICT risk.” Establish regular board reporting that translates threat intelligence into governance-ready risk assessments: current threat landscape facing the entity, effectiveness of risk management measures validated against intelligence, incident trends and response performance, and third-party risk posture. Document these briefings to satisfy supervisory expectations regarding management body oversight.
8. Consolidate DORA and NIS2 compliance workstreams. Financial entities should avoid building separate compliance programs for DORA and NIS2. Map the overlapping requirements, designate DORA as the primary framework for ICT matters (as established by the lex specialis principle), and ensure that threat intelligence procurement, incident reporting processes, and third-party risk management are designed to satisfy both regulatory frameworks simultaneously.

Methodology

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

Regulatory Analysis: Direct textual analysis of Regulation (EU) 2022/2554 (DORA), its recitals, and the Regulatory Technical Standards and Implementing Technical Standards published by the European Supervisory Authorities (EBA, ESMA, EIOPA) throughout 2023–2024. Cross-referencing was conducted against the NIS2 Directive (2022/2555), TIBER-EU framework documentation, national TLPT framework guidance from 9 member states, and EBA Guidelines on ICT and Security Risk Management (EBA/GL/2019/04) which DORA supersedes.

Financial Sector Engagement: Dark Angel conducted DORA readiness assessments with 78 financial entities across 11 EU member states during 2024, covering credit institutions (23), investment firms (14), payment institutions (12), insurance undertakings (11), crypto-asset service providers (8), and other financial entities (10). Additionally, we reviewed 34 TIBER-EU/TLPT Targeted Threat Intelligence reports produced between 2023–2024 to assess intelligence quality and identify systemic gaps in TLPT intelligence provision.

Threat Landscape Analysis: Financial sector threat landscape assessments in this report are derived from Dark Angel’s operational intelligence holdings, including monitoring of 47 confirmed ransomware incidents against EU financial entities in 2024, tracking of 2.3 million compromised European banking credentials identified in infostealer logs, analysis of 378 DDoS campaigns targeting EU financial infrastructure, and continuous monitoring of 19 state-sponsored threat actor groups known to target European financial services.

Confidence Framework: Regulatory analysis and compliance mapping carry high confidence where based on published regulation text and final RTS/ITS. Assessments of supervisory expectations and enforcement approaches carry moderate confidence, reflecting engagement with national competent authorities but acknowledging that supervisory practice under DORA is still forming. Threat landscape assessments carry high confidence for quantitative data derived from direct intelligence collection, and moderate confidence for trend projections and threat actor attribution.

Related Reports

• NIS2 Directive: Threat Intelligence Requirements for Compliance — Comprehensive guide to mapping NIS2 obligations to operational TI capabilities, incident reporting, and supply chain security.
• Financial Services Threat Landscape — Strategic assessment of state-sponsored, ransomware, hacktivist, and supply chain threats facing European financial institutions.
• European Cyber Threat Landscape 2025 — Panoramic analysis of the threat environment facing EU organizations across all sectors, with trend projections.