Ten years ago, the CISO reported to the CTO at most mid-market companies. Security was a subset of IT. The CTO made architecture decisions, and the CISO implemented security controls around them.

That structure is breaking down, and it’s about time.

The threat landscape has changed so dramatically that security can’t be bolted on after technical decisions are made. At the same time, security requirements can’t be allowed to paralyse technical progress. Getting the balance right requires a relationship between CISO and CTO that’s collaborative, sometimes contentious, and always rooted in shared business objectives.

Why the Old Model Doesn’t Work

When security reports to technology, there’s an inherent conflict of interest. The CTO is measured on delivery speed, innovation, and system performance. Security controls slow delivery, limit architectural options, and sometimes reduce performance. When the person being slowed down is also the person approving the slowdown, guess what happens.

The Australian Signals Directorate’s Essential Eight provides a useful framework, but implementing it properly requires authority that’s independent from delivery pressure. A CISO who reports to the CTO is structurally unable to push back on technical decisions that compromise security if the CTO has decided the risk is acceptable.

I’ve seen this play out repeatedly. The CTO approves a cloud architecture that doesn’t meet the organisation’s data residency requirements because the compliant option is 30% more expensive. The CISO raises concerns, the CTO overrules them because they control the budget, and six months later there’s a regulatory issue.

Where the Tension Actually Lives

The most productive CISO-CTO relationships I’ve observed acknowledge that tension is inherent and useful. They disagree on specific decisions regularly but align on strategic direction.

Common friction points include:

Cloud architecture decisions. CTOs generally favour flexibility and speed. CISOs favour control and visibility. Multi-cloud strategies create security monitoring complexity. Serverless architectures reduce attack surface but can create visibility gaps. Container orchestration platforms need security configurations that slow deployment pipelines.

Third-party integrations. Every SaaS tool the CTO approves expands the attack surface. The CISO wants security assessments before every new vendor. The CTO wants to move fast and evaluate tools through rapid pilots. Neither position is wrong, but they’re fundamentally in tension.

AI deployment. This is the newest and perhaps sharpest conflict area. AI systems process massive amounts of data, often including sensitive information. They create new attack vectors. They produce outputs that can be manipulated. CTOs are under pressure to deploy AI capabilities quickly. CISOs are still working out how to assess and mitigate AI-specific risks.

Development practices. Shift-left security sounds great in theory. In practice, it means developers spend time on security tasks instead of feature development. The CTO’s delivery metrics suffer. The CISO’s security posture improves. Finding the right balance requires ongoing negotiation.

What Good Looks Like

The organisations getting this right share some common patterns.

Separate reporting lines with shared accountability. The CISO reports to the CEO or board, not to the CTO. But both roles share accountability for specific outcomes — system availability, incident response times, regulatory compliance. This creates peer-level negotiation rather than hierarchical override.

Joint architecture reviews. Security isn’t consulted after architecture decisions are made. Security participates in the design process from the beginning. This is slower initially but dramatically faster overall because it eliminates the rework cycle of building something, having security reject it, and rebuilding.

Shared risk language. The CTO and CISO use the same risk framework and speak the same language to the board. They might disagree on risk tolerance for specific decisions, but they describe risks consistently. This prevents the board from getting confused by competing narratives.

Clear escalation paths. When the CISO and CTO disagree and can’t resolve it, there’s a defined process for escalating to the CEO or board. Neither role has unilateral override authority on decisions that affect the other’s domain.

The AI Complication

AI is straining CISO-CTO relationships more than any technology shift since cloud migration. The speed at which AI capabilities are being deployed, the volume of data they require, and the novelty of the attack vectors they introduce create a perfect storm of disagreement.

CTOs are getting pressure from the business to deploy AI tools fast. CISOs don’t yet have mature frameworks for assessing AI security risks. NIST’s AI Risk Management Framework provides some structure, but applying it to specific deployment decisions is still more art than science.

The most pragmatic approach I’ve seen is establishing AI-specific governance that both the CISO and CTO co-own. They jointly approve AI use cases, jointly assess risks, and jointly present recommendations to the board. This forces alignment and prevents either side from acting unilaterally.

Getting There

If your organisation still has the CISO reporting to the CTO, changing that reporting line is the single most impactful structural change you can make. It won’t be comfortable — it reduces the CTO’s authority and creates a new peer relationship that requires negotiation. But it’s the right structure for the threat environment we’re operating in.

If the reporting line is already separate, focus on the collaboration mechanisms. Joint reviews, shared metrics, common risk language, clear escalation paths. The structure only works if the relationship works, and the relationship only works if both sides respect what the other brings to the table.

Security and technology leadership alignment isn’t a nice-to-have anymore. It’s table stakes for operating a technology-dependent business in 2026. Get it right, and you move faster with less risk. Get it wrong, and you either move too slowly to compete or too recklessly to survive.