Someone had done their homework. Whoever specified this installation had thought it through. There was a written policy somewhere covering OSHA compliance, HIPAA, maybe both, and the physical control matched the intent of that policy to a T.

Except for one thing.

The key was still in the lock.

There it was, right at the top of the container: a small silver key, inserted into the very lock it was supposed to secure, dangling for anyone to see. One turn and the “secure” container was open. The entire physical security apparatus, thoughtfully designed and properly installed, had been rendered ineffective by a single, mundane act of negligence. Not malice. Not a sophisticated attack. Just someone who unlocked the container, did what they needed to do, and walked away without completing the last step.

I took a photo, because I’ve been in enough boardrooms and conference rooms and executive briefings to know exactly what I was looking at. This wasn’t a medical office problem. This was an organizational problem. And it’s one I see everywhere.

The Gap Between Policy and Practice

Every organization that has reached a meaningful level of maturity has done the hard work of putting controls in place. They’ve written the policies. They’ve deployed the technology. They’ve installed the metaphorical sharps containers: mounted high on the wall, properly labeled, securely fastened. The compliance checkbox is checked.

What far fewer organizations have done is close the loop. They’ve built the control, but they haven’t built the system that verifies the control is actually working as intended.

This is the gap between having a policy and governing a policy. It’s the difference between installing a lock and making sure the key doesn’t stay in it.

In my experience working with organizations across a range of industries, this gap shows up in remarkably consistent ways. Here are a few of the patterns I see most often.

“We Have a Password Policy”

Password policies are one of the most common examples of this phenomenon. The policy exists. It has complexity requirements, expiration windows, perhaps even multi-factor authentication mandates. IT drafted it, Legal reviewed it, Leadership approved it.

And then, somewhere out in the organization, there’s a shared service account with a twelve-year-old password that three different teams know. There’s an executive assistant whose account is set to “password never expires” because someone in IT made an exception years ago and no one tracked it. There’s a vendor with remote access credentials that were provisioned during an implementation project and were never revoked.

The policy is real. The gap is in enforcement and validation. No one went back to check. No one asked, “Are we sure this is being followed?” The key is in the lock.

“We Do Annual Access Reviews”

Access governance is another area where the gap appears with alarming frequency. Many organizations have adopted formal user access review processes, often driven by SOC 2, ISO 27001, or internal audit requirements. Managers receive a spreadsheet once a year, are asked to confirm that their team members still need the access they have, and click “approve.”

In practice, this process frequently becomes rubber-stamping. Managers receive a list of fifty names with access to fifteen different systems and are given two weeks to complete the review while also doing their actual job. The path of least resistance is to approve everything and move on. No one is verifying that the review was conducted thoughtfully. No one is spot-checking the outcomes. The process exists; the governance doesn’t.

What does governance look like here? It looks like reviewing how the review was completed, not just that it was completed. It looks like sampling decisions (particularly approvals for elevated access) and asking managers to explain their reasoning. It looks like trend analysis: is this team consistently approving access that never gets used? It looks like closing the loop.

“We Have an Incident Response Plan”

Incident response plans are a beloved artifact of mature security programs. Organizations spend considerable effort drafting them: defining roles, escalation paths, communication templates, recovery time objectives. The documents are thorough. They often live in a shared drive, neatly organized, last reviewed fourteen months ago.

Then an incident happens, and it quickly becomes clear that the people who are supposed to execute the plan have never run through it. The contact lists are outdated. The escalation path includes a team lead who left the company. The recovery procedures reference a backup system that was replaced two years ago during infrastructure modernization.

The plan was never the problem. The problem was that no one ever tested it. No one ran a tabletop exercise. No one asked, “If this happened tomorrow at 2 AM, would this plan actually work?”

The container was mounted. The key was in the lock. And nobody noticed until it mattered.

Why This Happens

The pattern isn’t a mystery. Organizations develop controls under pressure: regulatory pressure, insurance requirements, audit findings, incident post-mortems. The pressure is high, the timeline is tight, and the goal is to have the control in place by a deadline. That’s where most of the organizational energy goes.

Once the control is in place, the pressure largely dissipates. The auditor signs off. The certification is issued. Leadership moves on to the next priority. The control becomes infrastructure, assumed to be working and rarely examined.

This is compounded by something fundamental to how organizations allocate resources: it is much easier to justify the cost of building a new control than the cost of validating an existing one. Building is visible. Validation is invisible until something goes wrong.

There’s also an accountability gap. The team that built the control often isn’t the team responsible for governing it long-term. Ownership diffuses. Nobody is clearly accountable for asking, “Is this control still doing what we built it to do?”

What Governance Actually Looks Like

Governance is not a document. It’s not a committee. It’s not an annual review meeting where everyone nods along.

Governance is the organizational muscle that closes the loop. It takes a control from installed to verified to continuously operating as intended. It requires a few things that don’t come naturally to organizations built around building and shipping.

It requires someone to be accountable for the outcome, not just the artifact. The person responsible for the password policy shouldn’t be the person who wrote it. It should be the person accountable for ensuring that accounts in your environment actually comply with it. Those are often different roles.

It requires scheduled, structured validation. Not “we’ll check if something goes wrong,” but a defined cadence for sampling, testing, and confirming that controls are working. Tabletop exercises. Penetration tests. Spot audits. Pull five access approvals from last quarter’s review and see if the reasoning holds up.

It requires metrics that measure intent, not activity. “We completed 100% of our access reviews on time” is an activity metric. “Access to critical systems is held only by people with a current business need” is an outcome metric. One of those tells you the review happened. The other tells you it worked.

It requires psychological safety around bad news. The key was in that lock partly because nobody felt empowered (or responsible) to say anything about it. In organizations where finding a problem is punished and checking a box is rewarded, people check boxes. Governance requires a culture where surfacing a gap is valued, not penalized.

The Uncomfortable Question

Here’s what I’d encourage you to take back from this: the sharps container was doing everything right except one thing. And that one thing (the key in the lock) completely defeated the purpose of everything else.

Your organization almost certainly has its own version of this. A control that looks right on paper. A process that exists in documentation. A safeguard that was properly installed by people who cared, and then never validated.

The question isn’t whether you have policies and procedures in place. Most mature organizations do. The question is: when did you last check if the key is still in the lock?

Because I can tell you from experience: more often than not, it is.