A cybersecurity risk assessment matrix is a structured tool that scores identified security risks by combining two variables — the likelihood that a threat will materialise and the impact it would have if it did. The resulting score tells you which risks to treat first, which to monitor, and which fall within your acceptance threshold. For financial institutions running ISO 27001, DORA, or SOC 2 programmes, the risk assessment matrix is not optional infrastructure — it is the document that connects your threat landscape to your control decisions, and the one auditors will examine to verify that your risk management process is both systematic and defensible. This guide explains how to build a matrix that holds up under audit scrutiny, how to score and classify risks consistently, and how to keep it current.
What a Cybersecurity Risk Assessment Matrix Is
A risk assessment matrix — sometimes called a risk heat map or risk scoring grid — is a visual tool that plots the likelihood of a risk event on one axis and the potential impact of that event on the other, helping organisations allocate resources effectively to mitigate risks. Each identified risk is scored against both dimensions and positioned in the matrix. The combination of likelihood and impact dictates the severity of the risk, which can be categorised as Low, Medium, High, or Extreme. That classification drives the treatment decision.
The matrix is not a standalone document. It is one output of a broader risk assessment process — the visual and analytical tool that organises the risk register, makes prioritisation decisions transparent, simplifies complex risk data for executives and security teams reviewing cyber risk, and provides the evidence that the risk assessment methodology is being applied consistently rather than arbitrarily.
For ISO 27001 compliance, the matrix supports the Clause 6.1.2 requirement that the risk assessment process produce consistent and comparable results. For DORA’s ICT risk management requirements, it provides the documented risk scoring that supervisory authorities expect to see in an ICT risk management framework. For SOC 2, it underpins the Common Criteria risk assessment requirement (CC3) that every in-scope system’s risks be identified, analysed, and evaluated.
Choosing Your Matrix Format: 3×3 vs 5×5
The first structural decision is the size of the matrix — how many levels to define for likelihood and impact.
3×3 matrix (three likelihood levels × three impact levels, producing nine possible scores) is fast to complete and easy to explain to non-technical stakeholders. The limitation is resolution: with nine possible scores, risks cluster in the middle band and lose meaningful differentiation, which makes it harder to prioritize risks based on true differences in risk levels. A 3×3 is appropriate for initial screening exercises or for very small organisations conducting their first formal risk assessment.
5×5 matrix (five likelihood levels × five impact levels, producing 25 possible scores) provides substantially more resolution. Risks that would all land as “medium” in a 3×3 can be meaningfully differentiated in a 5×5. For financial institutions conducting a full ISO 27001 or DORA risk assessment across a complex environment, a 5×5 is the standard. It requires more careful calibration of the scales, but the result is a risk register where prioritisation decisions are defensible and granular, with high-likelihood/high-impact risks typically ranked ahead of low-likelihood/low-impact risks, helping teams align limited resources with the most significant cyber security risk areas.
The 5×5 is the format described throughout this guide.
Step 1: Define Your Likelihood Scale
Define five likelihood levels with explicit, anchored descriptions so that different assessors scoring the same risk arrive at the same level, using a low-to-high scale from Rare to Almost Certain. Defining the likelihood scale this way helps identify threats consistently across the it environment. Vague descriptions (“unlikely”, “possible”) produce inconsistent scoring; anchored descriptions produce defensible results.
Level 1 — Rare: The event could occur only in exceptional circumstances. No known instances in your sector in the last three years. Probability less than 5% in a twelve-month period.
Level 2 — Unlikely: The event has occurred in your sector but not at your organisation. Probability between 5% and 20% in a twelve-month period.
Level 3 — Possible: The event could occur at some point and has occurred at comparable organisations. Probability between 20% and 50% in a twelve-month period.
Level 4 — Likely: The event will probably occur in most circumstances. Known attack patterns directly applicable to your environment. Probability between 50% and 80% in a twelve-month period.
Level 5 — Almost Certain: The event is expected to occur in most circumstances. Active exploitation of the relevant vulnerability is known to be occurring. Probability above 80% in a twelve-month period.
Step 2: Define Your Impact Scale
Define five impact levels anchored to consequences that are meaningful in your operational context, with the scale running from low to high, from Negligible to Catastrophic. For financial institutions, impact dimensions should cover financial loss, regulatory consequence, operational disruption, reputational damage, and exposure involving sensitive data or personally identifiable information.
Level 1 — Negligible: Minimal operational disruption, no regulatory notification required, financial loss below a defined threshold (e.g., under €10,000), no customer impact.
Level 2 — Minor: Limited disruption to non-critical systems, no reportable breach, financial loss within a defined band (e.g., €10,000–€100,000), minimal customer impact resolvable without escalation.
Level 3 — Moderate: Significant disruption to one or more systems, possible regulatory notification, financial loss within a defined band (e.g., €100,000–€500,000), some customer impact requiring communication.
Level 4 — Major: Extended outage of critical systems, probable regulatory notification and investigation, financial loss within a defined band (e.g., €500,000–€2,000,000), material customer impact requiring public communication.
Level 5 — Catastrophic: Loss of critical system availability for an extended period, mandatory regulatory notification under DORA or GDPR, financial loss above a defined threshold (e.g., over €2,000,000), severe reputational damage and potential loss of operating licence, including major data breaches, financial penalties, or compromise of intellectual property and other critical information assets where relevant.
Calibrate the financial thresholds to your organisation’s size and risk appetite. The thresholds above are illustrative; what matters is that they are internally consistent and approved by senior management before the assessment begins. Impact thresholds should also reflect regulatory risk and business value, and periodic cybersecurity risk assessments help reduce long-term costs and reputational harm by preventing incidents and application downtime.
Step 3: Build the Scoring Grid
With likelihood and impact scales defined, the risk score for each identified risk is calculated as:
Risk Score = Likelihood (1–5) × Impact (1–5)
This produces scores ranging from 1 (Rare × Negligible) to 25 (Almost Certain × Catastrophic). Assigning values to threats means multiplying the likelihood score by the impact score and plotting the result on the matrix grid. Map these scores to four risk classifications; this risk rating makes risk exposure easier to compare across scenarios, and organisations should prioritize risks and prioritize remediation efforts starting with the highest-rated items:
- Low (1–4): Risk falls within the acceptance threshold. Document the decision to accept, assign an owner, and review at the next scheduled cycle.
- Medium (5–9): Risk requires monitoring and may require treatment depending on the organisation’s risk appetite. Document the treatment decision with rationale.
- High (10–19): Risk requires treatment. The risk treatment plan must document the specific controls selected, the target residual risk score, and the implementation timeline.
- Critical (20–25): Risk requires immediate treatment. Escalate to senior management. Do not proceed with the associated activity or system without implementing controls to reduce the score below the critical threshold.
Colour-coding the grid — green for low, amber for medium, red for high, dark red for critical — makes the matrix readable for management reviews and audit presentations, and helps stakeholders understand urgency at a glance.
Step 4: Identify and Score Your Risks
With the matrix defined, a thorough risk assessment starts with identifying critical assets and other valuable assets in scope, then mapping threats and identifying vulnerabilities against them. This usually relies on an asset register covering technology systems, critical assets, and related business processes. Each identified risk scenario is scored against the likelihood and impact scales.
As part of a broader cyber risk assessment and security risk assessment workflow that includes compliance mapping, the risk scenario format connects an asset, a threat, a vulnerability, and a consequence:
The same scoring approach helps security teams assess potential risks to critical information assets and determine where security controls and remediation efforts should focus first. The inherent risk score reflects the risk before controls are applied. Once the treatment controls are documented and implemented, the residual risk score reflects what remains after those controls are operational. Both scores should appear in the risk register — the gap between them represents the value your controls are delivering.
Organisations often use a cybersecurity risk assessment template aligned to frameworks such as ISO 27001, the NIST Cybersecurity Framework from the national institute, or HIPAA
Step 5: Distinguish Inherent Risk from Residual Risk
One of the most common gaps in risk assessment matrices is conflating inherent and residual risk. The distinction matters because it is what allows the matrix to answer two different questions and quantify exposure against the organisation’s risk tolerance: how exposed are we without controls, and how exposed are we with the controls we have in place?
Inherent risk is the risk level before any controls are applied — the raw exposure from the threat-vulnerability combination. Scoring inherent risk requires temporarily setting aside the controls that exist and assessing the risk as if those controls were absent.
Residual risk is the risk level after the treatment controls have been applied. It reflects the effectiveness of those controls: a high-quality access control programme implementing MFA, quarterly access reviews, and privileged access management will produce a materially lower residual risk score for an access-related threat than a programme with only a password policy. At this stage, documented security controls should be evaluated to mitigate risks and support a stronger security posture.
For ISO 27001, residual risk must fall within the risk acceptance criteria defined by senior management. Where it does not, the risk treatment plan must document additional controls to bring the residual risk within the threshold. In practice, that is where teams should use a cost benefit analysis to decide which measures best reduce exposure and align limited cybersecurity resources with the most significant threats.
How the Matrix Connects to the Risk Register and Treatment Plan
The risk assessment matrix is the analytical engine; the risk register is where the outputs are recorded. Each risk scenario should be a row in the register, capturing: the asset, including critical information assets and third party risk where external providers are involved, threat, vulnerability, inherent likelihood and impact scores, inherent risk score, risk classification, treatment decision (mitigate, accept, transfer, avoid), the specific controls selected for mitigation, the target residual score, the risk owner, and the review date.
The risk treatment plan — a separate document or section of the risk register — details the implementation steps for each mitigating control: who is responsible, what action is required, the target completion date, and the current status, supporting compliance alignment and audit readiness through clear ownership and tracking. Under ISO 27001, the treatment plan must be approved by management and the residual risk must be accepted by risk owners before certification.
For DORA, the risk register and treatment plan together constitute the ICT risk management documentation that supervisory authorities will request in a regulatory review. The matrix provides the scoring rationale; the register provides the inventory; the treatment plan provides the evidence that risks are being addressed, not just identified, and clear records also support regulatory compliance and data protection expectations.
Keeping the Matrix Current
A risk assessment matrix that was accurate at the time of certification and has not been updated since is a compliance liability, not an asset. Continuous monitoring helps keep it aligned with changes in configurations, policies, and compliance requirements. The threat landscape changes — new attack techniques emerge, the organisation’s own systems change, suppliers change, and regulatory requirements evolve.
Minimum maintenance standard: formal review through annual risk assessments, refreshed risk scores where circumstances have changed, new risk scenarios added for new systems or services, closed risk scenarios removed or archived; future assessments should also be triggered by major changes.
Trigger-based reassessment: material changes to in-scope systems, security incidents (internally or at comparable organisations), significant changes to the threat landscape, new regulatory requirements, mergers or acquisitions that change the asset scope, shifts in data governance, or changes to business processes.
Under ISO 27001 Clause 9.1, monitoring and measurement of the ISMS — including the risk assessment — is a continuous requirement, not an annual event. Under DORA’s ICT risk management framework, the ICT risk assessment must be updated when significant changes occur in the ICT environment. Regular reassessment strengthens security posture and operational efficiency, and automated or AI-powered workflows can reduce inconsistency while maintaining visibility into evolving cyber threats.
Frequently Asked Questions
What is the difference between a 3×3 and a 5×5 risk matrix?
A 3×3 matrix uses three levels for both likelihood and impact, producing nine possible risk scores. It is fast and simple but lacks resolution — risks cluster in the middle band. A 5×5 matrix uses five levels for each dimension, producing 25 possible scores and enabling meaningful differentiation across a large risk inventory. For financial institutions conducting formal ISO 27001 or DORA risk assessments, a 5×5 is the appropriate format.
What is the difference between inherent risk and residual risk?
Inherent risk is the risk level before any controls are applied. Residual risk is the risk level after treatment controls have been implemented. The gap between the two represents the risk reduction delivered by your controls. Both scores should be recorded in the risk register; residual risk is the figure that must fall within your risk acceptance criteria.
How often should the risk assessment matrix be updated?
At minimum, annually, with continuous monitoring often supplementing that baseline. In practice, the matrix should be updated whenever significant changes occur — new systems, material security incidents, changes to the threat landscape, or new regulatory requirements. Under ISO 27001 and DORA, the risk assessment is a continuous process, not a point-in-time exercise.
Does ISO 27001 prescribe a specific risk matrix format?
No. ISO 27001 requires that the risk assessment methodology produce consistent and comparable results, but it does not mandate a specific format. Organisations often use a cybersecurity risk assessment template aligned to frameworks such as ISO 27001, the NIST Cybersecurity Framework from the national institute, or HIPAA, depending on their obligations; this supports consistent risk assessment and future assessments. A 5×5 likelihood-impact matrix is the most widely used approach and is well recognised by certification body auditors.
A cybersecurity risk assessment matrix is only as useful as the discipline applied to maintaining it. Built once and left static, it becomes a compliance artefact that no longer reflects the organisation’s actual exposure. Updated regularly, anchored to a well-calibrated scoring methodology, and connected to a live risk register and treatment plan, it becomes the operational tool that tells the security function where to direct its effort — and the evidence that tells regulators and auditors that the direction is principled rather than reactive.
How Copla Supports Cybersecurity Risk Assessment
We work with financial institutions to build and maintain the risk assessment methodology that underpins ISO 27001 certification and DORA compliance. The engagement starts with methodology definition — calibrating the likelihood and impact scales to your organisation’s size, risk appetite, and regulatory context, while identifying the critical assets, sensitive data, and business processes in scope — before running the risk identification exercise across your in-scope asset inventory.
From there, we populate the risk register and scoring matrix in the Copla platform, build the risk treatment plan connecting each identified risk to the Annex A controls selected to address it, and obtain the management sign-off on residual risk that ISO 27001 Clause 6 requires. The platform automates asset discovery, scoring, and reporting to reduce human error, accelerate the assessment process, and keep security ratings current. The platform keeps the risk register live between annual review cycles, prompting reassessment when trigger conditions are met and tracking treatment plan progress so the register reflects current reality rather than the state of the environment at the last audit, supporting continuous visibility, remediation efforts, and stronger audit readiness between formal reviews.
Schedule a call with Copla to walk through how this would look for your organisation.
