Cyber Risk Appetite Statement Template: Defining Board-Approved Risk Tolerances

Most boards say they have a low appetite for cyber risk, but few have written down what that means in numbers a security team can measure and escalate against. NIST CSF 2.0 subcategory GV.RM-02 expects risk appetite and risk tolerance statements to be established, communicated and maintained, and the UK Cyber Governance Code of Practice (April 2025) asks boards to define and clearly communicate their cyber security risk appetite (action A.3) and to agree tolerances for the metrics they receive (action E.2). This template gives you a board-level appetite statement, category statements with measurable tolerances, escalation rules and a review cycle, including categories for non-human identities (NHIs) and AI agents. It is written for CISOs, chief risk officers, company secretaries and board members preparing a first statement or replacing one that nobody uses.

How to use this template

• Replace text in square brackets, such as [Organisation], [Board risk committee] and [X%], with your own terms and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a justified exception may apply.
• All example appetite levels and tolerance values in section 4 are illustrative. Set your own from your risk register, business impact analysis and, where available, quantified loss estimates.
• Write appetite in words the board can debate and tolerance in numbers the security team can measure. NIST IR 8286 Rev. 1 describes tolerance as narrower and more specific than the appetite it supports, with clear, measurable boundaries where possible.
• Align the categories with your enterprise risk management (ERM) taxonomy so cyber risk rolls up into the enterprise risk profile rather than sitting in a separate report.
• Have the statement approved by the board or its delegated committee, not by the CISO. A statement the security team writes and approves for itself is a target, not an appetite.

1. Purpose

This statement sets out the amount and type of cyber risk [Organisation] is willing to accept in pursuit of its objectives (risk appetite) and the measurable limits within which management must operate (risk tolerances). Its aims are to:

• Give management clear direction on how much cyber risk may be taken, and where risk must be reduced, transferred or avoided.
• Provide the basis for prioritising security investment, accepting exceptions and approving new technology, suppliers and AI use.
• Define the key risk indicators (KRIs) and thresholds that trigger escalation to [Executive risk committee] and the [Board risk committee].
• Support the board's oversight duties, including its annual review of the risk management and internal controls framework and, where applicable, its disclosures on cyber risk governance.

2. Scope

This statement applies to cyber and information security risk across [Organisation] and its subsidiaries, including:

• All information systems, cloud services, operational technology and data owned, operated or processed by or for [Organisation].
• Human identities and non-human identities, including service accounts, workload identities, API keys, tokens, certificates and AI agents.
• Risk introduced by suppliers, managed service providers, SaaS applications and their integrations.
• New products, acquisitions and technology changes, which must be assessed against this statement before approval.

It does not replace [Organisation]'s enterprise risk appetite statement; it refines the [operational / technology] risk appetite for cyber risk and must be read alongside it.

3. Roles and responsibilities

For how these roles fit together, see the Three Lines Model for Cyber Risk Guide.

4. Policy statements

4.1 Overall cyber risk appetite

[Organisation] has a [low / moderate] appetite for cyber risk. It will take measured cyber risk to adopt new technology, including cloud services and AI, where doing so supports [strategic objective] and the residual risk stays within the tolerances below. It has a minimal appetite for risks that could cause harm to customers, loss of [regulated / personal] data, extended disruption of [critical services], or a breach of legal and regulatory obligations.

4.2 Appetite scale

4.3 Category appetite and tolerances (illustrative)

4.4 Tolerance zones and escalation

1. Each KRI must have a green (within appetite), amber (approaching tolerance) and red (tolerance breached) threshold. The amber threshold should give enough warning to act before a breach.
2. Amber KRIs must be reported to [Executive risk committee] with an action plan at its next meeting.
3. A red KRI must be reported to the [Chief Risk Officer] within [5] business days and to the [Board risk committee] at its next meeting, or within [X] days for categories rated Averse.
4. Every breach report must state the cause, the residual risk, the remediation plan and date, and whether the tolerance itself remains appropriate.
5. A tolerance must not be changed to close a breach without [Board risk committee] approval.

4.5 Use in decision making

1. Business cases for new systems, suppliers, products and AI deployments must state which categories they affect and whether residual risk stays within tolerance.
2. Risk acceptance decisions must be taken at the authority level shown in section 4.2 for the category's appetite.
3. Security investment must be prioritised towards categories that are amber or red, or forecast to become so.
4. Risk ratings in the [risk register] must use the same categories and scales as this statement.

5. Exceptions

Where a risk owner cannot meet a tolerance, they must request an exception stating the reason, the residual risk, compensating controls and an expiry date of no more than [12] months. Exceptions are approved at the authority level in section 4.2, recorded in [exception register], reported in aggregate to [Executive risk committee] each quarter, and reviewed before expiry. An exception does not change the tolerance. See the Security Exceptions and Risk Acceptance Guide.

