Risk appetite and criteria that decisions can use

Scope: appetite statement to applied criteria · Who: the officer who drafts what the board approves · Prerequisites: an objectives set and a standing forum · First result: one approved criteria set

1. Why this exists (the failure mode it prevents)#

"We have a low appetite for cyber risk." The sentence appears on a slide, nobody objects, and it decides nothing. It does not say which risks may be taken, which must be escalated, or which are never accepted. Three symptoms follow, each a later finding.

The first is the scale with no anchors. Consequence and likelihood both run one to five, and neither carries a sentence a non-specialist can test. Two teams score the same exposure two levels apart, and both are right, because "medium" was never defined.

The second is acceptance decided by attendance. A treatment looked expensive, the exposure sounded tolerable, and the meeting moved on. Nothing records who could accept at that level, for how long, or against which threshold. ISO/IEC 27005:2022 defines risk acceptance as an informed decision to take a particular risk ¹. An acceptance with no criterion behind it is not informed; it is a preference.

The third is the register nobody can reproduce. An assessor asks for the risk criteria and the record of their approval, and receives a deck. ISO/IEC 27001:2022 clause 6.1.2 is titled "Information security risk assessment" ², and it is the clause the question is asked against. A board that funds treatment without ever approving the appetite it serves has funded a decision it never took.

One loop, not three silos. The decision about how much risk may be taken is governance's. ISO 31000:2018 puts it on top management and oversight bodies. They decide how much risk, and of what kind, the organisation is prepared to carry, and that decision steers the criteria ³. The instrument that carries the decision into daily work is risk's: the criteria, the scales and the level-of-risk rule, defined under clause 6.3.4 ⁴. What compliance later demonstrates is the record of both applied: an approved criteria set, dated, with acceptances taken by named roles inside their stated limits. Governance ensures protection, compliance demonstrates it, and both exist to manage risk.

2. Definitions (only the ones that cause disputes)#

Term	Working definition	Source
Risk	The effect of uncertainty on objectives. An effect is a deviation from the expected, positive or negative.	ISO 31000:2018, 3.1 5
Risk source	An element which alone or in combination can give rise to risk.	ISO 31000:2018, 3.4 6
Event	An occurrence, or a change of a particular set of circumstances. Something expected that does not happen counts.	ISO 31000:2018, 3.5 7
Consequence	The outcome of an event affecting objectives. Consequences escalate through cascading and cumulative effects.	ISO 31000:2018, 3.6 8
Likelihood	The chance of something happening, described in general terms or mathematically. Broader than a narrow reading of "probability".	ISO 31000:2018, 3.7 9
Control	A measure that maintains or modifies risk. Controls do not always exert the effect assumed of them.	ISO 31000:2018, 3.8 10
Risk criteria	Terms of reference against which the significance of a risk is evaluated. They rest on objectives and context.	ISO/IEC 27005:2022, 3.1.7 11
Risk appetite	The amount and type of risk an organisation is willing to pursue or retain.	ISO/IEC 27005:2022, 3.1.8 12
Level of risk	The significance of a risk, as the combination of consequences and their likelihood. "Combination" is the operative word.	ISO/IEC 27005:2022, 3.1.15 1
Risk acceptance	An informed decision to take a particular risk. Accepted risks stay under monitoring.	ISO/IEC 27005:2022, 3.2.8 1
Risk tolerance	Working term. The threshold at which a category's exposure stops being routine and becomes a decision.	Regulation (EU) 2022/2554, Article 6(8)(b) 13
Acceptance criteria	Working term. The published rule saying which role may accept which level, for how long, and on what record.	House convention, applied under ISO/IEC 27001:2022, 6.1.2 2

"Risk appetite" is not a term ISO 31000:2018 defines. Its clause 3 carries eight terms only: risk, risk management, stakeholder, risk source, event, consequence, likelihood and control ¹⁴. The nearest wording is clause 6.3.4, where the organisation states how much risk, and of what kind, it is prepared to take ⁴. The defined term lives in ISO/IEC 27005:2022 clause 3.1.8 instead ¹². Quoting "appetite" as an ISO 31000 term quotes something that is not there.

