DORA Threat Intelligence: Deliverables Your Control Team Can Actually Accept

DORA threat intelligence: buy a usable decision, not a threat feed

A useful DORA threat intelligence deliverable explains why particular adversaries and attack paths matter to your financial institution, how those paths connect to the functions in scope, and what the testing team should attempt to learn. A list of malicious addresses, a generic sector report or a collection of screenshots cannot answer those questions on its own. The practical buying decision is whether the intelligence will help a controlled test explore the right business risks.

This guide provides an acceptance framework for the targeted threat intelligence report and its handover. It is intended for control teams, security leaders and procurement reviewers who need to evaluate the work before red team execution begins. The matrices and examples are our practical review recommendations. They are not a replacement for the applicable regulation, the authority’s instructions or the agreed test process. All example institutions, assets and attack hypotheses below are fictional.

Our DORA TLPT service begins with the function and the evidence required to understand its resilience. This article goes deeper into one deliverable rather than repeating the entire DORA TLPT RTS framework. The outcome should be a reviewable chain from an intelligence observation to a justified scenario, with assumptions and uncertainty visible to everyone authorised to make the decision.

Separate legal requirements, framework guidance and your own acceptance criteria

Use Commission Delegated Regulation (EU) 2025/1190 as the primary source for the detailed TLPT process. Its targeted intelligence requirements address the institution’s exposure and relevant threats, including end-to-end scenarios concerning availability, integrity and confidentiality. Read the applicable articles and annexes together with the validated scope. A procurement checklist must not quietly narrow the required work to the provider’s standard deliverable.

The ECB’s Targeted Threat Intelligence Report guidance explains how contextualised intelligence supports scenario selection and operationalisation. It also contains operational guidance beyond the minimum DORA obligations. Keep those categories separate in your review register. Label a requirement as regulatory, authority-specific, contractual or recommended. This makes disagreements resolvable without pretending that every editorial preference has the force of law.

Before starting, ask the control team to identify the authoritative version of the scope, the expected review participants and the route for unresolved questions. Record the document versions and review dates. A beautifully formatted report can still be unusable if it addresses an earlier scope or assumes a function that has since been excluded. The final acceptance record should identify exactly which version was reviewed and which conditions, if any, remain open.

Turn the critical function into intelligence questions

Start with the financial service, not an internet asset search. Consider a fictional institution whose scoped function is corporate payment initiation and authorisation. Ask which people, identities, applications and outsourced dependencies support that function. Then ask what an adversary would need to influence to affect its confidentiality, integrity or availability. This produces a collection plan with a purpose: each research task should help confirm, reject or refine a business-relevant hypothesis.

Write questions that a reviewer can evaluate. “Research our attack surface” is vague. “Identify publicly observable access routes associated with the corporate payment support chain and explain their ownership confidence” is more useful. Similarly, “find relevant threat actors” should become a request to explain motivation, capability, targeting relevance and evidential confidence. The provider should be allowed to conclude that a proposed hypothesis is weak rather than being pressured to manufacture a dramatic story.

Distinguish what the provider may collect independently from information the institution supplies. Internal architecture context can improve interpretation, but it must not be presented as an externally discoverable weakness. Mark supplied facts, external observations, analytical judgments and unknowns separately. That distinction becomes particularly important when reviewers ask whether a plausible path would really have been available to an adversary at the start of the exercise.

Make source provenance inspectable without spreading sensitive information

For each material assertion, retain a source reference, observation date, collection method and confidence explanation. A source reference need not mean putting sensitive source material into every recipient’s copy of the report. Use a controlled evidence register that authorised reviewers can consult. The report should contain enough information to assess the conclusion while the underlying material remains subject to agreed access and retention controls.

Separate observation time from publication time. An article published recently may describe infrastructure that disappeared months earlier. A domain record observed yesterday may still have uncertain ownership. Ask the analyst to explain why the evidence remains relevant to the scoped service now. Where current validation would require an intrusive action, record the limitation and route the question through the agreed process instead of treating reconnaissance as unrestricted testing permission.

Avoid confidence expressed only as an unexplained percentage. A short rationale is more useful: ownership was corroborated by two independent public records, the relationship is inferred from naming alone, or the information was supplied by the institution but not externally observable. These distinctions help the red team choose a reasonable next step and help the control team prevent an incorrectly attributed third party from entering the test boundary.

Also examine the dependencies between sources. Five articles copying one original statement are not five independent confirmations. A provider should be able to distinguish corroboration from repetition. Ask for a sample review of the most consequential claims rather than attempting to inspect every footnote with equal intensity. Concentrate on the claims that determine scope relevance, scenario selection, third-party involvement or a potentially risky testing assumption.

Review exposure as an attributed inventory rather than a list of targets

