Why IT Governance Fails Without Evidence-Based Controls

There's a particular kind of meeting that happens in a lot of IT organizations. Someone from risk or audit presents a dashboard. Every control has a green checkmark. Change tickets were filed. Access reviews were completed. The policy library was updated in Q2, right on schedule. Everybody nods. The meeting ends. And then three weeks later, a production database gets accidentally deleted by a contractor nobody remembers approving, or a ransomware crew walks in through a service account that had domain admin rights because "that's how we've always done it."

The checkmarks were real. The governance was not.

This isn't a story about lazy people or bad intentions. Most IT governance programs fail for a much duller reason: the controls were chosen because they sounded reasonable, matched a framework someone downloaded, or survived the last audit cycle—not because anyone had evidence they actually changed outcomes. When you build governance on assumptions, you get a structure that looks solid from the outside and behaves like wet cardboard the moment something unexpected happens.

That's the problem I want to dig into here. Not "governance is hard" (everybody knows that), but specifically why governance built without evidence-based controls tends to collapse, what evidence-based actually means in practice, and how to tell the difference before you find out the hard way.

What "Evidence-Based Controls" Actually Means

Let's define terms, because "evidence-based" gets thrown around loosely.

An evidence-based control is a practice, policy, or technical measure that has been shown—through data, not assertion—to correlate with better outcomes in organizations that actually perform well. The word "correlate" is doing a lot of work there. It doesn't mean the control is guaranteed to fix your problem. It means that when you compare organizations that do the thing to organizations that don't, the ones that do it consistently outperform on measurable dimensions: change success rates, mean time to recover, incident frequency, audit findings, whatever you're tracking.

Compare that to what most governance programs rely on:

• Framework defaults. The control exists because a framework said so. Frameworks are useful scaffolding, but they're written to cover a broad range of industries and risk appetites. They tell you what could matter, not what does matter for you.
• Auditor preference. The control exists because a specific auditor asked for it in 2019 and the documentation still lives in a shared drive.
• Executive intuition. A senior leader read an article or heard a vendor pitch and decided this was the thing. Sometimes they're right. Often they're pattern-matching on a situation that doesn't resemble yours.
• Industry folklore. "Everyone does quarterly access reviews." Everyone does a lot of things. That's not evidence that those things work.

None of these sources are worthless. Frameworks, auditors, and experienced leaders all bring something to the table. The trouble starts when they become the only input, and nobody ever circles back to ask the blunt question: is this control producing the result we claimed it would?

The Difference Between Descriptive and Prescriptive Controls

There's a subtle trap inside this. A lot of governance guidance is descriptive—it tells you what high-performing organizations look like. Descriptive guidance is comfortable to read. It's also nearly useless on its own, because knowing that top performers do X doesn't tell you how to do X in your environment, or in what order, or what to stop doing to make room for it.

Prescriptive guidance is harder to write and much more useful. It says: do this, in this sequence, with these specific artifacts, and here's what changes when you do. That's the gap between "top performers automate change management" and "here's the eleven-step path to automating change management without breaking your incident response process."

Governance fails when it's descriptive in a board deck and absent in the hallway. Evidence-based controls are prescriptive by nature. They come with an implementation path, not just a principle.

Why Intuition-Driven Governance Breaks Down

I want to be fair to intuition. Experienced IT leaders have good instincts. The problem isn't that intuition is bad—it's that intuition scales badly and deteriorates quietly.

Here's what happens. A CIO with twenty years of experience makes a judgment call about a control. It works, or it appears to work, in their context. That judgment becomes policy. The policy gets inherited by a new leader who wasn't in the room, applied to a different environment (cloud instead of data center, microservices instead of monolith), and now nobody knows why the control exists. It just exists. Questioning it feels like questioning the institution.

Three things go wrong from there.

First, the control drifts from its original intent. Nobody remembers the failure mode it was designed to prevent, so nobody notices when the environment changes enough that the control no longer addresses anything real. The access review still happens. It just reviews access to systems that were decommissioned eighteen months ago.

Second, the control accumulates cost without accumulating value. Every control has a labor cost. Multiply a quarterly review by the number of systems, the number of reviewers, and the number of exceptions, and you get a number that's often startling. When the control isn't producing measurable risk reduction, that cost is pure drag. And drag is where governance programs slowly die—not from a dramatic failure, but from the thousand small resentments of people filling out forms that don't do anything.

