ISO 27001 Risk Criteria: Defensible 3x3 to 5x5 Templates

Risk criteria are the documented rules you use to judge how likely a risk is, how serious its impact would be, and when it is acceptable. Define them as a simple 3x3 to 5x5 scale with plain-language anchors, tie them to business objectives, and have top management approve them in writing. That combination is what makes your criteria defensible in an ISO 27001 audit.

TL;DR:

• Get top management to approve the thresholds, scales, scope, review triggers, and version in writing; document who may accept or escalate each risk.
• Choose a 3x3 for a small or first year scope, or a 5x5 for finer ranking; define plain language anchors and a fixed assessment horizon.
• Rate impact across relevant business dimensions, then use the worst case as the overall rating unless your organization can maintain and explain weighted scoring.
• Map every matrix category to a default action, owner, and escalation authority, and link treatment choices, residual risk, and Annex A controls to register entries.
• Keep evidence and rating rationales in the register, then reassess affected risks after major incidents, scope or technology changes, new regulations, or strategy shifts.

Table of Contents

• 1. What ISO 27001 expects from your risk criteria
• 2. How to define acceptance thresholds, scope, and governance
• 3. Assessing likelihood with scales that assessors can reproduce
• 4. Assessing impact across the dimensions that matter to the business
• 5. Choosing a risk matrix: 3x3, 4x4, or 5x5
• 6. Documenting criteria and assessment evidence for auditors
• 7. Connecting risk criteria to treatment decisions and the SoA
• 8. Ready-to-adapt scale templates and a worked example
• 9. Why you can rely on this guidance
• 10. My advice for rolling criteria out
• 11. How we help you document defensible criteria faster
• FAQ
• Sources

1. What ISO 27001 expects from your risk criteria

ISO/IEC 27001 requires an information security management system and puts risk management at its center: the process you use to identify and manage information security risks and to preserve confidentiality, integrity, and availability. Clause 6.1.2 is where this becomes concrete. It asks you to establish and maintain risk criteria, including criteria for accepting risk and criteria for performing assessments, and to make sure repeated assessments produce consistent, valid and comparable results.

Notice what the standard does not say. It does not hand you a formula or a mandatory matrix. ISO/IEC 27005 provides guidance on information security risk management and expects you to define your own risk evaluation, impact criteria and acceptance thresholds to suit your context. In other words, the method is your choice. The reasoning behind it is not optional.

Auditors tend to probe three things:

• Documentation. Are the criteria written down, with scale definitions, thresholds and the date they were approved?
• Consistent application. Do two assessors looking at the same scenario land on the same rating? Implementation guidance such as NQA’s ISO 27001 guide stresses that the method must be applied consistently across the whole ISMS scope and reviewed periodically.
• Traceable decisions. Can they follow a line from a rating in the register, to a treatment decision, to a control in the Statement of Applicability?

Think of the criteria as the rulebook your risk register plays by. If the rulebook is vague, every rating becomes an argument, and every argument becomes an audit finding. If it is precise but impractical, nobody follows it and the register drifts away from reality.

Risk models matter here as well. NIST SP 800-30 Revision 1 describes risk through factors such as threat, vulnerability, impact and likelihood, and recommends defining scales and time frames that fit the organization’s context. It is a US government document, but its logic maps cleanly onto ISO 27001 and gives you vocabulary an auditor will recognize.

One practical consequence: write your criteria before you start populating the register. Teams that rate risks first and justify the scale afterward end up reverse engineering anchors to fit numbers they already chose, and auditors spot that quickly. The scale comes first, the ratings follow, and any change to the scale triggers a documented review of existing ratings.

2. How to define acceptance thresholds, scope, and governance

Start by separating three terms that often get blurred. Risk appetite is the broad amount of risk the organization is willing to pursue to reach its objectives. Risk tolerance is the acceptable variation around a specific objective. Risk acceptance criteria are the operational thresholds your assessors apply: below this score we accept, above it we treat. Appetite is a leadership statement, tolerance is an objective-level limit, and criteria are the working rules. If you want a deeper treatment of the first concept, our guide to ISO 27001 risk appetite shows how to define and measure it.

Express thresholds in language a manager can read without a glossary, and tie each to a business objective. Some examples:

• “We accept risks that could cause no more than a minor, same-day disruption to customer-facing services.”
• “Any risk that could expose regulated customer data is never accepted without a documented treatment plan.”
• “Risks rated High require a named owner and a treatment date within the current quarter.”

