Risk Register – Entry Template¶
Purpose: Capture, track, and manage risks in a consistent and auditable manner
Scope: Product, Technical, Operational, Compliance, and Business risks
- Table of contents
- Risk Register – Entry Template
1. Risk Identification¶
| Field | Value |
|---|---|
| Risk ID | RISK-YYYY-NN |
| Risk Title | Short, descriptive name |
| Risk Category | Product / Technical / Operational / Security / Compliance / Business |
| Affected Area | Product / Service / Team / Customer / Platform |
| Identified By | Name / Role |
| Identified Date | YYYY-MM-DD |
- One risk per entry
- Title should clearly state the risk, not the symptom
Example:
bq. Inadequate audit logging may lead to HIPAA non-compliance.
2. Risk Description¶
Describe the risk clearly and concisely.
Include:- What could go wrong
- Why it matters
- Who or what is impacted
- Solutions
- Long narratives
- Speculation
3. Risk Impact & Likelihood¶
| Attribute | Level |
|---|---|
| Impact | Low / Medium / High / Critical |
| Likelihood | Rare / Possible / Likely / Almost Certain |
| Overall Risk Level | Low / Medium / High |
- Impact = severity of damage
- Likelihood = probability of occurrence
- Overall risk should reflect combined judgment
4. Risk Consequences¶
Describe potential consequences if the risk materializes.
Examples:- Regulatory penalties
- Customer trust erosion
- Service downtime
- Delivery delays
This section helps leadership understand why the risk matters.
5. Mitigation Strategy¶
Describe how the risk is being managed.
| Field | Value |
|---|---|
| Mitigation Type | Avoid / Reduce / Transfer / Accept |
| Mitigation Summary | Short description |
| Owner | Role / Name |
| Target Date | YYYY-MM-DD |
- Mitigation must be realistic
- One clear owner is mandatory
- “Monitor only” is acceptable if justified
6. Current Status¶
| Field | Value |
|---|---|
| Status | Open / Mitigating / Monitoring / Closed |
| Last Reviewed On | YYYY-MM-DD |
| Next Review Due | YYYY-MM-DD |
- Risks must be reviewed periodically
- Stale risks must be escalated or closed
7. Related References¶
Link to relevant items for traceability.
Examples:- Related Epics / Stories
- Compliance requirements
- Sprint(s) impacted
- Decision Records
- External regulations or policies
Use Redmine links where possible.
8. Closure (If Applicable)¶
Complete this section only when closing a risk.
| Field | Value |
|---|---|
| Closure Date | YYYY-MM-DD |
| Closure Reason | Mitigated / No Longer Relevant / Accepted |
| Closure Notes | Short explanation |
bq. Closed risks must not be deleted — history must be preserved.
9. Governance Rules¶
- Every active risk must have an owner
- High and Critical risks must be reviewed regularly
- Risks must not be hidden inside issues or comments
- This register is for risks, not bugs or tasks
10. Final Statement¶
bq. Risks that are not written down are unmanaged risks.
This template ensures risks are visible, owned, and reviewed —
before they become incidents.
Updated by Redmine Admin about 2 months ago · 1 revisions