What Should Be Included in a Risk Register

SOP-RM-001: Risk Register Construction & Maintenance

Chief Architect: Julian Vance | Template Registry Engineering

---

1. Document Control Block

---

2. Executive Summary & Purpose

The purpose of this SOP is to standardize the identification, assessment, and mitigation tracking of operational, technical, and strategic risks within Template Registry projects. This document ensures consistent risk documentation, enabling data-driven decision-making and minimizing systemic exposure.

---

3. Scope & Prerequisites

• Scope: Applies to all engineering departments, product management, and third-party vendor integrations.
• Tools/Software: Jira (Risk Issue Type), Confluence (Master Registry), or GRC (Governance, Risk, and Compliance) platform.
• Prerequisites: Access to project technical specifications, historical post-mortem data, and stakeholder authority to implement mitigation controls.

---

4. Roles & Responsibilities (RACI Matrix)

---

5. Step-by-Step Procedure

Phase 1: Risk Identification

• Define the risk scope (Project, Operational, or Security).
• Document the risk description using the "Condition + Consequence" format.
• Assign a unique Risk ID (e.g., R-001).

Phase 2: Assessment & Quantifying

• Determine Likelihood (1-5 scale: 1=Rare, 5=Almost Certain).
• Determine Impact (1-5 scale: 1=Negligible, 5=Catastrophic).
• Calculate Risk Score (Likelihood × Impact).

Phase 3: Mitigation Strategy

• Assign a strategy: Avoid, Mitigate, Transfer, or Accept.
• Define specific mitigation actions (What, Who, When).
• Assign a "Risk Owner" (Must be an individual, not a department).

Phase 4: Monitoring & Review

• Audit the registry for staleness (Monthly minimum).
• Update the registry post-mitigation to reflect the Residual Risk level.
• Close the risk if the mitigation satisfies the threshold for closure.

---

6. Quality Assurance & Pro-Tips

• Metric Thresholds:
  • High Risk (15-25): Immediate mitigation plan required. Escalation to Chief Architect mandatory.
  • Medium Risk (6-12): Scheduled review and monitoring.
  • Low Risk (1-5): Accepted risk; monitor for drift.
• Pro-Tips:
  • Avoid "Vague Risks." If you cannot define the mitigation, you have not defined the risk.
  • The "So What?" Test: If the consequence is not measurable in terms of time, budget, or quality, it is not a project risk.
  • Common Pitfall: Treating "Issues" (realized events) as "Risks" (potential events). Use separate trackers for active issues.

---

7. Frequently Asked Questions

Q: How do we differentiate between an Issue and a Risk? A: A Risk is a potential event that has not yet occurred but has a probability of impacting project objectives. An Issue is a risk that has manifested; it requires a resolution plan, not a mitigation plan.

Q: Who is responsible for updating a risk that spans multiple departments? A: The "Risk Owner" is solely responsible for coordinating across departments. If a risk impacts multiple domains, the Project Lead must designate a Lead Owner to prevent ownership fragmentation.