Risk Acceptance Memo Template for Buying AI Controls From an Early-Stage Vendor

What the memo has to decide

A risk acceptance memo records a decision to proceed with a purchase that does not clear a standard threshold. The NIST AI RMF Playbook lists four organizational responses to AI risk: avoid, accept, mitigate or transfer. The memo should state which response applies to each gap rather than treating the whole purchase as a single yes or no.

An early-stage vendor commonly misses criteria such as operating history, financial durability and concentration risk. When approval is granted informally, nothing records the residual risk, the compensating controls, the owner or the conditions for revisiting the decision. The Playbook defines residual risk as the sum of all unmitigated risks and says it should be documented, with accepted risks denoted in the risk response plan.

A control in the AI execution path raises the stakes. If it fails, AI availability and the continuity of audit evidence can both be affected. The memo should therefore be time-bound and evidence-backed, not a procurement formality.

Sections 1 and 2: decision, scope and unmet criteria

Section 1 states the decision in one sentence. Suggested wording: "Approve [vendor] to provide [control function] for [systems, models, agents, business units] under an exception to [policy reference], for a period ending [date]." Then define scope: which environments and data classes are covered, which are excluded, and what the control is allowed to do to an interaction.

Section 2 lists every standard third-party criterion the vendor does not meet. For each, record the response option (accept, mitigate, transfer or avoid) and the reason. Record the risk tolerance that applies and why this acquisition falls inside or outside it. If the purchase deviates from policy, cite the policy and the deviation explicitly.

One published supply chain case study illustrates the logic. A security exception protocol required formal acceptance of risk from the business unit leader whenever the business wanted more vendor risk than the vendor's rating would justify. The exception was a documented approval, not an informal one.

Section 3: vendor-specific risks of an in-path control

Generic vendor risk language is not enough here. Write each of the following as a specific statement with the evidence reviewed.

Failure behavior. State whether the control fails open or fails closed when it is unavailable. Fail-open keeps AI workloads running but lets interactions proceed without enforcement. Fail-closed preserves enforcement but interrupts the business process. The memo should name the chosen behavior, who chose it and what the vendor has demonstrated. Ask how often the vendor performs resilience testing.

Change control. Ask how vendor updates are released and what reassessment happens before they reach your environment. Make an update to the in-path control a reassessment trigger.

Support and key-person dependency. Identify who can respond to an incident, how escalation works and whether your team can operate the control if specific vendor staff become unavailable.

Financial viability and continuity. Record what financial evidence you reviewed and what happens to the deployment if the vendor is acquired, restructured or stops operating.

Evidence continuity. State whether you can still show what the control allowed, redacted or blocked for the full retention period if the vendor relationship ends.

Sections 5 to 7: ownership, review triggers, expiry and approval

Section 5 names one accountable owner on the business side. That person acknowledges the risk and accepts responsibility for adverse impact from the deviation. Security and risk functions advise and challenge, but they should not be the default owner. Also record who is responsible for ongoing management of the control, and how residual risk is disclosed to internal teams that rely on it.

Section 6 sets review triggers. Useful ones include a vendor update to the in-path control, a change in vendor ownership or financial position, an incident or failure event, a change in scope, a lapse in any compensating control, and a re-calibration of your risk tolerance. Set a regular review cadence by policy, since published guidance calls for regular review but gives no fixed interval.

Section 7 sets an expiry date after which the acceptance lapses unless renewed, and defines exit conditions that start the transition plan. Close with the approver block: business owner, risk, security, legal or procurement, and any authority your exception policy requires, each with date and signature.