Risk Analysis: A Practical Guide

Risk identification tells you what might affect your objectives. Risk analysis helps you understand how much each identified risk matters.

A practical analysis considers:

• how likely the uncertain event is to occur;
• how serious the consequences may be;
• which objectives may be affected;
• how effective existing controls are;
• how urgent the risk is;
• how risks compare with one another; and
• where limited treatment resources should be directed.

Many organisations analyse risks qualitatively using descriptive scales such as Rare, Possible, Likely, Minor, Major, Low, and High. Qualitative analysis is faster and easier to apply than detailed quantitative modelling, but it still requires carefully defined criteria and disciplined judgement.

This guide explains how to define probability and impact scales, use risk matrices, distinguish inherent from residual risk, prioritise risks, avoid common assessment errors, and configure a consistent assessment model in Jira.

What is risk analysis?

Risk analysis is the process of understanding the nature and level of a risk.

It normally follows risk identification and supports the next decisions in the risk-management process:

• Is the risk within tolerance?
• Does it require treatment?
• How urgently should the organisation act?
• Which risks deserve the most attention?
• What additional information is required?
• Who should approve the response?
• How should the risk be monitored?

Risk analysis should be tied to objectives. A consequence is significant because it may affect cost, schedule, safety, service quality, compliance, reputation, strategic outcomes, or another defined objective.

A risk assessment performed without clear objectives easily becomes a mechanical exercise in assigning colours.

Qualitative and quantitative risk analysis

Risk analysis can be qualitative, quantitative, or a combination of both.

Qualitative risk analysis

Qualitative analysis uses descriptive categories to estimate probability and impact.

Examples include:

• Rare, Unlikely, Possible, Likely, Almost Certain
• Insignificant, Minor, Moderate, Major, Severe
• Low, Medium, High, Extreme

The resulting assessment may be displayed in a risk matrix or translated into a risk level.

Qualitative analysis is widely used because it is relatively quick, inexpensive, easy to explain, suitable when data is limited, and useful for screening and prioritisation.

Its principal limitation is subjectivity. Two assessors may apply the same label differently unless the scales are clearly defined.

Quantitative risk analysis

Quantitative analysis represents probability and consequences numerically.

Examples include:

• a 25% probability of occurrence;
• an estimated loss of $300,000;
• a potential schedule delay of 40 days;
• an expected annual loss; or
• a range of possible outcomes modelled through simulation.

Quantitative analysis can support detailed financial, engineering, schedule, or investment decisions. It also requires reliable data, suitable models, expertise, and sufficient time.

A numerical result is not automatically more accurate. Poor assumptions expressed as precise numbers may create false confidence.

Using both approaches

Qualitative analysis is often used to screen the full risk register. Higher-priority or more complex risks may then receive quantitative analysis.

For example:

1. Assess all project risks qualitatively.
2. Select the highest or most decision-critical risks.
3. Model cost or schedule exposure quantitatively.
4. Use both results to guide treatment and contingency decisions.

Probability and impact

The two most common dimensions in qualitative risk analysis are probability and impact.

Probability

Probability describes the likelihood that an uncertain event will occur within the relevant period.

It answers:

How likely is this risk to happen?

Probability should apply to the uncertain event, not its cause or consequence.

For example:

Because the integration specification is incomplete, there is a risk that significant interface defects will be found during system testing, resulting in rework and schedule delay.

The probability assessment concerns the occurrence of significant interface defects during testing. It does not separately assess whether the specification is incomplete—the cause is already present.

Impact

Impact describes the consequence if the risk occurs.

It answers:

If this risk happens, how serious will the effect be?

Impact may be assessed against one or more objectives, including:

• cost;
• schedule;
• scope;
• quality;
• safety;
• compliance;
• service continuity;
• reputation;
• customer outcomes; and
• strategic value.

A single overall impact score is simple to operate, but multiple impact dimensions can show more clearly why a risk matters.

Defining probability scales

Labels such as Low and High are ambiguous unless they have agreed meanings.

One person may interpret Low probability as less than 10%. Another may use it for anything below 50%. Both may believe they are applying the model correctly.

A probability scale should therefore include explicit definitions.

Example five-level probability scale

