Risk Management Policy Template: Method, Appetite and Acceptance Authority

Most cyber risk registers fail not because the scoring is wrong but because nobody agreed who may accept a risk, at what level, for how long, and what happens when it breaches appetite. A risk management policy is the document that settles those questions: it gives the method its authority, ties cyber risk to enterprise risk management, sets who owns appetite and tolerance, and defines the acceptance and escalation rules that make a register mean something. This template covers scope, roles, the mandatory process steps, a risk acceptance authority matrix, escalation triggers, reporting, and the points where risk assessment must happen (change, projects, suppliers, new identities and AI systems). The scoring scales and register fields are in the companion Risk Register Template and are not repeated here. It is written for CISOs, chief risk officers, risk and GRC teams and policy owners.

How to use this template

• Replace text in square brackets, such as [Organisation], [Chief Risk Officer] and [12 months], with your own names and values.
• "Must" is mandatory. "Should" is a recommended practice where a documented exception may be justified.
• If [Organisation] has an enterprise risk management (ERM) policy, adopt this as the cyber and information risk policy beneath it and align the terms, scales and acceptance levels with it. Do not create a parallel risk language.
• Set appetite in a separate, board-approved statement that this policy references. See the Cyber Risk Appetite Statement Template.
• Adjust the acceptance matrix in section 6 to your organisation's size. A small company may have only two levels of authority; a regulated group may need business unit and group levels.

1. Purpose

This policy establishes how [Organisation] identifies, assesses, treats, accepts, monitors and reports information security and cyber risk, so that decisions about risk are made consistently, by people with the authority to make them, and within the risk appetite set by [the board].

2. Scope

1. This policy applies to risks to the confidentiality, integrity and availability of [Organisation] information, systems and services, and to the privacy of the individuals whose data [Organisation] processes.
2. It covers all business units, subsidiaries, locations and environments, including cloud, SaaS, operational technology and AI systems, and risks arising from suppliers, partners and other third parties.
3. It covers risks arising from human and non-human identities, including service accounts, API keys, tokens, workload identities and AI agents.
4. It operates within the [Enterprise Risk Management Policy]. Where the two conflict, the ERM policy prevails and [Chief Risk Officer] must be informed.

3. Roles and responsibilities

A risk owner must be a named individual with the authority and budget to treat the risk. A team, a committee or the security function must not be recorded as a risk owner for business risks.

4. Risk appetite and tolerance

1. [The board] must approve a cyber risk appetite statement at least [annually]. It must state, for each [risk category], the level of risk [Organisation] is willing to pursue or retain, and measurable tolerances (for example key risk indicator thresholds) that signal when appetite is being exceeded.
2. Only [the board] may change the appetite statement. [The risk committee] may approve temporary tolerance changes for up to [6 months], reported to [the board].
3. Any risk rated above appetite must have an approved treatment plan or a recorded acceptance under section 6.

5. Risk management process

5.1 Method

1. All cyber risk assessments must use the standard method published in the [Risk Assessment Standard], including its likelihood and impact scales, rating bands and risk statement format. Local methods must not be used for risks entering the register.
2. Impact scales must be expressed in the same business terms as the enterprise risk scales (financial, operational, legal and regulatory, safety, reputation) so that cyber risks can be compared with other enterprise risks.
3. Quantitative methods (for example FAIR) may be used for the top risks or for investment decisions, with results translated into the standard bands for the register. See the FAIR Model and Open FAIR Standard Guide.

5.2 Mandatory steps

1. Identify: risks must be written as a cause, event and consequence, linked to the affected assets or processes and to relevant threats and vulnerabilities.
2. Analyse: inherent risk and residual risk (taking account of existing, evidenced controls) must both be rated.
3. Evaluate: residual risk must be compared with appetite and tolerance.
4. Treat: the risk owner must choose one response: mitigate, avoid, transfer or share, or accept. Mitigation plans must have actions, owners, dates and a target residual rating.
5. Record: every assessed risk must be entered in the [cyber risk register] within [10 business days].
6. Monitor: risks must be reviewed at the frequency set by their rating, and on any trigger in section 7.2.

5.3 Insurance and transfer

1. Transferring risk through insurance or contract does not remove the risk from the register. The residual risk after transfer, including uninsured and excluded loss, must still be recorded and owned.

6. Risk acceptance authority

1. Risk acceptance must be documented with the reason, the residual rating, compensating controls, the expiry date and the acceptor's name, and must be visible to [internal audit].
2. The [CISO] must not accept business risks on behalf of a risk owner, and may record a formal dissent if they consider an acceptance to be outside appetite.
3. Accepted risks expire on their end date. An expired acceptance must be re-approved or the risk treated; it must not roll over automatically.
4. Policy exceptions are treated as risk acceptances and must follow this section.

