Connected scenarios and risk register

An advanced risk register is not a list of independent hazards. In a digital enterprise, fraud detection, customer support and settlement may all depend on one data feed, one administrative identity service or one cloud provider. Failure of the shared component raises risks that appear separate when written in isolation. Map dependencies across service, data and decision layers first: who sends the data, who changes it, who detects a deviation and who can stop its effects? Use consistent identifiers for an asset, process and control so that the same provider does not appear under three names. Causal dependence differs from incidental simultaneity. Two events occurring on the same day do not show that one caused the other. Ask whether the second effect would still have occurred if the shared component had remained healthy.

Describe a scenario as a testable chain: enabling condition, initiating event, preventive or detective control, propagation path, effect on an objective and response decision. 'Data breach risk' alone does not identify the estimate or intervention. The analyst needs to know whether unauthorised access could reach only a test record or production keys and customer information. Make assumptions visible: backup validity, provider privilege boundaries, an independent audit log and team response time. If credible likelihood data are absent, a qualitative ranking with defined criteria can be useful, but do not convert it into a number that pretends to be precise. Record the impact range and the observation that could change the judgment.

A register links a decision to an owner, not merely to an observation. Include the scenario identifier, affected objective, cause and path, current evidence, impact severity and its basis, existing controls and which have been tested, residual exposure and confidence limits, treatment option, responsible decision maker, decision date and reopening trigger. 'The technical team' is not an accountable owner. Name a role with authority to allocate resources or pause a function. Where teams share work, distinguish final decision authority from execution and evidence roles. A late remediation task is different from the underlying risk scenario. The late task may increase exposure, but it does not replace the causal description. Mark evidence as established, estimated or unverified rather than using one colour to imply uniform certainty.

A small impact matrix helps avoid duplication. Rows might be accurate orders, fraud detection and customer response; columns might be shared identity, data store and alerts. Mark each evidenced intersection and link it to an exercise or incident. Many marks do not prove that the supplier is inherently dangerous. They indicate a concentration of dependence worth testing for common failure. Look for a control likely to fail with the event it is meant to detect. If the alert dashboard itself requires login through the failed provider, it does not demonstrate detection during that provider's outage. Move critical observation to an independent route or establish a bounded manual procedure, and test it. Also examine what emergency controls do to confidentiality and integrity, not only availability.

Draw two short trees to locate interventions. In the cause tree, ask how the event arises: incorrect configuration, approval of a change without review, and failure to detect it early. In the consequence tree, ask what follows: lost access, inability to change a fraud rule, a backlog of transactions needing review, then an inaccurate message to customers. A preventive control interrupts a cause path. Detection reduces time to awareness, mitigation limits propagation, and recovery restores the objective. Four named controls do not constitute four independent layers if all require the same identity service. Test one common failure to see which layer survives. If none does, escalate the combined exposure to the portfolio owner rather than split it among teams until each fragment appears acceptable.

When ranking treatments, examine their effect on the causal path and on another objective. Moving alerts to a separate channel may reduce detection failure but expose sensitive data if full transaction details are sent without limits. Use minimum necessary information, access logging and an outage exercise for that channel. Pausing high-impact transactions may limit potential loss but deny urgent service to a legitimate customer. Record affected groups, appeal or assistance routes and authority to restart. Do not call one isolated control test a final residual-risk estimate. Reassemble the scenario with other controls and test activation order and dependencies. The register then becomes a decision-review tool when supplier or design changes, rather than an archive of coloured dots.