A useful exposure inventory associates each relevant observation with an owner, function relationship, observation date and collection limitation. Include uncertainty explicitly. The same brand may appear across subsidiaries, acquisition remnants, suppliers and unrelated lookalike infrastructure. The appearance of a hostname in a search result is not permission to test it, and similarity to the institution’s branding is not sufficient proof of control.

Give reviewers a way to correct attribution without erasing the original reasoning. Preserve the initial observation, the institution’s clarification and the resulting disposition. An asset may be confirmed in scope, relevant but outside active testing, obsolete, or incorrectly attributed. This small workflow prevents the final report from blending genuine exposure, historical records and discarded leads into one alarming inventory.

Assess whether the inventory explains the path to a meaningful objective. An exposed remote-access portal may matter because it supports administrators of an in-scope payment platform. A public marketing service may be unrelated. Neither conclusion should be automatic: document the relationship and the evidence available. Where the connection is speculative, label it as a hypothesis requiring safe validation rather than presenting it as a confirmed attack chain.

Do not reward the provider for finding the greatest number of internet-facing objects. A smaller, well-attributed set of function-relevant observations can be more useful than thousands of undifferentiated records. Ask the provider to explain which observations changed scenario selection and which were background context. That answer shows whether collection served the test objectives or merely filled pages.

Require an end-to-end scenario with a measurable learning objective

A scenario should describe a plausible starting position, the relevant actor behaviour, the intended route through the scoped environment and an objective that the test can assess. It should also state the dependencies and assumptions required for that route to make sense. This is a hypothesis to be operationalised through the approved testing plan, not a prediction that the institution is already compromised.

For a fictional payment function, an integrity-oriented scenario might ask whether an attacker who obtains an appropriately bounded foothold can influence a sensitive instruction before independent approval. The learning objective concerns the transaction control and the institution’s ability to detect and respond. It does not require real customer money to move. The precise flag, safety measures and permitted actions belong in the agreed operational plan.

Include alternative explanations and stopping conditions in the handover discussion. If the proposed route depends on an unconfirmed supplier relationship, what evidence is needed before proceeding? If the route is blocked, which result would constitute useful defensive evidence? If assistance becomes necessary, how will it be recorded so the final narrative does not imply that the red team independently achieved the assisted starting condition?

Run a challenge meeting before accepting the report

Distribute a controlled draft far enough ahead of the meeting for reviewers to inspect the important claims. Assign reviewers by question rather than asking everyone to comment on everything. The function owner checks business relevance, architecture representatives check dependencies, the control team checks scope and risk, and the testers assess whether the intelligence can be operationalised. Follow the agreed authority involvement and confidentiality arrangements.

Use a decision log with three simple outcomes: accepted, accepted subject to a defined correction, or unresolved. Each condition should identify an owner, expected evidence and decision date. “Improve the scenario” is not an actionable condition. “Clarify whether the support identity reaches the scoped administration plane and identify the source of that assumption” is actionable and can be closed without another general meeting.

Ask the analyst to defend one important scenario and one rejected scenario. The rejected example is particularly revealing: it shows whether the team considered alternatives and resisted attractive but weak narratives. A credible report should explain why some possibilities were not selected. This protects the exercise from being driven only by the most fashionable threat or the technique the testers happen to prefer.

Keep the challenge constructive. The purpose is not to force certainty where the evidence cannot support it. A clearly bounded unknown can be planned around; a hidden assumption can undermine the whole exercise. Preserve the original concern, the provider’s response and the final disposition so that later readers understand why the decision was reasonable at the time.

Check that the testers can use the intelligence

A report is not complete merely because it has been emailed. Hold a handover in which the intelligence team explains the selected scenarios, source confidence, relevant exposure and unresolved assumptions. Ask the testers to restate the intended learning objectives and identify the information they still need. A mismatch at this point is much cheaper to fix than discovering it during an active production exercise.

Trace each proposed test scenario back to the intelligence rationale. This does not mean every operational step must appear in the intelligence document. The testers will develop the detailed approach through the agreed planning process. It does mean that a major change in objective or adversary behaviour should be visible, justified and handled through the appropriate review route rather than silently replacing the threat-led premise.

Record what was supplied directly by the control team and how it will be treated. The team may need architecture context or safe test identifiers to operate responsibly. That support should not later be described as attacker discovery. Maintain separate records for context supplied during preparation, operational assistance during testing and findings independently demonstrated. This makes the eventual report honest about both progress and limitations.

Agree how new intelligence will be handled after acceptance. A materially changed exposure or newly relevant event may justify revisiting an assumption, but uncontrolled updates can destabilise an agreed test. Define the notification route, triage owner and change decision. Freeze the accepted version while retaining a dated addendum trail for changes that are approved.

Recognise common quality failures early

The first warning sign is a report that could apply unchanged to almost any bank. Generic actor summaries can provide context, but the useful work lies in connecting them to the institution’s functions, dependencies and exposure. Ask what would change if the customer name were removed. If the answer is almost nothing, the report probably needs more targeted analysis before acceptance.