7. Escalation and reporting

7.1 Reporting

1. The [CISO] must report to [the risk committee] at least [quarterly] on: top cyber risks, risks outside appetite, key risk indicators against tolerance, overdue treatment actions, and acceptances due to expire.
2. Cyber risks rated [High or Critical] must be included in the enterprise risk register maintained by [Chief Risk Officer].

7.2 Escalation triggers and reassessment

A risk must be reassessed, and escalated if its rating rises, when:

1. A security incident or near miss involves the risk or its controls.
2. A key risk indicator breaches its tolerance.
3. A significant new threat or vulnerability affects the assets concerned (for example a vulnerability listed in the CISA Known Exploited Vulnerabilities catalog).
4. An audit, penetration test or control test finds a control failure.
5. The business, technology, regulation or supplier concerned changes materially.

8. When a risk assessment is required

1. New systems, major changes and projects above [threshold] must complete a risk assessment before go-live, approved by the risk owner.
2. New suppliers that will process Confidential data, connect to [Organisation] systems or hold privileged access must be assessed under the [Third-Party Risk Management Policy] before contract signature.
3. New integrations, service accounts with privileged access, and AI agents that can act on production systems or data must be risk assessed, with the assessment recording the identity's permissions, owner and credential type.
4. The enterprise-wide cyber risk assessment must be refreshed at least [annually].

9. Review and approval

Implementation guidance

Where the design choices come from

• One risk language: NIST IR 8286 Rev. 1 (final, December 2025) explains how to feed cybersecurity risk into enterprise risk management through risk registers and why risk measures should roll up from system and organisational levels to the enterprise. Section 5.1 requires impact scales in enterprise terms for that reason.
• Policy, method and appetite: NIST SP 800-53 Rev. 5 control PM-9 Risk Management Strategy calls for an expression of risk tolerance, acceptable risk assessment methodologies, a process for evaluating risk against tolerance and approaches for monitoring risk over time. Sections 4 to 7 correspond to those elements.
• Principles, framework and process: ISO 31000:2018 provides principles, a framework and a process for managing risk and is intended to be embedded in governance, strategy and policy. It is a guideline, not a certifiable standard; ISO lists it as to be revised, so check the current edition before citing clause numbers.
• Acceptance by named owners: ISO/IEC 27001:2022 clause 6.1.3 requires risk owners' approval of the risk treatment plan and acceptance of residual risk, which is why section 6 names the acceptor for each band.

Choosing acceptance levels

Rollout

1. Agree terminology, scales and acceptance levels with [Chief Risk Officer] before drafting the method standard.
2. Obtain board approval of the appetite statement, then of this policy.
3. Migrate existing risks into the register, assign named owners and re-rate them with the standard method. Flag any risk without an owner to [the risk committee].
4. Convert all open policy exceptions into time-limited risk acceptances under section 6.
5. Run the first quarterly report and use the committee's questions to adjust the report format.

Measures

• Ownership: percentage of register entries with a named, current risk owner (target [100%]).
• Appetite position: number of risks outside appetite, and how long each has been outside.
• Treatment delivery: percentage of treatment actions delivered by their due date.
• Expired acceptances: acceptances past their end date without re-approval (target zero).
• Reassessment timeliness: percentage of risks reviewed within the frequency their rating requires.

Failure patterns this policy is written to prevent

• The security team owns everything: when the CISO is recorded as owner of business risks, nobody with budget decides on treatment. Section 3 forbids it.
• Acceptances that never expire: risks accepted years ago, by people who have since left, with the original conditions long gone. Section 6 makes every acceptance time-limited.
• Insurance treated as treatment: buying cover and closing the risk, then finding exclusions after an incident. Section 5.3 keeps the residual risk on the register.
• Unassessed machine access: integrations and service accounts added without assessment become the path of least resistance for attackers. In the Colonial Pipeline ransomware attack, entry came through a dormant VPN account without MFA, the kind of access that section 8 and periodic reassessment are meant to surface.

Framework mapping

Sources for the design choices

• NIST: IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management (ERM)
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: Cybersecurity Framework 2.0
• ISO: ISO 31000:2018 Risk management, Guidelines
• ISO: ISO/IEC 27001:2022 Information security management systems, Requirements

Related NHI Mgmt Group resources: Risk Register Template · Risk Management Guide · Risk Appetite and Tolerance for Cyber Guide · NIST IR 8286 Cybersecurity and ERM Integration Guide · ISO 31000 Risk Management Guide