Templates for an AI risk management policy are easy to find and mostly worthless, because the parts that can be templated are the parts that do not matter. Scope paragraphs, definitions, a review clause and a sentence about commitment to responsible innovation can all be copied into any AI risk management policy. None of it survives contact with an auditor.
AI risk management policies get tested on something narrower and harder. Every instrument in AI risk management requires an organisation to state what level of risk it will accept, and not one of them tells you what that level is. The NIST framework says so outright: it can be used to prioritise risk, and “it does not prescribe risk tolerance”. ISO/IEC 42001 requires documented acceptance criteria without supplying them. Article 9 of the EU AI Act requires residual risk to be judged acceptable without defining acceptable.
A risk management policy is better approached as a short series of blanks that only your organisation can fill, surrounded by boilerplate that does not matter. Eight blanks, below, each with the instrument that forces it and the failure that follows from leaving it as prose. Teams that have not yet built the per-system record this policy governs should start with the assessment template and its fields.
Article 9 Defers, ISO 42001 Does Not, and Colorado Repealed Its Version
Timing explains why so many of these policies were written in 2025 and quietly shelved.
Article 9 of the EU AI Act requires a risk management system to be established, implemented, documented and maintained for high-risk systems, run as a continuous iterative process across the entire lifecycle. The obligation is substantial, and it does not apply until 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Nothing in the Digital Omnibus amended Article 9 itself; only its commencement moved.
Colorado went further in the other direction. The state’s original statute required deployers to operate a risk management programme and produce annual impact assessments. Senate Bill 26-189 repealed and reenacted the law in May 2026 and removed both. Any AI risk management policy still citing Colorado as the reason for its risk programme cites a repealed provision.
ISO/IEC 42001 is the instrument actually biting today, because certification is voluntary until a customer or a tender makes it mandatory, at which point Clause 6.1 is assessed immediately rather than in 2027. Clause 6.1.2 requires an AI risk assessment process that applies documented risk acceptance criteria and produces consistent, valid and comparable results. Clause 6.1.3 requires a documented risk treatment plan, approved by the risk owners.
AI risk management today runs in reverse of the usual order. A risk management policy written now is driven by the standard rather than by the statute, and the statute arrives later with heavier requirements that the standard largely anticipates. Drafting to ISO now and mapping to Article 9 later costs less than the reverse, which is the argument for a control crosswalk rather than one policy per regime.
Blank One: The Scope Line That Decides What the Policy Governs
Scope is the blank most often filled with something that cannot be applied.
A risk management policy covering “all artificial intelligence used by the organisation” sounds complete and decides nothing, because the first question anyone asks is whether a spreadsheet macro, a vendor feature flag or an embedded recommendation engine is in. Scope has to be written so that a person holding a system description can reach a yes or no without escalating.
Three tests make a risk management policy scope applicable. Name the trigger for inclusion in terms of what the system does rather than how it is built, since capability definitions sweep in everything. Name the decision types that bring a system into the highest tier, because decision type eliminates faster than technology. Name the exclusions explicitly, and record the reasoning, since out of scope is a position that gets defended rather than a gap that gets forgiven.
A risk management policy that cannot be applied by someone who did not write it will be applied inconsistently, and Clause 6.1.2 asks precisely for consistent, valid and comparable results. The system register is where that scope line gets tested against reality.
Blank Two: Risk Acceptance Criteria, Written as a Threshold Rather Than a Sentiment
AI risk management policies fail this blank more than any other, usually by describing a process for deciding acceptability instead of stating what is acceptable.
ISO/IEC 42001 Clause 6.1.2 requires an AI risk assessment process that applies documented risk acceptance criteria and produces consistent, valid and comparable results over time. Each risk’s level is compared against those criteria to decide what is accepted and what goes to treatment. Documented risk acceptance criteria are what make two assessors reach the same conclusion about the same system, which is what comparable over time actually means. Without risk acceptance criteria, the assessment process produces opinions that happen to be recorded on a form.
Risk acceptance criteria worth having commit to specifics the organisation can defend. Which combinations of likelihood and consequence are accepted without escalation, which require treatment before deployment, and which are refused. Whether acceptance differs by decision type, so that a system touching employment or credit faces a lower acceptance ceiling than an internal productivity tool. Who may accept a risk at each level, by role rather than by name.
One warning from the NIST framework belongs here. Attempting to eliminate negative risk entirely “can be counterproductive in practice”, so a risk management policy whose acceptance criteria amount to accepting nothing will either be ignored or will stop work that should proceed. Risk acceptance criteria have to be achievable or they are decorative.
Blank Three: Who Judges Residual Risk Acceptable, Hazard by Hazard and Overall
Article 9(5) sets a requirement most policies miss on a technicality. Residual risk must be judged acceptable for each individual hazard and for the system overall. Two separate judgments, and a risk management policy naming only an overall sign-off has not provided for the first.
Clause 6.1.3 adds the mechanics on the treatment side. Controls selected for each risk are compared against the Annex A reference set, any Annex A control left out has to be justified, and the result is recorded in a Statement of Applicability. The risk treatment plan is then approved by the risk owners, and that approval carries acceptance of the residual risk with it. Approval and acceptance are a single act, which is why the signature matters more than the document.
A risk management policy worth the name states the role that signs the per-hazard judgment, the role that signs the overall judgment, and the condition under which those must be different people. Separating them matters because the overall judgment is where optimism aggregates: eight individually acceptable hazards can combine into a system nobody would approve if asked about it directly. Both signatures belong in the evidence an internal audit team will sample.
Blank Four: The Metrics and Probabilistic Thresholds Testing Runs Against
Article 9 is unusually prescriptive about numbers, and the wording is worth reading closely. Testing must happen during development as appropriate and, in any event, before placing on the market or putting into service, and it must be conducted against “prior defined metrics and probabilistic thresholds” appropriate to the intended purpose.
Prior defined is the operative phrase. A threshold selected after seeing the results is not a threshold. A risk management policy is the document that forces the metric and the number to be set before the test runs, and it should say who sets them, when they are fixed relative to the test, and what happens when a system misses.
Consequence of failure is the part teams avoid. An AI risk management policy mandating testing without stating the consequence of failure leaves the decision to whoever is under deadline pressure. Naming the consequence, whether remediation and retest, deployment with restrictions, or no deployment, converts a measurement into a control. The same logic governs the evidence a model has to produce before release.
Blank Five: A Named Owner, a Date and a Budget for Every Treatment
AI risk management quietly becomes uncollectable at ownership.
Clause 6.1.3 requires the risk treatment plan to set out what will be done, by whom, with what resources and on what timeline. Four fields, and most registers hold one of them. A treatment with an owner but no date never completes. A treatment with a date but no resources gets reprioritised. A treatment with neither is a note, and an unapproved plan is not a plan at all.
The risk management policy’s job is to make those fields mandatory at the point a risk is accepted into treatment rather than optional at review time. The clause should also name who can change a date, because a deadline that any owner may move is not a deadline. The risk register build is where this becomes an operational constraint rather than a sentence.
Blank Six: The Events That Force a Reassessment
Periodic review is the default and the weakest possible answer, because risk does not change annually.
Article 9(2) requires the process to be subject to regular systematic review and updating, with each step repeated as the system changes. Regular and systematic is the floor, not the design. Three trigger categories are worth naming above it: a change to the system, a change to its deployment context, and a change to the regulatory environment. The third is the one nobody instruments, and 2026 supplied two examples, since any organisation relying on Colorado’s repealed programme or on the federal selection guidelines now being rescinded needed to reopen assessments without any system having changed.
Article 9(2)(c) adds a fourth route by requiring evaluation of other risks possibly arising from post-market monitoring data. Monitoring findings are therefore an input to assessment rather than a parallel activity, which means the risk management policy has to say how a monitoring observation becomes a reopened risk entry. Teams running that loop should read it alongside the post-market monitoring obligations.
A filled version of this blank names the triggers, the person responsible for noticing each one, and the window within which reassessment must start. Noticing is the part that needs an owner, because a regulatory change nobody is watching for produces no trigger at all.
Blank Seven: The Condition Under Which the Organisation Does Not Deploy
Most AI risk management policies contain no stop condition, which makes every other clause of the risk management policy advisory.
The NIST framework is direct about this. Where an AI system presents unacceptable negative risk levels, development and deployment should stop in a safe manner until risks can be sufficiently managed, with examples including imminent significant negative impacts, severe harms actually occurring, and catastrophic risk. The framework declines to set a numeric threshold, which returns the question to the policy.
A risk management policy fills this blank with three things. A description of the condition in terms the organisation can observe. The role with authority to halt, which should sit outside the delivery line. And the escalation route for overriding a halt, including who may do it and what gets recorded, because an unoverridable stop will be bypassed informally rather than invoked formally.
Prioritisation guidance from the same framework is worth encoding alongside it. Systems that interact directly with people, process sensitive personal data, or have direct or indirect impacts on individuals warrant higher initial prioritisation, which gives a defensible basis for the tiering the acceptance criteria rely on.
Blank Eight: The Groups Whose Exposure You Assess Separately
Article 9(9) requires providers to consider whether a high-risk system is likely to have an adverse impact on persons under the age of 18 and, as appropriate, other vulnerable groups. Few policies name any group at all.
The blank asks for two things. A list of the groups the organisation assesses separately, which will vary by sector and should be derived from who the systems actually touch rather than copied. And the method, since considering impact on a group is not the same as measuring it, and a policy that requires consideration without specifying evidence will generate a sentence rather than a finding.
Keeping this blank narrow and real beats a long list nobody applies. Where the exposure is differential outcomes rather than safety, detection and mitigation methods supply the evidence the assessment needs. Two or three named groups with a defined assessment method produces usable evidence. Ten groups with no method produces a paragraph.
| Blank | Instrument that forces it | What it looks like unfilled |
| Scope line | ISO/IEC 42001 Clause 6.1.2, consistent and comparable results | “All AI used by the organisation” |
| Risk acceptance criteria | ISO/IEC 42001 Clause 6.1.2, documented acceptance criteria | A process for deciding acceptability |
| Residual risk judgment | EU AI Act Article 9(5), per hazard and overall | One overall sign-off |
| Metrics and thresholds | EU AI Act Article 9(6) to (8), prior defined | “Appropriate testing will be performed” |
| Owner, date, resources, approval | ISO/IEC 42001 Clause 6.1.3 | A risk owner and nothing else |
| Reassessment triggers | EU AI Act Article 9(2) and 9(2)(c) | Annual review |
| Stop condition | NIST AI RMF, cease on unacceptable risk | No stop condition at all |
| Vulnerable groups | EU AI Act Article 9(9) | No group named |
What a Finished AI Risk Management Policy Has to Survive
Three tests tell you whether the blanks are genuinely filled, and all three can be run before an auditor does.
Hand the policy to someone who did not write it, with a real system description, and ask them to reach a scope decision and an acceptance decision. Disagreement between two readers is not a training problem. Disagreement is the policy failing Clause 6.1.2’s requirement for consistent, valid and comparable results.
Take a system approved eighteen months ago and reconstruct why its residual risk was judged acceptable. If the answer depends on remembering who was in the room, the per-hazard judgment was never recorded separately from the overall one.
Pick a regulatory change from this year and trace whether it triggered anything. Colorado’s repeal and the federal rescission of the selection guidelines both landed in 2026, and an organisation whose risk register shows no entry from either has a reassessment trigger that exists only on paper.
AI risk management lives or dies on whether those answers are retrievable against a named system on a named date. Risk management policy text is cheap, and the register behind it is the expensive part, which is why govern365.ai holds the acceptance criteria, the per-hazard judgment, the treatment owner and the trigger history against the system record rather than in a document nobody opens between audits. Organisations running this across several frameworks can see how govern365.ai operationalises the workflow from assessment through approval.
Two further pieces complete the set. The governing document above this one is the AI governance policy, which allocates authority that this policy then exercises, and the classification question that determines whether Article 9 applies at all is handled in the high-risk classification guide. Where the board needs a view of the output rather than the process, risk reporting at board level is a different document with a different audience, and the platform view is what keeps the two consistent.
Questions About the AI Risk Management Policy
Is an AI Risk Management Policy Legally Required?
Not as a named document. Article 9 of the EU AI Act requires a risk management system for high-risk systems to be established, implemented, documented and maintained, which in practice needs a policy, and that obligation applies from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. ISO/IEC 42001 requires documented risk criteria and a documented treatment plan for certification. Colorado required a risk management programme until Senate Bill 26-189 repealed it in May 2026.
What Is the Difference Between a Risk Management Policy and a Risk Assessment Template?
A risk management policy is the governing document that states what level of risk the organisation accepts, who may accept it, what forces reassessment and when the organisation stops. The assessment template is the per-system record produced by applying that policy. One sets the criteria, the other applies them, and an assessment process without documented criteria produces results that cannot be compared across assessors.
What Should Risk Acceptance Criteria Actually Say?
Risk acceptance criteria should state which combinations of likelihood and consequence are accepted without escalation, which require treatment before deployment and which are refused, together with the role permitted to accept at each level. ISO/IEC 42001 Clause 6.1.2 requires acceptance criteria to be documented and to produce consistent, valid and comparable results, which a description of the decision process does not achieve on its own.
Does the EU AI Act Say What Level of Residual Risk Is Acceptable?
No. Article 9(5) requires residual risk to be judged acceptable for each individual hazard and for the system as a whole, without defining the level. The judgment is the organisation’s to make and defend, which is why the threshold belongs in the policy rather than in the assessment of any single system.
What Are Prior Defined Metrics and Probabilistic Thresholds?
Article 9 requires testing against metrics and probabilistic thresholds appropriate to the intended purpose, defined before the test rather than after it. A threshold chosen once results are known is not a threshold. The policy should say who sets the metric and the number, at what point they are fixed, and what happens when a system fails to meet them.
Does NIST Set a Risk Tolerance?
No. The AI RMF states that it can be used to prioritise risk but does not prescribe risk tolerance, which it treats as highly contextual and shaped by legal requirements and by policies set by system owners, organisations, industries and policy makers. Where no sector or regulatory guidance exists, the framework says organisations should define reasonable risk tolerance themselves.
How Often Should the Policy Trigger a Reassessment?
Periodic review alone is insufficient. Article 9(2) requires regular systematic review and updating, with each step repeated as the system changes, and Article 9(2)(c) requires evaluation of other risks possibly arising from post-market monitoring data. Beyond that floor, a policy should name three triggers: a change to the system, a change to its deployment context and a change to the regulatory environment. The policy should name each trigger, the person responsible for noticing it and the window for starting the reassessment.
Should the Policy Include a Condition for Not Deploying?
Yes, and most do not. The NIST framework states that development and deployment should stop where an AI system presents unacceptable negative risk levels, in a safe manner until risks can be sufficiently managed. Without a stop condition, a named halting authority outside the delivery line and a recorded override route, every other clause in the policy is advisory.