Third, and worst, the control provides false confidence. A green dashboard is a decision input. Executives use it to decide where to spend attention and money. If the dashboard is measuring activity (reviews completed, tickets filed) rather than outcome (risk reduced, incidents prevented), you're steering with a broken compass. You'll keep the budget flat on the thing that isn't working and starve the thing that would.

A Small, Realistic Scenario

Picture a mid-size healthcare organization. They have a change advisory board that meets weekly. Every production change over some threshold requires CAB approval. The CAB agenda is full. Approval turnaround averages four days.

Now picture their actual incident data. Most of their outages trace to a handful of things: configuration drift in one legacy integration layer, a recurring database connection pool exhaustion issue, and miscommunication between two teams. Almost none of them involve changes that went through the CAB—because the teams closest to those systems stopped routing small changes through the CAB months ago. They route around it. The CAB reviews big changes, and big changes are rarely the source of pain.

The CAB isn't wrong in principle. It's just not aimed at the actual failure mode. Nobody checked. The control was inherited, the meetings continued, and the evidence—incident postmortems—sat in a folder nobody connected back to the governance design.

That's the pattern. Governance fails quietly, in the gap between what the controls measure and what actually hurts you.

The Four Failure Modes of Evidence-Free Governance

Let me name these, because once you can name them, you can hunt for them.

Failure Mode 1: The Proxy Metric Swamp

You wanted to reduce unauthorized change. So you measure change tickets filed. Ticket volume goes up. Did unauthorized change go down? Not necessarily—you just made paperwork more visible.

Proxy metrics are everywhere in governance because they're easy to collect. Tickets, reviews, approvals, training completions, policy acknowledgments. These are outputs, not outcomes. They're not useless—they can be leading indicators—but if you treat them as proof, you'll keep optimizing the paperwork and ignoring the thing the paperwork was supposed to protect.

The fix isn't to abandon proxy metrics. It's to pair every proxy with an outcome measure and check whether they move together. If change tickets rise and change-related incidents don't fall, your proxy is lying to you.

Failure Mode 2: The Framework Transplant

Someone imports NIST CSF or ISO 27001 or COBIT wholesale, maps existing controls to it, and declares the gap analysis complete. This feels rigorous. It usually isn't, because the mapping exercise answers "do we have something that could be called this control?"—not "does this control work here?"

Two organizations can both be "compliant" with the same framework and have wildly different security and reliability outcomes. The framework doesn't distinguish them. Only evidence does.

Failure Mode 3: The Compliance Theater Loop

This is the nastiest one, and it's common in regulated industries. The organization learns what auditors want. It produces that. Over time, the internal definition of "good governance" becomes "what passes the audit." The actual risk profile drifts somewhere else entirely.

Healthcare IT is a frequent offender here—not because healthcare people are careless, but because regulatory pressure is intense and continuous. When compliance consumes the governance budget, security posture can quietly degrade while every box stays ticked. The evidence that would have caught this is usually sitting in incident data, exception logs, and the informal "we always work around this" knowledge that never makes it into a report.

Failure Mode 4: The Culture Blind Spot

Governance written without evidence tends to ignore the human system. Controls assume people will follow them. Evidence consistently shows that people follow controls when the controls make sense to them and when leadership models the behavior—not when the controls are merely mandated.

If you've never measured whether your controls are followed in practice versus followed on paper, you have a culture blind spot. And culture blind spots are where governance goes to die.

How High Performers Decide Differently

The interesting thing about organizations that get this right is that they don't have secret techniques. They have a habit. They treat governance decisions the way engineers treat technical decisions: form a hypothesis, implement, measure, adjust.

Concretely, that habit shows up as a few recurring behaviors:

• They benchmark against peers before designing controls. Not to copy—to find the anomalies. If your peer group's change failure rate is materially lower, what are they doing differently? If it's materially higher, maybe you're solving a problem nobody else has.
• They instrument the control itself. A control without telemetry is a hope. High performers track how often the control fires, what it catches, what it misses, and what it costs.
• They kill controls. This is the one that separates serious organizations from performative ones. When the evidence shows a control isn't producing outcome improvement, they retire it. Most organizations never retire anything.
• They distinguish preventive from detective controls and fund them differently. Preventive controls stop bad things. Detective controls find them after the fact. You need both, but they earn their keep in different ways and should be measured differently.
• They separate governance from compliance. Compliance is a floor. Governance is how you decide what to build above it.

