Beyond the threat report: what I learned managing intelligence in a regulated TLPT

The situation

A recent TLPT threat-intelligence phase concluded with the Control Team confirming that the report contained the relevant information and required elements needed for the subsequent phase. The downstream Red Team provider also confirmed that its format, detail and content provided a sufficient basis for execution.

The eventual conclusion was unambiguous: the report was complete and fit for its intended purpose, with no deficiencies preventing progression.

Getting there was less straightforward. The principal challenge was not a lack of intelligence, scenarios or supporting evidence. It was maintaining an analytically defensible process while different stakeholders questioned individual judgements, requested additional coverage and approached the report with different expectations about what a targeted threat-intelligence report should contain.

This matters beyond one engagement. The DORA TLPT Regulatory Technical Standards establish an operating model in which the Threat Intelligence Provider recommends scenarios, the Test Managers provide input, the Red Team assesses feasibility and the Control Team Lead selects the scenarios. That structure necessarily combines intelligence assessment, supervisory input, operational feasibility and organisational risk appetite.

The process therefore requires more than a good report. It requires disciplined adjudication when those inputs point in different directions.

What is actually happening

Three different activities can become conflated during scenario development:

1. assessing which threats are supported by the intelligence;
2. deciding which scenarios are operationally executable;
3. deciding which controls the organisation or authority wants exercised.

These activities are related, but they are not interchangeable.

Established fact: Article 10 of the DORA TLPT RTS requires scenario selection to consider the Threat Intelligence Provider's recommendation and the threat-led nature of each scenario, Test Manager input, Red Team feasibility, and the entity's size, complexity and risk profile. It also permits no more than one selected scenario to be non-threat-led and based on a forward-looking or potentially fictitious threat.

That provision is significant. It recognises that a scenario may be selected for anticipatory or assurance reasons even where it is not supported to the same degree as the primary threat-led scenarios.

Our assessment: a substantial amount of friction in TLPT scenario development is likely to arise when participants do not explicitly identify which of these decision grounds they are applying.

A stakeholder may reasonably want a physical-access, insider, supply-chain or other alternative scenario tested. That does not, by itself, establish that current intelligence supports presenting the scenario as a probable or entity-relevant threat.

That is not resistance to challenge. It is the separation of intelligence assessment from programme risk appetite.

Assumption: organisations entering early DORA TLPT cycles may initially apply conventional document-review practices to a process that actually requires intelligence adjudication. If that assumption is correct, some apparent disputes about report quality will in fact be unresolved disagreements about evidence thresholds, scenario coverage or decision ownership.

The TTIR is an operational intelligence product

The ECB's TIBER-EU guidance describes the Targeted Threat Intelligence Report as a summary of the Threat Intelligence Provider's findings, the relevant target and threat intelligence, and the scenarios selected through the associated process. It is intended to provide the starting point from which the Red Team operationalises bespoke attack scenarios.

That makes the TTIR an operational handover product. It is not necessarily the repository for every search result, analytical matrix, script output, discarded hypothesis, reviewer comment or internal QA artefact generated during the intelligence cycle.

Supporting evidence still matters. It should be available, traceable, securely handled, reproducible where appropriate, and sufficient to defend the judgements. But putting every working artefact into the principal report can make it less useful to the Red Team rather than more defensible.

We assess with moderate confidence that the better model is a two-level structure: a concise TTIR containing the intelligence and scenarios required for execution, supported by a controlled working-evidence record for QA, challenge and audit.

Challenge is necessary; indefinite challenge is not

Threat intelligence should withstand scrutiny. Challenges may reveal factual errors, weak sources, unsupported assumptions, missing collection or poorly calibrated confidence. A functioning analytical process must also be capable of producing results that weaken the analyst's original position.

In practice, however, a broad comment such as “the conclusion is not evidenced” is not yet an actionable analytical challenge. It must be converted into something testable:

• Which conclusion is disputed?
• Is the objection factual, analytical, methodological or presentational?
• Which evidence is considered insufficient?
• Is an alternative hypothesis being proposed?
• What information would resolve the disagreement?
• Who owns the resulting decision?
• When is the matter closed?

Without that structure, the engagement risks repeated redrafting without a defined analytical or contractual endpoint.

Preserving analytical independence

The Threat Intelligence Provider should be responsive to evidence and correction. It should not be responsive to preference in the same way.

A factual correction should be made when verified. A material analytical challenge should be assessed against the evidence. A request for alternative test coverage should be considered by the authorised decision-makers. A request to change an assessment simply because a different scenario is preferred should not be represented as an intelligence-led change.

The objective is not to make the Threat Intelligence Provider the sole authority over the test. The Control Team Lead owns scenario selection under the RTS. The objective is to preserve an accurate record of why each scenario was recommended and why it was ultimately selected.

What this means in practice

Establish an analytical challenge protocol at the start

The Control Team Lead should agree how comments will be raised, classified, assigned and closed. A useful classification is: factual correction; source or evidence challenge; alternative analytical interpretation; confidence challenge; scope or coverage request; Red Team feasibility issue; regulatory requirement; or editorial comment.

This costs almost nothing to implement and prevents fundamentally different issues from being handled through the same drafting process.

Make the evidence-to-judgement chain visible

The Threat Intelligence Provider should provide a concise matrix linking:

Scenario → key evidence → confidence → critical function → test objective → decision status

The deeper evidence register and structured analysis can remain in controlled working papers. Reviewers should not need to reconstruct the entire collection process to identify why a scenario exists.

Record the basis for scenario selection

The Control Team Lead owns this record, supported by the Threat Intelligence Provider, Red Team and Test Managers. For each selected scenario, the record should state whether the principal basis was current entity-specific intelligence, sector or jurisdictional intelligence, a credible forward-looking assessment, Red Team feasibility, organisational risk appetite, or control-coverage value.

Several grounds may apply, but they should not be conflated.

Use one consolidated review register

Comments dispersed across email, meetings, annotated drafts and informal conversations create uncertainty about what remains open. The register should identify the comment owner, date raised, affected section, issue classification, response, decision authority, action, target version and closure status.

The Control Team should own the consolidated register. The Threat Intelligence Provider should own the analytical responses.

Define completion and acceptance criteria contractually

The commercial agreement should state the required deliverables, the boundary between the TTIR and supporting working evidence, permitted review rounds, stakeholder response periods, client dependencies, change-control requirements, objective acceptance criteria and the consequence of delayed or conflicting feedback.

DORA and the TLPT RTS define regulatory responsibilities. They do not replace clear commercial acceptance terms between the entity and its service providers.

Preserve dissent without allowing permanent deadlock

Where an analytical disagreement cannot be resolved, record both positions and identify the authorised decision. A defensible close might state:

That protects the integrity of the assessment while allowing the programme to proceed.