Every security team I've run had a graveyard. Not of ideas that were wrong — of controls that were right. Controls we scoped, justified, rolled out, and then watched die. And the ones that died weren't the sloppy ones. They were often the most technically correct thing we did that year.
That took me a while to understand. Early on I thought a rejected control meant we'd gotten the analysis wrong — misjudged the risk, picked the wrong tool, missed something in testing. Sometimes. But more often the analysis was fine. The control did exactly what we said it would. It just didn't fit how the organization actually worked, and correct-but-doesn't-fit loses every time.
A control lives or dies on whether people can do their jobs with it running. That's it. You can be completely right about the threat, right about the fix, right about the residual risk you're buying down — and if the control makes the daily work harder than the people doing that work will tolerate, it's already dead. It just doesn't know it yet.
I've watched this happen more than once — a control that was exactly right on paper, a strict egress-filtering rule, say, that in practice broke a deploy pipeline nobody had fully mapped. And here's the thing: the people it broke weren't wrong to be annoyed. Their work mattered too. The control was one input to the org, not the whole point of it.
Controls that don't fit almost never get killed in one meeting. It's quieter than that, and it goes in the same order every time.
First, friction. The control does its job, which means it says no to things. Tickets pile up. People wait.
Then, exceptions. Someone important gets blocked at a bad moment, and you carve out an exception "just for this team, just for now." That's the tell. Once you're writing exceptions, the org has already decided the control costs more than it's worth — they're just letting you save face.
Then, disabled. Enough exceptions, and someone flips it to monitor-only "temporarily" to unblock a launch. Nobody meant for temporary to be permanent. It always is.
Then, removed. Eventually someone cleaning up notices the thing everybody's been routing around and pulls it, because a control that's off is just noise and false alerts.
The reflex is to blame the people who route around it. Don't. They're doing the same thing your engineers do with a security ticket that risks a 2am page — taking the path that's safe for them. A high-friction control asks the whole org to absorb a real, daily, visible cost in exchange for a benefit that is abstract and only shows up on the days nothing goes wrong. That's a bad trade for almost everyone who isn't you. They're not sabotaging the control. They're responding to it rationally.
Here's why a removed control is worse than a control you never deployed: it leaves false confidence behind.
When you never had egress filtering, everyone knows you don't have egress filtering. You plan around the gap. When you had it and it got quietly disabled six months ago, the dashboard still shows it. The architecture diagram still shows it. The last auditor checked the box. You are now defending against a threat you believe is covered and isn't. That's strictly worse than the honest gap, because nobody's watching it.
A dead control doesn't just stop protecting you. It lies about protecting you.
I stopped grading controls on whether they were correct and started grading them on whether they'd survive contact with how the org really works. Before rolling anything out now, I want to know: what's the daily friction, who eats it, and what's the first workflow that's going to demand an exception? If I can't answer that, I'm not deploying a control. I'm scheduling a funeral.
Correct gets you a design review. Fit is what's still running a year later.
If you've got a control in your graveyard that was right and died anyway, I'd like to hear what killed it.