A documented risk matrix, usually a 5×5 grid scoring likelihood against impact, is an acceptable and practical method for prioritizing information security risks under ISO 27001. Auditors don’t care whether you use 5×5 or 4×4; they care whether your methodology is written down, applied consistently, and traceable to your Annex A controls and Statement of Applicability. Get those three things right and the matrix itself is the easy part.
TL;DR:
- A documented 5×5 risk matrix is sufficient for ISO 27001 compliance if it is clearly defined, consistently applied, and traceable to controls and the statement of applicability.
- Choosing appropriate scales and levels—usually between 4×4 and 5×5—balances granularity with assessor agreement, especially when impact criteria are tailored to sector-specific risks.
- The risk assessment process must specify matrix size, likelihood, impact definitions, risk acceptance criteria, assessment frequency, risk owner, and threat/vulnerability identification, with regular updates after significant changes.
- Scoring should focus on inherent risk before controls, with residual risk used to justify control effectiveness and treatment decisions aligned with documented acceptance thresholds.
- Risk treatment plans and annex control mappings need precise traceability to risks, with documented management sign-offs for residual risk above acceptance thresholds to satisfy audit requirements.
Table of Contents
- What Is an ISO 27001 Risk Matrix and When Should You Use One?
- Choosing Scales and Matrix Design: 5×5, 4×4, and Beyond
- Building the Matrix Step by Step Under Clause 6.1.2
- Turning Scores Into Treatment Decisions and an Annex A Mapping
- Structuring the Risk Register and Treatment Plan
- A Worked 5×5 Matrix You Can Adapt
- Where Calculators and Benchmarks Actually Help
- Getting the Matrix Auditor-Ready: What Actually Moves the Needle
- Skip the Spreadsheet Guesswork With Ismscalculator
- Primary Sources and Further Reading
- Sources
What Is an ISO 27001 Risk Matrix and When Should You Use One?
An ISO 27001 risk matrix is a grid that plots likelihood on one axis and impact on the other, producing a heat map that ranks risks from negligible to critical. Multiply the two scores and you get a risk value you can sort, compare, and track over time. It’s the same logic project managers have used for decades, borrowed and formalized for information security work.
The matrix earns its place in an ISO 27001 program because it forces you to score every risk against the same yardstick. Without that discipline, one risk owner rates a phishing scenario as “high” based on gut feeling while another rates a near-identical scenario as “medium” because they had a good week. A matrix with defined levels removes that inconsistency, or at least shrinks it to something defensible.
Impact scoring maps naturally to the CIA triad: confidentiality, integrity, and availability. A ransomware scenario, for instance, hits availability hard (systems go down) and can touch integrity too (data gets corrupted before you notice). A misconfigured cloud storage bucket is almost purely a confidentiality failure. Scoring against all three dimensions, rather than a single blended “how bad is this” number, keeps your risk register honest about what actually breaks when a threat materializes.
Matrices aren’t the only risk assessment method ISO 27001 allows. The standard is explicit that it does not prescribe one technique. Quantitative models using annualized loss expectancy, Monte Carlo simulations, and FAIR (Factor Analysis of Information Risk) all satisfy the same clause. So why do most organizations, especially small and midsize ones, land on a matrix anyway?
- It scales with a growing asset inventory without demanding a statistics background from every risk owner.
- It produces results non technical stakeholders and auditors can read at a glance.
- It’s repeatable across annual reviews, which matters more to a certification body than raw precision.
- It’s cheap to build and maintain compared to quantitative modeling that needs loss-history data most companies don’t have.
Choose a matrix when your risk population is broad (dozens to hundreds of scenarios across IT, HR, physical security, and third parties) and you need a method that a compliance officer, an IT manager, and an external auditor can all interpret the same way. Save quantitative modeling for the handful of high-stakes risks where a board wants a dollar figure attached to the exposure.
Choosing Scales and Matrix Design: 5×5, 4×4, and Beyond
The 5×5 matrix (five likelihood levels by five impact levels, scored 1 through 5 on each axis) is the default in most ISO 27001 implementations, and for good reason. A documented 5×5 approach with defined acceptance bands gives auditors exactly what they want: enough granularity to differentiate risks meaningfully, without so many levels that two assessors can’t agree on where a scenario lands.
Numeric scales (1 to 5) and labeled scales (rare, unlikely, possible, likely, almost certain) both work, but they solve different problems. Numeric scales multiply cleanly into a single risk score, which is what most heat maps and risk registers expect. Labeled scales read better in board presentations but need a translation table back to numbers before you can rank anything. Most mature programs use both: labels for the narrative, numbers for the math.
Here’s a simple process for picking and defining your scale:
- Decide on matrix size first. A 5×5 works for most mid-market organizations; a 4×4 suits smaller teams that struggle to distinguish five gradations of anything with confidence.
- Write a one-sentence definition for every level on both axes. “Likelihood 3: could plausibly occur once in the next 12 months based on industry incident data or past internal events” beats “moderate” every time an auditor asks a risk owner to justify a score.
- Anchor impact criteria to business consequences, not just technical ones. Financial loss thresholds, regulatory fine exposure, contractual penalties, and outage-hour thresholds translate technical risk into language management actually signs off on.
- Pilot the scale on ten real risks before rolling it out. If three different reviewers score the same scenario two levels apart, your definitions are too vague.
- Lock the scale in your risk methodology document and change it only through a formal review, never mid-cycle.
The trade-off every team wrestles with is granularity against consistency. A 7×7 matrix looks impressively precise on paper, but ask five risk owners to independently distinguish “likelihood 4” from “likelihood 5” across 49 cells and you’ll get more disagreement than data. Coarser scales sacrifice nuance but gain something more valuable during an audit: reviewers who apply the criteria the same way every time.
Pro Tip: Adapt your impact scale to your sector before you adapt anything else. A healthcare provider’s “critical” impact level should reference patient safety and HIPAA exposure; an insurer’s should reference policyholder data and regulatory capital requirements. A generic scale copied from a template rarely maps to what your board actually loses sleep over.
Building the Matrix Step by Step Under Clause 6.1.2
Clause 6.1.2 of ISO/IEC 27001 requires you to define and apply a documented information security risk assessment process, including risk acceptance criteria and criteria for performing the assessments themselves. That single requirement drives almost everything an auditor checks later, so it’s worth treating as a checklist rather than a suggestion.
Before you score a single risk, your documented methodology needs to specify:
- The matrix size and the definition of every likelihood and impact level.
- Risk acceptance criteria (the score above which a risk requires treatment, not just monitoring).
- Assessment frequency (annual is standard; more often for high-change environments).
- Who owns the process, who owns individual risks, and who approves acceptance decisions.
- How you’ll identify assets, threats, and vulnerabilities in the first place.
That last point deserves its own attention because it’s where a lot of first-time ISMS teams stall. Start with an asset inventory, information, systems, people, facilities, third parties, and work outward. For each asset, run scenario-based identification: what could realistically go wrong, and what threat/vulnerability pair causes it? A laptop fleet pairs the threat “theft” with the vulnerability “unencrypted disks.” A customer database pairs “SQL injection” with “unpatched application code.” You don’t need exotic threat modeling frameworks for this stage; a structured brainstorm against your asset list, cross-checked against a threat catalog, covers most organizations.
Once you’ve identified a scenario, the scoring itself follows a simple formula: inherent risk = likelihood × impact, calculated as if no controls existed yet. This matters because it establishes a baseline. Skip straight to scoring with controls in mind and you’ll systematically underestimate what you’re actually exposed to, and you’ll have no way to demonstrate control effectiveness later.
Residual risk is where existing controls come into the picture. If you’ve already deployed multi-factor authentication and endpoint detection on that laptop fleet, the likelihood of a successful theft-driven data breach drops, maybe from a 4 to a 2. Recalculate the score using the same formula, and the gap between inherent and residual risk becomes your evidence that controls are doing something measurable. This gap is also what most compliance officers underestimate the value of: it’s the single clearest artifact you can hand an auditor to prove your controls aren’t just documented, they’re functioning.
With a residual score in hand, the evaluation step is a comparison, not a judgment call: does the residual score sit above or below your documented acceptance criteria? If it’s below, you can accept the risk and move on. If it’s above, you choose a treatment path, and common treatment options break into four categories:
- Mitigate by implementing additional Annex A controls.
- Transfer the exposure through insurance or outsourcing.
- Avoid the risk by discontinuing the activity that creates it.
- Accept the residual exposure, documented and formally signed off by top management.
Every one of these decisions needs a paper trail. A documented, repeatable matrix method reduces audit findings not because any particular scoring model is superior, but because auditors are checking for consistency and evidence, not mathematical elegance. Your risk register entry, sign-off record, and review notes are what actually get inspected. The matrix is just the mechanism that produced the number.
Turning Scores Into Treatment Decisions and an Annex A Mapping
A risk score means nothing until you decide what to do above and below it. Most organizations set three or four acceptance bands, something like: scores of 1 to 4 are low and get monitored, 5 to 9 are medium and get reviewed at the next cycle, 10 to 15 are high and require a treatment plan within 90 days, and 16 to 25 are critical and demand action within 30 days along with immediate management notification.
Those exact thresholds aren’t sacred. What matters is that you set them before you start scoring risks, write them into your methodology, and apply them without exception. A common misstep is adjusting the acceptance line after the fact because a favorite project’s risk landed just above it. That kind of after-the-fact rationalization is exactly what shows up as a nonconformity when an auditor traces your decisions back to the criteria you documented.
Once a risk clears your treatment threshold, the next move is mapping it to Annex A. ISO 27001’s Annex A lists 93 controls across four themes: organizational, people, physical, and technological. For each high or critical risk, you select the control or controls that address it, and you record that selection, along with your justification for including or excluding it, in the Statement of Applicability.
The SoA is where a lot of otherwise solid ISMS programs lose points. Auditors expect traceability from each Annex A control to at least one risk in the register, and a mismatch between the two is one of the most frequently cited nonconformities in certification audits. If your SoA says A.8.24 (use of cryptography) is applicable but your risk register never mentions a scenario cryptography would mitigate, that’s a gap an auditor will flag on sight.
The fix is procedural, not clever: build the SoA directly from the risk register rather than as a separate exercise. For every risk that required treatment, note which Annex A control (or controls) you’re implementing and cross-reference the risk ID in the SoA’s justification column. Working in the other direction, backfilling justifications for a generic SoA template, is how the traceability gap happens in the first place.
Auditor checks on this front tend to follow a predictable path:
- Pick several risks from the register rated high or critical and ask to see the corresponding SoA entry.
- Pick several “applicable” controls from the SoA and ask which risk drove that selection.
- Check whether excluded controls have a documented justification tied to an actual risk assessment finding, not just a boilerplate “not applicable to our context.”
- Confirm that residual risk acceptances above your documented threshold carry a management sign off, dated and attributable to a named approver.
That last point catches more organizations off guard than it should. If your acceptance criteria say anything above a score of 15 needs executive sign-off, and you’ve got a 20-rated risk sitting in the register with no signature attached, that’s not a documentation nitpick. It’s a break in the chain of accountability the whole standard is built around.
Structuring the Risk Register and Treatment Plan
Your risk register is the working document everything else in this process feeds into, and it needs to hold more than a risk description and a score. At minimum, build columns for:
- A unique risk ID (for cross-referencing in the SoA and treatment plan)
- Risk description and the affected asset
- Threat and vulnerability pairing that creates the scenario
- Inherent likelihood, inherent impact, and inherent score
- Existing controls already in place
- Residual likelihood, residual impact, and residual score
- Treatment decision (mitigate, transfer, avoid, accept)
- Risk owner (a named individual, not a department)
- Status and next review date
That risk owner field is worth pausing on. “IT department” is not a risk owner; it’s an org chart entry with no accountability attached. Auditors have started asking pointedly who is personally responsible for tracking a given risk to closure, and “the IT department” doesn’t survive that question. Name a person.
For every risk that lands above your acceptance threshold, the register entry needs to spin off into a treatment plan with its own structure: the specific control being implemented, a milestone date, the person validating that the control actually works once deployed (not just that it was installed), and evidence of that validation, screenshots, test results, a policy sign-off, whatever fits the control type.
Review cadence should match your risk landscape’s rate of change. Annual full reviews are the baseline everyone runs, but a genuinely mature ISMS also triggers ad hoc reviews after major events: a new system going live, an acquisition, a significant incident, or a new regulatory requirement landing on your desk. Waiting a full year to reassess risk after a material change to your environment is a gap auditors notice quickly, because it suggests the risk process runs on a calendar rather than on actual conditions.
Pro Tip: Keep a lightweight change log next to your risk register, not buried in meeting minutes, that notes every event that triggered an off-cycle review and what changed as a result. It turns “we review annually” into a demonstrable pattern of continuous monitoring, which is a stronger audit story than a single annual snapshot ever tells.
A Worked 5×5 Matrix You Can Adapt
Here’s a standard 5×5 heat map with likelihood on the vertical axis and impact across the top. Multiply the two to get the risk score in each cell.
| Likelihood ↓ / Impact → | 1 (Negligible) | 2 (Minor) | 3 (Moderate) | 4 (Major) | 5 (Severe) |
|---|---|---|---|---|---|
| 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 commonly used banding structure treats scores 1 to 4 as low, 5 to 9 as medium, 10 to 15 as high, and 16 to 25 as critical. Those bands are what you’d document in your methodology and apply consistently across the register.
Here’s a fully worked entry that walks through the whole process:
Asset: Customer relationship management database (contains names, contact details, purchase history). Threat/vulnerability: External attacker exploits an unpatched application vulnerability to exfiltrate records. Inherent scoring: Likelihood 4 (unpatched systems are a recurring finding in vulnerability scans) × Impact 5 (regulatory fines, breach notification costs, reputational damage) = 20, critical. Existing and added controls: Web application firewall, quarterly patch management cycle, encryption at rest, access logging with anomaly alerts. Residual scoring: Likelihood drops to 2 (controls significantly reduce exploitability) × Impact stays at 4 (a breach is still costly even if contained faster) = 8, medium. Treatment decision: Accept the residual risk with a documented review every six months, signed off by the CISO, since it now sits inside the medium acceptance band.
Adapting this template across industries mostly means changing the impact criteria, not the matrix mechanics. An insurer scoring the same database scenario would weight impact against regulatory capital and policyholder-notification obligations, which often pushes impact scores higher than a retail business would assign for an equivalent breach. A five-person startup might reasonably run a 4×4 version of this same table if a full 5×5 adds more granularity than the team can consistently apply.
Where Calculators and Benchmarks Actually Help
Spreadsheets can run a risk matrix just fine, but they fall apart the moment you need to compare this year’s scores against last year’s, benchmark your maturity against similar companies, or export a clean SoA without hunting for formula errors across forty tabs. Purpose-built tools close that gap, and vendor data on risk assessment software consistently points to the same operational wins: fewer manual errors, faster scenario comparison, and reporting that doesn’t require rebuilding pivot tables every quarter.
A few capabilities move the needle in practice:
- Real-time readiness calculators that estimate implementation cost and effort against your company size and industry.
- Maturity assessments spanning the 14 ISO domains, so you know where your program is thin before an auditor finds out for you.
- Templated exports that turn a risk register directly into SoA-ready documentation.
- Saved and comparable assessments, useful when leadership wants to see progress across quarters.
None of that replaces the documented methodology Clause 6.1.2 demands, and no tool signs off on residual risk acceptance for you. Tools speed up the mechanics; the judgment, the owner assignments, and the management approvals still belong to your team.
Getting the Matrix Auditor-Ready: What Actually Moves the Needle
Most of the ISMS programs that sail through certification aren’t the ones with the fanciest scoring model. They’re the ones that wrote their acceptance bands down before scoring a single risk, and never quietly moved the goalposts afterward. That single discipline prevents more nonconformities than any amount of matrix sophistication.
Simplicity beats precision here more often than people expect. A clean 5×5 with well-defined levels, applied the same way every quarter, will outperform an elaborate 10×10 model that three different risk owners interpret three different ways. Consistency is the thing auditors can actually verify; granularity mostly just looks impressive in a slide deck.
The last piece practitioners underweight is cadence tied to real events, not the calendar. A named owner, a review triggered by an actual change to your environment, and a record of what shifted between assessments tell a far stronger audit story than a single polished annual snapshot ever will.
— Martin
Skip the Spreadsheet Guesswork With Ismscalculator
Building a matrix by hand works, but scoping how long the entire ISO 27001 project will take, and what it will cost, is a separate problem most spreadsheets were never built to solve. Ismscalculator gives you a real-time estimate tailored to your company size, industry, and current security maturity, benchmarked against organizations that have already been through certification.
The platform runs a maturity assessment across 14 ISO domains, so you can see exactly where your risk management practices stand before an auditor tells you. From there, a customizable Gantt chart lays out your implementation phases, and you can export findings as a PDF or save multiple estimates to compare scenarios as your scope shifts. It’s built to complement the risk register and treatment plan you’re already assembling, not replace the judgment calls that go into it.
Start with the free 2-minute readiness check to get an initial estimate, or run the full ISO 27001 readiness assessment if you’re ready to map out cost, timeline, and effort in detail.
Primary Sources and Further Reading
For the standard’s own language on documented risk assessment requirements, consult ISO/IEC 27001:2022 directly. For implementation and audit-focused detail, see the ISO 27001 risk treatment guide and the complete methodology guide.
Sources
- ISO/IEC 27001:2022 - Information security management systems
- ISO 27001 Risk Assessment Methodology: A Complete Guide
- ISO 27001:2022 INFORMATION SECURITY IMPLEMENTATION GUIDE