What this template is for
Risk registers are how organisations stop being surprised by predictable problems. The discipline of writing down ‘this might happen, here’s what we’d do’ converts vague anxiety into a tracked, owned, reviewable record - and crucially, makes it queryable so executives can see what the team is worried about without sitting through a status meeting.
This template enforces three pieces of register hygiene:
- Required fields on the create screen - likelihood, impact, owner, mitigation, contingency, trigger indicators, review cadence. Without these, risk register entries become wishlists; with them, they become decisions.
- STM-created sub-tasks - assess, mitigate, contingency, triggers, owner, review cadence, quarterly close-out. The close-out sub-task is the one teams skip; without it, risk registers grow forever and lose signal.
When to use it
Use this template for project and program risks that have non-trivial impact and reasonable likelihood. Some teams maintain a separate operational risk register (security risks, compliance risks, key-person risks) using the same template - that’s fine; filter by component or label rather than splitting into multiple registers.
Don’t track every possible risk - only those worth a named owner and a review cadence. If nobody’s reviewing the entry, it’s not a register entry, it’s a worry written down.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Risk: third-party API rate limits could throttle Q3 launch | Yes |
Risk Description (custom) | Specific scenario - 'if X happens, then Y' | Yes |
Likelihood (custom) | Low / Medium / High - assessed, not guessed | Yes |
Impact (custom) | Low / Medium / High - in customer / revenue / time terms | Yes |
Risk Score (custom) | Likelihood * Impact, used for prioritisation | Yes |
Owner (custom) | @named.person.who.tracks.this | Yes |
Linked Project / Epic | EPIC-228 or PROGRAM-12 | No |
Mitigation Strategy (custom) | What we'll do BEFORE the risk materialises | Yes |
Contingency Plan (custom) | What we'll do IF the risk materialises | Yes |
Trigger Indicators (custom) | Signals that suggest the risk is moving from possible to imminent | No |
Review Cadence (custom) | Weekly / Sprint / Monthly | Yes |
Status (custom) | Open / Mitigating / Realised / Closed - no longer relevant | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Assess likelihood and impact - document the reasoning, not just the score
- Write mitigation strategy - what we'll do BEFORE this materialises
- Write contingency plan - what we'll do IF this materialises
- Identify trigger indicators - what tells us the risk is moving
- Assign named owner - not 'the team'
- Add to recurring review cadence (sprint review, monthly, etc.)
- Quarterly close-out review - still relevant? Update or close
Common questions
What's the difference between a Jira risk and an issue?
A risk is something that might happen. An issue is something that has happened. A risk that materialises stops being a risk and becomes a problem to solve - typically tracked as a new incident, bug, or task ticket, with the risk register entry updated to 'realised' so the historical record stays accurate.
How should likelihood and impact be assessed on a Jira risk?
With named criteria, not vibes. Likelihood: Low (under 10% probability over the relevant time window), Medium (10-50%), High (over 50%). Impact: Low (manageable within team), Medium (visible at department level), High (executive escalation). Document the scale so risk scores are comparable across the team.
How often should a Jira risk register be reviewed?
Per the cadence on each entry, but at minimum monthly for active projects. The point of a risk register is to catch risks before they become incidents; a register that's reviewed quarterly misses fast-moving risks. Bake the review into existing meetings - project status, sprint planning - rather than scheduling separate risk meetings nobody attends.
Should every risk have a mitigation and contingency plan?
Every risk that's worth tracking does. If you can't write a one-paragraph mitigation strategy or contingency plan, you don't understand the risk well enough to track it - and tracking risks you can't articulate creates noise without value. Spend the time to articulate it, or close the entry.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →