All posts
Risk ManagementRisk AssessmentRisk MatrixCompliance

Risk Assessment Matrix: The Complete Guide for 2026

Learn what a risk assessment matrix is, how to build one step by step, how to use it across ISO 27001, SOC 2, and NIST frameworks, and how AI is changing who has to do this work.

Flow Team|GRC Insights|April 10, 202611 min read
Risk Assessment Matrix: The Complete Guide for 2026

If someone at your company just asked you to build a risk assessment matrix, here is the honest situation: it is one of the most important things you can do for your risk program, and it is also one of the most commonly done wrong.

This guide covers exactly what a risk assessment matrix is, how to build one that holds up under audit scrutiny, how it maps to the frameworks most companies care about, and, because it is 2026, how AI is changing who actually has to do this work.

What Is a Risk Assessment Matrix?

A risk assessment matrix is a grid that maps every identified risk by two factors: how likely it is to happen and how severe the consequences would be if it did. The score that results from those two factors determines the risk's overall level, and the matrix gives you a visual, sortable view of your entire risk portfolio.

Every cell in the grid is typically color-coded:

  • Green: Low risk. Monitor, no immediate action required.
  • Yellow: Medium risk. Document a treatment plan.
  • Orange/Red: High risk. Active mitigation required.
  • Red: Critical risk. Escalate and act immediately.

The visual format matters. A table of numbers means nothing to an executive. A heat map makes the risk distribution immediately obvious to anyone in the room.

Why Frameworks Require It

A risk assessment matrix is not a best practice. It is a requirement.

  • ISO 27001 requires a formal risk assessment (clause 6.1.2) that identifies, analyzes, and evaluates information security risks. Annex A controls are selected based on that assessment.
  • SOC 2 requires evidence of risk identification and assessment as part of Common Criteria CC3.2, CC3.3, and CC9.1.
  • NIST RMF makes risk assessment the central step in the framework. SP 800-30 provides the guidance; the matrix is the output.
  • COSO ERM requires risk assessment across the enterprise with documented likelihood and impact scores.

Auditors will ask to see your risk assessment matrix. If you do not have one, or if it looks like a spreadsheet someone last touched 18 months ago, that is a finding.

Risk Matrix Types: Which One Is Right for You

3x3 Matrix

Three likelihood levels, three impact levels, nine possible scores (1 to 9). Simple and fast to complete.

The problem: too many risks cluster in the middle. When everything is "medium," you lose the ability to prioritize. Use a 3x3 only for initial screening or very small organizations doing their first assessment.

5x5 Matrix (Standard)

Five likelihood levels, five impact levels, 25 possible scores (1 to 25) with four risk level thresholds (Low, Medium, High, Critical). This is the format required by most frameworks, used by most GRC software, and recognized by most auditors.

The 5x5 provides enough differentiation to make real prioritization decisions without requiring precision that does not actually exist in risk estimation. Start here unless you have a specific reason not to.

Custom Scales (3x3 to 10x10)

Some organizations need finer granularity. A security team running a detailed threat model might use a 7x7. A large bank tracking operational risk might use a 10x10. The tradeoff is that larger matrices require more specific scale definitions. Without them, distinguishing between a 6 and a 7 on a 10-point likelihood scale becomes subjective and inconsistent.

If you are using GRC software, check whether it supports configurable matrix sizes. Locking you into a single format is a limitation worth knowing about before you buy.

How to Build a Risk Assessment Matrix: Step by Step

Step 1: Define Your Likelihood Scale

Every level on your likelihood scale needs a concrete definition. Vague labels like "high likelihood" produce inconsistent scores across different assessors and fail audit scrutiny.

A well-defined 5-level likelihood scale:

Level Label Probability Time-Based Definition
1 Rare < 5% Not expected in the next 5 years
2 Unlikely 5–20% Could occur once in 2–5 years
3 Possible 20–50% Could occur once in 1–2 years
4 Likely 50–80% Expected at least once this year
5 Almost Certain > 80% Expected to occur multiple times this year

Use both probability ranges and time horizons. Different assessors reason about risk differently, and anchoring to concrete intervals reduces subjectivity.

Step 2: Define Your Impact Scale

Impact should be defined across the dimensions that matter to your organization. For most companies, that means financial loss, operational disruption, and regulatory consequences at minimum.

Level Label Financial Operational Regulatory
1 Negligible < $10K Minimal disruption (< 1 hour) No regulatory interest
2 Minor $10K–$100K Limited disruption (hours) Minor finding, no fine
3 Moderate $100K–$1M Significant disruption (1–3 days) Regulatory notice, potential fine
4 Major $1M–$10M Extended disruption (weeks) Investigation, significant fine
5 Catastrophic > $10M Business continuity threat License revocation, enforcement action

Adjust the financial thresholds to match your organization's size. What is catastrophic for a 50-person startup is different from what is catastrophic for a 5,000-person enterprise.

Step 3: Set Your Risk Level Thresholds

