A control framework with no decision point at the end of it isn’t governance.
ISO 42001 doesn’t use the word “approval” as prominently as it uses “risk assessment” or “control,” but the standard’s leadership and operational planning clauses (5 and 8) presuppose that someone, at some defined point, makes an accountable decision about whether an AI system proceeds into development, into deployment, or into continued operation after a material change. Organizations that skip building an explicit approval mechanism end up with governance that looks complete on paper and has no actual decision-making teeth.
Identifying your approval trigger points
Before designing an approval framework, get specific about what actually requires a decision. In most organizations, the meaningful trigger points are: a new AI use case entering development, a system moving from development/pilot to production, a material change to an existing system (model update, new data source, expanded user population, new deployment context), and periodic reauthorization of systems that remain in production over time.
Organizations frequently build robust approval processes for the first trigger (new use case intake) and nothing for the other three. This is understandable, because intake is the most visible moment and the easiest to build a form around. It’s also why so many governance programs have excellent records for how a system started and no record at all of the changes that took it somewhere the original approval never contemplated.
Risk-based approval paths, not one-size-fits-all sign-off
Not every approval decision needs the same rigor or the same decision-maker. A workable approach ties the approval path directly to the risk level established in the Assess stage:
- Low-risk systems: standard approval, potentially delegated to a designated governance role rather than requiring committee review, with lightweight documentation
- Medium-risk systems: committee review with defined membership, documented rationale, and specific conditions attached to approval (e.g., “approved contingent on monitoring cadence X”)
- High-risk systems: escalation to senior leadership or a dedicated AI governance board, with more extensive documentation and often a defined reassessment interval as a condition of approval
The point of tiering is to concentrate the organization’s limited high-attention governance bandwidth on the decisions that actually warrant it, rather than spreading thin oversight evenly across everything and effectively under-scrutinizing the systems that need the most.
What an approval record actually needs to contain
The single biggest documentation gap in approval processes: recording that something was approved, without recording why. An approval record that will hold up under audit scrutiny needs: the risk assessment it relied on (and its date, since risk assessments age), the specific controls verified as implemented at the time of approval, any conditions attached to the approval, the identity and authority of the approver, and the date the approval expires or is due for reassessment.
That last element deters a specific failure mode: approvals that are technically still “valid” three years after a system has changed beyond recognition, because nobody defined an expiration or trigger for re-review. An approval without a review horizon is really a permanent exemption from governance wearing an approval’s clothing.
The feedback loop that most programs skip
Approval decisions should feed back into risk assessment practice, not just proceed from it. If a committee routinely approves systems with conditions, that’s a signal the standard risk criteria may be miscalibrated — either too conservative (generating unnecessary friction) or the conditions attached are a workaround for a control gap that should be fixed structurally rather than patched per-approval. Programs that treat approval as a one-way output of assessment, rather than a source of signal back into it, miss an easy opportunity to improve their own process.
Decision authority: who can actually say no
An approval framework only has teeth if the approving role has genuine authority to decline or condition approval. This sounds obvious and is nonetheless the single most common structural failure in governance programs: an approval committee exists on paper, has never actually declined anything, and everyone involved privately understands that it functions as a formality. If that’s the honest current state of your approval process, it’s worth naming directly, because an auditor evaluating operating effectiveness (not just design) will eventually notice a 100% approval rate and ask exactly this question.
An accountable decision, once made, is only as good as your ability to confirm later that the conditions underlying it still hold. That’s the final stage, and it’s the one certification programs most often under-resource.
Put these ideas to work.
Schedule a 30-minute walkthrough with our team.