Risk Appetite and Risk Criteria Template (ISO/IEC 27001 6.1.2)

Appetite and tolerance per category, criteria for performing assessments, 5x5 scales (C, I, A, financial, legal, reputation, OT safety), bands, approvals

SGSI e ISO/IEC 27001CompletaISO/IEC 27001:2022 + Amd 1:2024 clause 6.1.2 a (cited only); ISO/IEC 27005:2022; ISO 31000:2018risk appetite criteriaActualizada 1 nov 2026

Abrir en el editorDescargar .md

Cómo usar: Use it before the first risk assessment, and whenever strategy, revenue or regulation changes. Fill the appetite per category with top management, calibrate the impact scales to real money, then set who may accept each band. The main pitfall is appetite written as adjectives that no assessor can test.

Vista previa

Risk Appetite and Risk Criteria: [Organization name] ISMS

States how much information security risk [Organization name] is willing to take in pursuit of its objectives, the tolerance around that appetite for each risk category, and the risk criteria every assessor uses: the criteria for performing assessments, the 5 x 5 likelihood and impact scales, the risk bands and the acceptance criteria with the approval level for each band. It supports ISO/IEC 27001:2022 + Amd 1:2024 clause 6.1.2 a (risk acceptance criteria and criteria for performing assessments) and feeds clauses 6.1.3, 8.2 and 8.3, with guidance from ISO/IEC 27005:2022 and ISO 31000:2018. Replace every [bracketed] value and every row marked Example.

Document control

Field	Value
Document ID	DOC-ISMS-015
Version	[1.0]
Status	[Draft / In review / Approved / Superseded]
Owner	[@isms-manager]
Approvers/reviewers	[@ceo], [@ciso], [@cfo], [@risk-committee-chair]
Last updated	YYYY-MM-DD
Effective from	YYYY-MM-DD
Classification	[Internal]
Standard and edition	ISO/IEC 27001:2022 + Amd 1:2024 (clause 6.1.2 a); ISO/IEC 27005:2022; ISO 31000:2018
ISMS scope reference	DOC-ISMS-002 (ISMS scope)
Used by	DOC-ISMS-010 (method), DOC-ISMS-016 (risk register), DOC-ISMS-017 (risk assessment report), DOC-ISMS-019 (risk acceptance record)
Enterprise risk link	[ERM framework or board risk appetite statement, reference and date]
Next scheduled review	YYYY-MM-DD

Approvals

Role	Name	Decision	Date
ISMS manager (prepared)	[@isms-manager]	[Prepared]	YYYY-MM-DD
Chief executive or top management	[@ceo]	[Approved / Approved with changes]	YYYY-MM-DD
Finance (financial thresholds)	[@cfo]	[Reviewed]	YYYY-MM-DD
Risk committee or steering committee	[@risk-committee-chair]	[Endorsed]	YYYY-MM-DD

Revision history

Version	Date	Author	Change
0.1 (Example)	YYYY-MM-DD	[@isms-manager]	Draft for top management workshop
1.0 (Example)	YYYY-MM-DD	[@isms-manager]	Approved; scales tested on three past incidents
[x.y]	YYYY-MM-DD	[@author]	[Change summary]

1. Purpose and scope
2. Overall risk appetite statement
3. Appetite and tolerance by risk category
4. Criteria for performing risk assessments
5. Likelihood scale
6. Impact scale: information security properties
7. Impact scale: business consequences
8. Risk matrix and bands
9. Risk acceptance criteria and approval levels
10. Escalation and tolerance breaches
11. Alignment with enterprise risk management
12. Size tiers
13. Review cadence and change control
14. Records and evidence
15. References
Standard and licence note

1. Purpose and scope

This document sets the risk appetite and the risk criteria for all information security risks inside the ISMS scope defined in DOC-ISMS-002. Clause 6.1.2 a of ISO/IEC 27001:2022 is where these rules come from: you decide in advance which risks you can live with and how an assessment is carried out, then keep those rules current. Clause 6.1.2 b is why it matters: two assessors looking at the same risk a year apart should reach the same answer, which is only possible when every assessor uses the same scales.

