Operational Risk Register Builder
Find fragile dependencies and decide what to fix first.
Build an evidence-led operational risk register with warning signals, verified controls and prioritised responses.
Ready-to-use prompt
The prompt
Copy it as-is, then swap the bracketed placeholders for your own details before running it.
Role: You are building an operational risk register for a working business, not a compliance document.
Context:
- What the business does and how it delivers: {{operation}}
- Critical dependencies: people, suppliers, systems, licences: {{dependencies}}
- Volume, seasonality and peak periods: {{load_profile}}
- Incidents and near misses in the past two years: {{history}}
- Existing controls, backups and insurance: {{controls}}
- What the business cannot survive: {{intolerable_outcomes}}
Task: Build the register.
1. Identify risks across six areas: people and key-person dependency, supplier and third party, systems and data, process and quality, capacity and demand, and legal or regulatory exposure.
2. For each risk give: description in cause and effect form, likelihood over twelve months as low, medium or high with reasoning, impact expressed in money, downtime or customer loss, existing control and whether it has ever been tested, and the residual exposure after that control.
3. Early warning signal: the observable indicator that this risk is developing, and who would see it first.
4. Response: mitigate, transfer, accept or avoid, with the specific action, an owner role and a cost band.
Then return:
- The top five by residual exposure, with the single cheapest action that most reduces each.
- Single points of failure where one person, supplier or system carries the whole operation.
- Controls that exist on paper but have never been tested, ranked by what depends on them.
- Risks to monitor only, with the threshold that would move them onto the active list.
- Review cadence, and the events that should trigger an unscheduled review.
Rules:
- Every risk must be stated as a cause leading to an effect, never as a topic.
- Do not score anything as low likelihood if it has already happened once. Say so.
- Distinguish clearly between a control that exists and a control that is verified.Estimated results
Editor's note
Why this prompt matters
An operational risk register should help you decide what to fix before delivery fails, not simply record that risks exist. In a working business, the difficult part is connecting scattered knowledge: the dispatcher knows which supplier misses collections, finance knows the cash buffer, and only one administrator knows whether backups restore successfully. This prompt brings those observations into one decision framework.
Start with the delivery chain in {{operation}}, then identify dependencies by function rather than listing names alone. In {{history}}, include near misses, workarounds and repeat failures. Describe controls honestly in {{controls}}: a documented recovery procedure is different from a successful recovery test.
The result is a prioritised register built around consequences, warning signals and accountable responses. Use it in an operations meeting to challenge assumptions, assign verification work and choose affordable interventions. Treat the first draft as a structured hypothesis for the team to validate, not an authoritative assessment.
Anatomy
Prompt engineering breakdown
Role
Prioritises operational usefulness over compliance formatting.
Context
Grounds risks in delivery evidence.
Goal
Surface and prioritise remaining exposure.
Constraints
Enforces causal risks and control verification.
Output format
Comparable entries plus decision shortlists.
Why this structure works
Connects failure mechanisms to accountable interventions.
What you'll get
Expected output
What the register contains
Expect coverage across people, suppliers, systems, process, capacity and legal or regulatory exposure. Each entry should connect a cause to an operational consequence, explain twelve-month likelihood, quantify impact where evidence permits, and distinguish existing controls from tested controls. Residual exposure means what remains after credible controls, not what remains after assuming every safeguard works.
Warning signals should identify both an observable change and the role that notices it first. Responses should specify mitigate, transfer, accept or avoid, followed by an action, owner role and cost band. Define cost bands locally; do not accept unexplained labels such as “cheap”.
Worked example
Assume a small distributor uses one courier for all outbound orders. Its supplied history includes two missed collections, peak dispatches reach 120 orders daily, and its alternative courier account has never been used. These are illustrative inputs, not benchmarks.
- Risk: A missed collection at peak leaves up to 120 orders awaiting dispatch, delaying customer deliveries.
- Likelihood: Medium over twelve months, provisionally; previous incidents rule out low under this prompt.
- Control: Alternative courier account exists; collection capability is unverified.
- Residual exposure: Elevated until fallback capacity and cut-off times are confirmed. Refund exposure remains unknown without order economics.
- Warning: No collection confirmation by the agreed escalation time; dispatch lead sees it first.
- Response: Mitigate through a paid trial collection, owned by operations, cost band pending a quote.
Decision shortlist
The final sections identify five leading residual exposures, each with its cheapest meaningful reduction; single points of failure; untested controls ranked by dependency; and monitor-only risks with activation thresholds. They also set review cadence and incident-triggered reviews. Challenge whether courier testing outranks other actions before approving spend.
Under the hood
Why this prompt works
The Role frames the exercise around operating decisions rather than compliance presentation. That matters because a polished register can still omit the failure that stops tomorrow’s deliveries. Context connects {{dependencies}} and {{load_profile}} to {{history}}, {{controls}} and {{intolerable_outcomes}}, giving the model evidence for prioritisation rather than inviting a generic catalogue.
The Task forces each risk through the same sequence: cause, consequence, likelihood, control, remaining exposure, warning and response. This makes entries comparable while exposing missing information. The Rules prevent topic-only risks and stop an untested safeguard being treated as demonstrated protection.
The rule against low likelihood after a previous occurrence is deliberately conservative; it is not a statistical forecasting method. Keep its classification, but record material changes since the incident. Finally, the shortlist and monitoring thresholds turn analysis into decisions: act now, verify first, or watch a defined signal.
Model fit
Best AI models for this prompt
ChatGPT
Useful for consistent register tables. Ask it to flag missing impact evidence rather than fill gaps with plausible amounts.
Claude
A strong primary choice for detailed operational narratives. Ask it to distinguish documented controls from verified controls throughout the shortlist.
Gemini
Useful when reviewing supplied supplier contracts alongside operations notes. Request source references for contractual claims and flag anything needing legal interpretation.
Grok
Useful for challenging optimistic recovery assumptions. Keep it anchored to supplied evidence and ask it to label speculative failure scenarios explicitly.
When to use
- Before peak-season staffing and supplier commitments.
- After an outage or delivery near miss.
- Before growth increases dependency on one system.
- Ahead of insurance renewal or diligence.
When not to use
- For accredited safety-critical assessments.
- During incidents needing live operational command.
- To resolve legal or coverage questions independently.
- When dependency evidence is unavailable; gather it first.
Get more from it
Pro tips
- 1
Supply recovery-test dates and outcomes.
- 2
Define cost bands before running.
- 3
Separate cash loss from delayed revenue.
- 4
Name owner roles, not departments.
- 5
Give monitoring thresholds measurement windows.
- 6
Validate the shortlist with frontline staff.
Don't ship this
Common mistakes
✗ Listing “staffing” as a risk.
Fix — Specify the absence and delivery consequence.
✗ Treating insurance as prevention.
Fix — Separate financial transfer from operational continuity.
✗ Inventing impact precision.
Fix — Label assumptions and request missing inputs.
People also ask
Frequently asked questions
Q.How is this different from a compliance risk assessment?
It is built to be used rather than filed. Every risk carries an observable early warning signal, an owner and a cost band, and controls are split into tested and untested, which a compliance grid rarely shows.
Q.Why score impact in money or downtime?
Because unitless scales produce debates that never close, and they cannot be compared against the cost of a mitigation. Units let you say plainly that a four-hundred pound control removes a fifteen-thousand pound exposure.
Q.How often should the register be reviewed?
The prompt proposes a cadence, but the more useful rule is event-driven: after any near miss, supplier change, key departure or system migration. Near misses are free data and most businesses throw them away.