How to run a risk register in Jira (without buying enterprise software)
Most project risk registers live in spreadsheets. That works until it doesn’t: the file gets emailed around, someone edits the wrong version, and by the time a risk escalates, nobody can tell who owned it or when the score changed.
If your team already works in Jira, you have most of what you need to fix this. Jira doesn’t ship with a native risk register, but its custom fields and board configuration are flexible enough to build one. This guide covers how to do that from scratch – and what to reach for when the DIY setup starts to feel like its own project.
What a risk register actually does
A risk register is a living record of every known risk on a project: what could go wrong, how likely it is, how bad the impact would be, who owns it, and what the mitigation plan is.
At minimum, each entry needs:
- Title: a short description of the risk
- Probability: how likely it is to happen (usually a 1–5 or 1–3 scale)
- Impact: how damaging it would be if it did (same scale)
- Risk score: probability × impact, used for prioritization
- Status: open, in progress, resolved, accepted, or closed
- Owner: the person responsible for mitigation
- Mitigation plan: what steps reduce the risk
That’s the core. Once you have those fields, you can triage, assign, and review risks like any other work item.
Step 1: Create a “Risk” issue type
Jira treats risks as just another kind of work item once you give them their own issue type. This keeps them separate from stories, tasks, and bugs – and makes filtering and reporting much cleaner.
To create the issue type:
- Go to Project settings in your Jira project.
- Select Issue types.
- Click Add issue type, name it “Risk,” and save.
For company-managed projects, you’ll do this through the Jira admin panel under Work items → Issue types. Team-managed projects let you create issue types directly in project settings without admin access.
Give it a distinct icon if you can. When you’re scanning a board or backlog, a visual cue matters.
Step 2: Add custom fields for risk scoring
Out of the box, Jira doesn’t have Probability or Impact fields. You’ll need to create them.
Go to the Jira admin panel, navigate to Fields, and create two new fields:
- Probability — use a dropdown or number field with values 1–5
- Impact — same structure
Add both fields to the Risk issue type’s field configuration. If your project uses a screen scheme, make sure these fields appear on the Risk create and edit screens.
For Risk Score, you have two options. You can calculate it manually (probability × impact) and store it in a third number field, or you can use Jira Automation to calculate and populate it whenever Probability or Impact changes. The automation route saves you from updating three fields every time a score changes.
A basic automation rule looks like this:
- Trigger: issue updated
- Condition: issue type is Risk AND (Probability or Impact changed)
- Action: edit the Risk Score field, set value to
{{issue.Probability}} * {{issue.Impact}}
This keeps scores current without manual arithmetic.
Step 3: Build a board to visualize risk status
A Jira board gives you a live view of where every risk stands. The simplest approach is a Kanban board with columns that map to the risk lifecycle:
| Column | What it means |
|---|---|
| Identified | Risk is logged but not yet assessed |
| Assessing | Owner is evaluating probability and impact |
| Mitigating | Mitigation plan is active |
| Monitoring | Risk is reduced but still being watched |
| Closed | Risk resolved, accepted, or no longer relevant |
Create a board filter that shows only the Risk issue type so the board doesn’t mix risks with development work. In Jira, go to Board settings → Filter and add issuetype = Risk to your JQL query.
You can also add swimlanes by owner or by risk score tier (high / medium / low) to make prioritization faster during team reviews.
Step 4: Link risks to Jira issues
The gap between a spreadsheet risk log and a Jira-native one is traceability. If the risk may impact one of the stories in your backlog, link it to the risk with one of the default link types, like “related to,” or create a new one. For example, “impacts” and “is impacted by.”
Additionally, connect a risk to the story, task, or epic that addresses it. Choose a link type like “is mitigated by” or create a custom one in your Jira admin settings.
This does a few things:
- Anyone looking at the mitigation task can see the risk it addresses.
- When you close the mitigation task, you have a clear signal to reassess the risk.
- Reviewers and auditors can trace decisions without hunting through separate files.
Step 5: Set up a regular review cadence
A risk register is only useful if people look at it. Without a process, even a well-configured register goes stale.
A simple cadence that might work for most teams:
- Weekly: each risk owner reviews their open risks and updates status
- Bi-weekly: the project lead reviews all high-score risks (score ≥ 12 on a 5×5 scale) with the team
- At milestones: full register review before major releases or phase gates
Talk to your leads, see what they have to say, and schedule these as recurring calendar events. The format matters less than the habit.
What this setup handles well
This DIY configuration gives you:
- Risk items alongside other work in Jira
- Automated score calculation
- Basic traceability through issue links
- Status tracking on a visual board
For small to medium projects, that covers the essentials without adding a new tool.
Where it runs into trouble
The manual setup has real limits.
No visual heatmap. Risk prioritization gets easier with a probability × impact matrix – a visual grid that shows which risks cluster in the critical zone. Jira boards show status, not risk score distribution. You can approximate this with filters and labels, but it’s not the same as seeing risk positions on a 5×5 grid at a glance.
Scoring drift. Custom number fields don’t enforce scoring conventions. Someone enters “10” for probability on a 1–5 scale, the automation fires, and the score becomes meaningless. You can add field validation, but it takes extra configuration.
Audit trail gaps. Jira tracks issue history, but it tracks everything – comments, assignment changes, description edits. Isolating the history of scoring and status decisions for a governance review takes manual filtering.
Setup time. Creating issue types, building field configurations, writing automation rules, and maintaining them across multiple projects is real administrative work. For teams running one or two projects, that’s manageable. For teams managing risk across a portfolio, it compounds quickly.
When a purpose-built app makes sense
If the DIY setup is working for you, keep using it. Frankly, I stick to this setup in the majority of the cases because of its simplicity and inherent traceability. The configuration above is free and entirely within what Jira provides.
If you want the structure without building it yourself, Simple Risk Management is a Jira app I built for this. It adds a PMBOK-aligned 5×5 heatmap directly to your Jira project, with drag-and-drop scoring, risk-to-issue linking, and a full audit trail for review prep. Risks live inside Jira – no separate tool, no third-party access to your project data. You can import an existing spreadsheet via CSV and pick up where you left off.
It’s not enterprise risk management software. It’s the structure this article describes, already configured and ready to use.
Install Simple Risk Management from the Atlassian Marketplace →
The honest case for keeping it in Jira
Spreadsheet risk logs solve an immediate problem but create a coordination one. By the time a risk is worth escalating, the data trail is in someone’s Downloads folder.
Jira already has the visibility, the workflow, and the ownership model your team uses for everything else. The work of setting up a proper risk register there – whether from scratch or with an app – pays off the first time a stakeholder asks “what happened with that risk?” and someone can actually answer.