None of that requires exotic tooling. It requires discipline and, honestly, a willingness to be embarrassed by your own data. That last part is what stops most teams.

Where the Data Comes From

Here's where it gets practical for most readers. You probably can't run a multi-year longitudinal study of IT performance across thousands of organizations. You don't have to. The IT Process Institute has been doing exactly that since 2004—studying top performers and publishing what actually differentiates them. That research base is what turns a hunch into a control with a track record.

The Visible Ops book series is the most visible output of that work—over 400,000 copies sold, spanning the original handbook plus volumes on security, private cloud, cybersecurity, and the recent VisibleOps A.I. The reason those books matter to a governance conversation is that they don't just describe high performers; they walk through the specific practices, in sequence, with the operational detail that governance teams need to implement them.

If you're designing controls from scratch, that's a much better starting point than a framework appendix. You're beginning from practices that have already been tested in the field, and you can shape them to your environment rather than guessing at what might work.

A Worked Example: Rebuilding an Access Review

Access reviews are the perfect case study for evidence-free governance, because almost every organization runs them and almost none can tell you whether they work.

The typical review looks like this: every quarter, system owners get a spreadsheet. They scan it. They approve most rows. A few get revoked, usually the ones that look obviously stale. The review is "complete." Audit is satisfied. Life goes on.

Now let's rebuild it with evidence.

Step 1: Define the outcome. What are you actually trying to prevent? Not "unauthorized access"—that's too vague to measure. Be specific: standing privileged access that outlives its business need. That's the failure mode. That's what you're hunting.

Step 2: Find the leading indicator. The best predictor of stale privileged access isn't how old the account is—it's whether the account has been used for its privileged purpose in the last N days. Unused privileged accounts are where dormant risk lives. That's a measurable signal, and it's available from your logging infrastructure in most environments.

Step 3: Instrument before you act. For one quarter, don't change the review process. Just collect data: how many privileged accounts exist, how many were used for privileged actions, how many had no privileged activity, how many had activity that no one could explain. You'll learn things. Frequently you'll learn that the review has been approving accounts because the reviewers don't have the context to judge them.

Step 4: Redesign the control around the signal. Instead of a quarterly review of everything, automate a weekly report of privileged accounts with no privileged activity in 30 days. Route it to the system owner with a deadline and a default action: if no justification is filed, the privilege is removed. The review stops being a review and becomes an exception-handling process, which is what it should have been all along.

Step 5: Measure the new control against the old outcome. Track stale privileged accounts over time. Track how many justify-and-keep decisions get reversed later. Track the labor hours. If stale accounts drop and labor hours drop, you've got a control that earns its keep. If stale accounts don't drop, you've learned something important: your problem isn't standing access, it's something else, and now you can go look for it.

That sequence—define outcome, find signal, instrument, redesign, measure—is the skeleton of every evidence-based control. It works the same way for change management, incident response, and AI governance.

Change Management: Where Gut Feel Gets Expensive

Change management is the second place evidence-free governance does the most damage, and for a very specific reason: the cost of a bad change policy is invisible until it isn't.

A change advisory board that reviews too much creates a queue. Queues create pressure. Pressure creates the informal workaround—the "emergency" change that isn't really an emergency, the small fix that gets applied directly because waiting four days is worse than the risk. Once workarounds become normal, your change data becomes fiction. You're governing a process that a meaningful fraction of changes bypass, and you don't know which fraction.

Top performers tend to move in the opposite direction. They shrink the review surface: low-risk, well-understood, reversible changes go through lightweight or automated approval; the heavy review goes to changes that are high-blast-radius, hard to reverse, or touch systems with poor change history. The risk model is empirical—it's based on what has actually gone wrong, not on a uniform severity scale applied to everything.

You can't build that model without data. You need change history, incident history, and the ability to connect them. Most organizations have all three and connect none of them.

A Quick Comparison

| Governance approach | How the change policy is set | What happens over time |

|---|---|---|

| Intuition-based | Senior leader's judgment plus framework defaults | Review scope creeps; workarounds increase; data quality degrades |

| Audit-based | Whatever the last auditor asked for | Policy tracks regulator attention, not risk; cost rises without outcome gain |

| Evidence-based | Risk model built from change and incident history | Review scope narrows to real risk; automation increases; outcomes measurable |

The difference isn't sophistication. It's just whether you looked at your own data.

