Every security leader eventually decides the infrastructure team is the obstacle. The findings are clear, the fixes are known, and the tickets sit open for weeks. So you conclude the people on the other side are dragging their feet — that they don't take security seriously, that they're lazy, that they need to be pushed.
I've been the CISO who thought that. I was wrong, and being wrong cost me time and relationships I didn't get back.
The infra team isn't sitting on your findings because they don't care. They're sitting on them because you're asking them to do something that, on their scoreboard, is all downside.
Pull up the metrics an infrastructure engineer is reviewed on. Uptime. Latency. Successful deploys. Time-to-recovery when something breaks. Nowhere on that list is "closed a security finding." Nowhere on that list is "tightened an IAM policy."
What is on the list, implicitly, is "didn't cause an outage." That one isn't written down, but everybody who owns production knows it's the real one. Cause a Sev1 that takes down checkout during business hours and you'll be explaining it in a review for months. Nobody remembers the twelve security tickets you cleared. Everybody remembers the outage.
So when a security ticket lands asking an engineer to change a live system, they're being asked to take on personal risk in exchange for zero personal reward. Deferring it isn't negligence. It's the rational read of the incentives you handed them.
From the security side, the fix looks trivial. Rotate the key. Tighten the role. Close the port. Two hours of work.
From the side of the person who owns that system, it looks different. That over-permissioned role — something depends on it in a way nobody wrote down, and if they get it wrong, they're the one getting paged at 2am. That key rotation — there might be a hard-coded credential in a service nobody's touched in three years, and it'll break silently. They don't know it will break. They know they can't prove it won't. And they're the name on the change.
Manual change to production, under time pressure, with no clean way back if it breaks — that's the exact shape of the thing that ends careers. Asking someone to do it casually, and then being annoyed when they don't, tells them you don't understand their job.
I spent a stretch trying to win this by force. Escalations. Mandatory-priority tickets. SLAs with the engineering VP's name on them. It works for a quarter, because you're spending your own capital to push against the incentives. Then you get busy, the pressure comes off, and it snaps right back — because the underlying scoreboard never changed.
What actually moved things was the opposite. When I stopped treating the infra team as adversaries and started treating their caution as information, the conversations changed. They weren't blocking me. They were telling me where the real risk in the change lived — the dependencies, the blast radius, the thing that would break. That's the person you want in the room, not the person you're routing around.
The version of this that works starts from a different question. Not "why won't engineering do their job?" but "why does the system I've built make sitting on this the safe move for them — and what would have to change for fixing it to be the safe move instead?"
That reframe matters because you can't fix people, but you can change a system. As long as the security scoreboard and the uptime scoreboard reward opposite behavior, the two teams will pull against each other, and no amount of goodwill or escalation will hold. Change what's safe for the engineer to say yes to, and the finding closes on its own.
The infra team was never your enemy. They were doing exactly what you'd do if you were measured the way they are.
If you've been on either side of this — the CISO pushing, or the engineer who knew the "simple" change wasn't — I'd like to hear how it went.