Appetite and tolerance are two statements, not one. GV.RM-02 expects appetite and tolerance statements to be established, communicated and maintained ¹⁵. Appetite is the standing position on a category of risk. Tolerance is the edge of that position, where a single exposure is escalated rather than absorbed.

3. The method — numbered steps, each with input, activity, output and owner#

3.1 Start from objectives and obligations, not from a maturity model#

• Input: the organisation's objectives, the obligations that bind it, and the scope of the management system.
• Activity: list the objectives risk can affect, then the obligations that constrain the answer. Write both before any scale is drafted.
• Output: an objectives and obligations sheet, one page, referenced by the criteria set.
• Owner: the risk or security officer, confirmed by the owner of each objective.

Criteria sit inside clause 6.3, "Scope, context and criteria". They should reflect the organisation's values, objectives and resources, stay consistent with its risk management policies, and be defined taking its obligations and stakeholder views into account ⁴. Criteria written from a maturity model describe a generic organisation, and no objective owner recognises their exposure in them.

ISO/IEC 27001:2022 supplies the same starting point at clause 4.1, "Understanding the organization and its context", and clause 6.2 ¹⁶. The obligations column is where proportionality enters. Directive (EU) 2022/2555 requires measures that are appropriate and proportionate. Assessing proportionality takes due account of the entity's degree of exposure, its size, and the likelihood and severity of incidents, including societal and economic impact ¹⁷. Those factors belong in the criteria, because an authority will use them to judge the criteria.

3.2 Write the appetite as decisions, not adjectives#

• Input: the objectives and obligations sheet, and the risk categories the organisation already reports on.
• Activity: for each category, write three sentences: what is tolerated without escalation, what is escalated and to whom, and what is never accepted. Delete every adjective that survives alone.
• Output: the appetite statement, one row per category.
• Owner: top management, drafted by the risk or security officer.

An appetite sentence is usable when the person holding a decision can act on it without a second question. "Low appetite for supplier risk" fails. Its replacement names a boundary, a route and an absolute. "Personal data is not processed by a supplier without an assessed and recorded transfer basis; exceptions go to the executive committee, and never for special-category data." Keep that last field short and mean it. An appetite statement with no "never" is a preference dressed as a decision.

Top management and oversight bodies decide how much risk, and of what kind, may be taken. That decision guides the development of risk criteria, and the result is communicated to the organisation and its stakeholders ³. The commitment is articulated through a policy or statement. It covers authorities and accountabilities, the resources made available, and the way conflicting objectives are dealt with ¹⁸. That last item is what an appetite statement really is: a written answer to a conflict between an objective and its cost.

For a financial entity the wording is set. Regulation (EU) 2022/2554 requires a resilience strategy. It establishes the risk tolerance level for ICT risk, in accordance with the entity's risk appetite, and analyses the impact tolerance for disruptions ¹³. The management body bears the overall responsibility for setting and approving that strategy, including the tolerance level ¹⁹.

3.3 Set consequence scales with sentence-level anchors per dimension#

• Input: the objectives set, the obligations list, and the loss data the organisation already holds.
• Activity: anchor each of five levels on every dimension in use, in a sentence a non-specialist can test. Rule that the highest dimension sets the level, and record which one did.
• Output: the consequence scale, five levels by six dimensions.
• Owner: the risk or security officer; each dimension is confirmed by the function that owns it.

Six dimensions cover most organisations: financial, service, regulatory, information, safety where a safety duty exists, and reputation. Finance owns the financial anchors, the service owner the service anchors, and legal the regulatory ones. A scale drafted by security alone is one security will be arguing about for a year.

Anchors are sentences, not adjectives. "Major" is not a scale point. A scale point reads like this: "notification duty certain; supervisory correspondence expected; material unbudgeted cost in the current period". Two people can disagree about whether a situation meets it, then settle it by reading.

The criteria state how consequences and likelihood are defined and measured, how the level of risk is determined, and how multiple risks combine ⁴. The multiple-risk item is the one most scales omit, and it is why a "highest dimension wins" rule needs a companion rule for correlated failures.

Consequence is scored before likelihood. Groups that start with likelihood anchor on how often something happens, then inflate the damage to justify the attention already given.

3.4 Set likelihood scales with time-bound anchors#