Notice that each statement connects a rating to something the business cares about: uptime, regulatory standing, customer trust. That connection is what survives an auditor’s “why this threshold?” question.

Governance is where many programs stumble. Top management should approve the criteria and the acceptance thresholds, not just the security team. Practitioners consistently report that securing formal agreement early, especially on acceptance thresholds, gives you a clear mandate and makes later budget conversations easier, because leadership already agreed what “too risky” means. Record who approved, when, and which version.

Scope deserves the same discipline. State which assets, processes, locations and business units the criteria cover. If one department uses a different scale than another, document why. Mixed scales inside one ISMS scope are a common source of nonconformities, because the results are no longer comparable.

A governance record that works in practice includes:

• The approved scales for likelihood and impact, with anchors
• The acceptance threshold and who may accept risks above or below it
• The scope the criteria apply to
• The review cadence and the triggers that force an earlier review
• The approver’s name, role, date and version number

Keep it to a page or two. Short criteria documents get read, followed and audited without friction.

3. Assessing likelihood with scales that assessors can reproduce

Likelihood is the rating most likely to drift between assessors, so give it the tightest anchors. Three common options exist, and any of them can pass an audit if applied consistently:

• Qualitative labels: Rare, Possible, Likely. Simple and fast, but easy to interpret differently.
• Semi-quantitative 1–5 scales: Each number has a written description. This is the most common choice in ISO 27001 programs.
• Frequency-based wording: “Could occur about once in five years” versus “could occur several times a year.” Easier to defend because it points at something observable.

Whichever you choose, fix the time horizon. A risk that is unlikely next month can be near certain over a decade. State the horizon in the criteria, such as a defined assessment horizon, and record it in the register so every rating means the same thing. NIST SP 800-30 makes the same point from the lifecycle side: choose assessment scales and models appropriate to the context and stage of the assessment.

Anchors are what make ratings reproducible. A sample 5-point scale might read:

• 1, Rare: Not expected within the horizon; no known occurrence in our sector or our history.
• 2, Unlikely: Could happen but would need unusual circumstances.
• 3, Possible: Has happened to comparable organizations; plausible within the horizon.
• 4, Likely: Has happened to us or close peers; expected under current controls.
• 5, Almost certain: Occurring now or repeatedly; current controls do not prevent it.

The wording is deliberately plain. If a new assessor cannot apply a scale point after reading one sentence, rewrite it.

Evidence strengthens likelihood ratings. Use your own incident history, near-miss logs, vulnerability scan results and relevant threat intelligence to justify a rating, and note the source in the register. A rating of “Likely” backed by documented phishing incidents is far easier to defend than the same rating backed by instinct. Older NIST guidance, such as the archived Risk Management Guide for IT Systems, includes example tables of likelihood definitions you can adapt rather than invent from scratch.

Pro Tip: Have colleagues rate the same risks independently using only your written anchors. Wherever their ratings differ, the anchor wording is the problem, so fix it before rolling out.

4. Assessing impact across the dimensions that matter to the business

Impact answers a different question: if this risk materialized, how bad would it be? Because information security failures hurt in different ways, define impact across several dimensions rather than a single vague “severity.” The usual set for ISO 27001 programs is:

• Confidentiality: unauthorized disclosure of sensitive or regulated data
• Integrity: corruption or unauthorized modification of data or systems
• Availability: loss of access to systems or information
• Financial: direct loss, recovery cost, penalties, lost revenue
• Regulatory and legal: breach of law, contract or regulator expectations
• Reputational: loss of customer, partner or public trust
• Operational: disruption to delivery of products or services

You do not need every dimension in every program. Choose the ones that reflect your objectives and say so in the criteria. A SaaS provider will weigh availability and confidentiality heavily; a clinic will weigh confidentiality and regulatory exposure.

For each dimension, write anchors for Low, Medium and High, or for each point on a 1–5 scale. For example, on availability: Low might mean a brief outage affecting internal tools only; Medium might mean a longer outage affecting some customers; High might mean a prolonged outage of a core service. If you want numeric thresholds, such as financial loss bands, set them with finance and have management confirm them. Never copy another company’s dollar figures; they will not match your size or appetite.

Then decide how multiple dimensions combine into one impact rating. Two approaches dominate:

• Worst-case: The overall impact equals the highest dimension. Simple, conservative, and very easy to explain to an auditor.
• Weighted: Each dimension gets a weight reflecting business priority. More nuanced, but harder to defend and maintain.

For most organizations, worst-case is the better default. It avoids the trap where a severe confidentiality impact gets averaged away by a trivial operational one.