A second warning sign is unsupported certainty. Statements such as “this actor will target the institution” or “this asset enables access to payments” require evidence that is rarely as absolute as the wording suggests. Replace certainty with a reasoned assessment and its limitations. The report should enable a proportionate testing decision, not exaggerate the likelihood of a scenario to make the engagement seem more dramatic.

A third failure is an operationally unusable scenario. The narrative may be compelling but depend on an out-of-scope supplier, an unavailable identity or an unsafe action. Do not solve this by pretending the dependency does not exist. Route the issue through scope and risk decisions, or select a justified alternative. The accepted record should make clear what is feasible, what is conditional and what will not be tested.

Finally, watch for findings language appearing before testing. Intelligence may identify an exposed service, a suspected relationship or a plausible weakness. Unless separately validated within permission, it is not a demonstrated compromise. Distinguish observations, hypotheses and confirmed test results throughout the document lifecycle. This improves both technical credibility and the usefulness of the eventual remediation discussion.

A practical acceptance record your team can reuse

Create a short acceptance record that references the report version rather than copying the full report into another document. Include the scoped functions, selected scenarios, key assumptions, unresolved conditions, reviewers and decision date. Attach the decision log and controlled source-register reference. The record should help a later reviewer reconstruct what was accepted without exposing unnecessary operational details to a wider audience.

For each condition, state whether it prevents progression or can be resolved through the next approved planning step. Avoid a blanket “approved with comments” status that hides material gaps. A typographical correction and an unverified third-party dependency have different consequences. The control team should make that distinction explicit, with the relevant authority process followed where required.

Measure quality through decision readiness, not document length. Can the testers explain the selected scenarios? Can the control team identify the main risks and assumptions? Can the function owner recognise the business impact being explored? Can an authorised reviewer trace consequential assertions to evidence? A positive answer to those questions is more valuable than a large appendix that nobody can interpret.

Use a small evidence sample to test the report’s reasoning

Select one high-impact assertion from each chosen scenario and ask an authorised reviewer to reconstruct the reasoning. The reviewer should be able to identify the original observation, its age, the ownership assessment and the step from observation to scenario. If that reconstruction requires an undocumented conversation with the analyst, improve the record before acceptance. The aim is not to repeat the entire collection exercise but to test whether the most consequential judgments are understandable.

Include one assertion with low or mixed confidence. A report that handles uncertainty well should explain why the scenario remains worth exploring despite the limitation, or why an alternative was selected. This review is particularly helpful when several sources appear to corroborate a claim but ultimately depend on the same original publication. Record the sample and the resulting corrections. Later reviewers can then see that quality assurance examined the reasoning, rather than merely checking that all expected headings were present.

Five questions to resolve before the final handover

Ask whether every selected scenario still matches the latest accepted function scope. Check whether a material assumption has changed since collection began. Confirm that the testers understand the source confidence and the distinction between supplied context and independent observation. Identify any unresolved third-party permission or ownership question. Finally, agree who can authorise a change if new information alters the scenario during operational planning.

These questions work best as a short recorded conversation with named owners. A provider may have answered them in different parts of the report, but bringing them together exposes contradictions. For example, the exposure inventory may classify a supplier as unconfirmed while the scenario assumes full access to its service. Resolve that mismatch before accepting the document. The objective is a usable decision, not a perfect-looking report with unresolved dependencies hidden between sections.

Retain the answers with the acceptance record and revisit only the items affected by later changes. This keeps the process proportionate while preserving a clear explanation of why the team believed the intelligence was ready to support testing.

Ask for the deliverable before accepting the proposal

During procurement, request a redacted example structure, a description of the collection and review process, and the roles of the people who will perform the work. Do not ask providers to disclose another customer’s sensitive evidence. A useful alternative is a fictional worked example showing observation, analytical judgment, scenario rationale and acceptance questions. Evaluate the reasoning and traceability rather than the visual polish alone.

State your own dependencies clearly. The provider needs an agreed scope, suitable points of contact and a secure route for questions. Delays in those inputs can reduce the usefulness of the intelligence even when the provider performs well. Put the review milestones and responsibilities into the engagement plan so acceptance does not become a last-minute procurement formality.

If you are preparing a TLPT, use the scoping brief to describe the functions, dependencies and desired timing without submitting credentials or sensitive architecture. You can also discuss the intelligence and testing workstreams with Atlant Security. We will help define what evidence the engagement should produce and which questions need to be resolved before a proposal is meaningful.

This guide was reviewed on 25 October 2026. Its checklists are practical implementation suggestions, not a legal opinion, regulatory attestation or claim that a particular provider meets all selection requirements. Confirm the applicable process with the responsible authority and the institution’s legal and risk teams. The value of the intelligence is the quality of the decisions it enables, followed by an honestly documented test of those decisions.