Imagine a governance program that has 147 policies. One hundred forty-seven. Well-written and organized into a taxonomy. Every one of them has an owner, a review date, and version history.
The catch? The institution has no supporting mechanisms.
When an auditor asks how the access review control actually work, the answer is a policy document saying reviews are conducted quarterly. When the auditor asks for evidence the Q2 review had completed, the answer is a spreadsheet someone started in April and abandoned by May. When the auditor asks what happens when a manager fails to complete their review on time, the answer is silence.
This is governance theater.
An impressive collection of documents that satisfies the appearance of governance without producing any of its substance. It is the single most common failure mode I have seen at federally regulated institutions of every size.
What is a governance mechanism? A governance mechanism is a designed, repeatable system that produces predictable outcomes and generates its own evidence as a byproduct of operation. It differs from a policy (which declares intent) and a control (which specifies enforceable action) because a mechanism executes reliably without depending on individual human discipline. In federally regulated institutions, mechanisms are the difference between a program that survives examination and a program that produces findings.
The Design Failure Nobody Talks About
Policies are necessary. They establish intent, they define boundaries, and they create the authoritative basis for governance. I am not arguing against policies. I am arguing that most organizations stop at the policy layer and call it done. That is a design failure, not an effort failure.
A policy declares what should happen.
A control specifies the enforceable action that makes it happen.
A mechanism is the designed, repeatable system that produces the outcome whether or not any individual human remembers to execute it.
Most governance programs conflate all three. They write a policy, call it a control, and wonder why the auditor issues findings.
Pick any policy in your governance program. Trace it forward. Can you identify the specific control that enforces it? The specific mechanism that makes the control repeatable and evidence-generating? The artifact that proves the control executed last quarter? If the answer to any of those questions is no, you have a policy. You do not have a governance program.
What a Mechanism Actually Looks Like
The distinction is not semantic. It is structural. Let me make it concrete with an example everyone in banking recognizes: the access review.
Policy
"All user access must be reviewed quarterly." This declares intent. It is a boundary. It tells the organization what should happen.
Control
"Managers must certify or revoke each entitlement assigned to their direct reports within 14 calendar days of campaign launch." This specifies the enforceable action. It has a who, a what, and a timeline.
Mechanism
"SailPoint IdentityNow auto-generates quarterly review campaigns scoped to the authoritative HR feed. Campaigns route to the manager of record. Non-responses escalate to the manager's supervisor at day 10. Uncertified entitlements auto-revoke at day 15. Completion evidence logs to the governance repository with reviewer identity, timestamps, decisions, and escalation records."
That is a mechanism. Designed. Repeatable. It produces the outcome regardless of whether any individual manager is disciplined, distracted, out on vacation, or simply too buried in quarter-close to remember the campaign is open. It generates its own evidence as a byproduct of operation, not because someone remembered to update a spreadsheet afterward.
When the Mechanism Layer Is Missing
When organizations skip the mechanism layer, here is what actually happens. Someone in IT sends an email reminder about access reviews. Some managers respond. Most do not. The overdue list grows through week two, then week three. Someone chases stragglers for three weeks, then gives up. By the time the review "closes," the evidence shows partial completion, no enforcement of the timeline, and no consequence for non-compliance.
The policy said quarterly. The control said 14 days. The reality was a six-week scramble that produced a half-finished spreadsheet.
The finding on the next exam reads something close to: "Management has established a quarterly access review policy; however, testing identified systemic non-completion of the 14-day review window, absence of evidence supporting timely remediation, and a population of entitlements for which no reviewer decision was recorded during the certification period."
That is the anatomy of an audit finding. Not because the policy was wrong. Not because the people were negligent. Because the mechanism was never designed.
The Governance Spine
The way to ensure policies produce outcomes and outcomes produce evidence is to trace every governance activity through five stages: Appetite, Strategy, Controls, Evidence, Reporting. I call this the Governance Spine.
Risk Appetite
Defines the boundaries. What level of risk is the organization willing to accept, in which domains? This is the executive-level decision that all downstream governance traces back to.
Strategy
Translates appetite into investment. Which domains are prioritized? What maturity targets are set? What resources are allocated? Strategy connects risk tolerance to operational action.
Controls
The enforceable activities that execute the strategy. Each control must trace upward to a strategic objective and downward to an evidence artifact. Orphaned controls are ones that exist but cannot connect to a risk appetite statement. They are governance debris. They consume effort without advancing the program.
Evidence
The proof layer. Every control must generate evidence as a byproduct of operation. If a control requires a human to manually record that it happened, what you have is an assertion dressed up as proof. Assertions degrade. They have gaps. And under examination, the gaps become findings.
Reporting
Translates evidence into governance intelligence for decision-makers. Reporting without evidence is storytelling. Evidence without reporting is invisible value.
The break test. Pick any control. Trace it backward to a risk appetite statement. Trace it forward to an evidence artifact. If the spine is intact, both traces succeed. If the spine is broken, and it usually is, the gap tells you exactly where to invest.
The Monday-Morning Exercise
Every CISO reading this should do one specific thing this week. It takes about thirty minutes and produces a diagnostic result that outranks any maturity assessment.
Pick one control in your program. Any control. Access reviews. Vendor risk assessments. AI model approvals. Privileged access reviews. Pick the one you would want to defend first if an examiner walked in tomorrow.
Then trace it in both directions.
Backward. Which risk appetite statement does this control derive from? Not which policy. Which appetite. If you cannot identify the appetite statement, or if the appetite statement is missing, the control is operating in a governance vacuum regardless of how well it is executed.
Forward. Which specific system-generated artifact proves the control executed last quarter? Not the ticket someone opened. Not the spreadsheet someone updated. The timestamped, system-generated log or report that was produced by the control itself, as a byproduct of its operation, with no human in the middle deciding to create it.
If either trace breaks, you have found your mechanism gap. The next move is to close it, not by writing another policy, but by redesigning the control as a mechanism that produces the evidence automatically.
You do not need a consultant to run this exercise. You need thirty minutes and a willingness to look at the gap honestly.
Bottom Line
Most governance programs fail because they stop at the policy layer. The fix is not more policies, more training, or better documentation. The fix is mechanism design, building repeatable systems that produce outcomes and evidence as byproducts of operation, not as manual afterthoughts.
If you can trace every control in your program backward to a risk appetite statement and forward to a system-generated evidence artifact, you have a governance program. If you cannot, what you have is a policy library wearing a governance costume.
The shift from policies to mechanisms is not a philosophical preference. It is the operational difference between governance programs that survive examination and governance programs that produce findings. I have seen both up close. The gap between them is always the same: one was designed. The other was documented.
Frequently Asked Questions
What is the difference between a policy and a mechanism?
A policy is a written declaration of what should happen. A mechanism is a designed system that makes it happen reliably without depending on individual human discipline. The policy says "access reviews quarterly." The mechanism is the IGA platform workflow that generates the campaign, routes it to managers, escalates non-responses, and auto-revokes uncertified entitlements. One is documentation. The other is execution. Most governance findings come from institutions that have the policy and not the mechanism.
How does the Governance Spine framework work?
The Governance Spine is a five-stage structural framework: Appetite, Strategy, Controls, Evidence, Reporting. Each stage traces to the one below it. Risk appetite defines boundaries. Strategy translates appetite into investment. Controls execute the strategy. Evidence proves the controls operated. Reporting surfaces the evidence for decision-makers. When a governance program fails, the failure is almost always upstream of where the finding lands. A reporting finding is usually an evidence problem, an evidence finding is usually a controls problem, and a controls finding is usually a strategy problem.
What does an auditor look for when testing a governance control?
An auditor tests three things: whether the control was designed to produce the stated outcome, whether it operated as designed during the review period, and whether there is system-generated evidence to prove both. Controls that depend on manual documentation, such as spreadsheets, email confirmations, and verbal attestations, consistently fail the second and third tests because manual evidence has gaps, and gaps under examination become findings. Federal examiners operating under FFIEC guidance apply Substantial Reliance testing, which means evidence has to survive sample-of-a-sample scrutiny, not just look complete on the surface.
How do I know if my governance program has mechanism gaps?
Pick one control and run the break test described above. Trace it backward to a risk appetite statement. Trace it forward to a system-generated evidence artifact produced by the control itself. If either trace breaks, if you cannot identify the appetite statement, or if the evidence requires manual reconstruction, you have a mechanism gap at that control. Most governance programs have mechanism gaps in at least half their controls. The ones that survive examination are the ones where the critical controls, such as access management, segregation of duties, privileged access, and data classification, have been redesigned as mechanisms.
What is mechanism design in AI governance?
Mechanism design in AI governance is the practice of building the structural controls that enforce AI policy decisions automatically, rather than relying on committees and reviews to enforce them manually. It covers things like automated model registration at deployment, identity-aware data retrieval for AI inferences, Non-Human Identity governance for AI agents, and evidence logging for every model decision that affects a regulated outcome. The same discipline that makes access reviews work as mechanisms rather than theater applies directly to AI model governance, with the added complication that AI systems move faster than quarterly review cycles were designed to handle.
