Risk Scoring Cheat Sheet
This page is a reference for every risk assessment you will do. Print it, bookmark it, or keep it open when building a risk register.
Keep this handy
You will use this scoring framework every time you assess a risk, review a vendor, or present findings to leadership. Consistency in scoring is what makes a risk register useful over time.
Likelihood scale
┌───────┬────────────────┬──────────────────────────────────────────────────────┐ │ Score │ Label │ Description │ ├───────┼────────────────┼──────────────────────────────────────────────────────┤ │ 1 │ Rare │ Requires multiple unlikely conditions to align. │ │ │ │ Has never happened here. Industry incidents are │ │ │ │ exceptional. │ │ │ │ Example: Regional cloud provider outage lasting │ │ │ │ 24+ hours. │ ├───────┼────────────────┼──────────────────────────────────────────────────────┤ │ 2 │ Unlikely │ Could happen, but controls are in place and working. │ │ │ │ Has not happened in 2+ years. │ │ │ │ Example: Credential compromise with MFA enforced │ │ │ │ across the org. │ ├───────┼────────────────┼──────────────────────────────────────────────────────┤ │ 3 │ Possible │ Has happened before or plausibly could. Some │ │ │ │ controls exist but are imperfect. │ │ │ │ Example: Phishing email reaches an employee inbox │ │ │ │ despite email filtering. │ ├───────┼────────────────┼──────────────────────────────────────────────────────┤ │ 4 │ Likely │ Expected to happen within the next 12 months. │ │ │ │ Known gaps exist. │ │ │ │ Example: Third-party dependency has a known CVE │ │ │ │ with no patch schedule. │ ├───────┼────────────────┼──────────────────────────────────────────────────────┤ │ 5 │ Almost certain │ Currently happening or will happen imminently. │ │ │ │ No controls in place. │ │ │ │ Example: Production database has no encryption and │ │ │ │ stores PII. │ └───────┴────────────────┴──────────────────────────────────────────────────────┘
How likely is this risk to materialize?
Impact scale
┌───────┬────────────────┬──────────────────────────────────────────────────────┐ │ Score │ Label │ Description │ ├───────┼────────────────┼──────────────────────────────────────────────────────┤ │ 1 │ Negligible │ Internal inconvenience only. No customer impact. │ │ │ │ No regulatory notification. Resolved in hours. │ │ │ │ Example: Dev environment downtime. │ ├───────┼────────────────┼──────────────────────────────────────────────────────┤ │ 2 │ Minor │ Small number of users affected briefly. No data │ │ │ │ loss. Resolved in a day. Minor cost. │ │ │ │ Example: Staging credentials rotated after accidental│ │ │ │ exposure in a PR. │ ├───────┼────────────────┼──────────────────────────────────────────────────────┤ │ 3 │ Moderate │ Noticeable service degradation. Limited data │ │ │ │ exposure. May require customer notification. Days │ │ │ │ to resolve. │ │ │ │ Example: Non-sensitive metadata exposed via │ │ │ │ misconfigured API endpoint. │ ├───────┼────────────────┼──────────────────────────────────────────────────────┤ │ 4 │ Major │ Significant data breach or extended outage. Multiple │ │ │ │ customers affected. Regulatory notification likely. │ │ │ │ Reputation damage. Weeks to recover fully. │ │ │ │ Example: Customer PII exposed via public S3 bucket. │ ├───────┼────────────────┼──────────────────────────────────────────────────────┤ │ 5 │ Catastrophic │ Existential threat to the business. Massive data │ │ │ │ breach. Regulatory fines. Litigation. Loss of major │ │ │ │ customers. Months to recover, if recoverable. │ │ │ │ Example: Full database exfiltration of health records│ │ │ │ with HIPAA breach notification to HHS. │ └───────┴────────────────┴──────────────────────────────────────────────────────┘
How much damage when the risk materializes?
Risk score interpretation
The risk score is likelihood x impact. It ranges from 1 to 25.
┌─────────────┬─────────────┬──────────────────────────────────────────────────┐ │ Score range │ Severity │ Recommended action │ ├─────────────┼─────────────┼──────────────────────────────────────────────────┤ │ 1 – 4 │ Low │ Accept and monitor. Review quarterly. Document │ │ │ │ the acceptance decision. │ ├─────────────┼─────────────┼──────────────────────────────────────────────────┤ │ 5 – 9 │ Medium │ Mitigate within the current quarter. Assign an │ │ │ │ owner. Track in the risk register actively. │ ├─────────────┼─────────────┼──────────────────────────────────────────────────┤ │ 10 – 15 │ High │ Mitigate within 30 days. Escalate to leadership. │ │ │ │ Requires a documented mitigation plan. │ ├─────────────┼─────────────┼──────────────────────────────────────────────────┤ │ 16 – 25 │ Critical │ Mitigate immediately. Block affected operations │ │ │ │ if necessary. Board-level visibility. This is a │ │ │ │ stop-the-line risk. │ └─────────────┴─────────────┴──────────────────────────────────────────────────┘
What the score means and what to do about it
Scores are starting points
A risk with likelihood 2 and impact 5 (score 10) may warrant more urgency than one with likelihood 4 and impact 3 (score 12). High-impact, low-likelihood risks — like a full database breach — deserve attention disproportionate to their score. Use the number to prioritize, then apply judgment.
Risk response options
┌──────────────┬───────────────────────────────────────────────────────────────┐ │ Response │ When to use │ ├──────────────┼───────────────────────────────────────────────────────────────┤ │ Accept │ The risk score is low, or the cost of mitigation exceeds the │ │ │ potential loss. Document the decision and the rationale. │ │ │ Review periodically — accepted risks can grow. │ │ │ │ │ │ Example: Accepting the risk that a junior engineer could │ │ │ accidentally push to main, given branch protection rules. │ ├──────────────┼───────────────────────────────────────────────────────────────┤ │ Mitigate │ Reduce likelihood, impact, or both by implementing a │ │ │ control. The most common response. Reduces but does not │ │ │ eliminate the risk — the remainder is residual risk. │ │ │ │ │ │ Example: Deploying MFA to reduce the likelihood of │ │ │ credential compromise from 4 to 2. │ ├──────────────┼───────────────────────────────────────────────────────────────┤ │ Transfer │ Shift the financial impact to a third party. Does not │ │ │ eliminate the risk — it changes who pays when it happens. │ │ │ │ │ │ Example: Purchasing cyber insurance to cover breach │ │ │ response costs, legal fees, and regulatory fines. │ ├──────────────┼───────────────────────────────────────────────────────────────┤ │ Avoid │ Eliminate the risk entirely by not doing the activity that │ │ │ creates it. The most effective response, but not always │ │ │ possible — sometimes the business requires the activity. │ │ │ │ │ │ Example: Not storing cardholder data by using Stripe │ │ │ Checkout, eliminating PCI DSS scope for card storage. │ └──────────────┴───────────────────────────────────────────────────────────────┘
Four ways to respond to an identified risk
Quick reference: risk register columns
Every risk register entry should capture these fields:
┌─────────────────────┬────────────────────────────────────────────────────────┐ │ Column │ What it captures │ ├─────────────────────┼────────────────────────────────────────────────────────┤ │ Risk ID │ Unique identifier (e.g., RISK-001) │ │ Title │ Short name (e.g., "Unencrypted PII at rest") │ │ Description │ What could happen and why │ │ Category │ Technical / Operational / Compliance / Strategic │ │ Likelihood (1-5) │ How likely to materialize │ │ Impact (1-5) │ How much damage when it does │ │ Risk Score │ Likelihood x Impact │ │ Risk Owner │ Person accountable for managing this risk │ │ Response │ Accept / Mitigate / Transfer / Avoid │ │ Mitigation Plan │ Specific actions to reduce likelihood or impact │ │ Status │ Open / In Progress / Mitigated / Accepted / Closed │ │ Last Review Date │ When this risk was last evaluated │ └─────────────────────┴────────────────────────────────────────────────────────┘
Standard risk register columns