Cybersecurity Governance: The Compliance Trap and How to Escape It

Cybersecurity governance is where evidence-free controls are most expensive, because the cost is paid in breaches.

The trap is straightforward. Regulatory and contractual requirements define a floor. Organizations meet the floor. The floor becomes the ceiling. Attention flows to the things that generate audit evidence rather than the things that reduce actual risk. Meanwhile, the threat model keeps moving.

Getting out of the trap requires separating two questions that governance programs routinely blur:

• Are we compliant? (Answered by control testing against a standard.)
• Are we reducing risk? (Answered by incident data, exposure measurements, and threat-relevant telemetry.)

Both questions matter. But if you only answer the first, you'll build a security program that is auditable and permeable. If you only answer the second, you'll fail audits and lose contracts. The organizations that do this well run both tracks and keep them visibly distinct.

On the cybersecurity side specifically, the Visible Ops approach is useful because it treats security as an operational discipline rather than a documentation exercise. The practices that show up in high performers tend to involve tight integration between security controls and the operational cadence—change management, access management, incident response, configuration control. Security that lives in a separate silo, however well-documented, tends to be slower and less effective than security woven into the way the organization actually operates.

You can see this in the difference between two common postures:

• Siloed security: Security team defines controls, hands them to operations, measures completion. Incidents reveal gaps that the controls never addressed.
• Integrated security: Security and operations co-own the operational control set, measure outcomes together, and adjust controls based on incident learning. Incidents reveal gaps that get folded back into the control design.

The second posture isn't more expensive. It's just organized differently, and it depends on having evidence about what's actually happening rather than what the control documentation says should be happening.

AI Governance and the New Evidence Gap

Artificial intelligence has dropped a fresh set of governance problems on IT leaders, and it's happening faster than most governance functions can adapt. That's exactly the condition under which evidence-free controls thrive—high uncertainty, high executive attention, and a strong pull toward doing something visible.

The problem with most AI governance today is that it's almost entirely policy-based. Acceptable use policies. Review boards for new AI deployments. Data handling rules. Bias assessment questionnaires. All reasonable. None of these have an evidence base yet, because the field is too young for the kind of longitudinal study that produced the Visible Ops findings on IT operations.

So what do you do? You borrow the methodology. The evidence-based approach doesn't require mature research on the specific technology—it requires:

• Clearly defined outcomes. What could go wrong with this AI deployment, specifically? Model drift, data leakage, bias in a decision path, regulatory exposure, reputational damage. Name them.
• Instrumentation. Can you detect the failure before it becomes an incident? If not, that's the first gap to close, ahead of any policy.
• A hypothesis about the control. "This review process will catch X before it reaches production." Test it. If you can't test it, you've written a hope, not a control.
• The willingness to revise. AI governance will change faster than any governance area in recent memory. Build for revision.

ITPI's VisibleOps A.I. is interesting precisely because it applies the existing methodology—prescriptive, top-performer-derived, operationally grounded—to a domain with almost no established practice. It debuted high on Amazon's new releases list for computers and technology, which suggests there was real appetite for something prescriptive in a space full of vague guidance.

Building an Evidence Pipeline: A Practical Walkthrough

Let's get concrete. If you're running a governance function and you recognize your program in some of the above, here's a sequence that works. It takes a couple of quarters to see the payoff, but you can start moving in weeks.

Phase 1: Inventory Your Controls and Their Claims

List every control in your governance program. For each, write down two things: what it's supposed to prevent or detect, and what evidence you have that it does so. Be honest. Most controls will have "we believe" as their evidence line.

You're not trying to fix anything yet. You're just establishing a baseline of how much of your program is assumed versus demonstrated. For a lot of organizations, this exercise alone is clarifying, and a little uncomfortable.

Phase 2: Rank Controls by Cost and Claim Strength

Plot each control on two axes: how much it costs (labor hours, tooling, delay, friction) and how strong its evidence is. Controls that are expensive and weakly evidenced are your priority targets—either to strengthen the evidence or to retire the control.

Don't try to overhaul everything. Pick two or three high-cost, low-evidence controls and work them through the full cycle.

Phase 3: Instrument the Outcome

For each target control, identify the outcome you'd expect to move if the control works. Then find or build the measurement. This is often the hardest step, because it requires connecting data sources that live in different places—ticketing systems, SIEM, CMDB, incident records, HR systems for access. Sometimes the data exists but nobody has joined it before.