6. Compliance and monitoring

• Reporting cadence: KRIs reported monthly to [Executive risk committee] and at least quarterly to the [Board risk committee], consistent with action E.2 of the Cyber Governance Code of Practice.
• Data quality: each KRI has a defined data source, owner, calculation and refresh date; manual KRIs must be evidenced.
• Independent assurance: [Internal audit] tests a sample of KRIs and breach escalations at least [annually].
• Measures of the statement itself: percentage of categories with measurable tolerances; percentage of KRIs fed automatically; number of tolerance breaches escalated late; number of business decisions referencing the statement; time from red KRI to approved remediation plan.

7. Review and approval

This statement is owned by [Chief Information Security Officer] jointly with [Chief Risk Officer], recommended by [Board risk committee] and approved by [Board of directors]. It must be reviewed at least annually, and sooner after a material incident, a significant change in strategy, an acquisition, a change in regulation or a material change in the threat environment.

Implementation guidance

Building the first statement

1. Start from the enterprise appetite. Read the existing ERM appetite statement and use its scale and wording. NIST IR 8286 Rev. 1 describes appetite and tolerance being set by senior leadership and then interpreted by receiving disciplines such as cybersecurity down to system level.
2. Pick 8 to 12 categories. Use your risk register and business impact analysis to choose categories that matter to the business, not one per control family. Include NHIs and AI agents explicitly if your identity estate is dominated by machine credentials.
3. Run a facilitated workshop. Ask executives to rank scenarios, for example a two-day outage of [critical service] or a leaked cloud key, and agree the appetite level per category. Quantified estimates help; see the Cyber Risk Quantification Guide.
4. Translate into tolerances. For each category choose one to three KRIs you can already measure, set green, amber and red thresholds, and record the data source.
5. Baseline before approval. Measure current values for three months. If most KRIs are red on day one, either the tolerances are unrealistic or the board needs to see that it is outside appetite and fund remediation. Both are useful outcomes; hiding them is not.
6. Approve and communicate. Take the statement through committee to the board, then publish it to risk owners, procurement, architecture and change boards.
7. Embed and report. Add KRIs to the board pack and reference the statement in exception, procurement and project approval forms. See the Board Cyber Risk Reporting Guide.
8. Review and adjust. After the first full year, retire KRIs that never move and tighten tolerances as controls mature. If the statement causes a bad decision, revert to the previous approved version while the change is reviewed.

Small and large organisations

• Smaller organisations: use one overall statement plus five or six categories, qualitative appetite levels and KRIs that come from existing tools. The board itself can approve tolerances.
• Larger and regulated organisations: cascade group appetite to business units, set tolerances by legal entity where regulators expect it, quantify loss scenarios and automate KRI feeds from the GRC platform.

Common failure patterns

• "Zero appetite" for everything: it cannot be met, so it is ignored. Reserve Averse for a few categories and accept measured risk elsewhere.
• Appetite without tolerance: words like "low" give no escalation trigger. GV.RM-02 example guidance calls for translating appetite into specific, measurable tolerance statements.
• KRIs that are really activity counts: "phishing emails blocked" says nothing about exposure. Prefer coverage, age and time-to-fix measures.
• Machine identities left out: statements cover users and patching but not service accounts, keys and agents, which are often the larger attack surface. See the NHI Risk Scoring Guide.
• Quietly moving thresholds: raising a tolerance to make a red KRI green removes the board's oversight. Section 4.4 rule 5 prevents this.

Mapping to frameworks and governance requirements

Notes on the regulatory hooks: for companies reporting against the UK Corporate Governance Code, Provision 29 of the 2024 UK Corporate Governance Code applies to financial years beginning on or after 1 January 2026 and asks the board to review the effectiveness of the risk management and internal controls framework and declare on the effectiveness of material internal controls; a cyber appetite statement with tolerances gives that review a measurable basis. US registrants describe board oversight and management's role for cybersecurity risk under SEC Regulation S-K Item 106(c), required in annual reports for fiscal years ending on or after 15 December 2023. Neither requires a document in this exact form.

Standards and references

• NIST: Cybersecurity Framework 2.0
• NIST: IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management
• NIST: SP 800-53 Rev. 5
• UK Government: Cyber Governance Code of Practice
• NCSC: Board Toolkit
• FRC: UK Corporate Governance Code 2024
• eCFR: 17 CFR 229.106 (Regulation S-K Item 106) Cybersecurity

This template is provided for guidance and must be adapted to your organisation. It summarises governance requirements and is not legal advice. Related NHI Mgmt Group resources: Cyber Risk Quantification Guide · Board Cyber Risk Reporting Guide · Security Policy Framework Guide · Risk Register Template · Regulatory Change Management Guide