Finally, record your assumptions. If you rated impact as High because the asset holds customer records, say so, and note where the data volume came from. Impact ratings without stated assumptions look arbitrary; with them, they look like reasoning.

5. Choosing a risk matrix: 3x3, 4x4, or 5x5

The matrix is the rule that turns a likelihood rating and an impact rating into a risk level. Size is a trade-off between ease of use and granularity.

• 3x3: Quickest to apply and easiest to explain. Works well for small scopes or first-year programs, but nine cells lump many different risks together, so prioritization can feel blunt.
• 4x4: Removes the comfortable middle option, forcing assessors to lean one way. Useful, though less common, so templates are scarcer.
• 5x5: Offers finer distinctions and is widely recognized by auditors. The cost is more room for disagreement between adjacent ratings, so it needs strong anchors.

Practitioner best practice favors simple qualitative or semi-quantitative matrices, in 3x3 or 5x5 form, with plain-language anchors over complex numeric scales that are hard to defend. We agree. The matrix an assessor can apply identically on a Tuesday afternoon beats the clever one that needs a spreadsheet to interpret.

For audit defensibility, use categorical mapping rather than formulas. Instead of “risk equals likelihood times impact, then apply a weighting curve,” write a table that says which combinations are Low, Medium, High or Critical. Multiplication can still sit underneath, but the categories are what you govern. Our 5x5 risk matrix template shows a version built for audits.

Each category should trigger a defined action and owner. A generic example:

A few rules keep the mapping honest:

• Every cell in the matrix maps to exactly one category.
• Every category maps to one default action.
• Exceptions require written justification and a named approver.
• Owners are people, not departments.

If your matrix cannot be summarized on one page, it is probably too complicated to apply consistently.

6. Documenting criteria and assessment evidence for auditors

A defensible rating is one someone else can reconstruct. That means your register captures enough context to replay the reasoning months later. The minimum fields are: asset, context, threat, vulnerability, existing controls, likelihood, impact, score, owner, date, assumptions and evidence.

Beyond the fields, follow these practices:

1. Write a one or two sentence rationale for each rating. “Rated Likely because phishing reached staff mailboxes in three incidents last year and awareness training is annual only” is a rationale. “Likely” alone is not.
2. Link each risk to treatment and to the SoA. Record which Annex A control addresses it and why that control was selected, so the chain from risk to control is visible.
3. Control versions and approvals. Number your criteria document, log changes, and keep prior versions. Auditors may ask which version applied when a given assessment was done.
4. Store evidence where auditors can find it. Incident tickets, scan reports, threat briefings and meeting minutes should be referenced from the register, not scattered across inboxes.
5. Set a review cadence and name the triggers. Review the criteria periodically, as implementation guidance commonly advises, and sooner after a major incident, a significant change in scope or technology, a new regulation, or a shift in business strategy.

Treat the register as a living record. A register that was beautifully populated eighteen months ago and never touched since is a finding waiting to happen. For a full workflow around these records, see our ISO 27001 risk assessment methodology guide.

Teams translating criteria into everyday hardening sometimes want a plain-language primer on the basics. This overview of website security basics covers practical steps for small businesses, and it pairs well with the control-selection work that follows your assessment.

7. Connecting risk criteria to treatment decisions and the SoA

Criteria earn their keep when they drive decisions. The acceptance threshold tells you which risks you can live with and which demand action. The ISO 27001 risk treatment guidance from our team walks through that step in detail, and the logic is straightforward:

• Below the threshold: accept, document the acceptance, and monitor.
• At or above the threshold: choose a treatment: reduce through controls, transfer through insurance or contract, avoid by stopping the activity, or, with management approval, accept despite the rating.
• Above the escalation line: send to top management. Define that line in your criteria so escalation is a rule, not a judgment call.

When you select Annex A controls for the Statement of Applicability, tie each inclusion to a risk, an assessment result or a legal or contractual requirement. “Included because risks R-014 and R-021 were rated High and this control reduces likelihood” is a justification an auditor can verify. Exclusions need reasons too.

To make treatment actionable:

• Convert each category into a work queue: Critical first, then High, and so on.
• Assign each task an owner, a due date and a link to the register entry.
• Estimate effort and cost so plans are funded realistically. Our risk treatment plan template maps risks to Annex A controls and SoA entries in an audit-ready layout.
• Record residual risk after treatment and confirm it falls within the acceptance threshold.

Change is inevitable. When criteria, scope or business context change, reassess affected risks, revisit treatment decisions and update the SoA. Keep a change log noting what shifted and who approved it. Auditors rarely penalize change; they penalize unexplained change.

