Tingg

h1. Risk Register – Entry Template

*Purpose:* Capture, track, and manage risks in a consistent and auditable manner  

*Scope:* Product, Technical, Operational, Compliance, and Business risks

{{toc}}

---

h2. 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 |

Guidelines:

* One risk per entry

* Title should clearly state the risk, not the symptom

Example:

*bq.* Inadequate audit logging may lead to HIPAA non-compliance.

---

h2. 2. Risk Description

Describe the risk clearly and concisely.

Include:

* What could go wrong

* Why it matters

* Who or what is impacted

Avoid:

* Solutions

* Long narratives

* Speculation

---

h2. 3. Risk Impact & Likelihood

|_. Attribute |_. Level |

| Impact | Low / Medium / High / Critical |

| Likelihood | Rare / Possible / Likely / Almost Certain |

| Overall Risk Level | Low / Medium / High |

Guidelines:

* Impact = severity of damage

* Likelihood = probability of occurrence

* Overall risk should reflect combined judgment

---

h2. 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*.

---

h2. 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 |

Guidelines:

* Mitigation must be realistic

* One clear owner is mandatory

* “Monitor only” is acceptable if justified

---

h2. 6. Current Status

|_. Field |_. Value |

| Status | Open / Mitigating / Monitoring / Closed |

| Last Reviewed On | YYYY-MM-DD |

| Next Review Due | YYYY-MM-DD |

Rules:

* Risks must be reviewed periodically

* Stale risks must be escalated or closed

---

h2. 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.

---

h2. 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.

---

h2. 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*

---

h2. 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.