DORA & Threat Intelligence

The Digital Operational Resilience Act (DORA, EU 2022/2554) is the EU's attempt to make financial-sector resilience concrete. Banks, insurers, investment firms, and their critical ICT service providers must be able to withstand, respond to, and recover from all forms of ICT disruption. A central pillar of the regulation is that resilience cannot be theoretical. It must be threat-led.

That phrase — threat-led — is where intelligence comes in. DORA expects that risk frameworks, prevention controls, response plans, penetration tests, and third-party monitoring are all anchored in current adversary behaviour, not in last year's risk register.

What "Threat-Led" Actually Means

For decades, financial-sector controls were evaluated against frameworks and best practices. DORA turns that on its head. The test is no longer "do you have a control?" — it is "is your control tuned to the threats you actually face?"

In practice, that means a SOC's detection rules should reference the MITRE ATT&CK techniques of the actors targeting the financial sector. It means a vulnerability management programme should prioritise CVEs that are actively exploited in financial-services incidents. It means an incident response plan should be tested against realistic, sector-relevant scenarios, and a penetration test should be scoped using real adversary intelligence, not generic TTPs.

The Articles That Lean on Intelligence

Article 6 — ICT Risk Management Framework

Financial entities must maintain a comprehensive ICT risk framework where risk identification reflects current threat intelligence. A live, financial-sector-aware feed replaces the static annual assessment with something that updates as adversaries change tactics.

Article 9 — Protection and Prevention

Detection rules and prevention controls must be calibrated to known adversary TTPs. Detection engineers can pull behavioural indicators, ATT&CK-mapped techniques, and IOC feeds from structured intelligence and push them directly into SIEM and SOAR tuning cycles.

Article 11 — Response and Recovery

Response plans should be tested against realistic scenarios and informed by sector incident patterns. Current ransomware tactics, exfiltration methods, and financial-sector incident playbooks turn tabletop exercises from box-ticking into genuine rehearsal.

Article 13 — Threat-Led Penetration Testing (TLPT)

Significant financial entities must run threat-led penetration testing under the TIBER-EU framework. TLPT has a dedicated threat-intelligence phase at the front: scoping the test using current adversary profiles, TTPs relevant to the entity's sector and technology stack, and historical attack patterns. Without that phase, the rest of the test is built on guesswork.

Article 19 — Information Sharing

Financial entities are encouraged to participate in cyber-threat information sharing arrangements. STIX-formatted intelligence is directly compatible with TAXII-based sharing platforms, which means structured outputs can flow into sector ISACs and other sharing communities without manual conversion.

Articles 28–30 — ICT Third-Party Risk Management

DORA explicitly requires monitoring of critical ICT third-party providers. Darknet monitoring and ransomware-victim intelligence are the most efficient way to detect vendor compromise early — often before the vendor itself is forced to disclose the incident.

Common Mistakes

• Annual risk assessments that go stale within weeks and are not refreshed as the threat picture changes
• TLPT scoping documents that read like a generic red-team brief rather than something anchored in real actor behaviour
• Ignoring critical third-party providers because they are out of scope of the in-house security team
• Manually exporting STIX bundles once a quarter rather than automating TAXII-based sharing into sector ISACs

Next Steps

For the regulatory overlap and how the same evidence pack covers all three frameworks, see our compliance overview. For the EU-wide parallel regulation, see NIS2 threat intelligence.