Don't be precious about perfect measurement. A rough outcome metric that you can trend over time beats a precise one you'll never build.

Phase 4: Redesign Around Evidence

Now redesign the control based on what you learned. Usually this means narrowing scope to the actual risk, automating the routine parts, and turning periodic blanket reviews into exception-driven processes. You'll often find that the redesigned control is cheaper and more effective, because you've stopped paying for work that wasn't doing anything.

Phase 5: Measure, Compare, Decide

Give the new control a quarter or two. Compare outcomes. Then make a decision: keep, adjust, or retire. And write down the reasoning, so the next person who inherits this program doesn't have to guess why the control exists.

A Simple Checklist for Any New Control

Before you add a control to the governance program, answer these:

• [ ] What specific failure is this control designed to prevent or detect?
• [ ] What evidence exists that this type of control works in organizations like ours?
• [ ] What outcome would change if this control is effective, and how will we measure it?
• [ ] What's the labor and process cost of running this control for a year?
• [ ] Who owns it, and who reviews whether it's still needed?
• [ ] What would make us retire it?
• [ ] How will we know if it's being followed in practice versus on paper?

If you can't answer four or five of those, the control is a hypothesis at best. That's fine—just label it as one and plan to test it.

Common Mistakes When Adopting Evidence-Based Governance

I've watched enough organizations try this to know where they get stuck.

Treating "evidence-based" as a synonym for "data-driven." Data-driven means you have dashboards. Evidence-based means you've connected the data to a claim and tested it. The difference matters.

Measuring only what's easy. Ticket counts, completion percentages, and training records are easy. Change failure rates, mean time to recover, and exposure windows are harder. The harder metrics are where the real signal is. Budget the effort.

Turning it into a research project. The point isn't to publish a study. It's to make better decisions faster. If your evidence effort is slowing down governance without changing any decisions, you've missed the point. Aim for "good enough to decide."

Ignoring the culture dimension. Evidence-based governance still depends on people following it. If leaders skip the process, everyone else will too, and your measurements will capture a fictional process. Culture isn't a soft add-on here—it's part of the evidence picture.

Retiring controls too hastily. The flip side of the kill-what-doesn't-work principle is that some controls have lagging effects or low-frequency but high-impact value. A control that prevents one catastrophic event every five years may look useless in quarterly data. Use judgment, and be explicit about the risk you're accepting when you retire something.

Forgetting the exception path. Evidence-based controls need a documented way to handle exceptions, because there will always be some. If the exception path is informal, the control will erode from the edges.

Confusing consistency with correctness. "We've always done it this way" is a consistency argument, not a correctness argument. They're different claims.

Metrics and Benchmarks That Actually Move the Needle

If you want to know whether your governance program is doing anything, these are the kinds of measures worth tracking. They're not a universal set—your environment will suggest others—but they're a reasonable starting point.

Change outcomes

• Change failure rate: what percentage of changes cause an incident or require remediation?
• Change lead time: how long from code commit or request to production?
• Emergency change ratio: how many changes bypass normal review, and is that number trending up or down?

Incident and recovery

• Mean time to detect
• Mean time to recover
• Recurrence rate: how often does the same class of incident repeat?

Access and exposure

• Count of privileged accounts with no recent privileged activity
• Median time from role change to access adjustment
• Number of standing exceptions, and their age distribution

Governance process health

• Control cost per outcome unit (labor hours per incident prevented, or however you want to frame it)
• Exception request volume and approval rate
• Percentage of controls with an active owner and a defined review date

Security posture

• Time from vulnerability disclosure to remediation, segmented by exploitability
• Coverage of detection across the asset inventory
• Third-party risk findings closed into contract or remediation

Whatever you pick, trend it. Point-in-time numbers in governance are mostly noise. Direction over time is what tells you whether your controls are working.

Using Benchmarks Without Drowning in Them

Benchmarks are useful for the same reason they're dangerous: they invite comparison. A benchmark tells you where you stand relative to similar organizations, which is genuinely helpful for setting targets. It becomes a problem when you treat the benchmark as your strategy. Being at the median is not a strategy. Being measurably better than your peers on the outcomes that matter to your business is.

This is where research organizations like ITPI earn their keep. Public benchmarks tend to measure broad, publicly reportable things. The practices that differentiate top performers are usually more specific—they live in the operational detail, in how change is actually routed, how access is actually managed, how incidents are actually run down. That specificity is what you can implement. General benchmarks tell you whether you need to.