Level	Label	Illustrative probability	Example description
1	Rare	1–10%	Exceptional; not expected in normal circumstances
2	Unlikely	11–30%	Could occur, but there is limited evidence or precedent
3	Possible	31–50%	Plausible and may occur under current conditions
4	Likely	51–80%	More likely than not; comparable events occur regularly
5	Almost Certain	81–99%	Expected to occur unless conditions change

These percentages are illustrative rather than universal. The boundaries should fit the decisions the organisation needs to make.

Frequency-based probability scales

For recurring operational events, frequency may be more useful than percentages.

Level	Label	Illustrative frequency
1	Rare	Less than once in ten years
2	Unlikely	Once in five to ten years
3	Possible	Once in two to five years
4	Likely	Several times within two years
5	Almost Certain	Several times each year

The time horizon must be explicit. “A 20% probability” means little unless the assessor knows whether the period is one month, one project, or five years.

Principles for a useful probability scale

A good scale should be:

• mutually exclusive;
• collectively comprehensive;
• understandable to assessors;
• relevant to the assessment period;
• supported by evidence where possible;
• stable enough for comparisons over time; and
• reviewed when the operating context changes.

Do not assume equally spaced probability bands are always best. A safety or regulatory context may need finer discrimination at very low probabilities, while ordinary project risks may not.

Improving probability assessments

Probability is difficult because the future is uncertain and human judgement is affected by bias.

Common influences include:

• recent events being easier to recall;
• excessive confidence in personal experience;
• anchoring on the first estimate;
• pressure to match a senior stakeholder’s view;
• optimism or pessimism;
• confusion between possibility and probability; and
• lack of historical data.

Several practices can improve the assessment.

Use multiple perspectives

Have several informed people assess the risk before agreeing on a final rating.

Diverse views can reveal different assumptions, missing information, operational experience, technical constraints, and alternative interpretations of the risk.

Estimate independently before discussion

Ask participants to record an initial assessment privately.

This reduces anchoring and conformity. The group can then compare estimates and discuss the reasons for significant differences.

Use risk poker or a Delphi-style process

Participants estimate independently, reveal their assessments together, discuss the highest and lowest values, and repeat the process.

The aim is not artificial unanimity. The discussion exposes different evidence and assumptions.

Compare with reference risks

Relative judgement is often easier than isolated judgement.

Ask:

• Is this risk more likely than a risk we previously rated Possible?
• Have comparable events occurred before?
• Does the current assessment fit similar risks elsewhere in the register?

Reference risks help assessors apply the scale consistently.

Use available evidence

Relevant evidence may include incident records, lessons learned, supplier performance, defect data, schedule history, audit findings, expert judgement, industry data, and leading indicators.

Evidence rarely eliminates uncertainty, but it makes the rationale more defensible.

Record the basis of assessment

Document why a rating was chosen.

For example:

Rated Likely because three of the previous five integrations required significant redesign, and the current interface specification is less mature than those used previously.

This improves traceability and helps future reviewers understand whether the rating remains valid.

Defining impact scales

An impact scale describes the severity of consequences if a risk occurs.

Generic labels alone are insufficient. The organisation should define what each level means for the objectives that matter.

Example multidimensional impact scale

Level	Label	Cost	Schedule	Service or quality	Compliance or reputation
1	Insignificant	Less than $10,000	Less than 1 week	Minor local inconvenience	No external attention or breach
2	Minor	$10,000–$50,000	1–2 weeks	Limited rework or degradation	Minor internal nonconformance
3	Moderate	$50,001–$200,000	2–6 weeks	Material effect requiring management action	Reportable concern or limited customer effect
4	Major	$200,001–$1 million	6–12 weeks	Major disruption or failure of a key deliverable	Significant breach, media attention, or customer harm
5	Severe	More than $1 million	More than 12 weeks	Critical service failure or loss of objective	Severe legal, regulatory, or reputational consequence

The thresholds are examples only. Appropriate values depend on the size, objectives, obligations, and tolerance of the organisation or project.

Use objective-specific definitions

A $100,000 consequence may be catastrophic for a small project and immaterial for a large enterprise. A two-week delay may be tolerable during early design but unacceptable immediately before a regulatory deadline.

Scales should reflect context.

Possible models include:

• one enterprise-wide scale;
• different scales for different business units;
• project-specific scales;
• separate strategic and operational models; or
• a common structure with configurable thresholds.

Consistency supports comparison, but excessive standardisation can make the model irrelevant to local decisions.

Decide how to combine impact dimensions

A risk may have low financial impact, moderate schedule impact, and severe safety impact.

Common approaches include:

1. Highest-consequence rule: use the highest dimension as the overall impact.
2. Weighted model: assign greater weight to selected dimensions.
3. Separate reporting: preserve each dimension rather than forcing one overall value.
4. Decision rules: automatically escalate certain consequences regardless of the general score.

The method should be documented and applied consistently.

Risk matrices

A risk matrix combines probability and impact to produce a risk level.

A typical five-by-five matrix contains five probability levels, five impact levels, and risk ratings such as Low, Medium, High, and Extreme.

The matrix helps teams visualise exposure, compare risks, identify concentrations, apply escalation rules, communicate priorities, and track changes over time.

Example matrix logic

Probability \ Impact	1 Insignificant	2 Minor	3 Moderate	4 Major	5 Severe
5 Almost Certain	Medium	High	High	Extreme	Extreme
4 Likely	Medium	Medium	High	High	Extreme
3 Possible	Low	Medium	Medium	High	High
2 Unlikely	Low	Low	Medium	Medium	High
1 Rare	Low	Low	Low	Medium	Medium

There is no universal correct pattern. The matrix should reflect the organisation’s tolerance and escalation requirements.

Avoid treating the matrix as a calculation engine

The matrix supports judgement; it does not replace it.

Two risks in the same cell may differ in urgency, velocity, control effectiveness, uncertainty in the evidence, legal significance, reversibility, concentration, stakeholder concern, and treatment feasibility.

The matrix is one input to prioritisation rather than the final decision.

Matrix design principles

A useful matrix should:

• reflect the defined probability and impact scales;
• contain clear, documented boundaries;
• avoid excessive complexity;
• support the decisions users must make;
• distinguish materially different levels of exposure;
• align risk levels with response expectations; and
• be tested with realistic example risks.

Before adopting a matrix, place several known risks into it and ask whether the resulting ratings make sense.

Risk scores versus descriptive ratings

Some organisations multiply ordinal probability and impact values.

For example:

• Probability 4
• Impact 5
• Score 20

This appears precise, but the numbers usually represent ordered categories rather than equal mathematical intervals.

The difference between probability levels 1 and 2 may not be equivalent to the difference between levels 4 and 5. The same problem applies to impact.

Advantages of numeric scores

Numeric scores can simplify sorting, support thresholds, provide a compact summary, enable basic reporting, and make changes easy to display.

Limitations of numeric scores

They can also imply false precision, conceal different probability-impact combinations, encourage mechanical decision-making, create arbitrary distinctions, produce ties, and suggest that ordinal categories support arithmetic they may not justify.

For example, these risks may both score 10:

• probability 2 × impact 5;
• probability 5 × impact 2.

One is a rare catastrophic event; the other is an almost-certain minor event. They may require very different responses.

Practical recommendation

Use descriptive ratings and matrix positions as the primary communication tool. Use numeric values for sorting or reporting only when users understand their limitations.

Do not assume a score alone determines treatment priority.

Inherent and residual risk

Risk analysis should distinguish exposure before and after controls or treatments.

Inherent risk

Inherent risk is the level of risk before considering relevant controls or treatments.

It answers:

How serious would this risk be if we did nothing to reduce it?

Inherent assessment helps reveal the underlying exposure and the importance of existing controls.

Current or controlled risk

Some organisations assess the risk after considering controls already operating but before proposed additional treatments.

This may be called current risk, controlled risk, present risk, or net risk.

Residual risk

Residual risk is the exposure expected to remain after controls and treatments have been applied.

It answers:

What risk remains after our response?

Residual risk should be accepted by an appropriate decision-maker when it remains material.

Example inherent and residual assessment

Risk

Because the application depends on a single hosting region, there is a risk that a regional outage will make the service unavailable, resulting in customer disruption and contractual penalties.

Inherent assessment

• Probability: Possible
• Impact: Severe
• Rating: High

Existing and planned treatments

• multi-region failover;
• replicated data;
• tested recovery procedures;
• service monitoring; and
• customer communication plan.

