# Risk Register Builder

Builds a structured risk register from the threats you identify, scoring each by likelihood and impact and noting current controls. Use it at the start of a project or after a major scope change to get all known risks on paper and prioritized.

## Prompt

## Context
You are a project management assistant helping [PROJECT MANAGER NAME] build a risk register for [PROJECT NAME] at [ORGANIZATION NAME]. The project involves [PROJECT DESCRIPTION]. The project is currently in [PROJECT PHASE] and is scheduled to complete by [TARGET COMPLETION DATE]. Key stakeholders include [KEY STAKEHOLDERS]. The risk identification inputs below come from the project team.

Risk inputs from the team:
[RISK INPUTS]

## Task
Build a risk register table with these columns: Risk ID, Risk Description, Category (schedule / cost / scope / resource / external / safety), Likelihood (1 to 5), Impact (1 to 5), Risk Score (Likelihood x Impact), Priority (High if score 15 or above, Medium if 8 to 14, Low if 7 or below), Current Controls, Risk Owner, and Status (Open).

After the table, provide:
1. A top-3 list of the highest-scoring risks with one sentence on why each deserves immediate attention.
2. Any risk categories that appear underrepresented based on the project description, so the team can decide whether to dig deeper.

## Standards
- Assign Risk IDs sequentially: R-001, R-002, and so on.
- Use only the risks and controls the team provided. Do not invent risks, scores, owners, dates, or controls.
- If a risk input is vague, write the description as clearly as possible and flag it with "(Needs clarification)" in the Description field.
- Do not invent dollar figures, schedule estimates, or percentage probabilities. Use the 1-to-5 scale only.
- Keep each risk description to one sentence: what could go wrong and what it would affect.
- The Risk Owner column lists names or roles only if the team provided them; otherwise leave it blank.
- If any required input is missing or ambiguous, ask before building the register.

## Variables

- PROJECT MANAGER NAME
- PROJECT NAME
- ORGANIZATION NAME
- PROJECT DESCRIPTION
- PROJECT PHASE
- TARGET COMPLETION DATE
- KEY STAKEHOLDERS
- RISK INPUTS

## Input checklist

- [ ] Project name, phase, and target completion date from the project plan
- [ ] List of identified risks from the team, including any controls already in place
- [ ] Names or roles of likely risk owners for each risk category
- [ ] Confirm that all dates, scores, and status information come from your project records, not assumed by the AI
- [ ] Keep vendor names, contract values, and personnel details general or anonymized unless your AI tool is approved for sensitive project data
- [ ] A note on any risk categories the team already discussed so the AI can flag gaps

## Verification checklist

- [ ] Confirm every Risk ID is unique and sequential before sharing the register
- [ ] Recompute each Risk Score (Likelihood x Impact) yourself to catch arithmetic errors
- [ ] Check that no risk, control, owner, or date was invented by the AI that you did not provide
- [ ] Verify the Priority thresholds were applied correctly: High is 15 or above, Medium is 8 to 14, Low is 7 or below
- [ ] Confirm the top-3 list matches the highest numeric scores in the table
- [ ] Review any flagged '(Needs clarification)' descriptions with the team before the register is baselined

## Sample output

Sample output. Generated by AI from sample inputs:

Risk register for Project Atlas -- Northwind Logistics Warehouse Migration, Phase 2 (Planning).

| Risk ID | Risk Description | Category | Likelihood | Impact | Score | Priority | Current Controls | Risk Owner | Status |
|---|---|---|---|---|---|---|---|---|---|
| R-001 | Key migration vendor may miss the delivery window, delaying warehouse cutover by two or more weeks. | Schedule | 3 | 5 | 15 | High | Weekly vendor check-in; milestone payment tied to delivery. | Ops Director | Open |
| R-002 | Legacy inventory system may not map cleanly to the new warehouse management system, requiring rework. | Scope | 4 | 4 | 16 | High | Data mapping review scheduled for Week 3. | IT Lead | Open |
| R-003 | Trained staff turnover during migration window could reduce throughput at go-live. | Resource | 2 | 4 | 8 | Medium | Cross-training plan drafted; not yet executed. | HR Lead | Open |
| R-004 | Permit approval for dock expansion may be delayed by the city, pushing Phase 3 start. | External | 2 | 3 | 6 | Low | Permit submitted; city timeline is 30 business days. | Facilities | Open |
| R-005 | Budget variance from fuel and freight cost increases may exceed contingency reserve. | Cost | 3 | 3 | 9 | Medium | Contingency reserve in place; freight costs not yet locked. | (Needs clarification) | Open |

Top 3 risks:
1. R-002 (Score 16) -- A data mapping failure at this scale can halt the go-live entirely; the Week 3 review is the critical gate.
2. R-001 (Score 15) -- Vendor delivery is on the critical path; any slip cascades directly to cutover.
3. R-005 (Score 9) -- Freight cost volatility is active now; the contingency size needs confirmation against current quotes.

Underrepresented category: Safety. A warehouse migration involves physical relocation of equipment and personnel working in a changed environment. The team may want to add at least one safety risk before baselining.

## Customization notes

Adjust the scoring thresholds in the Standards block to match your organization's risk matrix. For larger programs, add columns for Residual Risk Score and Target Mitigation Date. Veterans and logistics professionals can use this same structure for readiness reviews by renaming categories to match their standard risk taxonomy (for example: personnel, equipment, sustainment, external).

---

From The Logistics, Operations & Project Management Library at vetslearn.com/libraries/logistics-pm