Item	Value
Applies to	[All information security risks in the ISMS scope, including supplier, cloud, privacy and OT security risks]
Does not apply to	[Credit, market and liquidity risk, handled by the enterprise risk framework]
Users	Risk owners, risk assessors, control owners, ISMS manager, internal audit, top management
Decisions made with it	Whether to assess, how to score, which band applies, whether a risk may be accepted and by whom
Inputs	Business objectives, context and interested parties (DOC-ISMS-003), legal register (DOC-ISMS-014), insurance limits, past incidents

2. Overall risk appetite statement

[Organization name] accepts information security risk only to the extent that it supports the delivery of [core services] and stays within the tolerances in section 3. It has no appetite for risks that could expose customer or patient personal data at scale, breach legal or contractual obligations, or endanger the safety of people. It accepts moderate risk in innovation, product speed and the adoption of new cloud services, provided that the risk is assessed, owned, recorded and reviewed. Risks above appetite are treated, avoided or escalated; they are never left undecided.

Example (Quillmere Analytics Ltd): "Quillmere Analytics protects the customer data it processes as a processor as its first priority. We are averse to any risk that could disclose customer datasets, cautious about availability risks to the analytics platform, and open to risk in evaluating new tools and features, provided each new service passes the security review before it touches customer data."

3. Appetite and tolerance by risk category

Appetite levels, as used in the risk register (compliance/risk-register):

Appetite level	Meaning	Highest residual band normally acceptable
Averse	Avoid the risk wherever practical; treat to the lowest reasonable level	Low (1 to 4)
Cautious	Accept limited risk where the benefit is clear and controls are in place	Medium (5 to 9)
Open	Accept higher risk for a clear strategic benefit, with executive oversight	High (10 to 16), only with top management acceptance under section 9

Category	Appetite	Tolerance statement	Indicator and threshold (Example)
Confidentiality of customer and personal data	Averse	No residual risk above Low for systems holding customer personal data	Zero open Critical or High risks on customer data stores older than 30 days
Integrity of customer-facing data and results	Averse	No residual risk above Low for data used in customer decisions	Data integrity incidents reaching customers: 0 per quarter
Availability of core services	Cautious	Residual risk up to Medium; outages within contractual service levels	Monthly availability at or above [99.9]%; recovery tested within RTO in the last 12 months
Legal, regulatory and contractual compliance	Averse	No accepted risk that would knowingly breach a legal or contractual obligation	Overdue legal register actions: 0; regulator notifications missed: 0
Supplier and cloud dependency	Cautious	Residual up to Medium for critical suppliers with an assessment less than 12 months old	Critical suppliers without a current assessment: 0
People and insider risk	Cautious	Residual up to Medium; training and screening complete for all staff in scope	Security training completion at or above [95]%
Innovation and new technology (including AI tools)	Open	Residual up to High during controlled pilots, never on production customer data without review	Pilots without a security review before go-live: 0
Physical and environmental, including climate-related disruption	Cautious	Residual up to Medium; climate-related hazards (flood, heat, storms) considered where relevant to sites and suppliers	Sites with an untested continuity arrangement: 0
Health and safety impact of security events (OT only)	Averse	No residual risk above Low where a security event could harm people	Open safety-related security risks above Low: 0

ISO/IEC 27001:2022 Amd 1:2024 asks the organization to determine whether climate change is a relevant issue (clause 4.1) and notes that interested parties can have climate-related requirements (clause 4.2). If the context analysis (DOC-ISMS-003) finds it relevant, keep the physical and environmental row and use it in assessments; if not, record why.

4. Criteria for performing risk assessments

4.1 When an assessment is required

Trigger	Assessment type	Deadline (Example)
Planned annual cycle	Full assessment of the ISMS scope	Completed before the management review
Quarterly register review	Review of existing risks, scores and treatment status	Within 10 working days of quarter end
New or significantly changed system, service or site	Targeted assessment of the change	Before go-live
New critical supplier or cloud service	Supplier risk assessment	Before contract signature
Major incident or near miss	Reassessment of affected scenarios	Within 30 days of incident closure
New legal, regulatory or contractual requirement	Targeted assessment	Before the requirement takes effect
Material change in threat intelligence	Review of affected scenarios in DOC-ISMS-018	Within 30 days
Merger, acquisition, reorganisation or scope change	Full or targeted assessment	Before the change is effective

