Prioritising Strategic Scenarios for an Online Retailer
An online retailer with 2.3 million customers expects 18,000 orders per hour on Black Friday. Its checkout depends on a payment provider, a cloud CDN and two logistics partners; a 40-person IT team runs the rest. The EBIOS RM team listed 11 business values and 9 threat sources and generated 99 'couples' (threat source × business value). The project sponsor wants all 99 turned into strategic scenarios so that 'nothing is missed,' while the risk manager warns that the workshop will stall. Existing controls are uneven: WAF and fraud scoring are mature, but partner API keys are shared in a spreadsheet, and no one has tested a payment-provider failover for two years. The retailer has 12 weeks before peak season. The sponsor also wants the exercise to justify investment in a new order-management platform. The team has incident data from the last 18 months, including two DDoS attempts and one logistics API outage.
1. How should the team reduce 99 couples to a defensible set of strategic scenarios? Give criteria and a practical grouping method.
Read the worked answer
Do not turn every couple into a scenario; that produces a catalogue and hides the real decisions. Group couples by business value and by the threat source's objective, then merge duplicates where the path and impact are the same. Score each group on severity of the feared event, threat motivation and capability, exposure, maturity of existing controls, and dependency on partners. Use incident evidence to raise or lower confidence. Select five to eight scenarios that cover distinct paths, including one peak-season availability scenario, one payment-integrity scenario and one partner-dependency scenario. Record why the remaining groups were excluded, so 'nothing is missed' becomes a documented judgement rather than an unmanageable list. Keep the order-management investment as a decision criterion for measures, not as a reason to inflate risk. The test is whether each retained scenario changes a decision.
2. Draft one strategic scenario for a DDoS-driven checkout outage, including threat source, objective, business value, feared event and ecosystem stakeholders. Explain each element.
Read the worked answer
Threat source: hacktivist or extortion group. Objective: prevent sales and damage reputation during peak trading. Business value: order taking and checkout. Feared event: checkout unavailable for more than two hours on Black Friday, with abandoned orders and public complaints. Ecosystem stakeholders: cloud CDN, payment provider, logistics partners and customers. The explanation matters: the source has a motive and some capability; the objective explains why the value is targeted; the feared event is a business consequence, not a TTP; the stakeholders show where controls and dependencies sit. The scenario should stop at strategic level and not list packet-level techniques, which belong in Workshop 4. It should also note the untested payment-provider failover as an aggravating factor, because that turns a partial DDoS into a full checkout outage.
3. How should the logistics partner be represented: as a threat source, an ecosystem stakeholder, or a supporting asset? Justify your choice.
Read the worked answer
It is primarily an ecosystem stakeholder, because the retailer depends on the partner's service and cannot directly control the partner's internal assets. It can also be a threat source in a narrower sense if the partner is negligent or malicious, but that is a different claim and needs evidence. The partner's API and the retailer's integration point are supporting assets on the retailer side; the partner's own systems are not. Representing the partner only as a supporting asset would overstate control; representing it only as a threat source would miss the dependency and contractual measures. The practical answer is to record both roles explicitly: dependency in the strategic scenario, and a separate source entry only if the threat assessment supports it. That prevents the common error of drawing a partner's internal network as if it were inside the retailer's scope.