How managed threat intelligence satisfies DORA's ICT risk management requirements
DORA's January 2025 application date has passed. The regulation is live. Yet the majority of in-scope financial entities are still operating threat intelligence programmes that were designed for a pre-DORA world — ones that generate volume but cannot demonstrate the specific evidence of proactive monitoring that EU regulators will demand at examination.
The Digital Operational Resilience Act is not a cybersecurity standard. It is an operational resilience regulation and the distinction matters enormously for how threat intelligence is designed, documented, and reported. Generic commercial threat feeds, even well-integrated ones, do not satisfy DORA's requirements for structured, entity-specific threat monitoring with demonstrable evidence of ongoing capability. This guide explains what does.
It is written for CISOs and compliance officers at financial entities in scope — credit institutions, investment firms, payment institutions, insurance undertakings, and third-party ICT service providers subject to DORA's oversight framework. If you are currently mapping your threat intelligence programme to DORA requirements, or preparing for supervisory examination, this is the technical reference you need.
Understanding DORA's threat intelligence architecture across Chapter II
DORA's threat intelligence requirements are not contained in a single article. They are distributed across the ICT risk management framework in Chapter II, from initial identification through detection, response, and the ongoing learning cycle. Articles 8 through 13 each carry specific obligations that a mature threat intelligence programme must address. The common mistake is treating threat feeds as the answer to Article 10 (Detection) in isolation, while failing to satisfy the identification, learning, and communication requirements that sit around it.
The six articles below constitute the threat intelligence architecture that DORA implicitly mandates. Each maps to a distinct operational capability — not a policy document.
Financial entities must identify and classify ICT assets and map information flows. For threat intelligence, this means understanding which assets represent the highest-value targets for known threat actors — not just what you own, but what adversaries want.
Policies and controls must be proportionate to identified threats. This creates a direct dependency on threat intelligence: protection measures that cannot be traced back to an assessed threat profile cannot be demonstrated as proportionate to a regulator.
Entities must deploy mechanisms to promptly detect anomalous activities. DORA requires these mechanisms to be based on threat intelligence — the detection capability must demonstrably reflect the current threat landscape facing the entity and its sector.
Response plans must be based on documented threat scenarios. Threat intelligence feeds directly into the scenario development that underpins incident response, business continuity, and recovery time objectives for critical functions.
Post-incident reviews must feed back into the risk management framework. Threat intelligence closes the learning loop — connecting what happened externally (sector incidents, new TTPs, emerging actor campaigns) to internal control improvements.
Crisis communication plans must address ICT-related incidents and material vulnerabilities. Threat intelligence informs the severity classification, stakeholder notification decisions, and timing of disclosures — both internally and to competent authorities.
A competent authority examining your DORA compliance will not ask to see your threat feed subscription invoice. They will ask how your threat intelligence programme maps to each of these articles — what specific outputs it produces, how those outputs are documented, how they have modified your controls, and how you can demonstrate that your monitoring is proactive rather than reactive. Generic feeds do not answer those questions.
Article 10 in depth — what 'proactive' threat monitoring actually means to a regulator
Article 10 is the most operationally demanding of DORA's threat intelligence requirements. It mandates that financial entities deploy mechanisms "to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents." The critical regulatory interpretation sits in the word anomalous — which the European Supervisory Authorities have signalled should be understood in relation to a documented, current understanding of what adversarial behaviour looks like for your entity and sector.
This is not a passive requirement. A SIEM that fires alerts is not, by itself, evidence of proactive threat monitoring under DORA. Proactive monitoring requires a documented threat picture that informs what you are looking for, updated on a frequency that reflects how quickly the threat landscape evolves, and producing outputs that can be demonstrated to a regulator as evidence of ongoing, structured vigilance.
The seven data points regulators will look for
DORA does not simply require you to do these things. It requires you to be able to demonstrate that you have done them with records that can withstand supervisory scrutiny. A threat intelligence programme that operates without documented processes, graded outputs, and an auditable feedback loop into your risk management framework is not DORA-compliant, regardless of the quality of its underlying analysis.
DORA Article-to-ThreatInsights capability mapping
The table below maps each relevant DORA article to the specific operational requirement it creates for your threat intelligence programme, and to the ThreatInsights service module that satisfies it. This is the compliance-to-capability structure that allows a CISO to walk a regulator through their threat intelligence programme article by article.
DORA-compliant CTI vs traditional threat feeds — why standard feeds fail the regulatory test
The commercial threat intelligence market is mature and well-supplied. ISAC feeds, commercial threat platforms, and vendor-bundled CTI have become standard infrastructure in financial sector security operations. None of them, by default, satisfy DORA's requirements, not because the underlying data is poor, but because DORA requires something that commercial feeds are not designed to produce: a documented, entity-specific, auditable intelligence programme with demonstrable outputs and a feedback loop into the ICT risk management framework.
The distinction is not about data quality. It is about analytical process, documentation, and regulatory posture.
Building a DORA-defensible threat intelligence programme — the evidence framework
Regulatory examination under DORA will not be satisfied by a policy that describes your threat intelligence intentions. It will require evidence that the programme operates as described with outputs that can be traced from intelligence collection through to risk management decisions. The following seven evidence components constitute a defensible threat intelligence programme under DORA's Chapter II framework.
A documented policy that defines the scope, objectives, roles, collection sources, grading methodology, distribution framework, and feedback mechanisms of your CTI programme. This is the governance document that demonstrates programme maturity to a regulator.
Art. 6 / 13A structured, analyst-produced report covering the threat actors assessed to pose risk to your entity, their current TTP profile, recent campaign activity in your sector, and specific indicators relevant to your infrastructure. Dated, graded, and version-controlled.
Art. 8 / 10A mapping of your detection use cases to the MITRE ATT&CK techniques associated with your identified threat actors. Demonstrates that your detection capability is informed by specific adversary behaviour and has measurable, traceable coverage against known TTPs.
Art. 10At minimum three documented threat scenarios, each traceable to an identified threat actor and current intelligence, used to underpin ICT business continuity planning, response playbooks, and recovery time objectives for critical functions.
Art. 11Documented monitoring of critical ICT third-party providers for threat activity, vulnerability disclosure, incident history, and sector exposure. Evidence that third-party risk is treated as a live threat surface under DORA Chapter V, not only managed at contract stage.
Art. 9 / 28A documented record connecting specific intelligence outputs to control changes, detection rule modifications, or risk appetite decisions. Demonstrates the learning cycle mandated by Article 13, that intelligence is consumed and acted upon, not merely received.
Art. 13A record of threat intelligence products delivered to senior management and the management body, demonstrating that the board receives regular, structured threat intelligence in compliance with DORA's governance requirements under Article 5 and communication obligations under Article 14.
Art. 5 / 14Items 3 and 6 are consistently absent in organisations that believe they are DORA-compliant. A detection coverage map that cannot be traced to specific threat actor TTPs, and a control improvement process with no documented intelligence inputs, are the two evidence gaps most likely to produce adverse supervisory findings under DORA's ICT risk management framework.
What a DORA-ready threat intelligence engagement delivers
DORA compliance in threat intelligence is not achieved by procurement. It is achieved by programme design, building a CTI function that is structured around the evidence framework regulators will examine, not around the threat feed that was easiest to integrate. For most financial entities, that requires external expertise: not because the internal security team is inadequate, but because DORA's requirements extend into regulatory documentation, intelligence tradecraft, and evidence management that sits outside the typical scope of a commercial CTI programme.
A ThreatInsights DORA advisory engagement delivers a fully mapped, documented, and regulator-ready threat intelligence programme — one that satisfies each of the Chapter II articles above with traceable, examination-grade evidence. For entities approaching TLPT or supervisory examination, it also provides the accredited TISP function required under Article 26. The engagement is scoped to your regulatory timeline and risk profile, with outputs formatted for direct submission to your competent authority.
DORA Readiness Assessment
Start with a gap analysis. ThreatInsights offers a structured DORA threat intelligence readiness assessment that maps your current programme against the seven evidence components above, identifies critical gaps, and produces a prioritised remediation plan with regulatory timeline alignment. Engagements are available for Tier 1 and Tier 2 in-scope entities — contact ThreatInsights to discuss scope and timing relative to your supervisory calendar.
