What Is a Risk Assessment Matrix? How to Build and Use One

A systems engineer rates a new failure mode as “medium” risk, plots it on a 5×5 grid, and moves on. Six months later, that failure surfaces during integration testing, and the post-mortem reveals that nobody reassessed it after a requirement change in April. The score was valid when written, but nothing flagged that the underlying requirement had moved.

 This is what differentiates a risk assessment matrix as a diagram and one as a working artifact. For teams in medical devices, the matrix can affect compliance planning under International Organization for Standardization (ISO) 14971. Automotive programs under ISO 26262 and airborne software under DO-178C face their own expectations. This guide covers how to build a defensible matrix, which format fits which program, how the major safety standards treat it, and the mistakes that quietly undermine it.

What Is a Risk Assessment Matrix?

A risk assessment matrix ranks and displays risks by plotting likelihood and severity on a grid. Likelihood captures the chance a risk event occurs, and severity captures the harm if it does. Defined consequence and likelihood ranges give the matrix its axes, a framing described by ISO 22367:2020, and their intersection gives each risk a relative priority for deciding where mitigation effort goes first. The 5×5 format reflects system-safety practice and remains a familiar way to compare risks qualitatively when probability or harm severity cannot be estimated with precision.

The Role of a Risk Assessment Matrix in Requirements Management

A risk assessment matrix earns its place by forcing prioritization decisions that would otherwise stay implicit. In regulated development, it is also the checkpoint where risk scores connect to the requirements controlling them.

The Cost of Unscored Risk in Regulated Development

Unscored or misscored risk shows up as insufficient verification rigor. When a risk is misclassified as low, it receives minimal oversight, and the controls meant to address it may never be implemented or verified.

The severity of a software failure condition influences the Design Assurance Level, which dictates the rigor of verification the program must satisfy under DO-178C. Misjudge the severity and the program either over-invests or under-verifies a function whose failure can lead to loss of the aircraft.

Connecting Risk Visibility to Complete Requirements Coverage

Risk scores are only as good as their connection to the requirements baseline. The Requirements Traceability Matrix connects user needs to design inputs, outputs, verification, and risk controls. Those controls sit within the traced hierarchy required by design-controlled environments. 

The Core Components of a Risk Assessment Matrix

The likelihood and severity axes define the grid, and the scoring scheme maps their intersection to a risk priority. Each needs documented criteria specific enough that two engineers scoring the same risk reach the same answer.

Likelihood as the Probability Axis

Most qualitative matrices define likelihood in ranked categories rather than precise percentages. Each category captures the probability that a risk event will occur, with quantitative ranges the team can defend.

A likelihood scale without documented ranges lets the same word mean different things to different engineers, and scores drift apart. Define each category before scoring begins so reviewers apply the scale consistently.

Severity as the Impact Axis

Severity captures the magnitude of harm if the event occurs, and regulated standards define it with concrete thresholds. System-safety scales commonly use categories such as Catastrophic and Negligible, while for medical devices, ISO 14971 frames harm as injury or damage to health, property, or the environment.

Failure Mode and Effects Analysis (FMEA) practice includes a highest-severity rule that carries over to any matrix. When a failure mode produces more than one effect, record only the highest severity rating, since averaging hides the worst case the failure can produce.

Risk Scoring and the Color-Coded Grid

One common scoring method multiplies likelihood by severity. On a 5×5 grid, that produces scores from 1 to 25, with higher risks in red, moderate in orange or yellow, and lower in green. For medical device work, a red/yellow/green acceptance matrix can create a compliance trap when the green zone implies some risks are acceptable without further evaluation. Risk acceptability criteria need to be more defensible than color alone.

How to Build a Risk Assessment Matrix Step by Step

Building a defensible risk assessment matrix follows one sequence. Catalog the risks, define the scales, plot and prioritize, then assign ownership and actions.

Identify and Catalog Potential Risks

Risk identification should capture what could happen, why, and its consequences. For FMEA-driven programs, the catalog targets the elements most at risk, identifying each function, its potential failure modes, and the final effects of each.

Define Your Likelihood and Severity Scales

Each scale needs documented definitions distinguishable from adjacent categories before plotting begins, often a 5×5 matrix with each category clearly described. For FMEA, teams commonly rate severity, occurrence, and detection, where a high detection rating reflects low ability to catch the failure. A defensible FMEA should not use the Risk Priority Number (RPN) as the sole metric for deciding whether action is required.

Plot Risks and Calculate Risk Priority Levels

Plot each risk by its likelihood and severity scores on the matrix. Where the likelihood and consequence categories intersect, the matrix sets the relative priority level, and a program may treat consequence as the tie-breaker when two risks share a score. A full FMEA process may also calculate the RPN, where the bigger number signals the more important failure but stays relative, not absolute.

Assign Owners and Mitigation Actions

A scored risk with no owner stays scored and nothing more. Ownership turns the matrix into an action record instead of a static ranking exercise. For risks that require action, document the owner, responsible parties, target dates, actions taken, completion dates, and the resulting severity, occurrence, detection, and RPN.

Mitigation should follow a hierarchy ordered by effectiveness in medical-device risk management, as set by ISO 14971:

• Inherently safe design: Eliminate or reduce hazards through design changes before any other measure.
• Protective measures: Add safety mechanisms, alarms, and fail-safes where design alone cannot eliminate the hazard.
• Information for safety: Use labeling, instructions, and training as the last line, since they rely on human behavior.