4.2 Minimum quality of an assessment

An assessment is complete only when all of the following are true:

The scope of the assessment and the assets or processes covered are written down.
Scenarios are drawn from the threat and vulnerability catalogue (DOC-ISMS-018) or added to it.
Each risk has a named owner with authority and budget (clause 6.1.2 c 2).
Likelihood and impact are rated with the scales in sections 5 to 7, and the reason and evidence for each rating are recorded.
Existing controls are considered and named by Annex A number.
The score and band follow section 8 with no manual override.
The result is compared with the appetite in section 3 and the acceptance criteria in section 9.
Results are recorded in the risk register (DOC-ISMS-016) and summarised in the risk assessment report (DOC-ISMS-017).

4.3 Depth of assessment

Depth	Use when	Approach (ISO/IEC 27005:2022)
High-level	Annual cycle for the whole scope, first cycle, management workshops	Event-based: risk sources and events with their consequences
Detailed	Critical systems, new services, systems with High or Critical risks	Asset-based: assets, threats and vulnerabilities per asset
Rapid	Small changes inside an existing assessed system	Checklist against existing scenarios; escalate to detailed if a score rises above Medium

5. Likelihood scale

Rate likelihood of the scenario occurring within the next 12 months, taking existing controls into account.

Rating	Label	Descriptor	Indicative frequency (Example)	Typical evidence
1	Rare	Could occur only in exceptional circumstances; no known occurrences in the sector	Less than once in 10 years	No internal history, no sector reports
2	Unlikely	Not expected, but has occurred elsewhere in the sector	Once in 3 to 10 years	Sector reports, threat intelligence mentions
3	Possible	Could occur in the planning period; has occurred here or at peers	Once in 1 to 3 years	Internal near misses, peer incidents
4	Likely	Will probably occur; attempts are observed regularly	Once or more a year	Recurring alerts, audit findings, known weaknesses
5	Almost certain	Expected to occur, or occurring now	Several times a year	Active exploitation, repeated incidents

6. Impact scale: information security properties

Rating	Confidentiality	Integrity	Availability
1 Negligible	Disclosure of public or low-value internal information	Errors corrected before use, no reliance on wrong data	Non-critical service unavailable for less than [4] hours
2 Minor	Disclosure of internal information to a limited audience	Errors in internal data affecting one team, corrected within a day	Critical service degraded for less than [1] hour, or non-critical service down for up to a day
3 Moderate	Disclosure of confidential information or personal data of fewer than [1,000] people	Wrong data reaches a customer or a decision, corrected without lasting harm	Critical service unavailable for [1 to 8] hours
4 Major	Disclosure of personal or confidential data at scale, or of trade secrets	Undetected manipulation of customer data, financial records or production parameters	Critical service unavailable for [8 to 72] hours, or recovery point objective missed
5 Severe	Disclosure of special category, health or regulated data at scale, or of authentication secrets for the whole estate	Systemic loss of trust in core data; data cannot be restored to a known good state	Critical service unavailable for more than [72] hours, or loss of data with no recovery

7. Impact scale: business consequences

Use USD in this example; convert to your local currency.

Rating	Financial (Example)	Legal and regulatory	Reputational	Safety (OT only)
1 Negligible	Under [0.1]% of annual revenue	No breach of law or contract	No external attention	No injury possible
2 Minor	[0.1 to 0.5]% of annual revenue	Minor contract breach, corrected with the customer	Isolated complaints or social media mentions	First aid case
3 Moderate	[0.5 to 2]% of annual revenue	Reportable incident to a regulator or customer, no sanction expected	Trade press coverage, short-lived	Medical treatment or lost-time injury
4 Major	[2 to 5]% of annual revenue	Regulatory investigation, contractual penalties, loss of a key customer	National media coverage, measurable customer loss	Serious injury or significant environmental release
5 Severe	Over [5]% of annual revenue	Significant fine, sanction, loss of licence or certification	Sustained international coverage, long-term brand damage	Fatality, multiple serious injuries or major environmental damage

