Name the decision
For an illustrative treasury operation, ask how an actor might influence a high-value approval. That is more useful than commissioning a general briefing on finance-sector attacks. The provider can investigate relevant motivations, opportunities and constraints without assuming a particular actor already has access.
Give bounded context
The provider needs enough context to identify realistic paths. Supply an agreed description of staff roles, technology dependencies and third-party touchpoints. Agree secure handling and collection boundaries first. Do not send a network diagram or privileged-account list with the initial RFP.

Request a reasoning trail
Ask for an example showing how an observed fact supports an assessment and where uncertainty remains. Public evidence that an actor targets financial services does not establish capability against your specific platform. Look for reasoning that explains why one scenario is more credible or consequential than another.

Test the scenario logic
A plausible chain should connect its stages. If the initial opportunity concerns a contractor account, explain what further authority would be required before it could affect treasury approval. Revealing an unsupported assumption during design is useful: it narrows the question the exercise must answer.

Preserve alternatives
Conditions can change between intelligence collection and execution. Ask how the team records an alternative path and how assistance would affect interpretation. A scenario achieved with agreed help does not demonstrate the same unaided capability; the distinction should remain visible in the evidence.

Specify the handoff
Request time for the receiving team to challenge assumptions, align on the objective and identify unsafe actions. A document delivered by email is not necessarily a usable handoff. The control team should be able to explain why the selected scenario belongs in this institution's exercise.

Buy an actionable workstream
Compare proposals on targeted analysis, context gathering, secure collaboration and support for scenario selection. Ask what is excluded and how the provider will handle an inconclusive hypothesis. A useful proposal describes the decision the intelligence will support rather than promising a particular intrusion result.

Challenge a scenario before accepting it
An illustrative provider proposes targeting an outsourced support engineer to influence a payment limit. The control team knows the engineer can reset passwords but cannot change approval rules. Ask what further access would be necessary, what supports that hypothesis and what uncertainty remains. This is a productive challenge: it converts an impressive narrative into a question the test can meaningfully explore.
| Scenario claim | Challenge | Handoff decision |
|---|---|---|
| Adversary targets support | What evidence establishes relevance? | Record sources and confidence. |
| Support access enables escalation | Which trust relationship makes it plausible? | Validate the dependency or revise the path. |
| Payment limit can change | How could impact be demonstrated safely? | Agree controlled proof and stop conditions. |
Primary texts: DORA, Articles 26 and 27 and Commission Delegated Regulation (EU) 2025/1190.
Published by Atlant Security. Sources, editorial policy and corrections.