Each measure must be verified as applied correctly and validated as effective at reducing risk. Do not reduce severity or likelihood until the mitigation is complete, as likelihood should not drop until the last person has finished training.

Common Risk Assessment Matrix Formats and When to Use Them

Three symmetric formats dominate practice, the 3×3, 4×4, and 5×5, alongside asymmetric formats like the 4×5 used in some system-safety approaches. The right choice depends on how much you know about your risks, since more cells imply more precision than qualitative judgment can support.

The 3×3 Matrix for Lightweight Programs

The 3×3 matrix produces nine combinations using high-medium-low categories, intuitive to beginners and suited to small teams, early-stage programs, and quick project-level triage. That limited resolution tends to cluster most risks in the middle, blurring the boundary between acceptable and unacceptable.

The 5×5 Matrix for Complex, Regulated Work

The 5×5 matrix produces 25 combinations and offers finer separation for regulated work. That granularity carries its own risk of false precision, so the categories have to match what the team genuinely knows rather than imply accuracy that a qualitative scale cannot support.

How a Risk Assessment Matrix Supports Standards Compliance

The risk assessment matrix plays a different role in each major safety standard. Risk scores must be traced to verification evidence, but the mechanics diverge sharply.

Alignment With ISO 14971, ISO 26262, and DO-178C ExpectationsLinking Risk Scores to Verification and Validation Evidence

Risk scores under these standards have to connect to objective evidence of risk control. In medical-device programs, selected control measures need implementation and effectiveness evidence, documented in the risk management file.

Risk mitigation activities can be modeled as verification activities and linked to associated requirements using the verify relationship. Risk-based testing extends the same logic into execution, where a high-severity risk requires regression retesting of its linked test cases. Test coverage tells you how much scope your testing exercised, while traceability shows whether those tests connect back to requirements and risks you can defend.

Common Mistakes That Undermine a Risk Assessment Matrix

Risk matrices can produce poor resolution and ranking errors, suboptimal resource allocation, and ambiguous inputs, and those weaknesses compound in safety-critical work.

Static Matrices That Never Get Updated

A risk matrix completed during an initial assessment and then filed away becomes inaccurate as the program changes. Risk profiles shift as projects move through phases, new threats emerge, and controls degrade, yet the matrix sits frozen at its first draft.

Subjective Scoring Without Defined Criteria

Scoring without documented criteria invites cognitive bias to corrupt the inputs. Centering bias can push assessors toward the middle of any scale, compressing the distinctions the matrix exists to capture. Ordinal scale misuse compounds the problem, since the numbers on a likelihood scale represent rank order, not measured quantities, so multiplying them implies precision the scale does not support.

Disconnection From the Requirements Baseline

Risk matrices contain no inherent information about mitigation actions, so the link to controls and the requirements they trace to must be maintained deliberately. When that link breaks, a requirement change leaves the risk assessment looking complete while it no longer matches the design. Maintain structural traceability between each risk, its control measures, and the verification evidence that proves the control works.

How Jama Connect® Supports the Risk Assessment Matrix

When risks, requirements, and verification evidence live in separate tools, requirement changes can leave stale scores behind. Jama Connect® is web-based requirements management and traceability software that keeps risk items in the same system as requirements and test verification. Risk activities, including Hazard Analysis and Risk Assessment (HARA), FMEA, and Threat Analysis and Risk Assessment (TARA), live alongside the functional requirements they trace to, with pre-configured ISO 14971 templates so teams run risk assessments without rebuilding it.

When a requirement changes, Live Traceability™ automatically flags every downstream artifact, including linked risk items, as suspect for reassessment, so a stale risk score does not survive a change to the requirement that justified it. Jama Connect is certified by TÜV SÜD for safety-related products up to Automotive Safety Integrity Level (ASIL D) in accordance with ISO 26262.

Keep Risk Scores Connected as Requirements Change

A useful matrix depends on defensible likelihood and severity scales, clear ownership, and verification evidence that stays current as the design changes. The hardest part is keeping each score tied to the requirement that justified it.

If your team needs risk scores to stay connected as requirements change, Jama Connect supports traceability between risks, controls, and verification. You can start a free 30-day trial of Jama Connect to see how that workflow looks in practice.

Frequently Asked Questions About Risk Assessment Matrix

What is the difference between a risk assessment matrix and a risk register?

The matrix is the visual prioritization tool that plots each risk by likelihood and severity to rank it. The risk register is the record where you document each identified risk, its owner, mitigation strategy, and status over time. Regulated programs need both, since neither alone satisfies the traceability auditors expect.

How many levels should a risk assessment matrix have?

Match the number of levels to the quality of your inputs, not to a default. Use the smallest scale that still lets reviewers make different decisions, and if two adjacent levels would trigger the same action, combine them. Adding levels you cannot justify invites false precision, which is harder to defend in an audit than a coarser grid honestly applied.

How often should a risk assessment matrix be reviewed?

Teams may review the matrix on a cadence, often quarterly or around formal program checkpoints. Beyond the calendar, trigger a review when a significant incident occurs, the context changes, new regulatory requirements land, or a requirement change cascades through linked risks. Jama Connect can automatically trigger a reassessment when an upstream requirement changes.

This article was authored by Mario Maldari and published on July 9, 2026.