FAQ

What's the difference between evidence-based controls and just doing a risk assessment?

A risk assessment tells you what could go wrong. Evidence-based controls tell you what does go wrong in organizations like yours, and what practices have been shown to reduce that. They're complementary, not the same. Risk assessments are often hypothesis-generating—they produce candidate failure modes. Evidence is what tells you which candidates are worth building controls around.

Our organization is small. Do we need to do all this?

You need the habit more than the full apparatus. Small organizations can often get most of the benefit with a few outcome metrics and a willingness to retire controls that don't earn their cost. In fact, small organizations often benefit more from this discipline, because they have fewer people to absorb the drag of ineffective controls.

How long does it take to see results from redesigning controls around evidence?

For a single control, expect one to two quarters before you can tell whether the redesign is working. The full governance program can take a year or more to shift, because you're changing decisions, not just processes. The early wins—retiring a couple of expensive, low-evidence controls—usually come within the first quarter.

What if our data is a mess?

It probably is. Build a rough metric anyway. A trend line from imperfect data still tells you which direction things are moving, and you can improve data quality as you go. Waiting for clean data is how governance programs end up never changing.

How does this relate to frameworks like NIST or ISO?

Frameworks give you a control catalog and a vocabulary. Evidence gives you priorities and a way to test whether the controls in the catalog actually help in your environment. Use frameworks as scaffolding. Don't let them substitute for evidence about your own outcomes.

Can a control be evidence-based if there's no published research on it?

Yes, provided you build the evidence yourself. Define the outcome, instrument it, test the control, and decide based on what you see. The published research—like what ITPI has done over two decades—is valuable because it shortcuts the process for common IT management problems. For novel areas, you're the researcher, whether you wanted the role or not.

Where do we start if the whole thing feels overwhelming?

Pick one control. The most expensive one with the weakest evidence behind it. Run it through the sequence: define the outcome, instrument it, observe for a quarter, redesign, measure. You'll learn more from one control done properly than from a year of planning.

Getting From Principles to Practice

Reading about evidence-based governance is easy. Doing it runs into the usual obstacles: time, competing priorities, and the political discomfort of admitting that some of the current control set may not be doing anything.

A few ways to make it less painful:

Start with one visible win. Pick a control that's expensive and widely resented—something everyone suspects is theater. Redesign it based on data, and make the improvement visible. A single credible win buys you permission to do more.

Separate the evidence conversation from the blame conversation. If people think a control review is a hunt for who screwed up, they'll hide data. Frame it as a design question—was this control a good design for the risk we actually face?—and you'll get honesty.

Use existing research so you're not starting from zero. The reason organizations like ITPI exist is to do the research that individual organizations can't. The Visible Ops series and ITPI's benchmarking studies give you a starting point grounded in what top performers actually do. You can read "The Visible Ops Handbook" in an afternoon and walk into the next control design meeting with a much better set of hypotheses than you had before.

Build a review cadence into the program itself. Not a review of the reviews—that's more theater. A calendar entry, once a quarter, where someone asks: which controls have weak evidence, and what are we doing about it? Keep the meeting short. Make the answer actionable.

Track outcomes, not activity, in the reports that go upward. Your executive dashboard should answer "are we getting safer, more reliable, and more compliant?"—not "did we complete the activities?" If your board is reading activity counts, they're being told a story about effort, not results.

What Good Looks Like

An evidence-based governance program is not a giant research function. It's a governance function with a habit of asking "how do we know?" and the patience to wait for an answer. It's a little quieter than most. There are fewer new initiatives, fewer dashboards, and probably fewer meetings. There's also a shorter list of controls, each of which someone can explain in one sentence and point to a reason for believing it works.

That's the whole point. Governance that fails usually fails slowly and politely, hidden behind green checkmarks. Governance that holds up under pressure is built from controls that survived being questioned.

The next time you're in one of those meetings—the one where all the boxes are checked and something still feels off—ask the question. What evidence do we have that this control is doing anything? If nobody can answer, you've just found your first project.

And if you'd rather start from the research than from scratch, ITPI's work is a reasonable place to begin. Its benchmarking studies and the Visible Ops series were built for exactly this problem: giving IT leaders a way to make governance decisions based on what actually works, not what sounds good. That's a better foundation than a framework appendix and a hopeful expression.