• Input: the incident record, sector reporting, and the change and supplier pipeline.
• Activity: anchor each level on an observed frequency over a stated period, and name the evidence that supports each level.
• Output: the likelihood scale, five levels with a frequency band and an evidence column.
• Owner: the risk or security officer, using the incident and monitoring records.

A likelihood anchor without a time period is not an anchor. "Possible" means nothing; "has happened here at least once in the last three years" can be checked. Likelihood covers the chance of something happening, determined objectively or subjectively, and described in general terms or as a frequency over a given period ⁹. The standard permits the subjective reading; the criteria set should not, above the lowest bands.

Add an evidence column beside each level and the scale starts to defend itself. A four is claimed by pointing at the incident record, the monitoring feed or published sector data. Risk analysis can be influenced by divergence of opinions, biases, perceptions of risk and judgements, and those influences should be considered, documented and communicated to decision makers ²⁰. An evidence column is the cheapest form of that documentation.

3.5 Derive the level-of-risk lookup, the acceptance criteria and the escalation thresholds#

• Input: the approved consequence and likelihood scales.
• Activity: publish the combination as a lookup table, mark the acceptance line on it, and write who may accept each level, for how long, and against what record.
• Output: the level-of-risk lookup and the acceptance criteria table.
• Owner: top management approves; the risk or security officer drafts.

Publish the combination as a table, not a formula. Level of risk is a combination of consequences and their likelihood, and combination is not multiplication ¹. Ordinal scores are ranks, so a product asserts arithmetic the scale does not carry: likelihood four with consequence two, and its mirror, both give eight.

Mark the acceptance line on the lookup itself. Below it, the risk owner accepts inside a stated period; above it, the row is treated or escalated. Three closed options are enough: accept, treat, escalate. A fourth is always someone avoiding the third.

The escalation thresholds are the governance half of the instrument. Each level names the role that may accept, the maximum period before re-confirmation, and the record required. Where an acceptance would exceed the delegated level, the row goes to the forum holding the authority. The acceptance decision itself is covered by Risk acceptance and residual risk.

Risk evaluation compares the results of analysis with the established criteria, to determine where additional action is required. Its outcome should be recorded, communicated and then validated at appropriate levels ²¹. Selection between treatment options is made in accordance with the organisation's objectives, its risk criteria and the resources available ²². Criteria that cannot decide between two options are not yet criteria.

3.6 Test the criteria on ten known risks before approval#

• Input: the draft scales, the draft acceptance criteria, and ten risks the organisation already understands.
• Activity: run a calibration workshop. Score each risk independently, compare, and rewrite every anchor that produced a spread of more than one level.
• Output: the calibration record: ten risks, the scores given, the spread, and the anchor changes made.
• Owner: the risk or security officer facilitates; objective owners score.

This step decides whether the criteria survive contact with the organisation. Pick ten risks with known outcomes, including two accepted and two treated expensively. Each participant scores consequence and likelihood alone, before any discussion. Then reveal the spread.

A spread of two levels on the same risk is an anchor defect, not a training problem. Rewrite the anchor rather than repeating the briefing. A spread on the dimension that set the level shows which function has not been consulted yet.

Two counts matter as much as the scores. How many risks landed above the acceptance line: if most of them did, the line is in the wrong place. And how many nobody could score, which usually means a control gap rather than a risk.

Different views should be considered when defining risk criteria and when evaluating risks ²³. A calibration workshop is what that sentence looks like on a calendar.

3.7 Get it approved and recorded#

• Input: the appetite statement, the scales, the lookup, the acceptance criteria and the calibration record.
• Activity: put the set to the accountable forum as a decision, not as information. Record the approving role, the date, the version and the review date.
• Output: the approved criteria set, versioned, with an approval minute.
• Owner: the accountable management forum or board.

Here the three disciplines meet in one act. The forum takes a governance decision about how much risk the organisation will carry. The criteria set is the risk instrument turning that decision into reproducible scores. The minute, the version and the review date are what compliance produces when an assessor asks how the boundary was set, and by whom.