Your risk score (Likelihood × Impact) needs to map to risk levels. Common thresholds for a 5x5 matrix:

Risk Level Score Range Required Action
Low 1–5 Monitor annually, no immediate action
Medium 6–12 Develop treatment plan within 90 days
High 15–20 Active mitigation, monthly review
Critical 21–25 Immediate escalation, weekly review

These thresholds should reflect your organization's risk appetite: the amount of risk you are willing to accept before taking action. A risk-tolerant organization might set the Critical threshold higher. A regulated entity handling sensitive data might set it lower.

Step 4: Score Inherent Risk

Inherent risk is the raw score before any controls are applied. The question you are asking: if we had no controls at all for this risk, how likely would it be and how severe would the impact be?

Inherent risk is the honest starting point. It tells you what you are actually exposed to, not what you have managed to mitigate.

For each risk, assign a likelihood level (1–5) and an impact level (1–5). Multiply them. That is your inherent risk score.

Step 5: Apply Controls and Score Residual Risk

Residual risk is the score that remains after your controls are applied.

The calculation is conceptually simple but requires an honest assessment of control effectiveness. A control only reduces risk if it is actually implemented, tested, and working. "We have a firewall" counts. "We intend to implement endpoint detection" does not.

Residual scoring process:

  1. Identify all controls that mitigate this risk
  2. Assess each control's effectiveness (Low / Medium / High)
  3. Re-score likelihood and impact based on the controls in place
  4. Calculate the new score: that is residual risk

The gap between inherent and residual risk is one of the most important metrics in your program. A High inherent risk that drops to Low after controls demonstrates that your controls are working. A High inherent risk that stays High despite controls means your controls are insufficient or not actually operating.

Step 6: Set Review Cadence

A risk assessment matrix that is never updated is worse than not having one. It creates false confidence without providing any current insight.

Minimum review requirements:

  • Annual review of all risks (required by most frameworks)
  • Triggered review whenever a significant change occurs: new product, new vendor, new regulation, major incident, organizational change
  • Continuous monitoring where possible: if your GRC software integrates with your systems, some risk indicators can update automatically

Document when each risk was last reviewed and by whom. Auditors will ask.

Mapping to Compliance Frameworks

ISO 27001

ISO 27001 requires a documented risk assessment (clause 6.1.2) that:

  • Establishes and applies an information security risk assessment process
  • Defines risk acceptance criteria
  • Identifies risks and their owners
  • Analyzes and evaluates risks
  • Selects Annex A controls based on assessment results

Your risk assessment matrix is the central deliverable. The risk treatment plan (choosing which Annex A controls to implement) flows directly from it. Without a well-scored matrix, your Statement of Applicability does not have a justified foundation.

SOC 2

SOC 2 Common Criteria reference the risk assessment directly:

  • CC3.2: Management specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to them
  • CC3.3: Management identifies and analyzes risks to achieve its objectives as a basis for determining how those risks should be managed
  • CC9.1: The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions

Your auditor will review the risk register and may ask how specific controls map back to identified risks. A risk assessment matrix that clearly shows the risk, score, and linked control satisfies this requirement.

NIST RMF

NIST SP 800-30 defines risk assessment as the process of identifying, estimating, and prioritizing information security risks. The risk assessment matrix is the primary output.

NIST uses four steps: prepare, conduct, communicate, maintain. Your matrix is created in the "conduct" step and maintained in the "maintain" step. The specific likelihood and impact scales should align with those defined in your organization's risk management strategy.

COSO ERM

COSO's Enterprise Risk Management framework requires risk assessment at the enterprise level, integrating risk into strategy setting and business objective planning. This is broader than IT risk — operational, strategic, financial, and compliance risks all belong on the matrix.

COSO places particular emphasis on understanding the relationship between inherent and residual risk and how your risk appetite thresholds are set relative to your strategic objectives.

Common Mistakes That Fail Audits

Using undefined labels

"Low," "Medium," and "High" without numeric anchors or concrete descriptions are not a risk assessment. They are guesses. If two people score the same risk and get different levels because the definitions are vague, your matrix is not defensible.

Fix: define every level with specific probability ranges and consequence descriptions before anyone starts scoring.

Tracking only inherent risk

A risk register that shows only inherent scores does not demonstrate that your controls are working. Auditors want to see residual risk. Without it, you cannot show risk reduction.

Fix: score every risk twice, inherent and residual. Make control effectiveness part of the residual scoring process.

Never reviewing

An ISO 27001 or SOC 2 auditor will check the "last reviewed" date on your risks. If 40% of your register was last touched 18 months ago, that is a finding regardless of the scores.

Fix: set automated review reminders tied to each risk's review cadence, and document who completed each review.

A risk assessment matrix that lists risks but does not link them to the controls designed to mitigate them does not satisfy ISO 27001 Annex A or SOC 2 Common Criteria requirements.

Fix: use a GRC platform (or at minimum a spreadsheet with explicit linkage columns) that ties each risk to one or more controls with effectiveness ratings.

