5×5 risk matrix and risk register: how to assess information security risk
A 5×5 risk matrix for information security: likelihood and impact scales, acceptance thresholds, a sample risk register and KSC, NIS2 and GDPR requirements.
ZeroLayer Team 16 min read
A risk matrix is a table in which one axis describes the likelihood of an event and the other its impact. In information security it is most often 5×5: a risk is rated from 1 to 5 on both axes, and the product of those ratings points to a cell in the matrix and a risk level. The result, together with the decision, the owner and the safeguards, goes into the risk register. Popular guides to risk matrices usually deal with occupational health and safety, aviation or projects. This article shows how to build one for the risk assessment required by the Polish National Cybersecurity System Act (ustawa o krajowym systemie cyberbezpieczeństwa, KSC), the NIS2 Directive, the GDPR and ISO/IEC 27001:2022.
Why use a risk matrix in information security
The regulations do not prescribe a specific tool, but they require what a matrix provides: a comparable rating of likelihood and impact, and measures matched to the result.
The NIS2 Directive defines risk precisely through these two quantities. Under Art. 6(9), risk is the potential for loss or disruption caused by an incident, “expressed as a combination of the magnitude of such loss or disruption and the likelihood of occurrence of that incident”. Art. 21(1) requires appropriate and proportionate measures, and proportionality is assessed by taking into account, among other things, the likelihood of occurrence of incidents and their severity.
The KSC Act, as amended (Journal of Laws (Dz.U.) 2026 item 252), transposes this into Art. 8(1). The information security management system must ensure systematic risk assessment (point 1) and the implementation of measures “appropriate and proportionate to the assessed risk”, taking into account, among other things, the likelihood of incidents, the entity's exposure to risks and the social and economic impact (point 2). In point 2(a) the Act explicitly lists “risk assessment policies”. Whether an organisation is an essential or important entity is explained in our article NIS2 and the KSC Act: who it applies to.
The GDPR, in Art. 24(1) and Art. 32(1), requires account to be taken of the risks “of varying likelihood and severity for the rights and freedoms of natural persons”. ISO/IEC 27001:2022 requires, in clause 6.1.2, a risk assessment process with criteria, including risk acceptance criteria, that produces consistent and comparable results. Clause 6.1.3 covers risk treatment, and clauses 8.2 and 8.3 cover carrying out both processes. Guidance on the methodology is given in ISO/IEC 27005:2022, which contains guidelines, not requirements. We describe where risk assessment sits in the overall system, the statement of applicability and Annex A in our guide to the ISMS and information security policy (in Polish). Here we deal with the matrix and the register themselves.
- Art. 8(1)(1)
- systematic assessment of the risk of an incident occurring and management of that risk
- KSC Act, Dz.U. 2026 item 252
- EUR 10 million
- or 2% of revenue (whichever is higher): the maximum fine for an essential entity, including for failing to assess risk
- Art. 73(1)(2) and (3) of the KSC Act
- EUR 7 million
- or 1.4% of revenue: the maximum fine for an important entity
- Art. 73(4) of the KSC Act
- <10%
- of randomly selected pairs of hazards that a typical matrix compares correctly and unambiguously
- L.A. Cox, Risk Analysis 28(2), 2008
Before you start: what to prepare
- Scope: the processes, systems and locations covered by the assessment. An entity covered by the KSC Act starts with the information system used to provide the service.
- An asset inventory with owners: information, applications, cloud services, suppliers.
- Knowledge of threats and vulnerabilities: scan and test results, the incident register, CSIRT advisories. The Act requires these to be collected in Art. 8(1)(3).
- A management decision: the methodology and thresholds are approved by the head of the entity, who under Art. 8d(1) takes decisions on the information security management system.
- Process owners: only they know what a day of downtime or a leak of a specific database means.
Step 1: describe the likelihood scale
After this step, every assessor will know what a “3” on the likelihood axis means. It is best to combine frequency with a description of the situation, because for many cyber threats the organisation has no history of events of its own.
| Level | Name | Frequency (indicative) | Description of the situation |
|---|---|---|---|
| 1 | Rare | once in more than 5 years | Theoretical threat, effective safeguards are working |
| 2 | Unlikely | once every 2–5 years | Known in the sector, made difficult here by several layers of safeguards |
| 3 | Possible | once every 1–2 years | Has happened in similar organisations, safeguards are partial |
| 4 | Likely | several times a year | The vulnerability is known and exploited, safeguards have gaps |
| 5 | Almost certain | monthly or more often | Mass, automated attack, or the event is already occurring |
The table is an example. Adjust the thresholds to your organisation and record them in your methodology.
Check: give two people the same threat, for example a mailbox takeover through phishing. If their ratings differ by more than one level, the descriptions are too general.
Step 2: describe the impact scale in several dimensions
After this step, impact will be assessed against the same categories in every department. A server failure hits availability, while a customer database leak hits confidentiality and individuals' rights, so one dimension is not enough. Each dimension is assessed separately and the highest result is taken.
| Level | Service availability | Confidentiality, integrity, personal data | Legal and organisational impact |
|---|---|---|---|
| 1 Negligible | Downtime up to 1 hour, unnoticeable to users | Public information, no personal data | None |
| 2 Minor | Downtime up to 4 hours, manual workaround works | Data of a few people, no real harm | Internal explanations |
| 3 Moderate | Downtime up to 1 working day | Data of many people, possible notification to the Polish Data Protection Authority (UODO) | Incident report, customer complaints |
| 4 Major | Downtime from 1 to 3 days, noticeable to users | Special categories of data or harm to individuals | Serious incident, proceedings by an authority |
| 5 Critical | More than 3 days, or loss of data without recovery | Mass breach, threat to health and life | Threat to continued operation |
The table is an example. The dimensions and thresholds are set by the organisation.
The personal data column measures the impact on individuals, as required by Art. 24 and 32 GDPR. It is worth aligning the downtime thresholds with the business impact analysis in the business continuity plan, so that both assessments use the same numbers.
Step 3: calculate the score and set the zones in the 5×5 matrix
After this step, every risk has a number from 1 to 25 and a zone. The score is the product of likelihood, marked P (for probability), and impact (I). The matrix below shows a sample split: L (low, 1–4), M (medium, 5–9), H (high, 10–14) and C (critical, 15–25).
| Impact \ Likelihood | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| 5 Critical | 5 M (H*) | 10 H | 15 C | 20 C | 25 C |
| 4 Major | 4 L | 8 M | 12 H | 16 C | 20 C |
| 3 Moderate | 3 L | 6 M | 9 M | 12 H | 15 C |
| 2 Minor | 2 L | 4 L | 6 M | 8 M | 10 H |
| 1 Negligible | 1 L | 2 L | 3 L | 4 L | 5 M |
Sample zone split. *Override rule: a risk with an impact of 5 goes at least into the high zone.
Two cells have a score of 5: an almost certain event with negligible impact, and a rare event that could bring the organisation to a halt. The product is the same, the decisions are entirely different. Hence the override rule for the highest impact.
Zone thresholds are recorded in the methodology before the assessment and applied consistently. An organisation with a low tolerance for downtime may move the critical threshold lower. If you keep your risk matrix in Excel, a 1–5 drop-down list in the P and I columns, a multiplication formula and conditional formatting to colour the zone are enough. You can write the override rule as a condition: if I = 5, the zone cannot be lower than high.
Step 4: record the risk acceptance criteria
After this step, it is clear who can accept a risk in a given zone and what to do with the rest. ISO/IEC 27001 requires the acceptance criteria to be part of the risk criteria in clause 6.1.2. They answer three questions: what level the organisation tolerates without action, who decides on acceptance, and within what time a risk above the threshold must be dealt with.
| Zone | Sample rule | Who accepts the residual risk |
|---|---|---|
| Low (1–4) | Accept, monitor at review | Risk owner |
| Medium (5–9) | Act where the cost is justified, or accept with justification | Risk owner and ISMS owner |
| High (10–14) | Plan with a deadline, acceptance only temporary | Management |
| Critical (15–25) | Immediate action, report to management | Head of the entity, for a defined period |
Example. Enter deadlines and roles to match your structure.
Acceptance without a signature, a date and a re-assessment deadline is not evidence. Under clause 6.1.3, risk owners approve the treatment plan and accept the residual risk. In an entity covered by the KSC Act, responsibility for the obligations under Art. 8 rests with the head of the entity, even if they have entrusted them to another person (Art. 8c(1) and (3)), so risks in the highest zones should go to them.
Step 5: assess inherent risk, then residual risk
After this step, the register shows how much risk the safeguards remove. Inherent risk is the rating without safeguards. Residual risk is the rating after taking into account the safeguards that actually work, not the ones written into the plan.
The difference tells the board which safeguards carry the most weight and what will happen if they fail. A safeguard usually moves one axis. Multi-factor authentication and updates reduce likelihood, while tested backups and a recovery plan reduce impact, because they shorten downtime. Residual risk rarely falls to 1. Such a result usually means someone has rated the plan instead of the actual state.
Step 6: choose how to treat the risk
After this step, every risk above the threshold has a decision. There are four options.
| Option | What it involves | Example | What to watch out for |
|---|---|---|---|
| Mitigation | Safeguards reduce P or I | Multi-factor authentication, network segmentation, tested backups | Re-assess after implementation, not on the day of purchase |
| Transfer | Another party takes on part of the impact | Cyber insurance, a supplier contract with guarantees | Statutory obligations remain with you |
| Avoidance | Stopping the activity that creates the risk | Switching off an unused internet-facing service, no longer collecting unnecessary data | Whether the risk shifts elsewhere |
| Acceptance | Consciously leaving the risk in place | A low risk that would cost more to mitigate than the possible loss | Signature, justification, re-assessment date |
Insurance may cover part of the losses, but it does not release you from obligations under the KSC Act or the GDPR. Handing a service over to a supplier, in turn, creates a supply chain risk, which the Act requires you to take into account in Art. 8(1)(2)(e). We describe what such an incident looks like in our article on supply chain attacks (in Polish).
Step 7: record the result in the risk register
After this step, the whole assessment is in a single document for the auditor and the board. A risk register is a table in which each row describes one risk from identification to decision.
| Column | What to enter | Example (fictitious) |
|---|---|---|
| ID | Permanent identifier | R-07 |
| Asset or process | What the risk relates to | Cloud-based finance and accounting system |
| Threat | What could happen | Takeover of an administrator account after phishing |
| Vulnerability | What makes it possible | Privileged accounts without multi-factor authentication |
| Risk owner | Who decides and is accountable | Finance director |
| P and I (inherent) | Ratings 1–5 | P 4, I 4 (access to payroll data) |
| Score and zone | P × I | 16, critical |
| Decision | One of the four options | Mitigation |
| Safeguards | Specific actions | Phishing-resistant authentication for administrators, alerts on unusual sign-ins, quarterly access review |
| Deadline and responsible person | Date and person | 30 days, system administrator |
| Residual risk | P, I and score after implementation | P 2, I 4, score 8, medium |
| Acceptance | Who and when | Finance director, date of signature |
| Review date | When the assessment comes back | In 6 months or after a system change |
The row is an invented example, not a description of a real organisation.
Here the safeguards reduced likelihood from 4 to 2, but the impact remained unchanged, because a compromised account would still give access to the same data. Further mitigation would have to address impact, for example by narrowing administrators' permissions.
Record the threat and the vulnerability separately, because one vulnerability is often exploited by several threats. Do not delete closed rows; change their status instead. The history of ratings in the risk register shows that the assessment is systematic.
Step 8: review the register at a set interval and after changes
The KSC Act refers to “systematic” assessment, and clause 8.2 of ISO/IEC 27001 requires assessment at planned intervals and when significant changes occur. The review cycle is set by the methodology. It is worth triggering an additional assessment after:
- an incident at your organisation or at a supplier,
- the roll-out of a new system, a migration to the cloud or a change of supplier,
- an actively exploited vulnerability appearing in software you use,
- a change in the law or in the scope of activities,
- an audit or test that calls the effectiveness of safeguards into question.
The evidence for the auditor is the dates of reviews, the participants and the justification for changes in ratings. We describe what an auditor looks for in the documentation in our article cybersecurity audit: what it looks like (in Polish).
Limitations of the risk matrix
The matrix's weaknesses stem from its simplicity. Louis Anthony Cox described them in the article “What's Wrong with Risk Matrices?” (Risk Analysis, vol. 28, no. 2, 2008, pp. 497–512):
- Poor resolution: a typical matrix correctly and unambiguously compares only a small fraction of pairs of hazards, less than 10% in the examples analysed. Very different risks can receive the same rating.
- Errors in ranking: a smaller risk can come out as more serious. When likelihood and impact are negatively correlated, the matrix can, according to the author, perform worse than random.
- Suboptimal resource allocation: the zone does not say which safeguard removes the most risk for a given effort.
- Ambiguous inputs: when impacts are uncertain, different people may assign opposite ratings to the same risk.
Cox recommends using matrices with caution and openly describing the judgements behind them. In practice this means five rules:
- Describe every level of both scales in words, as in steps 1 and 2.
- Add an override rule for the highest impact.
- Do not compare risks to the point. A score of 15 is not “a quarter larger” than 12.
- When choosing safeguards, weigh the risk reduction against the effort required.
- Assess in a workshop with several people and record the reasoning behind every rating.
Risk assessment and the GDPR
The same matrix can be used for the GDPR risk assessment, but impact is then measured for the data subjects. Recital 76 GDPR states that the likelihood and severity of the risk should be determined by reference to the nature, scope, context and purposes of the processing, on the basis of an objective assessment. The starting point is the record of processing activities, which shows what data the organisation processes and in which systems. Where processing is likely to result in a high risk, Art. 35 GDPR requires a separate data protection impact assessment (DPIA), which a row in the register cannot replace. We describe the place of risk assessment in a compliance review in our article GDPR audit step by step.
How SelfAudyt links gaps to the risk register
In SelfAudyt, the organisation answers audit questions on the KSC Act, NIS2, the GDPR and ISO/IEC 27001:2022. Every gap goes into the risk register with a likelihood and impact rating on a 5×5 matrix. The priority matrix sets effort against risk reduction, which addresses Cox's third objection. The gaps become a remediation plan with deadlines over 14-, 90- and 365-day horizons, responsible persons and a status. This is what the result looks like: sample report.
SelfAudyt is a self-assessment. It helps collect gaps and rank them by risk, but it does not replace a methodology approved by management, an external audit or a legal analysis. ZeroLayer offers support with the methodology and audit evidence through its virtual CISO service.
FAQ
What is the difference between a risk matrix and a risk register?
A risk matrix is a rating scale: a table of likelihood and impact that assigns a risk a score and a zone. A risk register is a list of identified risks in which, for each one, you record the rating from the matrix, the owner, the decision, the safeguards, the deadline, the residual risk and the review date.
Does the KSC Act require a 5×5 matrix?
No. Art. 8(1)(1) of the KSC Act requires systematic assessment of the risk of an incident occurring and management of that risk, and point 2(a) requires risk assessment policies, but the Act does not impose a method. The 5×5 matrix is popular because, with simple scales, it gives sufficient resolution. Another method is also acceptable if the organisation describes it in its methodology and applies it consistently.
What risk acceptance thresholds should I set?
The thresholds are set by the organisation in its methodology and approved by management. ISO/IEC 27001 requires acceptance criteria to be defined, but does not give numbers. The sample split in this article: low 1–4, medium 5–9, high 10–14, critical 15–25, with the rule that a risk with the highest impact goes at least into the high zone.
How often should the risk register be updated?
At the interval set in the methodology and after every significant change: an incident, a system roll-out, a change of supplier or a new, actively exploited vulnerability. Clause 8.2 of ISO/IEC 27001 requires assessment at planned intervals and when significant changes occur, and the KSC Act refers to systematic assessment.
Disclaimer
This article is for information purposes only and reflects the law as at 24 October 2026. It is not legal advice. The scales, zones and acceptance criteria in the tables are examples to be adapted, not requirements of the law or the standard. A self-assessment, including in SelfAudyt, does not replace an external audit, ISO/IEC 27001 certification or a legal opinion.
Sources
- Act of 23 January 2026 amending the National Cybersecurity System Act and certain other acts (ustawa o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, Dz.U. 2026 item 252) — Journal of Laws of the Republic of Poland; Art. 8(1), Art. 8c, Art. 8d, Art. 73(1)(2), (3) and (4)
- Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2) — EUR-Lex; Art. 6(9), Art. 21(1)
- Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR) — EUR-Lex; Recital 76, Art. 24, Art. 32, Art. 35
- ISO/IEC 27001:2022 Information security management systems — Requirements — ISO
- ISO/IEC 27005:2022 Guidance on managing information security risks — ISO
- Cox, L.A. (2008). What's Wrong with Risk Matrices? Risk Analysis, 28(2), 497–512 — Wiley
Read next
Compliance
Business continuity plan (BCP) and disaster recovery plan (DRP): what to include and what NIS2 requires
Business continuity and disaster recovery plans: how they differ, what to include, how to test them and what NIS2, the Polish KSC Act and GDPR require in 2026.
16 min read
Compliance
GDPR audit step by step: what to check before an auditor or a UODO inspection
GDPR audit step by step: 12 areas with legal provisions, evidence and a remediation plan, plus what Polish law says about how a UODO inspection works.
15 min read
Compliance
Record of processing activities (RoPA): how to build and maintain it in 2026
Record of processing activities step by step: Art. 30 GDPR elements, controller vs processor records, under-250 exemption, a sample entry and typical errors.
15 min read