Residual assessment

• Probability: Rare
• Impact: Major
• Rating: Medium

Treatments may reduce probability, impact, or both. The residual rating should reflect the expected effect of the actual treatment plan, not an optimistic target unsupported by action.

How to prioritise risks

A risk matrix groups risks into broad levels. Prioritisation decides the order in which they deserve attention and resources.

These are related but not identical activities.

Start with risk level

High and Extreme risks will ordinarily receive more attention than Low risks.

However, a large register may contain many risks with the same rating. Further judgement is then required.

Compare risks directly

Relative comparison is often easier than assigning increasingly precise scores.

Ask:

• Which risk poses the greater threat to objectives?
• Which requires a decision first?
• Which has the narrowest treatment window?
• Which could cause irreversible harm?
• Which is least controlled?
• Which threatens a critical milestone or obligation?

Consider urgency and velocity

Urgency concerns how soon action is required.

Risk velocity concerns how quickly consequences develop after the event occurs.

A moderately rated risk that can materialise tomorrow and escalate rapidly may require action before a higher-rated risk that is several years away.

Consider control effectiveness

A high inherent risk with strong, proven controls may be less urgent than a lower inherent risk with weak or untested controls.

Assess whether controls are designed appropriately, implemented, operating consistently, monitored, evidenced, and sufficient for the exposure.

Consider uncertainty in the assessment

Some risks have weak evidence or highly divergent estimates.

High assessment uncertainty may justify additional investigation, conservative treatment, scenario analysis, escalation, or closer monitoring.

Consider interdependencies and concentration

Several individually moderate risks may share a common cause or affect the same objective.

For example, multiple supplier, staffing, and technology risks may all threaten one critical launch date. Their combined exposure may deserve higher priority than any individual rating suggests.

Use forced ranking when necessary

Where senior stakeholders need a concise focus list, require them to rank risks from most to least important without ties.

A forced ranking can help identify a top-ten or top-five list for governance attention.

It should not replace the full register. Lower-ranked risks still require ownership and appropriate monitoring.

Link priority to action

Define what each priority or risk level requires.

Risk level	Illustrative requirement
Extreme	Immediate executive escalation and approved treatment plan
High	Named senior owner and time-bound treatment actions
Medium	Active monitoring and proportionate treatment
Low	Periodic review and acceptance where appropriate

Without clear response expectations, coloured ratings may not change behaviour.

Common risk-analysis errors

Using undefined labels

Terms such as Likely and Major are interpreted differently unless the scales contain explicit criteria.

Assessing the cause instead of the event

Probability should describe the likelihood of the uncertain event, not a cause that already exists.

Confusing possibility with probability

Something can be possible but extremely unlikely.

Ignoring the assessment period

A risk may be unlikely this month but highly likely over five years.

Using precise percentages without evidence

A value such as 37% may imply a level of knowledge that does not exist.

Averaging incompatible impact dimensions

A severe safety consequence should not necessarily be diluted by low financial and schedule effects.

Treating matrix colours as objective truth

The matrix reflects organisational choices and simplified categories.

Allowing seniority to determine the rating

Evidence and relevant expertise should carry more weight than organisational rank.

Ignoring existing controls

Inherent and residual assessments become confused when assessors do not state whether controls are included.

Assuming planned treatments already work

A treatment that is not implemented should not reduce the current risk rating.

Using the score as the sole priority

Urgency, control weakness, legal duties, velocity, and interdependencies may change the order of action.

Failing to record rationale

Without an assessment basis, later reviewers cannot understand or challenge the rating.

Never recalibrating the model

Scales and matrices should be tested against real decisions and revised when they consistently produce implausible results.

Worked example 1: schedule risk

Risk statement

Because the project depends on regulatory approval from an external agency, there is a risk that approval will be received later than planned, resulting in a delayed launch and additional holding costs.

Probability analysis

Comparable approvals took between six and twelve weeks. The current plan assumes six weeks, and the agency has a backlog.

Assessment: Likely

Impact analysis

A delay longer than four weeks would move the launch beyond a contractual date and create significant additional cost.

Assessment: Major

Initial risk level

High

Prioritisation considerations

• external dependency;
• limited ability to influence the agency;
• narrow decision window;
• contractual milestone; and
• contingency planning required now.

