If you've worked in security long enough, you've sat in this meeting. Someone pulls up the open-findings dashboard. The critical count is up. Security says the same criticals have been open for two months. Engineering says they're heads-down on the release. Everyone agrees to prioritize security work. The meeting ends, nothing changes, and next quarter you have it again.
The reflex is to look for who's failing. Security is inflating severity to cover itself. Engineering doesn't take it seriously. Leadership won't put weight behind it.
I've been the CISO in that meeting at four companies, and the people were almost never the problem. They were competent and they were acting rationally. The system produced the bad outcome anyway.
That's not a small distinction. If the problem is people, you fix it with people — an escalation, an SLA, a new hire, a reorg. I've tried all of them. They hold for a quarter because you're spending your own capital to push against the system. Then you get busy, the pressure comes off, and it snaps back.
Security opens a ticket for an over-permissioned IAM role. To them it's obvious and urgent. It lands in an engineering backlog next to the release, a migration, on-call, and last month's other security tickets. The engineer who owns that service knows something security doesn't: a couple of things depend on that role in ways nobody wrote down, and if he tightens it wrong he's the one getting paged at 2am. Security knows something he doesn't: that role is one phished laptop away from being a real incident. Neither of them has the whole picture, and nothing in the process puts the two halves together.
So the ticket sits. Not because anyone decided it should. Closing it means changing a system nobody fully understands, under time pressure, with no clean way back if it breaks — and nobody wants their name on that downside. Doing nothing is the only choice that's safe for the person making it.
Then the metrics make it worse. Security is measured on how fast findings close. Engineering is measured on shipping and uptime. The same ticket that helps one team's number costs the other team's. You've built two scoreboards that reward opposite behavior, and then you're surprised the teams pull against each other. Governance can force it for a while — mandatory priorities, exec escalation — but the incentives are still there underneath, and they win as soon as attention moves on.
None of this needs a villain. It's competent people, incomplete information, and incentives that quietly reward leaving the dangerous thing alone.
I actually find that encouraging. You can't fix people, but a system is something you can change. The question stops being "who dropped this?" and becomes "why does the system make sitting on it the rational move, and what would have to be different for the rational move to be fixing it?" That's a more useful question, and it's the one worth walking into the next meeting with.
If this sounds familiar — if you've sat in that meeting — I'd like to hear how your org handles it.