5×5 risk assessment matrix to prioritize risks with clarity

A 5×5 risk assessment matrix turns risk evaluation into a repeatable decision-making process. It uses five levels of likelihood and five levels of impact to help organisations compare risks, prioritize treatment and explain decisions to management, auditors and other stakeholders.

The matrix is useful for information security, privacy, cybersecurity, supplier risk, business continuity and regulatory compliance. However, it only creates value when it is connected to defined criteria, a risk register, treatment actions, responsible owners and evidence.

What Is a 5×5 Risk Assessment Matrix?

A 5×5 risk assessment matrix is a visual method for evaluating risk by combining two variables:

• Likelihood: How probable is it that the risk scenario will occur?
• Impact: How serious would the consequences be if it occurred?

Each variable receives a score from 1 to 5. The scores are then combined to produce an overall risk rating.

The most common calculation is:

Risk score = Likelihood × Impact

For example, a risk with a likelihood score of 4 and an impact score of 5 would receive a total score of 20.

The score helps organisations prioritize risks, but the number alone is not the decision. The assessment should also explain:

• What scenario is being evaluated.
• Which assets, systems or processes are affected.
• Which threats and vulnerabilities are relevant.
• Which controls already exist.
• Why the selected likelihood and impact values are reasonable.
• What treatment is required.
• Who owns the decision.

A 5×5 matrix is therefore not just a coloured chart. It is a way to make risk decisions consistent and traceable.

When Should You Use a 5×5 Risk Matrix?

A 5×5 matrix can be useful when an organisation needs to:

• Compare risks across different departments.
• Prioritize security improvements.
• Support an ISO 27001 risk assessment.
• Evaluate supplier and third-party risks.
• Assess privacy and data protection risks.
• Decide which risks require immediate treatment.
• Explain risk exposure to senior management.
• Track changes after incidents or control improvements.
• Create a consistent method for internal audits.

It works best when risks can be described as specific scenarios.

For example:

A third-party administrator account is compromised, allowing unauthorised access to a customer support system containing personal data.

This is easier to assess than a vague statement such as “cybersecurity risk is high”. The scenario identifies a threat, an asset, a possible event and a consequence.

Before completing the matrix, define:

• The systems, assets, data or processes in scope.
• The threat or event being assessed.
• Relevant vulnerabilities or weaknesses.
• Existing controls.
• The potential consequences.
• The person responsible for the assessment.

A useful risk assessment should lead to a decision, not simply produce a score.

Why the 5×5 Matrix Supports ISO 27001 Risk Assessment

ISO/IEC 27001 does not require organisations to use a specific 5×5 matrix. It requires a consistent, documented and repeatable risk assessment process.

The organisation must define:

• Risk assessment criteria.
• Risk acceptance criteria.
• A method for identifying and evaluating risks.
• Responsibilities for assessment and approval.
• How risk treatment decisions are recorded.
• How the process is reviewed and updated.

The official ISO/IEC 27001 overview explains the standard’s role in establishing, implementing, maintaining and continually improving an information security management system.

A 5×5 matrix can support those requirements because it gives teams a shared scoring language. Without defined criteria, one department may consider a risk level 3 to be serious while another treats the same score as insignificant.

Auditors may ask:

• Why was this risk scored 4 rather than 3?
• Which evidence supports the likelihood rating?
• Were existing controls considered?
• Who approved the score?
• What happens when the risk exceeds the acceptance threshold?
• When will the assessment be reviewed?

The assessment should provide clear answers. A score without reasoning is difficult to defend.

How to Define Likelihood and Impact Scales

The objective is not simply to assign numbers. Each number should have a meaning that different people can apply consistently.

Likelihood Scale

Likelihood measures how probable it is that the risk scenario will occur.

Score	Suggested meaning	Example indicators
1	Rare	No known history, strong controls and limited exposure
2	Unlikely	Possible but unlikely under current conditions
3	Possible	Could occur under normal operating conditions
4	Likely	Has occurred before or current exposure is significant
5	Almost certain	Expected to occur frequently or controls are ineffective

Your organisation may use different labels, but the criteria should remain stable. Consider:

• Historical incidents.
• Frequency of similar events.
• External threat activity.
• Number of exposed users or systems.
• Level of access required.
• Strength of existing controls.
• Recent changes to the environment.
• Dependence on third parties.

For example, an exposed administrative interface with weak authentication should not receive the same likelihood score as an isolated system protected by strong access controls and continuous monitoring.

Impact Scale

Impact measures the consequences if the scenario occurs.

