Clearance vs approval — why the distinction matters for AI governance

The conflation is rarely deliberate. It accumulates. The AI Committee is set up. Its remit is described as “to approve AI systems before they go into production”. The CISO sits on the committee. The CTO sits on the committee. The DPO sits on the committee. They review a system, ask reasonable questions, and the committee votes to approve. The minute records “the committee approved the system on date X”.

What just happened in that minute is two distinct decisions being recorded as one. The CISO and the Security Architect made a clearance decision — the system's residual risk is consistent with what the organisation considers acceptable, given the controls in place. The CTO and the Business Owner made a business approval decision — the system is worth building or buying given strategic priorities, budget, and risk appetite. Those are different decisions with different evidence bases. The minute records neither cleanly, which means neither can be defended cleanly later.

The reason this matters is not vocabulary pedantry. It is that the two decisions answer questions from two different sets of stakeholders, on two different timelines, with two different consequences when they go wrong. When they are conflated, the wrong people end up accountable for the wrong things.

A security clearance is a structured decision made against an evidence pack that captures the system's threat profile, the controls that mitigate those threats, the residual risk, the gaps in evidence, and the triggers that would invalidate the decision. It is one of five states — not a binary “yes/no”.

The five-state model exists because real AI systems do not fit a binary. The states are:

• Proceed. Cleared for the lifecycle gate requested. Controls in place, residual risk acceptable, triggers registered.
• Conditional. Cleared subject to specific conditions, each of which is itself an artefact with an owner and a date.
• Restricted pilot only. Cleared to operate inside a stated boundary — a user group, a data class, a workflow. The path to full production is itself a list of conditions.
• Hold. Not cleared yet. Specific gaps must be closed before the clearance question can be re-opened. Materially different from “decline” — the door is open.
• Decline. The system as designed cannot be cleared. The threat profile and the available controls do not converge on an acceptable residual risk. A redesign is required, not more evidence.

Each state carries a set of mandated controls and a set of registered triggers. The clearance is not a permission slip; it is a structured contract between the system's owners and the organisation about the conditions under which the system may operate, and the events that force a re-review.

Crucially, a clearance does not answer the question “is this a good idea”. It answers the question “can this be operated safely given what we know about its threat profile and the controls available”. A system can be cleared and still be a terrible business idea. The clearance does not address that, and pretending it does is the first step toward the conflation.

A business approval is a portfolio decision. It answers a different set of questions: does this system serve the business strategy, does it fit the budget and the headcount, does the projected ROI justify the operating cost, is it consistent with the organisation's declared risk appetite, and is there an executive sponsor willing to own the outcome.

Approval is not the inverse of clearance. The two decisions overlap on exactly one input — risk — and even there they overlap differently. Clearance asks: is the residual risk consistent with our security risk appetite for systems of this class? Approval asks: is the residual risk consistent with our business risk appetite for this initiative, given what we expect to gain? Different question, different evidence, different signatory.

The evidence base for approval is also different. It is the business case, the ROI model, the strategic alignment memo, the headcount plan, and the integration roadmap. None of those are in the clearance evidence pack, and none of them should be — the clearance pack would be unreadable if you tried.

Approval is not the other half of clearance. It is a separate decision that happens to need clearance as one of its inputs. A system can be cleared and not approved. It can also be approved and not cleared — which is the failure mode that ships systems into production with a sign-off nobody can defend.

When clearance and approval are conflated, four recognisable failure modes appear. Each one has its own audit trail (or lack of one) and each one is expensive to unwind after the fact.

• Approved but not cleared.The system has executive sponsorship, budget, and a named business owner. It ships. There is no structured security review record — no threat register, no control plan, no evidence pack. When a customer's procurement reviewer asks for the security review, the answer is the business case or a SOC 2 report from the underlying platform. Neither answers the question. The organisation is now in the position of producing a clearance retroactively, against a system already in production, which is harder than producing one before the system shipped.
• Cleared but not approved.The Security Architect, AI Governance, and DPO have signed off on the system. The clearance is sound. But the business has never explicitly authorised the system to operate as part of a product line, allocated headcount to maintain it, or named a sponsor to own its outcome. The system runs in production but has no business owner of record. When something needs a budget decision, an integration choice, or a strategic pivot, nobody owns it. This failure mode is quieter than the first one and tends to surface during a portfolio review, an organisation change, or an incident, where the question “whose system is this” has no clean answer.
• Clearance owner equals approval owner.The CISO is asked to sign off on both the security clearance and the business decision because the AI Committee is structured to produce one signature per system. The CISO becomes the bottleneck for business decisions they should not be making, and the accountability for business outcomes attaches to a role that has no operational authority over them. When the system underperforms commercially, the security function is somehow part of the conversation. When the system has a security incident, the business owner can credibly claim “security signed off”. Both consequences are bad, and both are produced by the same structural defect.
• Clearance treated as binary.“Approved” or “not approved”. No restricted pilot state, no conditional state, no hold state. The committee's only available decisions are “all of this” or “none of this”, which produces a recognisable pattern: low-risk systems get cleared too easily because the alternative is to block them entirely, and high-risk systems get blocked even when a tightly scoped restricted pilot would have been the right call. The binary framing collapses the nuance the actual systems require, and that nuance is what makes clearance a useful artefact in the first place.

Each of these is a structural problem, not an execution problem. You cannot fix them by being more rigorous in the meeting. You fix them by separating the two decisions, naming the owners of each, and producing two artefacts where today there is one minute paragraph.

