Overview
Every security decision comes down to risk. Which risks do you accept, which do you mitigate, and which do you transfer? Without a structured risk management framework, those decisions happen informally and inconsistently. This template provides the methodology and documentation structure for identifying, analyzing, evaluating, treating, and monitoring cybersecurity risks across your organization. It works whether you follow ISO 31000, NIST RMF, or a custom approach.
Risk Management Lifecycle
- Establish context: define scope, stakeholders, and risk appetite
- Risk identification: catalog threats, vulnerabilities, and risk scenarios
- Risk analysis: assess likelihood and impact using qualitative or quantitative methods
- Risk evaluation: compare risk levels against acceptance criteria
- Risk treatment: select controls, transfer, accept, or avoid each risk
- Monitoring and review: track risk trends and treatment effectiveness
- Communication and reporting: report risk posture to leadership and the board
Risk Scoring Matrix
| Impact | Negligible (1) | Minor (2) | Moderate (3) | Major (4) | Severe (5) |
|---|---|---|---|---|---|
| Almost Certain (5) | 5 | 10 | 15 | 20 | 25 |
| Likely (4) | 4 | 8 | 12 | 16 | 20 |
| Possible (3) | 3 | 6 | 9 | 12 | 15 |
| Unlikely (2) | 2 | 4 | 6 | 8 | 10 |
| Rare (1) | 1 | 2 | 3 | 4 | 5 |
Building the Risk Register
The risk register is the central artifact of your risk management program. For each risk, document the risk ID, description, threat source, affected asset, existing controls, inherent risk score, treatment plan, residual risk score, risk owner, and review date. Group risks by category: operational, strategic, compliance, financial, and reputational. The register should be a living document reviewed at least quarterly and updated whenever new threats emerge or the business environment changes significantly.
Risk Treatment Options
Mitigation reduces the likelihood or impact through additional controls. Transfer shifts the financial burden through insurance or contractual terms. Acceptance acknowledges the risk when it falls within appetite and no further action is taken. Avoidance eliminates the risk entirely by discontinuing the activity. Each treatment decision should be documented with the rationale, the expected residual risk after treatment, and the responsible owner. Make sure treatment plans have budgets and timelines, not just intentions.
Reporting to the Board
Translate risk scores into business language. The board does not need to see your full risk register. Present a risk heatmap that shows the top 10 risks with their movement over time. Highlight risks above appetite, treatment plans in progress, and any risks the organization is accepting that the board should be aware of. Use trend arrows to show whether risks are increasing, decreasing, or stable. Tie risk discussions to business objectives so directors can make informed governance decisions.
Frequently Asked Questions
How often should the risk register be reviewed?
Quarterly at minimum, with ad-hoc reviews triggered by significant events like new threat intelligence, organizational changes, new regulations, or security incidents.
Should we use qualitative or quantitative risk analysis?
Start with qualitative (likelihood-impact matrix) since it is faster and well-understood. Move to quantitative methods like FAIR (Factor Analysis of Information Risk) for high-value decisions where you need financial estimates of expected loss.
How do we define risk appetite?
Risk appetite is the level of risk the organization is willing to accept to achieve its objectives. It should be set by the board with input from the CISO and CRO. Express it as a threshold on your risk scoring matrix and document it in a formal risk appetite statement.
What is the difference between inherent and residual risk?
Inherent risk is the level of risk before any controls are applied. Residual risk is what remains after controls and treatment plans are in place. Both should be tracked in the risk register to show the value of your security investments.
How do we get business units to participate in risk identification?
Make it easy and relevant. Conduct interviews and workshops focused on their business objectives, not technical threats. Use scenarios they care about such as revenue loss, customer churn, and operational disruption. Share results back to them so they see the value of participating.
Ready to use this resource?
Download it now or schedule a demo to see how Hunto AI can automate your security workflows.