Principle 9 belongs to the Risk Assessment component, and answers a simple observation: a control system designed against last year’s risks stops fitting when something material changes. Nothing about it is binding. COSO’s Framework is voluntary, carries no penalty, and may be departed from without consequence. Its usefulness here is that it already holds the concept a finance function needs and has not yet applied to the tools it buys.
The 2026 paper’s position is that changes to model architecture, training data, prompts, retrieval connectors, safety filters or integration points can materially alter a system’s risk profile; that risk assessment must track them; and that they should trigger re-evaluation before they affect operations rather than after. It expressly reaches supplier-driven changes, and notes that these may call for notification obligations or independent verification. Read that against the factor in R220.8 on the employing organisation’s oversight of the technology across its lifecycle, and the shape of the duty is clear: judging what verification an output needs is impossible if you do not know the tool changed.
For a finance function the operative word in all of that is "before". You cannot re-evaluate a change you learn about from a variance, and almost nothing about a hosted model is within your gift to detect. So the control is not technical, it is contractual: a term requiring the supplier to notify material changes to the model, the prompt scaffolding, the retrieval sources or the safety filters, with enough notice to test before the change reaches production, and a right to the evaluation results behind it. That term is written at procurement, by people usually negotiating price and uptime, and it is the single most consequential thing a finance function can do about AI risk in a close process. Its absence is what turns a supplier’s routine release into an undisclosed change to internal control — the disclosure problem taken up at deploying an AI tool mid-year.