Build a causal risk scenario under uncertainty

A risk meeting presents a slide saying “identity risk: 16 out of 25.” What made it 16? Does it mean that an employee's password might be stolen, an attacker could approve a payment, or the login service could fail? Without a causal path, a leader cannot choose where to intervene or which evidence would change the estimate. A useful scenario connects a threat to an unwanted business result through stated conditions, keeping observations apart from assumptions. The objective is not to claim knowledge of the future. It is to make a decision that can respond to new evidence.

Build the path from the right first. Define the **consequence** for a service or person: an incorrect refund, disclosed data, or service interruption. Ask which action would cause it, who could take that action, and through which permission or workflow. Then add the preceding conditions: a stolen session token, missing second approval, or an administrative privilege broader than the task requires. Read the resulting chain from left to right. Every arrow needs a plausible mechanism. A phishing message alone does not establish a completed theft; several steps and observations separate them.

NIST SP 800-30 Rev. 1 distinguishes factors in a risk model, including threat, vulnerability or predisposing condition, likelihood, and impact. It does not prescribe one algorithm for combining them. It asks a model to define its factors and relationships, and recognizes that uncertainty may be expressed in ranges or qualitative descriptions instead of a single numerical point. A colored risk matrix can help sort work if its scales and limitations are understood. Its “16” does not become a physical measurement merely because two ordinal labels were multiplied.

Keep four things separate. A **threat** is an event or circumstance capable of harm, not just the name of a tool. A **vulnerability** is a weakness in the path that can be exploited, such as excessive privilege. A **predisposing condition** can make harm possible or larger without being a direct software flaw, such as one critical service depending on one identity provider. **Impact** is what the completed path does to the mission or customer. Likelihood estimates the occurrence of that path within a period and context; it is not the alert count. More alerts could mean better visibility, more noise, or more dangerous activity. The count alone does not select among these explanations.

## Assumption and test register

Use a four-column register: proposition, supporting evidence, decision implication, and disconfirming test. “The token survives password change” is supported by a controlled session test and can be challenged by revocation tests across devices. “The 20,000 cap is daily and enforced” is only a policy-text claim until implementation logs and an over-limit test confirm it. “The unresolved login alert is an attacker” is an unproven interpretation; correlate device, session, timing, and legitimate staff activity. Observed weakness is not evidence of exploitation. Absence of an exploitation log is not proof that exploitation did not occur.

Compare interventions by the arrow they break. Revoking all supervisor sessions interrupts token reuse but may delay support work; measure reauthentication time and fallback channels. An independent second approval for beneficiary changes breaks the transition from privilege to transfer even if a token remains stolen. Testing and correcting the daily limit caps one kind of financial impact, but it does not prevent other data exposure through the account. Do not call any single action “the risk solved.” Say what it blocks and what remains. If universal dual approval delays refunds beyond customer tolerance, start with high-risk beneficiary changes and review exceptions.

An executive briefing can now say: “Redirection using a supervisor token is plausible because sessions persist after password change and approval is single-person. One session's financial impact is provisionally capped at 20,000 per day **if** the limit works; implementation is not verified, and one alert is unresolved. We will isolate the session, test the cap, and examine change logs before assigning a frequency or approving a permanent investment.” The statement takes longer to read than a matrix color, but it prevents the board from deciding on contradictory data.

## Practice with a reference answer

A fictional firm uses a shipping supplier's API. An access token appears in a public build log for 40 minutes. Its permissions allow reading delivery addresses and creating shipments, but not changing payment accounts. The system records 12 shipment requests in that period. Ten match scheduled work; two have no internal order identifier. No address-read log is available. Construct two separate scenarios, distinguish what can be concluded, and choose immediate actions.

A sound answer separates the possibility of two unauthorized shipments from the possibility that addresses were read without a log. The ten matching requests do not clear the other two. Equally, missing order identifiers do not prove attacker action; an integration defect is another explanation. The token cannot be described as capable of diverting payments because it lacks payment permission. Revoke it and issue a replacement through a safe channel, then reconcile the two requests with supplier and internal order records. Ask whether the supplier can provide address-access evidence. A finding that the token was restricted to a network the public could not reach would lower one exposure; evidence that the two requests came from an unknown address would strengthen the unauthorized-shipment hypothesis. Name the evidence behind either change. A good answer draws both causal paths, respects the permission boundary, and names uncertainty instead of treating it as zero or certainty.