Score	Suggested meaning	Example consequences
1	Negligible	Minor inconvenience with no meaningful business impact
2	Minor	Limited disruption or small-scale data or financial impact
3	Moderate	Noticeable service disruption, operational cost or limited data exposure
4	Major	Significant financial, legal, operational or reputational consequences
5	Severe	Critical business interruption, serious harm, major breach or regulatory consequences

Impact should be assessed across the relevant dimensions:

• Confidentiality: Could information be exposed to unauthorised people?
• Integrity: Could information or systems be changed incorrectly?
• Availability: Could services or data become unavailable?
• Privacy: Could individuals suffer harm or lose control over their data?
• Financial impact: Could the organisation incur losses, penalties or remediation costs?
• Reputation: Could the incident damage customer or partner trust?
• Regulatory impact: Could the organisation face investigation or enforcement?

For privacy-related assessments, the impact should also consider the sensitivity and volume of personal data, the number of affected individuals and whether vulnerable people are involved.

Document the Criteria Behind Each Number

A scoring guide should include:

• A short definition.
• Observable indicators.
• Examples relevant to the organisation.
• The evidence expected to support the score.
• Any assumptions or uncertainties.

If someone assigns an impact score of 4, another reviewer should be able to understand the reasoning without relying on personal intuition.

Example 5×5 Risk Matrix

The following matrix is an example. Each organisation should define its own thresholds based on its risk appetite and operating context.

Likelihood \ Impact	1	2	3	4	5
1 Rare	1	2	3	4	5
2 Unlikely	2	4	6	8	10
3 Possible	3	6	9	12	15
4 Likely	4	8	12	16	20
5 Almost certain	5	10	15	20	25

A possible set of thresholds could be:

• 1–4: Low risk; manage through routine controls.
• 5–9: Medium risk; define an improvement or monitoring action.
• 10–16: High risk; treatment should normally be prioritised.
• 17–25: Very high risk; immediate management attention and treatment may be required.

These thresholds are examples, not universal rules. Management should approve the organisation’s risk acceptance criteria before the matrix is used.

How to Score Risks Consistently

Scoring should follow the same process each time.

1. Define the Scenario and Scope

Identify the exact risk scenario and the systems, information or processes affected.

Avoid generic entries such as “data breach”. Instead, describe the event more precisely:

An employee sends a customer export to the wrong external recipient because the file is not protected and the recipient is not verified.

2. Identify Threats and Vulnerabilities

Describe what could cause the event and which weakness could allow it to happen.

Examples include:

• Excessive permissions.
• Missing multi-factor authentication.
• Unpatched software.
• Weak supplier controls.
• Poor data-handling procedures.
• Lack of employee training.
• Inadequate backup or recovery.
• Unclear incident escalation.

3. List Existing Controls and Evidence

Before assigning likelihood, identify the controls that already reduce the risk.

Evidence may include:

• Access reviews.
• Security configurations.
• Logs.
• Vulnerability reports.
• Training records.
• Supplier assessments.
• Incident simulations.
• Policies and procedures.
• Test results.
• Internal audit findings.

The existence of a policy should not automatically reduce the score. Consider whether the control is actually implemented and operating effectively.

4. Assess Likelihood

Use the documented likelihood criteria and record the reasoning. If evidence is incomplete, record the uncertainty rather than hiding it.

5. Assess Impact

Consider confidentiality, integrity, availability, privacy, financial consequences, regulatory exposure and business interruption.

6. Apply the Calculation Method

Use the agreed formula consistently. If the organisation uses multiplication, apply likelihood × impact every time.

If the organisation uses a cell-based method rather than multiplication, document how the cell is selected.

7. Record the Decision

The risk assessment should record:

• The final score.
• The risk level.
• The rationale.
• The applicable risk tolerance.
• The treatment decision.
• The risk owner.
• The review date.

How to Convert Risk Scores into Treatment Plans

A matrix is not a treatment plan. It is a prioritisation tool.

The next step is to determine what the organisation will do about the risk.

Common treatment options include:

• Modify: Reduce likelihood or impact through controls.
• Retain: Accept the risk because it falls within approved tolerance.
• Avoid: Stop or redesign the activity creating the risk.
• Share: Transfer part of the financial or operational impact through insurance or contractual arrangements.

Risk transfer does not remove accountability. An organisation remains responsible for understanding and managing its operational and regulatory obligations.

A treatment plan should include:

• Risk reference.
• Scenario and affected asset.
• Existing risk score.
• Treatment decision.
• Controls or actions required.
• Risk owner.
• Implementation owner.
• Target date.
• Required evidence.
• Expected residual risk.
• Formal approval or acceptance.
• Review date.