The approval is not optional. Under Directive (EU) 2022/2555, the management bodies of essential and important entities approve the cybersecurity risk-management measures taken to comply with Article 21. They oversee the implementation, and can be held liable for infringements ²⁴. ISO/IEC 27001:2022 clause 5.1 is "Leadership and commitment" and clause 5.2 "Policy" ²⁵. ISO/IEC 27002:2022 control 5.1 asks that the policy set be defined, approved by management, published, communicated, and reviewed at planned intervals and on significant change ²⁶.

How the set reaches the forum is covered in Board and management reporting for security, sections 3.2 and 3.3. Nothing there is repeated here.

3.8 Apply it: the register's scales become these scales#

• Input: the approved criteria set and the current risk register.
• Activity: replace the register's local scales with the approved ones, re-score one domain, and reconcile every open acceptance against the new thresholds.
• Output: a re-scored domain, plus a list of acceptances now outside the delegated level.
• Owner: the register keeper re-scores; risk owners confirm their own rows.

The criteria set is not a document beside the register; it is the register's scales sheet. That playbook anchors consequence on three axes: information, regulatory-financial and operational. The six dimensions here add safety and reputation; an organisation keeps the set it needs. The rows themselves, the grammar of a risk statement and the workshop that produces them are in The risk register other people trust, with the workbook at the risk register template. This piece supplies the scales that template's Scales sheet is filled from.

Expect the reconciliation to surface acceptances taken above the level the acceptor may now accept. Take that list to the next forum as a batch, one recommendation per row.

ISO/IEC 27001:2022 keeps assessment and treatment as running operations, clauses 8.2 and 8.3 ²⁷. Criteria approved once and never applied fail that pair.

3.9 Set the review triggers and the rhythm#

• Input: the approved criteria set, the incident record, the obligations list and the change pipeline.
• Activity: set an annual review, name the events that pull one forward, and log every trigger evaluation, including those concluding no change.
• Output: the review log, with a dated entry per evaluation.
• Owner: the risk or security officer; the accountable forum approves any change.

The criteria are set before the assessment starts, and the standard treats them as living: reviewed as the context moves and changed when they no longer fit ⁴. Reporting is an integral part of the organisation's governance, supporting top management and oversight bodies in meeting their responsibilities ²⁸.

Six triggers cover most organisations: a material incident; a new or changed obligation; a change of scope or an acquisition; repeated escalations in one category; a change of the accountable forum; the annual review. GV.OV-01 expects strategy outcomes to be reviewed, to inform and adjust strategy and direction ²⁹.

Log the evaluations that concluded "no change". Without them, a criteria set that has not moved is indistinguishable from one nobody looked at.

4. Deliverables#

Deliverable	Format	Template	Retention
Appetite statement	xlsx	Criteria and appetite	Every approved version, three years
Consequence and likelihood scales	xlsx	Criteria and appetite	Live version; superseded versions three years
Lookup and acceptance criteria	xlsx	Criteria and appetite	With the criteria set they belong to
Calibration record	xlsx	template pending	One cycle after the version it tested
Approval minute	minutes with decisions	template pending	Whole certification cycle
Review log	register	template pending	Three years after the last entry
Re-scored register domain	xlsx	Risk register	As the register

Retention periods above are organisational choices rather than requirements of any standard or instrument cited here.

5. What the auditor or authority will ask#

An assessment that stays on the criteria document is going well. One that moves to a register row, then to the minute authorising its acceptance, is where a criteria set written for the binder fails.

6. Failure modes and how they surface as findings#

7. Mapping to standards and instruments#

Clause titles below are abbreviated to keep the cells short; each is cited in full in the section that uses it. ISO 31000:2018 ³⁰. ISO/IEC 27001:2022 ³¹. CSF 2.0 ³². The two instruments ³³, ³⁴.

