From a Risk Description to a Treatment Decision

A risk is the possibility that an event will affect an objective, not merely a vulnerability or an incident that has already occurred. Start a record with an asset or service, a plausible threat, the weakness or condition that makes the event possible, and its consequence. For example, a long-lived account-recovery link could be used by someone who obtained it to recover another person's account; impact depends on what that account can reach. 'High risk' without a stated reason is not analysis. Record known facts, assumptions and the decision owner. Naming an owner makes response accountable; it does not make the risk disappear.

Likelihood estimates the chance of the scenario within a defined horizon; impact estimates the harm if it occurs. Keep them separate. A frequently exposed service may face many attempts but a public-read account may have limited impact, whereas rarely used administrative access can have lower likelihood but severe impact. Our practice uses an ordinal scale of 1 low, 2 medium and 3 high for each dimension and multiplies the values for an initial ranking only. This does not mean that a real-world 3 is three times a 1. If likelihood evidence is missing, record uncertainty instead of inventing a percentage. Equal scores can require a tie break based on asset importance, time pressure or further evidence.

Risk management does not end when a cell turns red. Set the context and objective, identify scenarios, analyze likelihood and impact, evaluate priority, choose a response, and monitor its result. A safeguard can reduce likelihood; a recovery plan can reduce consequence. An organization might avoid a risky activity or contractually transfer some financial consequence, but transfer does not remove its responsibility to protect people and oversee the provider. Acceptance is a conscious decision about the residual risk within delegated authority. Each treatment needs an owner, due date, observable success criterion and a reason to revisit it when technology or asset value changes.

Compare each treatment with the part of the scenario it changes. A shorter link lifetime reduces the window for misuse, but does not necessarily speed backup restoration. More frequent backups may reduce lost data, but do not prevent a stolen account from opening administration. Tie each action to a test criterion. An example is 'ten legitimate recovery attempts succeeded within the chosen lifetime, and every attempted reuse failed in a test environment,' rather than 'security improved.' Do not turn a test-environment result into a guarantee for production. Monitor the deployed control and revise the decision when usage changes.