ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
ISO 27001 risk criteria are the rules that decide how your organization rates information security risk and when it is willing to live with what remains. Clause 6.1.2 of ISO/IEC 27001 requires you to define and apply an information security risk assessment process that establishes and maintains risk criteria, including risk acceptance criteria and criteria for performing risk assessments. Without them, ratings are arbitrary, results are not comparable and the auditor has nothing to test your assessment against.
This guide explains what ISO 27001 risk criteria must cover, how to design likelihood and impact scales, how to set acceptance criteria, how to get management approval, how to apply them consistently and what auditors look for. It is general guidance, and you should check the standard itself for the exact requirements.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
ISO 27001 clause 6.1.2 asks the organization to define and apply a risk assessment process that establishes and maintains information security risk criteria, including risk acceptance criteria and criteria for performing information security risk assessments. It also requires that repeated assessments produce consistent, valid and comparable results. The full text is available through ISO/IEC 27001:2022.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
Two ideas follow. First, you must decide criteria before you assess, not adjust them to fit results. Second, the criteria must produce results that are comparable across assets, teams and time. That means written scales, clear thresholds and a documented method. Compare with the wider discussion in ISO 27001 risk assessment methodology.
Define the scales used to rate likelihood and impact. A common choice is four or five levels for each, described in words and, where possible, numbers. Likelihood might range from rare to almost certain, with an indication of frequency. Impact might range from minor to severe, described in terms of confidentiality, integrity and availability, financial loss, legal consequences, operational disruption and reputation.
Link the impact scale to your business. A severe impact should relate to something that matters, such as loss of a major contract, a regulatory penalty over a stated amount or an outage beyond a stated tolerance. Include examples so assessors apply the scale in the same way. See BIA impact scoring scales for similar thinking on impact thresholds.
Free business impact analysis
How long can each activity really be down?
Rate the impact of an outage over time, set RTOs and maximum tolerable periods of disruption, map the people, systems and suppliers behind each activity, and get a recovery sequence back, free.
Run the free business impact analysis → or View premium report sample
Decide how likelihood and impact combine into a risk level. Options include a matrix that maps each pair to low, medium, high or critical, or a numeric formula such as likelihood times impact grouped into bands. Whichever you choose, document it and use it every time.
Check that the result behaves sensibly. Very high impact with low likelihood should not vanish into “low” if your appetite is low for severe outcomes. Test the matrix on real scenarios, and adjust before it is approved. Once approved, changes should follow a controlled process and be recorded.
| Element | What it defines | Example |
|---|---|---|
| Assessment criteria | How likelihood and impact are rated | Four-level scales with descriptions |
| Risk matrix or formula | How the two are combined | Likelihood multiplied by impact, mapped to bands |
| Acceptance criteria | Which risks can be accepted and by whom | Low accepted by owner, medium needs plan, high needs top management |
| Consistency rules | How to produce valid, comparable results | Scale guidance and calibration |
| Review rule | When criteria are revisited | Annually and after major change |
Acceptance criteria state which risks the organization may accept without further treatment and who may decide. For example: risks rated low may be accepted by the risk owner; medium risks need a treatment plan but may be accepted for a limited time by a department head; high risks require treatment or acceptance by top management. The criteria can include conditions such as legal compliance, contractual duties and cost.
This links to clause 6.1.3, where risk owners must approve the treatment plan and accept residual risks. See ISO 27001 risk acceptance and ISO 27001 risk owner for how that works. Acceptance criteria should also connect to your risk appetite, so they are consistent with strategy.
Top management should approve the risk criteria, because they reflect how much risk the organization will tolerate. Record the approval and version. Communicate the criteria to everyone who performs or reviews risk assessments, and include them in training and in the ISMS documentation.
Auditors will ask to see the criteria and evidence of approval. They will then test whether assessments actually applied them. Keep the criteria in a controlled document, and refer to it from the risk assessment procedure and the risk register.
Consistency does not happen automatically. Provide scale guidance with examples, run a calibration session in which assessors rate the same scenarios and discuss differences, and have a second person review a sample of ratings. Use the same approach for asset-based and scenario-based methods; see asset-based risk assessment and scenario-based risk assessment.
Validity means that ratings reflect reality. Compare ratings with incident experience and audit findings. If incidents keep occurring in areas rated low, the criteria or the ratings need to be reviewed. Record the reasoning behind ratings so that a third party could follow it.
Many organizations must align information security risk criteria with an enterprise risk framework, ISO 31000, ISO/IEC 27005 or sector rules. Align scales and labels where possible so information security risks can be combined in the enterprise register. See ISO 31000 vs ISO 27005 for how the standards relate and risk criteria for the general concept.
If you handle personal data, align the impact scale with privacy considerations, such as harm to individuals, so the security and privacy assessments do not conflict.
Review the criteria at least annually, and after major changes in the business, the threat environment, regulation or risk appetite. Base changes on evidence: incidents, audit findings, changes in risk tolerance. Follow a change process that includes approval, version control and a note explaining how earlier results relate to the new criteria.
Avoid changing criteria in the middle of an assessment cycle unless there is a strong reason. If you do, re-run affected assessments or explain the effect. Auditors look for stability and control here.
Frequent errors include no written criteria, criteria copied from a template without adaptation, vague scale descriptions, acceptance thresholds that nobody approved, changing criteria to get a preferred result, mixing scales in different assessments, no evidence of calibration and not reviewing the criteria. Another is defining acceptance criteria but never applying them in practice, so all risks are treated as “accepted” by default.
Avoid these by writing plain descriptions, testing the criteria, obtaining approval and applying them consistently.
The register should show the likelihood and impact ratings, the resulting level and the acceptance decision, all traceable to the criteria. Include a column for the reason behind each rating, and lock the scales so users pick from the defined values. When someone proposes a rating outside the guidance, require a comment. Over time, review the register for patterns: clusters of ratings just below a threshold may show that assessors are avoiding higher levels, which is worth discussing.
A software company defines a four-level likelihood scale and a four-level impact scale, described in terms of financial loss, customer effect, legal consequences and downtime. The matrix maps combinations to low, medium, high and critical. Acceptance criteria say that low risks are accepted by the asset owner, medium risks need a dated plan approved by the department head and high or critical risks need treatment and approval by the executive committee.
The chief executive approves the criteria, and assessors are trained using five sample scenarios. At the next audit, the auditor compares three risks in the register with the criteria and finds the ratings consistent and the acceptances made at the right level. No findings arise.
Keep a single risk criteria document or section of the risk assessment procedure with version history, approval and the effective date. Reference it in the register, and make sure the assessment template reflects the scales. Keep training records and calibration outcomes, and note any changes with reasons.
When the auditor asks how you ensure consistent results, you can walk through the criteria, the training, the review of samples and the comparison with incidents. That story is much stronger than a claim that assessors are experienced.
If you want a report and workbook that carry scales, matrix, acceptance thresholds, risks and treatments in a consistent format, the ISO 27001 Risk Assessment Report and Workbook provides a structured layout for ISO 27001 risk assessment. Whatever tool you use, sound ISO 27001 risk criteria are written down, approved, applied consistently and reviewed.
Rules that set out which risks can be accepted, by whom and under what conditions, approved by management and applied when deciding on treatment.
No. The standard does not prescribe scales, but they must be defined, produce consistent, valid and comparable results and be applied as written.
Top management, because they reflect how much risk the organization is willing to accept.
Yes, with a controlled process, approval and a record of why. Avoid changing them mid-assessment to obtain a preferred result.
That criteria exist and were approved, that assessments applied them consistently and that acceptance decisions were made at the right level.
September 30, 2026