Rule: the impact rating of a scenario is the highest rating among the columns in sections 6 and 7 that apply. Record which column drove the rating so the score can be challenged.

8. Risk matrix and bands

Risk score = likelihood x impact, from 1 to 25. Possible scores are 1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 16, 20 and 25.

Likelihood / Impact	1 Negligible	2 Minor	3 Moderate	4 Major	5 Severe
5 Almost certain	5 Medium	10 High	15 High	20 Critical	25 Critical
4 Likely	4 Low	8 Medium	12 High	16 High	20 Critical
3 Possible	3 Low	6 Medium	9 Medium	12 High	15 High
2 Unlikely	2 Low	4 Low	6 Medium	8 Medium	10 High
1 Rare	1 Low	2 Low	3 Low	4 Low	5 Medium

Band	Score	Required response	Reported to
Low	1 to 4	Accept and monitor at the next review	Risk owner; included in register
Medium	5 to 9	Consider treatment; accept only with a written reason within appetite	Risk owner and department head
High	10 to 16	Treat; a treatment plan entry with dates is required; acceptance only by top management	Steering committee and top management
Critical	17 to 25 (in practice 20 and 25)	Treat immediately and escalate within [2] working days	Top management; board or owners where one exists

The bands match DOC-ISMS-010 section 2.3 and the risk register. Earlier versions of the method wrote the Critical band as 20 to 25; it is the same band, because no score between 17 and 19 is possible on a 5 x 5 matrix.

9. Risk acceptance criteria and approval levels

Residual band	Who may accept	Maximum period (Example)	Conditions	Record
Low (1 to 4)	Risk owner	12 months	Within appetite for the category	Risk register entry with date
Medium (5 to 9)	Risk owner and department head	12 months	Written reason; within the category tolerance in section 3	Risk register entry; acceptance record DOC-ISMS-019 if above the category appetite
High (10 to 16)	Top management ([CEO / COO / delegated executive])	6 months	Treatment decision with dates or documented reason why treatment is not feasible; compensating controls; steering committee informed	Acceptance record DOC-ISMS-019
Critical (17 to 25)	Not acceptable without treatment; exceptionally top management by documented decision	3 months	Immediate interim measures; board or owners informed where one exists; reassessment at expiry	Acceptance record DOC-ISMS-019 and management minutes

Additional rules:

A risk owner cannot accept a risk in a category marked Averse above Low; acceptance escalates one level (a Medium residual risk in an Averse category goes to top management) and needs an acceptance record DOC-ISMS-019.
No one may accept a risk that would knowingly breach a legal or regulatory obligation. Such risks are treated or the activity is stopped.
Acceptance is never permanent. When an acceptance expires, the risk returns to "open" in the register until it is renewed, treated or closed.
Acceptance of a risk created by a policy deviation follows the security exception route (security/security-exception-request) and uses the same approval levels.

10. Escalation and tolerance breaches

A tolerance breach on an indicator in section 3 (for example customer data risks above Low for more than 30 days) is itself reported to the steering committee (isms/isms-steering-committee-charter) with the cause, the owner and the date by which the position returns within tolerance.

11. Alignment with enterprise risk management

ISMS element	Enterprise risk equivalent	Mapping rule
5 x 5 matrix, score 1 to 25	[ERM matrix and scale]	[1:1 / mapping table]
Appetite levels Averse, Cautious, Open	[Board appetite levels]	[Averse = Minimal, Cautious = Cautious, Open = Open]
Critical band	[ERM principal risk threshold]	[Critical ISMS risks are reported as principal risks]
Financial thresholds	[ERM financial thresholds]	Same thresholds, reviewed by finance annually

Where finance owns a board risk appetite statement, link it (finance/risk-appetite-statement) and state here which of its statements this document refines for information security.

12. Size tiers