Element	ISO 31000:2018	ISO/IEC 27001:2022	NIST CSF 2.0	Regulation	Evidence sampled
Objectives and obligations	6.3.4 Defining risk criteria	4.1 Context; 6.2 objectives	GV.OC-03 legal and regulatory requirements managed	NIS2 Article 21(1)	Objectives and obligations sheet
The appetite decision	5.2 Leadership and commitment	5.1 Leadership and commitment	GV.RM-02 appetite and tolerance statements	DORA Article 6(8)(b)	Appetite statement, approving role, date
The commitment written down	5.4.2 Articulating risk management commitment	5.2 Policy	GV.RM-01 risk management objectives agreed	DORA Article 5(2)	Approved policy or statement, versioned
Scales and level-of-risk lookup	6.3.4 Defining risk criteria	6.1.2 risk assessment	GV.RM-06 standardised method for categorising risks	NIS2 Article 21(1)	Anchored scales; the published lookup
Acceptance and escalation thresholds	6.4.4 Risk evaluation	6.1.3 risk treatment	GV.RM-04 direction describing risk response options	DORA Article 6(8)(b)	Acceptance table; a row that crossed a threshold
Choosing a treatment option	6.5.2 Selection of risk treatment options	6.1.3 risk treatment	ID.RA-06 risk responses chosen and prioritised	not addressed	Treatment plan citing the criteria used
Calibration before approval	6.2 Communication and consultation	6.1.2 risk assessment	GV.RM-05 lines of communication established	not addressed	Calibration record with the scoring spread
Approval by the accountable body	5.2 Leadership and commitment	9.3.2 Management review inputs	GV.RM-03 outcomes in enterprise risk management	NIS2 Article 20(1)	Minute with the decision, version and date
Applying the criteria in operation	6.4.4 Risk evaluation	8.2 and 8.3 as operations	ID.RA-05 impacts and likelihoods inform prioritisation	NIS2 Article 21(1)	Re-scored domain, criteria version stamped
Review and adjustment	6.7 Recording and reporting	9.1 Monitoring and evaluation	GV.OV-01 strategy outcomes reviewed and adjusted	not addressed	Review log, including no-change entries

ISO 31000:2018 is guidance rather than a certifiable requirement set. Its column shows where the same act lives in a general risk vocabulary, which is what makes a security criteria set legible to enterprise risk. "Not addressed" means the instrument does not speak to that element, not that the element is optional.

Two Annex A controls carry this method: ISO/IEC 27002:2022 control 5.1, "Policies for information security", and control 5.4, "Management responsibilities". Control 5.4 asks management to require all personnel to apply information security in accordance with the established policies and procedures ³⁵.

8. Checklist#

• The objectives and obligations sheet exists and is referenced by the criteria set.
• Every risk category carries three sentences: tolerated, escalated and to whom, never accepted.
• No appetite row consists of an adjective and a category name.
• Each consequence level carries a sentence anchor on every dimension in use, and the dimension that set a level is recorded in the row.
• Each likelihood level carries a time-bound frequency band and a named evidence source.
• The level-of-risk rule is published as a lookup table, never as a product of two scores, and the acceptance line is marked on it.
• The acceptance criteria name the role, the maximum period and the record required for each level.
• The calibration record shows ten risks, the initial spread and the anchors changed as a result.
• The approval minute names the approving body, the version and the date, and the register stamps the version it used.
• The register's scales are the approved scales, and one domain has been re-scored against them.
• Open acceptances are reconciled against the current thresholds, with exceptions listed.
• The trigger list exists, and evaluations concluding no change are logged with dates.
• A named role can produce the current criteria set, its approval and its last review within one working day.

References#

1. ISO. Risk management — Guidelines. ISO 31000:2018. Read in a licensed copy of the identical national adoption ³⁶
2. ISO/IEC. Information security, cybersecurity and privacy protection — Guidance on managing information security risks. ISO/IEC 27005:2022. Terms read in the publisher's preview; no process clause is cited from it ³⁷
3. ISO/IEC. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO/IEC 27001:2022. https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-3:v1:en ³⁸
4. ISO/IEC. Information security, cybersecurity and privacy protection — Information security controls. ISO/IEC 27002:2022. Control titles and requirement text read in a licensed copy ³⁹
5. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, 26 February 2024. https://doi.org/10.6028/NIST.CSWP.29 ⁴⁰
6. European Parliament and Council. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union. OJ L 333, 27.12.2022, p. 80. https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng ⁴¹
7. European Parliament and Council. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. OJ L 333, 27.12.2022, pp. 1-79. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng ⁴²

Dimension counts, review periods, retention periods and delegation limits are organisational choices rather than requirements of any standard cited here.

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication and is not affiliated with, authorized, sponsored or endorsed by ISO, IEC, NIST or any other standards body.