Where the assessment also supports ISO 27001, a structured risk treatment plan can connect the risk register with treatment actions, the Statement of Applicability and the evidence used to verify each control. 

Worked Example

Consider this scenario:

A third-party administrator account gains access to a support system after a supplier change introduces an exploitable vulnerability.

The organisation may assign:

• Likelihood: 3, because the supplier has controls, but recent changes and incomplete validation increase exposure.
• Impact: 4, because the system contains customer information and access could affect confidentiality and integrity.
• Risk score: 12.
• Risk level: High, according to the example thresholds.
• Treatment: Modify the risk through stronger supplier access controls, MFA, permission reviews and change validation.
• Owner: IT or security lead.
• Evidence: Access review, supplier assessment, MFA configuration and change-testing record.
• Review date: After remediation and during the next supplier review.

The complete audit trail should show:

Scenario → criteria → score → decision → treatment → owner → evidence → residual risk

Minimum Risk Register Fields

A practical risk register should normally include:

• Risk ID.
• Asset, system or process.
• Risk scenario.
• Threat and vulnerability.
• Existing controls.
• Likelihood score.
• Impact score.
• Overall risk score.
• Risk rationale.
• Risk owner.
• Treatment decision.
• Planned controls.
• Target date.
• Status.
• Evidence reference.
• Residual risk.
• Acceptance or approval.
• Next review date.
• Change or incident trigger.

A risk register should not become a static spreadsheet that is only updated before an audit. It should support real decisions throughout the year.

How to Review and Maintain the Matrix

A risk matrix is a living management tool. It should be reviewed when the context changes or when new evidence becomes available.

Review Triggers

Update the assessment when there are:

• New systems or business processes.
• Changes to the organisation’s scope.
• New suppliers or material supplier changes.
• Security incidents or near misses.
• Changes to regulations.
• Changes to infrastructure or architecture.
• New types of personal or confidential data.
• Major control failures.
• Results from penetration tests or internal audits.
• Lessons from tabletop exercises.

Organisations working in Spain should also consider relevant developments in the Spanish NIS2 transposition framework when reviewing cybersecurity risks, responsibilities and evidence requirements.

Review Frequency

Many organisations use:

• A formal annual review.
• Additional reviews after major changes.
• Immediate reassessment after serious incidents.
• Shorter review cycles for high-risk systems.
• Periodic management reporting.

There is no value in reviewing the matrix every day if nothing has changed. The important point is that the review cadence is defined and that meaningful events trigger an update.

Versioning and Change Control

Each version should show:

• What changed.
• Why it changed.
• Which scenarios or criteria were affected.
• Who approved the change.
• When the change took effect.

This prevents the same score from having different meanings at different points in time.

Cross-Team Calibration

Different departments may interpret the same scale differently. To reduce this problem, run calibration sessions using realistic scenarios.

Ask multiple teams to score the same scenario independently. If results differ, determine whether the cause is:

• Unclear criteria.
• Different evidence.
• Different assumptions.
• Different understanding of impact.
• Different views of existing controls.

Record the outcome of the calibration session and update the guidance where necessary.

How PrivaLex Can Help with a 5×5 Risk Assessment Matrix

PrivaLex helps organisations design risk assessment processes that are consistent, documented and usable by teams.

Support may include:

• Defining likelihood and impact criteria.
• Creating the scoring methodology.
• Identifying assets, threats and vulnerabilities.
• Designing risk registers and treatment plans.
• Setting risk tolerance and acceptance criteria.
• Connecting risk results to ISO 27001 controls.
• Aligning risk processes with NIS2, DORA, GDPR or AI governance.
• Assigning owners and review responsibilities.
• Preparing audit-ready evidence.
• Calibrating scoring across teams.
• Reviewing whether the methodology works in practice.

The objective is not to create a more complicated spreadsheet. It is to establish a risk process that management can understand, teams can apply and auditors can trace.

PrivaLex can also help organisations connect the matrix with wider security and privacy work, including incident response, control documentation, training and management review. For example, employee training under NIS2 can create evidence that supports both risk treatment and regulatory readiness.

For organisations building an ISO 27001 programme, ISO 27001 certification depends on connecting risk assessment, control implementation, documentation and continual improvement rather than treating them as separate tasks. 

Risk Assessment Across Different Frameworks

A 5×5 matrix can support several risk and compliance frameworks, but the organisation should not assume that one score automatically satisfies every requirement.