8. Ready-to-adapt scale templates and a worked example

Here is a 3x3 matrix with plain-language anchors you can copy into your criteria document.

And a 5x5 version, with scoring bands applied to the product of the two ratings:

Worked example. The inputs below are illustrative, not market data.

Notice how the rationale cites evidence and the action cites the threshold. That pairing is what an auditor wants to see.

Sample sign-off wording: “Top management has reviewed and approved the information security risk criteria, including the likelihood and impact scales and the risk acceptance threshold, for the stated ISMS scope. Risks rated High or Critical require a documented treatment plan, and treatment decisions will be reflected in the Statement of Applicability. Approved by [name, role], on [date].” Fill in the bracketed items with real names and dates before filing.

9. Why you can rely on this guidance

The approach in this article follows the structure of ISO/IEC 27001, the guidance of ISO/IEC 27005 and the risk concepts in NIST SP 800-30. ISO/IEC 27001 supplies the requirement that criteria exist and are applied consistently. ISO/IEC 27005 supplies the expectation that you define evaluation, impact and acceptance criteria that fit your context. NIST SP 800-30 supplies the risk model vocabulary and example scale definitions that make plain-language anchors easy to write.

We build ISMS Calculator around the same principles. Our platform provides organization-specific estimates, model reference comparisons, a maturity assessment across ISO domains, templates, and exportable documentation. Our methodology is traceable and versioned, with transparent assumptions you can inspect and challenge.

You can start with what we offer for free. Our free 2-minute check gives you a quick read on readiness, and our template articles on the risk matrix and treatment plan are ready to adapt. Use them as a starting point, then tailor the anchors to your own business.

10. My advice for rolling criteria out

Start small. Pick one business unit or one domain, apply your draft matrix there, and get management sign-off on that pilot before widening the scope. Iterate on the anchors, then standardize.

Test your scale against reality before you commit. Take a handful of incidents your organization has actually lived through and rate them with your draft anchors. If a painful outage lands in the Low column, your anchors are wrong, and it is far cheaper to learn that in a pilot than in an audit. Resist the urge to add precision. Every extra scale point is another place for two assessors to disagree.

— Martin

11. How we help you document defensible criteria faster

Writing criteria by hand works, but versioning, benchmarking and exporting the evidence is where hours disappear. We built ISMS Calculator to take that load off you. Our tool gives you organization-specific estimates, model reference comparisons, maturity mapping across ISO domains and exportable reports with a traceable, versioned methodology. Use it alongside your manual templates to keep documentation consistent and audit-ready. Once your risks are rated, our ISO 27001 Cost Calculator estimates ISO 27001 implementation cost and effort, and our free 2-minute check shows where you stand today.

Start with the free 2-minute readiness check to get a quick read on your readiness.

FAQ

What are risk criteria in ISO 27001?

Risk criteria are the documented rules you use to evaluate risk: the scales for likelihood and impact, the method for combining them, and the thresholds that decide whether a risk is acceptable. ISO/IEC 27001 expects them to be defined and maintained so assessments are consistent and comparable.

What is the ISO standard for risk?

For information security, ISO/IEC 27001 sets the requirement to assess and treat risk within an ISMS, and ISO/IEC 27005 provides guidance on how to manage that risk. ISO/IEC 27005 does not mandate one method, so you define criteria suited to your context.

What are the steps of a standard security risk assessment?

Most models follow the same arc: prepare, identify assets, threats and vulnerabilities, rate likelihood and impact, determine the risk level, then communicate results and maintain the assessment. NIST’s guide to risk assessments describes this lifecycle of preparing, conducting and maintaining.

How big should my risk matrix be?

Choose the smallest matrix that still separates the risks you need to prioritize. A 3x3 suits small scopes and first-year programs, while a 5x5 gives finer ranking if your anchors are strong. Consistency matters more than size.

Sources

• NIST Special Publication 800-30 Revision 1, Guide for Conducting Risk Assessments
• Guide for Conducting Risk Assessments | NIST
• ISO/IEC 27001:2022 - Information security management systems
• INTERNATIONAL STANDARD

Recommended

• ISO 27001 Risk Matrix: 5×5 Template for Audit-Ready InfoSec
• Audit Ready ISO 27001 Risk Register: Copyable Excel Rows, Annex A Mapping
• Audit Ready ISO 27001 Risk Treatment Plan Template for ISMS Teams
• ISO 27001 Risk Assessment: A Complete Methodology Guide