The CISO and CTO of any enterprise should, in theory, be close partners. Both report to similar levels. Both have substantial influence over how technology is built and operated. Both have aligned interests in not having major incidents.

In practice, they’re frequently antagonists. Security teams see engineering as reckless. Engineering sees security as obstructive. Both are partly right. Both are mostly wrong about the other.

I’ve watched this dynamic across enough organisations to have a view on what causes it and what fixes it. The fix isn’t a process change. It’s a structural change.

Where the dysfunction comes from

The fundamental problem is that the operating model of most enterprise security teams hasn’t kept up with how engineering actually works.

Security frameworks were designed when software changes were rare events with formal release processes. A security review cycle could take weeks because changes were measured in months. Vulnerability remediation could be coordinated through quarterly patch cycles because the deployment pipeline didn’t exist.

That’s not how engineering works in 2026. Production deployments happen multiple times a day. Changes are continuous. Vulnerability disclosures hit the news and need response within hours, not quarters.

Most security teams are trying to apply 2010-era process to 2026 engineering velocity. The friction this creates is the visible symptom. The underlying cause is operational mismatch.

What engineering teams complain about

The engineering complaints are predictable:

• Security review cycles that take longer than the original development effort
• Vulnerability scans that flag thousands of low-priority findings without prioritization
• Compliance requirements that don’t account for modern architecture (containers, serverless, ephemeral infrastructure)
• Security tools that don’t integrate with developer workflows (CI/CD, IDE, code review)
• Demands for architectural changes that look reasonable on paper but break operational patterns

These complaints are usually accurate. The frustration is real and justified.

What security teams complain about

The security complaints are also predictable:

• Engineering shipping changes without security awareness
• Critical vulnerabilities sitting unpatched because of “operational priorities”
• Architecture decisions made without security input
• Inadequate logging and monitoring to detect or investigate incidents
• Engineering teams that don’t take security seriously until an incident forces them to

These complaints are also usually accurate. The frustration is real and justified.

Both sides are doing their jobs well by their own metrics. The dysfunction is structural.

What fixes it

The organisations that have functional CISO-CTO relationships have made specific structural changes:

Embedded security engineers in product teams. Not a security team that reviews work after the fact, but security engineers who sit with product teams and contribute to design decisions in real time. This shifts security from a gate to a participant. The cost is more security engineers but the throughput improvement is significant.

Threat modeling as part of design review. Every significant architecture decision includes a threat modeling step. This catches security implications when they’re cheap to address rather than after deployment when they’re expensive.

Automated security validation in CI/CD. Security checks that run automatically on every pull request, with clear remediation guidance. The friction shifts from “wait for the security team to review” to “fix the issue the automation flagged.”

Joint metrics between engineering and security. When both teams are measured on shared outcomes (mean time to patch critical vulnerabilities, security debt reduction, incident response performance), they cooperate. When they’re measured on conflicting metrics (engineering on velocity, security on number of findings raised), they don’t.

A security team operating model that mirrors engineering velocity. Continuous security review for continuous deployment. Real-time threat intel feeds, not quarterly reports. Tooling that produces signal instead of noise.

The political dimension

The structural changes above are usually opposed by both sides initially. Engineering doesn’t want security engineers in their stand-ups. Security doesn’t want to give up the gating power that comes with being the final approver.

The CTOs and CISOs who’ve made this work are usually peers who explicitly chose to make it work, against the institutional momentum on both sides. It’s a leadership choice as much as an organizational design.

The CTOs who’ve succeeded usually said: “I’m willing to slow down velocity by 10% if it means we don’t have a major incident.” The CISOs who’ve succeeded usually said: “I’m willing to accept some risk that I’d previously have blocked, in exchange for security being designed in rather than bolted on.”

Without that explicit trade-off, the organizations stay stuck.

The vendor noise

The security vendor space has plenty of products that promise to bridge the CISO-CTO gap. Platform plays, integrated security suites, AI-driven security operations centres, etc. Most of them are useful but none of them solve the structural problem on their own.

Buying a tool to bridge the cultural gap is similar to buying a project management tool to fix a strategy problem. The tool can help if the underlying issue is being addressed. It can’t substitute for the underlying issue being addressed.

What the boards should be asking

Boards that want to know whether their CISO-CTO relationship is working should ask both leaders these questions:

• Can engineering deploy the necessary changes to address a critical vulnerability within 24 hours?
• Are security findings prioritized and acted on, or do they accumulate as backlog?
• Is security a participant in architecture decisions or only a reviewer?
• Do the CISO and CTO have shared OKRs?
• When was the last time they worked together to push back on a business or compliance demand?

If the answers indicate friction, dysfunction, or surface-level cooperation, the structural problem is unresolved. No amount of tools or training will fix it without structural change.

The good news is that the change pays off. The organisations that have made this work have better security outcomes, faster engineering delivery, and lower team friction. It’s not a trade-off — it’s a both-things-improve change.

The bad news is that change requires explicit leadership attention from both the CTO and CISO. It doesn’t happen accidentally. It usually doesn’t survive a leadership transition without active support from the new leaders.

The dynamic of the next decade is going to favor enterprises that get this right. The ones that don’t will keep being the ones in the news for breaches that the engineering team knew were coming and the security team couldn’t prevent.