# 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*.

<!--
Guidance: How to use this template
- When to use: before the first risk assessment of the ISMS, and again
  whenever top management changes strategy, enters a new market or
  regulated sector, or after a major incident shows the scales were
  wrong.
- Fill first: section 3 (appetite per category) with top management,
  then section 7 (impact scales) calibrated to real money and real
  consequences, then section 9 (acceptance and approval levels). Have
  the whole document approved BEFORE anyone scores a risk.
- Main pitfall: writing appetite as adjectives ("low appetite for
  security risk") that no assessor can test. Every appetite statement
  needs a tolerance that a score, a metric or a yes/no question can
  check.
- This document holds the criteria. The method (process, roles,
  workshops) lives in the Risk Assessment Methodology
  (`compliance/risk-methodology`, DOC-ISMS-010). Keep the scales here
  and in DOC-ISMS-010 identical, or reference this document from it.
- Related templates: `compliance/risk-methodology`,
  `compliance/risk-register`, `compliance/risk-treatment-plan`,
  `isms/isms-risk-assessment-report`, `isms/isms-risk-acceptance-record`,
  `isms/isms-threat-vulnerability-catalogue`,
  `isms/isms-context-interested-parties`,
  `finance/risk-appetite-statement`, `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: A change to any scale, band or approval level is a major version: it changes every score in the register, so plan a re-scoring and record it in the risk register review log. -->

| 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] |

## Contents

- [1. Purpose and scope](#1-purpose-and-scope)
- [2. Overall risk appetite statement](#2-overall-risk-appetite-statement)
- [3. Appetite and tolerance by risk category](#3-appetite-and-tolerance-by-risk-category)
- [4. Criteria for performing risk assessments](#4-criteria-for-performing-risk-assessments)
- [5. Likelihood scale](#5-likelihood-scale)
- [6. Impact scale: information security properties](#6-impact-scale-information-security-properties)
- [7. Impact scale: business consequences](#7-impact-scale-business-consequences)
- [8. Risk matrix and bands](#8-risk-matrix-and-bands)
- [9. Risk acceptance criteria and approval levels](#9-risk-acceptance-criteria-and-approval-levels)
- [10. Escalation and tolerance breaches](#10-escalation-and-tolerance-breaches)
- [11. Alignment with enterprise risk management](#11-alignment-with-enterprise-risk-management)
- [12. Size tiers](#12-size-tiers)
- [13. Review cadence and change control](#13-review-cadence-and-change-control)
- [14. Records and evidence](#14-records-and-evidence)
- [15. References](#15-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and scope

<!-- Guidance: Say what the criteria apply to and what they do not. An auditor checks that the criteria exist, are approved by someone with authority, and are actually used in the register. -->

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

<!-- Guidance: Write three to six sentences that top management will sign and repeat. Tie the statement to what the organization sells and to what customers and regulators expect. Pitfall: copying a generic statement that does not match how the company really behaves; auditors compare it with actual acceptance decisions. -->

[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

<!-- Guidance: Appetite is the amount of risk you are willing to pursue; tolerance is the acceptable variation around it, written so it can be measured. Use the three appetite levels used in the risk register (Averse, Cautious, Open). Give each category at least one tolerance that a metric or key risk indicator (KRI) can test. -->

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

<!-- Guidance: This is the second half of clause 6.1.2 a and is often forgotten. Answer: when must an assessment happen, at what depth, with whom, with which inputs, and what makes it complete? An auditor checks that a significant change in the last year triggered an assessment. -->

### 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:

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

<!-- Guidance: Give each level a frequency and a qualitative descriptor. Assessors with data use the frequency; others use the descriptor. Pitfall: rating likelihood without considering existing controls, which makes every risk look the same. -->

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

<!-- Guidance: These descriptors help assessors translate a technical event into impact. Use them together with section 7 and take the highest applicable rating. Calibrate the record counts to your data volumes. -->

| 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

<!-- Guidance: Financial thresholds come from finance, not from security. Set them as a share of annual revenue or EBITDA and translate to currency each year. Safety applies only where OT or physical processes exist; delete the column otherwise and say so. -->

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

<!-- Guidance: Bands are set on the score alone (likelihood x impact). Do not add separate rules for likelihood or impact ranges: the two systems disagree at the edges. -->

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

<!-- Guidance: Under clause 6.1.3 f the people who own each risk sign off both the plan and whatever risk is left after it. Name who may accept each band, for how long, and on which conditions. Pitfall: acceptance with no expiry; an auditor will sample old acceptances and ask whether anyone looked again. -->

| 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:

1. 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.
2. No one may accept a risk that would knowingly breach a legal or
   regulatory obligation. Such risks are treated or the activity is
   stopped.
3. Acceptance is never permanent. When an acceptance expires, the risk
   returns to "open" in the register until it is renewed, treated or
   closed.
4. 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

<!-- Guidance: Show what happens when a score or an indicator exceeds tolerance. Keep the flow identical to section 9; an auditor may trace one real escalation from the register through to minutes. -->

```mermaid
flowchart TD
  A["Risk scored or indicator measured"] --> B{"Within category appetite?"}
  B -- "Yes" --> C["Accept at the section 9 level for the band, or treat"]
  C --> H["Record in DOC-ISMS-016"]
  B -- "No" --> D{"Residual band"}
  D -- "Medium (Averse category)" --> E["Escalated one level: top management decides (rule 1)"]
  D -- "High" --> F["Top management decides, treatment plan entry"]
  D -- "Critical" --> G["Escalate within 2 working days, immediate measures"]
  E --> I["Acceptance record DOC-ISMS-019 if accepted"]
  F --> I
  G --> I
  I --> J["Report at next steering committee and management review"]
  H --> J
```

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

<!-- Guidance: If the organization has an enterprise risk framework, the board should see one heat map, not two. Map the ISMS scale to the enterprise scale or adopt it. -->

| 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

<!-- Guidance: The criteria stay structurally the same at every size; what changes is the currency of the thresholds, the number of approval levels and the categories. These rows use the library's fictional settings. -->

| 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

<!-- Guidance: The criteria are reviewed at planned intervals and when the context changes. Changes are versioned and approved; the register is re-scored after any scale change. -->

- 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

<!-- Guidance: List the records that prove the criteria are set, approved and used. Link them in the control evidence matrix (`isms/control-evidence-matrix`). -->

| 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

<!-- Guidance: Cite the editions you used and check for new editions at each review. -->

| 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.