ISO 27001

Under ISO 27001, the assessment should connect to:

• The information security management system.
• The risk treatment plan.
• The Statement of Applicability.
• Control implementation.
• Internal audit.
• Management review.
• Continual improvement.

That connection between risk decisions, practical controls and supporting evidence is central to ISO 27001 control documentation. 

NIS2 and DORA

NIS2 and DORA both require structured cybersecurity and operational resilience, but they have different scopes and legal requirements.

Organisations affected by both should avoid creating separate and contradictory risk processes. The comparison of NIS2 and DORA explains where the frameworks overlap and where their requirements differ.

GDPR and Privacy Risk

A security risk assessment may need to be connected to privacy assessments when personal data is involved.

Consider:

• The type and sensitivity of personal data.
• The number of affected individuals.
• Whether vulnerable individuals are involved.
• The consequences of unauthorised access.
• The impact on rights and freedoms.
• Data retention and deletion.
• Processor and supplier risks.

A GDPR assessment should not be reduced to a technical security score. Legal, organisational and individual-rights consequences also need to be considered.

In other words, a complete GDPR audit should bring together records of processing, legal bases, processor relationships, security measures, breach management and DPIAs. 

AI Governance and Emerging Technology

AI systems may create additional risks involving data quality, bias, transparency, human oversight, security and unintended outcomes.

Organisations developing AI governance can consider the relationship between AI governance and ISO 42001 and the broader AI Act framework. Where AI affects people’s rights or uses personal data, the risk methodology may need additional impact-assessment criteria.

The integration of the AI Act and ISO 42001 can help organisations avoid creating disconnected risk and control systems.

SaaS and Cloud Environments

Cloud and SaaS organisations should include:

• Identity and access risks.
• Supplier and processor dependencies.
• Cloud misconfiguration.
• Data transfer and residency.
• Availability and service continuity.
• Vulnerability management.
• Customer isolation.
• Incident response.
• Backup and recovery.

For SaaS companies, the NIS2 compliance guide for SaaS organisations explains how risk assessment connects with security controls, suppliers and incident reporting.

Quality Checks Before Approving a 5×5 Risk Assessment

Before approving a risk assessment, review the following points to confirm that the result is consistent, defensible and connected to action.

Is the risk scenario specific?

The assessment should describe a clear event affecting a defined asset, system, process or type of data. Avoid broad statements such as “cybersecurity risk” or “supplier risk” without explaining what could happen.

Are the likelihood and impact criteria defined?

Each score should have a documented meaning, observable indicators and relevant examples. Different teams should be able to apply the same criteria and reach reasonably comparable results.

Is the assessment based on evidence?

Check whether the score is supported by current information such as access reviews, incident history, system changes, supplier assessments, test results or control records. If information is missing, record the uncertainty rather than ignoring it.

Have existing controls been considered?

The assessment should explain which controls already reduce the likelihood or impact of the scenario. A policy should not automatically be treated as an effective control unless there is evidence that it is implemented and operating.

Is the score connected to risk tolerance?

The organisation should define which scores can be accepted, which require monitoring and which require treatment. The decision should be consistent with management-approved risk acceptance criteria.

Are treatment actions clear?

For risks requiring action, record the selected controls, responsible owner, implementation deadline, expected result and verification method. “Improve security” is not a treatment plan unless it is divided into specific actions.

Is residual risk documented?

After treatment, reassess the risk and record the expected residual level. If the remaining risk is accepted, the risk owner should approve that decision and document the reasoning.

Is there a review trigger?

The assessment should identify when it must be updated, including after incidents, near misses, system changes, new suppliers, regulatory changes or control failures. A periodic review should also be scheduled.

Can an auditor follow the decision trail?

The final record should allow someone to trace the complete chain:

Scenario → criteria → evidence → score → treatment decision → owner → action → residual risk → review

This quality check is more useful than simply asking whether the matrix has been completed. It confirms that the assessment supports real decisions and can remain reliable over time.

Conclusion

A 5×5 risk assessment matrix is useful because it creates a shared method for comparing likelihood and impact. Its value, however, depends on how it is implemented.

A strong process defines the scales, assesses specific scenarios, considers existing controls, records the reasoning, assigns treatment owners and maintains evidence. It also includes review triggers so that the matrix changes when the organisation, technology or risk environment changes.

The matrix should not become a decorative chart or a one-time audit document. It should function as part of the organisation’s risk management system and connect directly to treatment plans, controls, management decisions and continuous improvement.

Frequently Asked Questions (FAQs)