Risk assessment examines what could go wrong, how likely it may be, and how serious the consequences could be. It helps a team choose safeguards and verification appropriate to the decision.
Before a journey, people consider weather, route conditions, and what a delay would affect. The useful response depends on both the chance of a problem and its consequences.
Describe concrete scenarios
State the trigger, failure, affected people or systems, and resulting harm. A specific scenario such as an account switch exposing a cached inbox is easier to evaluate than a broad label such as privacy risk. Include operational and human consequences alongside technical failures.
Estimate with visible uncertainty
Use available evidence about likelihood, exposure, and severity. A rating can support comparison, but a numerical matrix does not make uncertain judgments precise. Record assumptions and identify what additional information could materially change the assessment.
Choose controls and owners
Decide how the team will prevent, reduce, detect, or respond to the risk. Assign responsibility and define the evidence needed before proceeding. Consider the risk that remains after controls rather than treating the existence of a checklist as proof that the problem is solved.
Example: changing reward rules
A reward update can accidentally pay twice, erase progress, or block lesson completion. The team can inspect transaction boundaries, test repeat submissions, and observe a controlled rollout. Those actions address specific failure scenarios rather than relying on the fact that the code compiles.
Frequently asked questions
Key takeaways
- Describe risks through specific failure scenarios.
- Consider likelihood, severity, and exposure.
- Record uncertainty and assumptions.
- Assign controls, evidence, and accountable owners.