Static Excel matrix

A spreadsheet captures a point in time. Your risk posture changes continuously. A new vulnerability, a new vendor, a new regulation. None of these update your spreadsheet automatically.

Fix: move to a tool that supports real-time updates, automated reminders, and a heatmap that reflects current scores.

The Risk Assessment Matrix Template

Before you start scoring, set up the structure. A useful 5x5 risk assessment template includes:

Columns: Risk ID, Risk Title, Risk Description, Category, Owner, Likelihood (1–5), Impact (1–5), Inherent Score, Inherent Level, Controls Linked, Control Effectiveness, Residual Likelihood, Residual Impact, Residual Score, Residual Level, Treatment Decision, Treatment Notes, Review Date, Last Reviewed By

See the risk assessment matrix template for a ready-to-use version with formulas, color-coding, and framework mapping columns for ISO 27001, SOC 2, and NIST CSF.

How AI Changes the Risk Assessment Process

The process described above works. Organizations have been doing it this way for 20 years. But it requires significant time, expertise, and ongoing maintenance. Most companies do not have a dedicated risk manager to own it.

This is what AI changes.

A modern AI-native risk platform like Flow does not just organize your risk assessment. It runs it.

Risk identification: Instead of starting with a blank register, Flow's AI analyzes your organization (your tech stack, your data types, your vendor relationships) and generates a starting set of risks mapped to the frameworks you care about. You review and approve, rather than build from scratch.

Automatic scoring: As your environment changes, including new integrations, new vendors, and new employees, Flow updates risk likelihood and impact based on real signals rather than waiting for your annual review.

Inherent vs. residual tracking: Flow scores both automatically. When you link a control to a risk and mark it as effective, residual risk recalculates. The heatmap updates in real time.

Framework mapping: Every risk is automatically tagged to the relevant ISO 27001 Annex A controls, SOC 2 Trust Service Criteria, or NIST controls. You do not manually maintain that mapping.

Evidence collection: Flow's GitHub integration collects compliance evidence automatically. When an auditor asks for proof that a control is operating, the evidence is already there.

The honest framing: you can spend weeks building and maintaining a risk assessment matrix, or you can let an AI agent run the process for you while you focus on the risks that actually require human judgment.

Most founders and CTOs who arrive at Flow do so after realizing that the manual version is not sustainable beyond a certain point. The risk assessment matrix is complex enough that getting it right requires expertise they do not have on staff, and ongoing enough that it cannot be delegated to a quarterly spreadsheet session.

Start a free trial of Flow and let the AI build your risk assessment matrix. Or use the template if you want to understand the process before automating it.

Frequently Asked Questions

What is a risk assessment matrix?
A risk assessment matrix is a grid-based tool that maps identified risks according to two factors: how likely they are to occur (likelihood) and how severe the consequences would be (impact). The intersection of those two scores determines each risk's overall level — typically Low, Medium, High, or Critical. The matrix is usually color-coded from green to red so anyone can see the risk portfolio at a glance. It is a core requirement for ISO 27001, SOC 2, NIST RMF, and most other risk frameworks.
What is the difference between a risk matrix and a risk assessment matrix?
The terms are used interchangeably. A risk matrix is the scoring grid itself. A risk assessment matrix refers to the matrix used specifically in the context of a formal risk assessment process: identifying risks, scoring them, and documenting treatment decisions. In practice, most people mean the same thing when they use either term.
What is inherent vs. residual risk on a risk matrix?
Inherent risk is the raw risk score before any controls are applied — how bad would this be if you did nothing? Residual risk is the score after controls — how much risk remains once your mitigations are in place? Both should appear on your matrix. If inherent risk is High and residual risk is still High after controls, those controls are not working. The movement between inherent and residual positions is one of the clearest ways to demonstrate that your risk program is delivering value.
How often should a risk assessment matrix be updated?
Most frameworks recommend reviewing your risk matrix at least annually, with additional reviews triggered by significant changes: new products or services, acquisitions, major system changes, regulatory updates, or security incidents. ISO 27001 requires a risk assessment whenever significant changes occur. In practice, organizations that use software instead of spreadsheets tend to review more frequently because the friction is lower.
Do I need a risk assessment matrix for SOC 2?
Yes. SOC 2 requires a formal risk assessment as part of the Common Criteria (CC3.2, CC3.3, CC9.1). Auditors expect to see documented evidence that you identified risks, scored them, and established a treatment plan. A risk assessment matrix provides that evidence in a format auditors recognize. Many organizations fail their first SOC 2 audit because their risk assessment is informal or undocumented.
What size risk matrix should I use for a risk assessment?
The 5x5 matrix is standard for most organizations and satisfies the requirements of ISO 27001, SOC 2, NIST RMF, and COSO ERM. A 3x3 matrix is too coarse for meaningful prioritization. Too many risks cluster in the medium zone. Matrices larger than 5x5 are used in specialized industries but create false precision without better definitions. Start with 5x5 unless you have a specific reason to do otherwise.

Related Articles