Aspect	Small: Quillmere Analytics Ltd (Example)	Medium: Quillmere Health Systems (Example)	Large or multi-site: Quillmere Group (Example)
Who approves this document	CEO, with the part-time ISMS manager (Head of Engineering Operations, 0.5 FTE)	CEO and steering committee	Group executive committee on the CISO's proposal; risk committee endorses
Financial threshold for impact 4 Major	USD 250,000	USD 1,000,000	USD 5,000,000
Safety column	Removed (no OT); reason recorded	Patient safety used for clinical scheduling errors	Used for all 3 plants (OT)
Categories	Six categories; physical folded into availability	All nine categories	Nine categories plus site-specific tolerances per plant
High acceptance	CEO	CEO or COO	Divisional managing director for site risks, group executive for group-wide risks
Critical acceptance	Not acceptable; CEO decision only in an emergency	CEO with board informed	Group CEO with board informed
Review cadence	Annual and on product change	Annual and before the ISO/IEC 27701 extension	Annual, plus each site joining the certified scope

13. Review cadence and change control

Review this document at least every [12] months, before the annual risk assessment cycle and the management review.
Review it also after a major incident, a change of strategy, a significant change in revenue (financial thresholds), a new regulated activity, or an audit finding against the criteria.
Test the scales on [three] past incidents or near misses at each review; if the scores do not match what management felt, recalibrate.
Any change to scales, bands or approval levels is a major version. After approval, re-score the register and record the re-scoring in the register review log.
Communicate approved changes to all risk owners and assessors (DOC-ISMS-027 communication plan) and update DOC-ISMS-010 if it repeats the scales.

14. Records and evidence

Record	Proves	Owner	Location (Example)	Retention (Example)
Approved version of this document	Criteria established and approved (6.1.2 a)	ISMS manager	Document management system, DOC-ISMS-015	Current plus 3 superseded versions
Top management approval minute	Authority behind the appetite	Steering committee secretary	Steering committee minutes	6 years
Calibration test notes	Scales tested against real events	ISMS manager	ISMS working folder	3 years
Risk register entries with scores and bands	Criteria applied consistently (6.1.2 b)	ISMS manager	DOC-ISMS-016	Each dated snapshot for 3 years
Acceptance records	Acceptance within approved authority (6.1.3 f)	Risk owners	DOC-ISMS-019	Life of the risk plus 3 years
Tolerance indicator reports	Appetite monitored	ISMS manager	ISMS performance report (DOC-ISMS-081)	3 years

Record these in the documented information register (DOC-ISMS-028) and map them in the control evidence matrix (DOC-ISMS-033).

15. References

Reference	Edition	Use
ISO/IEC 27001:2022 + Amd 1:2024	3rd edition 2022; Amd 1 published 2024-02-23	Clauses 4.1, 4.2, 6.1.2 a and b, 6.1.3 f, 8.2
ISO/IEC 27005:2022	4th edition	Risk criteria, event-based and asset-based approaches
ISO 31000:2018	Current; a revision is in progress	Risk appetite, treatment options and vocabulary context
NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments	September 2012	Free reference for likelihood and impact scales

Related templates: compliance/risk-methodology (DOC-ISMS-010), compliance/risk-register (DOC-ISMS-016), compliance/risk-treatment-plan (DOC-ISMS-013), isms/isms-risk-assessment-report (DOC-ISMS-017), isms/isms-threat-vulnerability-catalogue (DOC-ISMS-018), isms/isms-risk-acceptance-record (DOC-ISMS-019), isms/isms-context-interested-parties (DOC-ISMS-003), security/security-exception-request, finance/risk-appetite-statement.

Official text: https://www.iso.org/standard/82875.html, https://www.iso.org/standard/88435.html, https://www.iso.org/standard/80585.html, https://www.iso.org/standard/65694.html.

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (clause 6.1.2 a and related clauses), ISO/IEC 27005:2022 and ISO 31000:2018. Clause numbers are cited only; the appetite statements, scales, descriptors, thresholds and examples are original text written for this template. No ISO or IEC text is reproduced, and you need the official standards to interpret the requirements. NIST SP 800-30 Rev. 1 is a US government publication cited as a free reference. Check the current editions before use (ISO 31000 is under revision). This template does not promise certification; certification decisions belong to the accredited certification body.

Template licence: MIT.

Plantillas relacionadas

SGSI e ISO/IEC 27001