ISO/IEC 27005 Risk Criteria

ISO/IEC 27001 requires risk acceptance criteria and criteria for performing information security risk assessments. ISO/IEC 27005 explains that the criteria should reflect organizational objectives, internal and external context, uncertainty, time, measurement consistency, combinations of risks, and the organization's capacity.

Assessment criteria define how significance is measured through consequence, likelihood, and level of risk. Acceptance criteria define the point at which risk is acceptable or needs treatment. They can use several thresholds, assign different authority levels, distinguish classes of risk, and set absolute or conditional acceptance. Authorized management should approve the acceptance criteria; individual assessors apply them but do not invent a threshold for each case.

Consequence can cover harm to people, privacy, operations, deadlines, finances, market position, reputation, legal or contractual duties, interested parties, and the environment. Likelihood can be expressed as probability within a stated period or as expected frequency. A level of risk can be qualitative, such as high or medium, or quantitative, such as expected annual monetary loss, provided the scale is understood and calibrated.

Keep the approved criteria as a controlled method, not only as colours in a matrix. Record scale definitions and boundaries, the reference period for likelihood, consequence dimensions, the risk-level calculation or decision rule, treatment and acceptance thresholds, authority levels, temporary or conditional acceptance rules, aggregation rules, and handling for values outside the scale.

Add worked scenarios that test boundary cases. ISO/IEC 27005 gives examples of a rare event that wipes out a company's stock value and a constant drain from frequent minor policy infractions to show why dominant consequence or likelihood can need a separate threshold. It also describes short-term retention above a desired threshold when an approved plan will reduce the risk within a defined period. Examples help users apply the criteria consistently; they do not replace judgment about the actual evidence.

Start with the ISMS scope, objectives, interested-party requirements, legal and contractual duties, risk appetite, operating model, technology, suppliers, human factors, organizational capacity, and available evidence. Align information security criteria with the organization's wider risk approach so information security risks can be compared with other organizational risks where comparison is meaningful.

Define the scales and decision rules, then test them on representative scenarios before approval. Check that users interpret category labels the same way, thresholds route decisions to the intended management level, and extreme consequences or likelihoods are not hidden by multiplication or colour. The authorized management level should approve the acceptance criteria.

A colour matrix can display a result, but it is incomplete unless its categories, boundaries, evidence rules, authority, and acceptance logic are defined. Do not automatically accept risk from a combined score when extreme consequence, very high likelihood, legal or regulatory exposure, a contractual requirement, or another class-specific rule changes the decision.

Review criteria on a planned schedule and when the risk-management context changes. ISO/IEC 27005 prescribes no universal annual cadence. Triggers include changed objectives or risk appetite, new legal or contractual duties, material business or technology change, new data, altered management authority, recurring exceptions, changed supplier relationships, or evidence that assessors reach inconsistent results.

Do not silently rescore past decisions under a new method. Record the effective date and change rationale, then identify which open risks need reassessment so owners can understand whether the risk changed, the criteria changed, or both.