Margin of Safety #14 – Battle of the CISO vs CIO

The tension between CISOs and CIOs stems from conflicting mandates—security vs. uptime or new capabilities

It’s one of the oldest dynamics in enterprise IT, but it’s particularly relevant in times of IT change – like AI adoption waves. The Chief Information Officer (CIO) is tasked with keeping systems humming, enabling business units, and hitting availability SLOs. The Chief Information Security Officer (CISO) is charged with minimizing cyber risk, enforcing policies, and staying off the breach headlines. On the org chart, they often sit side by side. But in practice, individual incentives can put them at odds more often than not.

The CIO gets rewarded for delivering capabilities, quick adoption of new tools, and keeping employees productive. On the margin, many employees are probably willing to suffer small amounts of downtime in order to access broad new capabilities. For example, user adoption of ChatGPT has not been stymied by its less than full available. On the other hand, the CISO gets rewarded for avoiding risk, closing audit gaps, and making sure even one missed CVE doesn’t turn into a PR nightmare. Put differently: the CIO’s job is to say yes, while the CISO’s job is to say “not until we’ve threat-modeled it.”

This tension isn’t new, but it’s growing louder. AI, regulatory scrutiny, and the expanding attack surface have turned every software deployment into a mini risk negotiation. And in the meantime, two things keep surfacing: vulnerability patching and AI-powered developer tools.

Vulnerability patching: scan, panic, escalate

Ask any CISO, and they’ll tell you patching is table stakes. Modern vulnerability scanners surface thousands—sometimes tens of thousands—of CVEs across enterprise assets. Those findings get routed to engineering teams for remediation, where the response is almost always the same: “We can’t possibly patch all of this.”

They’re not wrong. Many systems are old, brittle, and mission-critical. Even for new systems, patching is expensive: patches must be qualified in test and staging environments and then carefully monitored during production deployment. Mistakes in this process can mean downtime, rollbacks, and other technical fire drills (as a result, many companies never patch on Fridays, near major holidays, or during key events). The CIO org is on the hook for uptime and service availability, and they don’t take lightly the idea of rolling the dice for something that may or may not ever be exploited — in fact, most vulnerabilities are indeed never exploited.

Meanwhile, the CISO sees the backlog as a mine field—just waiting for exploits to happen. Add in compliance pressure (PCI, FedRAMP, CMMC), and you have a recipe for escalations, exception queues, and a parade of last-minute patch parties.

One security leader told us they stopped sending raw scan reports to engineering. “It just triggered fights,” they said. “Now we triage first, assign business impact scores, and only escalate the top 5%. Otherwise it’s just noise.” That sounds obvious in theory—but in practice, it’s a signal of how broken vulnerability management workflows can become without shared goals.

Shadow IT, meet AI coding assistants

If patching is the old-school flashpoint, AI developer tools are the new one. Engineers are racing to adopt tools like Cursor. But many CISOs are hitting pause (many enterprises actually do not allow Cursor)

The security concerns are real: code leakage to third-party LLMs, hallucinated logic vulnerabilities, unclear software bills of material, and a blurred understanding of where the model output came from or what licenses it might have inherited. For teams under regulatory scrutiny or handling sensitive IP, those risks aren’t just hypothetical—they’re critical.

So now we’re seeing a wave of push-pull. Developers want to deploy Cursor yesterday. CISOs want a DLP plan, tenant isolation, and a vendor SOC 2 before they’ll even allow a pilot. The result? Security vendors are scrambling to fill the gap—offering things like “LLM firewalls,” real-time prompt inspection, and provenance tracking for generated code (despite the fact that provenance on LLM outputs is as much research project as anything else).

The pattern is familiar: the CIO org brings in a new tool to move faster. The CISO org throws the flag. The business wants both speed and safety—but the two teams have no clear mechanism to balance those priorities. So, employees often use unauthorized tools (i.e. shadow IT).

Finding alignment

There’s no magic fix, but some companies are getting better at navigating the tension. One approach we’ve seen work: shared metrics. If both the CIO and CISO are measured not just on their own goals, but on mutual ones—like “99.95% uptime and < 5 open critical vulns”—they’re more likely to collaborate from day one.

Another is embedded security engineers. Instead of throwing CVEs over the fence, these engineers work directly with product squads, helping triage issues and patch during the development cycle—not after the fact. It’s the DevSecOps dream, but when done right, it replaces standoffs with shared wins.

We’re also seeing more traction in risk-based prioritization—where CVEs get scored not just on CVSS, but on actual business impact. Not every finding deserves a Sev 1 escalation. But the ones that do? They can’t sit in a Jira queue for a quarter.

Finally, there’s tooling. Cursor isn’t going away—and neither are other AI accelerators. Instead of blocking them entirely, forward-thinking CISOs are starting to explore guardrails: secure-by-design integrations, automated QA, output scanning, and visibility tools that don’t just say no—they say “here’s how we can safely say yes.”

The bottom line

CISOs and CIOs aren’t enemies. They just operate under different failure conditions. For the CIO, failure means an outage. For the CISO, it means a breach. Both are costly. Both are avoidable.

Done right, the tension between these two roles can be productive. It can raise the quality bar, force better decision-making, and make sure innovation doesn’t come at the cost of risk. But left unchecked, it can stall progress, generate animosity, and create a shadow IT problem inside the org.

Security and IT professionals out there – If this is something you’re navigating, we’d love to hear from you. Startups that are or building tools to address this problem, we’d love to hear from you too. You can reach us directly at: kshih@forgepointcap.com and jpark@forgepointcap.com.

This blog is also published on Margin of Safety, Jimmy and Kathryn’s Substack, as they research the practical sides of security + AI so you don’t have to.