The clean split is straightforward to describe and harder to install, because it usually requires unwinding an existing committee structure. Once you accept that clearance and approval are different decisions, the roles that own each become clearer than they were under the unified model.

Clearance authoritysits with CISO, AI Governance lead, Security Architecture, and DPO. These roles are accountable for whether the system's threat profile and controls produce an acceptable residual risk for the organisation. They do not own the business outcome. They own the security review record. If the residual risk is not acceptable, they issue a hold or a decline. If it is acceptable subject to specified controls, they issue a conditional or restricted pilot clearance. The decision is theirs; the artefact is the disposition memo.

Approval authoritysits with the CTO, the Business Owner, and — for material systems — the Executive Team. These roles are accountable for whether the system is the right thing to build or buy, whether the business case justifies the operating cost, and whether the strategic fit holds. They are not asked “is the residual security risk acceptable”. They are asked “given that residual risk, given the cost, given the strategy, is this the right move”.

The AI Committee, in the cleanly split model, is a forum where both sets of roles are present. But the two decisions are surfaced separately on the agenda, recorded separately in the minutes, signed separately in the sign-off log, and produce two distinct artefacts. The committee is the venue; the artefacts are what travel afterwards.

The operational difference between conflated and separated decisions is visible in the artefacts that leave the meeting. In the conflated model, the output is a meeting minute and (sometimes) a slide marked “approved” with a date. In the separated model, the output is two distinct documents.

The clearance artefact is a dated, scoped, signed dispositional memo. It names the system, the clearance state, the rationale, the controls in place, the residual risk acceptance with a named acceptor, and the re-assessment triggers. It is signed by the clearance-authority roles. It is filed with the AI Governance function and is the artefact that gets handed to internal audit, regulators, and procurement reviewers on request.

The approval artefact is a business decision record. It names the system, the business case, the budget allocation, the named business owner, and the portfolio category. It is signed by the approval-authority roles. It is filed with the business unit and is the artefact that informs portfolio review, headcount planning, and product roadmap discussions.

Both artefacts reference each other. The approval record says “subject to clearance dated X by AI Governance”. The clearance memo names the business sponsor and the named system owner of record. Neither artefact stands alone; both reference the other, and the reference is the audit trail.

When the model is swapped six months later, the operational split is what makes the next step obvious. A new model invalidates the clearance — the re-assessment trigger fires, AI Governance re-opens the disposition, and the new clearance is signed. The approval record does not need to be reissued unless the business case has changed, in which case it goes through a portfolio review. Each artefact has its own lifecycle.

The cleanest test of whether your organisation has separated clearance from approval is the answer you give to two different questions, asked by two different external parties.

When a regulator or an internal auditor asks “was this system reviewed before it went into production”, the answer should be the clearance memo. Not a slide deck. Not a meeting minute. Not a business case. A dated, scoped, signed disposition with a threat register, a control plan, an evidence pack, a residual risk acceptance, and a re-assessment trigger register attached to it.

When the AI Committee or the executive team asks “should we ship this”, the answer should be the business approval record. Strategic alignment, budget allocation, business owner, sponsor. The clearance memo is an input, not the answer.

Two different questions, two different answers, two different artefacts, two different sets of signatories. When the artefacts collapse into one, each question gets answered with material that does not actually address it. Regulators reading a business case will note the absence of a threat register. Executives reading a clearance memo will note the absence of a business case. Each party correctly identifies that what they are looking at is not what they asked for, and the organisation's answer to the next question becomes “we're producing that now” — which is the answer that surfaces governance debt that the conflated model has hidden.

Two different questions, two different artefacts, two different signatories. Get the split right and the rest of the governance posture follows. Get it wrong and every audit cycle is a scramble.

The most immediate change, when an organisation separates clearance from approval, is that the security function stops being asked to make business calls. The Security Architect's answer to “should we build this” becomes “here is the residual risk profile and the controls available; the business call is yours”. They stop being the bottleneck for product decisions, and the product organisation stops being able to claim that the security function blocked anything other than systems that genuinely couldn't be cleared.

The second change is that business owners stop being able to hide risk decisions behind “the security team signed off”. If the business decision is signed by the CTO and the Business Owner, then the residual risk the business accepted — as part of the approval, not the clearance — is signed by them too. The clearance memo identifies the residual risk and names the acceptor role. The business approval inherits that residual risk into its own business risk register. When the residual risk materialises later, nobody has to argue about who owned it.

The third change is procedural and quieter, but possibly the most useful: the AI Committee's agenda becomes legible. Instead of “we will review System X”, the agenda reads “clearance review for System X — Security Architecture to present threat register and proposed disposition; business approval discussion for System X — CTO to present business case and named sponsor proposal”. The committee knows what it is doing in each portion of the meeting. The minutes record each decision separately. The artefacts produced are different. The signatories are different. Six months later, when someone asks “what did the committee decide on System X on date Y”, the answer is a specific decision, with a specific signatory, on a specific artefact — not a fuzzy “the committee approved it”.

What does not change is the volume of decisions. The same number of systems are reviewed; the same questions get asked; the same risks are managed. What changes is the accountability for each decision, which becomes specific rather than collective. Specific accountability survives audits, regulator reviews, and three years of role turnover. Collective accountability does not — it dissolves the moment any of the original signatories changes role.

If your organisation is currently producing one signed minute per AI system, the path forward is to start producing two artefacts per system, signed by different roles, referencing each other. The committee can stay the same. The minute structure changes. The output structure changes. And once a few of these have been written, the failure modes from the conflation become visible by their absence — you stop seeing them, because the structure no longer produces them.