Treatment

Submit early, validate documentation with a regulatory specialist, monitor progress weekly, and prepare a phased-launch alternative.

Worked example 2: technology risk

Risk statement

Because the delivery team has limited experience with the selected integration platform, there is a risk that unexpected technical limitations will be discovered during development, resulting in redesign and schedule delay.

Inherent assessment

• Probability: Likely
• Impact: Major
• Rating: High

Existing controls

• vendor documentation;
• standard architecture review; and
• experienced technical lead.

Current assessment

• Probability: Possible
• Impact: Major
• Rating: High

Additional treatment

• early proof of concept;
• specialist review;
• performance testing;
• contingency in the delivery plan; and
• training for internal developers.

Expected residual assessment

• Probability: Unlikely
• Impact: Moderate
• Rating: Medium

The residual assessment should be confirmed after the proof of concept rather than assumed at the time the plan is written.

Worked example 3: supplier risk

Risk statement

Because a critical component is sourced from one supplier, there is a risk that production or logistics disruption will delay delivery, resulting in service interruption and contractual penalties.

Probability

Historical delivery performance is strong, but the supplier operates in a region with emerging transport disruption.

Assessment: Possible

Impact

The organisation holds only two weeks of inventory and cannot substitute the component immediately.

Assessment: Severe

Matrix result

High

Additional prioritisation factors

• single point of failure;
• rapid consequence once inventory is exhausted;
• long qualification period for alternatives; and
• multiple services depend on the component.

The organisation may prioritise this risk above another High risk because its treatment lead time is long and its consequences escalate quickly.

Configuring risk scales in Jira

A useful risk-management system should reflect the organisation’s actual assessment method rather than force every team into one generic model.

With Risk Register by ProjectBalm, organisations can configure risk models for use in Jira, including:

• probability scales;
• impact scales;
• matrix dimensions;
• risk levels;
• matrix colours;
• inherent and residual assessments; and
• terminology suited to the organisation.

Teams can then record assessments alongside Jira work, display risks in registers and matrices, and connect treatment actions to delivery items.

A practical configuration process is:

1. Define the objectives and decisions the model must support.
2. Select the number of probability and impact levels.
3. Write explicit criteria for every level.
4. Decide whether multiple impact dimensions are required.
5. Design the matrix and risk-level boundaries.
6. Define escalation and treatment expectations.
7. Test the model using realistic risks.
8. Configure the agreed model in Jira.
9. Train assessors using shared examples.
10. Review the model after practical use.

Learn more about risk management in Jira

Explore Risk Register features

Read Risk Identification: A Practical Guide

Frequently asked questions

What is qualitative risk analysis?

Qualitative risk analysis assesses risks using defined descriptive categories for probability and impact. The results are often displayed in a risk matrix and used to support prioritisation and treatment decisions.

What is the difference between risk analysis and risk assessment?

Terminology varies. Risk analysis usually concerns understanding probability, consequences, controls, and exposure. Risk assessment is often used more broadly to include risk identification, analysis, and evaluation.

How do you measure probability and impact?

Use clearly defined scales suited to the objectives and context. Probability criteria may use percentage ranges, frequencies, or descriptive evidence. Impact criteria may cover cost, schedule, safety, compliance, service, reputation, and other objectives.

What is a risk matrix?

A risk matrix combines probability and impact categories to assign a risk level and provide a visual representation of exposure.

Should probability and impact be multiplied?

They may be multiplied to create a simple sorting score, but the result should not be treated as mathematically precise. The inputs are usually ordinal categories, and identical scores can represent very different risks.

What is the difference between inherent and residual risk?

Inherent risk is the exposure before controls or treatments. Residual risk is the exposure expected to remain after those measures have been applied.

How should risks be prioritised?

Begin with the assessed risk level, then consider urgency, velocity, control effectiveness, legal significance, uncertainty, interdependencies, treatment lead time, and direct comparison with other risks.

How often should risks be reassessed?

Reassess risks at scheduled reviews and whenever material information, controls, objectives, assumptions, or external conditions change.

References

• ISO 31000:2018, Risk management — Guidelines.
• Hillson, D. (2009), Prioritising Risks as Simply as Possible, Risk Doctor Briefing Note #46.