Security leadership is an executive function, not a technical one

Most founders have encountered one of two versions of security leadership, and neither is the right one.

The first is the deeply technical person who can explain every vulnerability in your stack but can’t tell the board what it means for the business. Their risk updates are forty slides of jargon. Engineering respects their knowledge; nobody else understands their recommendations.

The second is the polished communicator who presents well to the board and customers but may not earn the engineering team’s trust because they don’t understand the systems they’re supposed to be protecting. Their slide decks look great. The engineers quietly ignore them.

Good security leadership is neither of these but an executive function that requires business judgment, communication skill, and technical credibility in roughly equal measure. When it’s working well, you barely notice it. When it’s not, everything from sales cycles to board confidence to engineering morale starts to degrade.

The job is translation

The single most important thing a security leader does is translate: between the board and engineering, between customer requirements and internal capability, between regulatory expectations and business reality, and between what security needs and what the company can afford.

Your board needs to understand security risk in terms they can act on: revenue impact, regulatory exposure, deal pipeline. They don’t need a list of vulnerabilities. They need to know which risks could materially affect the business, what’s being done about them, and what’s been deliberately left for later, with the reasoning behind that choice. A good security leader can deliver that in ten minutes without jargon. A poor one needs forty slides and still leaves the room confused.

Your engineering team needs security requirements in terms of architecture and workflow, not mandates handed down from above. A good security leader works with engineers to find solutions that are both secure and practical. A poor one publishes a policy and wonders why nobody follows it.

Your customers and their evaluators need confidence that you understand your own environment. The people assessing your security can distinguish between genuine understanding and rehearsed answers, and your security leader is often the person who determines which side of that line you land on.

Board security updates are where this translation skill is most visible and most consequential. Get them right and the board trusts your security leader, funds their priorities, and stays out of operational detail. Get them wrong and you end up with a board that either ignores security entirely or micromanages it.

The security leaders who fail at translation usually speak only one language. They’re technically brilliant but retreat into jargon when explaining risk to the board. Or they’re polished communicators who can’t quite earn engineering’s respect because they don’t understand the systems. The job requires fluency in business, technical, and regulatory worlds simultaneously.

The job is managing tension

Good security leadership lives permanently in the tension between competing priorities: speed versus safety, investment versus restraint, what the business needs today versus what it will need in eighteen months, what customers are asking for versus what actually reduces risk.

This tension is also where the question of full-time versus fractional leadership sits. At earlier stages, when security decisions are significant but intermittent, a few days a month of experienced judgment may be more valuable than a full-time person who doesn’t have enough strategic work to stay engaged. The fractional model generally works well when the organisation needs someone who can make executive-level security decisions, guide a small team or set of contractors, and represent security to the board and customers, but doesn’t yet generate the volume of work that keeps a dedicated senior leader fully occupied.

As the company grows, several things typically shift: the volume of security decisions outpaces what a few days a month can handle, the regulatory environment requires dedicated attention, the security team grows to need day-to-day management, or the risk profile becomes complex enough that part-time oversight creates gaps. That’s when the transition to full-time leadership typically makes sense. Many companies start fractional, use that period to build foundations, and then hire full-time when the organisation is ready, which means the full-time hire inherits a structured environment rather than a blank sheet.

Regardless of the model, the security leader who always says no is failing. They’re protecting themselves, not the business. Every refusal without an alternative is a missed opportunity to find a solution that works for both security and the product team.

The security leader who always says yes is also failing. They’ve become a rubber stamp, and the organisation has learned that security review is a formality. When something eventually goes wrong, there’s no credibility to draw on.

The job is making the trade-offs explicit and helping the business choose deliberately. The questions driving security decisions (what are we protecting, what are we willing to risk, what’s the minimum we need right now) aren’t a one-time exercise. The answers change as the company grows, as the market shifts, as customers demand more, and as the regulatory environment tightens. A good security leader keeps revisiting those questions and updating the organisation’s answers.

There are frameworks that can help with this. My Scaling Security model provides a common language for where a company sits and what security challenges matter at that stage. I’ve also developed a business-aligned security approach that derives security priorities from business objectives rather than from a textbook list of controls. Both help structure conversations about trade-offs rather than leaving them as ad hoc arguments about individual decisions.

The practical result of managing tension well is that people across the organisation generally feel like security is on their side. Engineering doesn’t dread security reviews. Sales doesn’t panic when a questionnaire arrives. The board doesn’t treat security updates as a box to tick. When the security leader has to say no, which does happen, there’s enough trust and context that the no is understood as a genuine risk assessment rather than reflexive obstruction.

What good looks like in practice

Abstract qualities are hard to evaluate, but observable behaviours are not.

The board gets a clear risk picture. No jargon, no forty-slide decks, no scaremongering to justify budget. The board understands what’s going well, what’s not, what decisions are coming up, and where the security leader needs support. The conversation is strategic, not operational.

Engineering teams feel enabled, not blocked. Security review is a conversation, not a gate, and engineers come to the security leader with questions because it’s useful rather than mandatory. When security requirements change how something gets built, the engineering team understands why.

External scrutiny runs smoothly. Customer security reviews, regulatory enquiries, and investor diligence produce confidence rather than anxiety, and the organisation speaks about its security posture with consistency and earned authority.

The security leader can articulate what they’re not doing. This is the clearest signal. A security leader who can explain which risks they’ve assessed and chosen not to address, and why, is demonstrating exactly the kind of judgment you need. One who presents an ever-growing list of things that need fixing without prioritisation is demonstrating the opposite.

They’re building capability, not dependency. The security leader’s job is to make the organisation better at security, not to make themselves indispensable. That means building processes that work without them in the room, developing security awareness across teams, and ensuring knowledge isn’t locked in one person’s head. If the security leader left tomorrow, would the organisation’s security capability survive the first month? If no, something is wrong.

What bad looks like

Bad security leadership is often less visible than good, because the symptoms show up everywhere except in the security function itself, and they tend to follow recognisable patterns.

The empire builder focuses on growing their team and budget rather than solving actual problems. Nearly every conversation leads to a request for more headcount, more tools. Security becomes a cost centre that grows faster than the company, and somehow the risk register never gets shorter. You can usually spot this pattern by checking whether the security team’s headcount growth outpaces the company’s. If it does, someone is building an organisation chart, not a security programme.

The fear merchant. Uses scare tactics to justify priorities. “We could be the next [insert recent breach]” is not a risk assessment; it’s emotional manipulation. Boards usually stop taking the warnings seriously, which means when there’s a genuine crisis, the credibility isn’t there.

The invisible bureaucrat produces policies and frameworks that nobody reads, and can show you the documentation but can’t tell you whether engineering actually follows it. Compliance artefacts are immaculate; the actual security posture is unknown.

There’s also the burned-out security leader, but that’s a different problem entirely: not bad leadership, but a structural failure in how most organisations support the role. It’s worth understanding as a separate topic, and one we’ll address in a future series.

The executive function

Security leadership at a scaling company is not a technical role with a bigger title but an executive function that happens to require technical credibility. The security leader needs to understand systems and architectures well enough to assess risk and guide technical decisions, but the actual job is judgment, communication, prioritisation, and influence.

If you’re evaluating whether you have good security leadership, whether that’s from a fractional arrangement, a full-time hire, or your CTO wearing a second hat, look at outcomes. Do your external parties trust you and do your internal teams feel enabled? Can you articulate your security position clearly and consistently, and are you making deliberate trade-offs rather than reactive decisions?

Those are the questions that matter. Everything else is detail.