Every company I worked at made the same mistake.

They hired someone for security, exhaled, and moved on. The org went back to shipping features, closing deals, hitting targets. Security was now someone else’s problem. Specifically, mine and my team’s.

And I get it. Hiring feels like action. It looks like progress on a board slide. “We have a dedicated security function now” is a sentence that makes investors comfortable and enterprise prospects slightly less nervous. But security does not work that way.

You cannot hire your way out of a culture problem.

In every previous role, the pattern was the same. I spent the first few weeks doing a gap assessment, figuring out what existed and what did not, and then started the real work: trying to get people to care.

That second part was always harder than it should have been.

When compliance requirements needed sign-off from engineering leads, I chased them. When access reviews needed managers to confirm who still needed what permissions, I sent reminders, then follow-ups, then follow-ups to the follow-ups. Security training completion rates were something I tracked manually because nobody else was going to.

At that point, I was not doing security work. I was doing project management for tasks that should have been treated as basic professional responsibility.

Nobody was malicious. Nobody was trying to make my job harder. They just did not see security as their job. And why would they? Leadership had made it clear, not in words but in behavior, that security belonged to the security person.

This is not just my experience. A 2024 Proofpoint report found that 60% of employees either were not sure or did not believe they were responsible for helping protect their organization. That number tracks with what I saw in every team I worked with. When a CISO has to beg an engineer to complete a 10-minute access review, that is not a process failure. That is a leadership failure.

Here is a reliable way to find out how seriously a company actually takes security: wait for an incident.

In previous roles, I got calls in the middle of the night when something went wrong. That part was expected. What came after surprised me every time. Suddenly there was budget. Tools that had been rejected for months got approved in 48 hours. More resources, more executive attention, more access than I had seen in the previous year combined.

The same leaders who had treated a $100 security tool as unjustifiable spending were now signing off on five-figure contracts without blinking.

I kept thinking: this money was always there. The willingness was always there. What changed was the perception of risk.

Security investment should not require a crisis to justify it. The numbers make the case clearly. The average cost of a data breach globally reached $4.44 million in 2025, according to the Ponemon Institute. In the United States, that figure climbed to $10.22 million. A 10-year simulation by Analysys Mason comparing reactive and proactive security approaches found that reactive organizations paid roughly $17 million in direct costs, compared to $8 million for proactive ones. By the time the incident happens, you are already paying more, in time, in damage, in customer trust, than any proactive investment would have cost.

Compliance deadlines brought a different version of the same dynamic.

When an enterprise deal stalled over a missing SOC 2 report, or a prospect’s security questionnaire arrived with a two-week deadline, something shifted. The entire organization mobilized. Engineers who had ignored my access review reminders for months suddenly had time. Leaders who had been unreachable were available. Everyone wanted to know: when will we be certified?

And then we got certified. The urgency evaporated.

The org got what it needed to close the deal. The security program that made certification possible got quietly de-prioritized. In at least one previous role, the security team was cut significantly after the audit closed. The work was done. The box was checked.

That is what happens when security is treated as a project instead of a function. Projects end. Functions do not.

The mistake is not malicious. It comes from a genuine misunderstanding of what security actually is.

Security is not a certification, a tool stack, or a headcount. It is the accumulation of thousands of small decisions made by every person in the organization, every day. Whether an engineer reuses a password. Whether a manager actually reviews the access list or just clicks approve. Whether someone questions a suspicious email or ignores it.

None of those decisions belong to the security team. They belong to everyone.

When leadership treats security as something handled by the person they hired for it, they create an org where everyone else is off the hook. The security person becomes the single point of accountability for a problem that needs distributed ownership. It is a structurally impossible position.

Research backs this up. The World Economic Forum found that 96% of executives believe more organization-wide security training would help reduce cyberattacks. The awareness is there. What is missing is the follow-through. Knowing that security culture matters and actually building one are different things, and the gap between them lives in leadership behavior.

The leaders who got this right, and there were a few, did something simple. They talked about security in all-hands meetings. They asked about it in 1:1s. When a compliance task came up, they made clear it would get done, not because the security team needed it but because the company needed it.

That signal, coming from the top, changes what the org believes is important. I watched it work. I also watched what happened in organizations where it was absent.

One more thing worth saying about timing.

In early-stage companies, moving fast makes sense. Security controls add friction. Not every startup can build a security program from day one, and I do not think that trade-off is always wrong.

But there is a point where it stops making sense, and most companies miss it.

Every year without a security baseline is another year of access debt, configuration drift, and undocumented decisions that someone will eventually have to reverse. By the time the first enterprise prospect asks for a SOC 2 report or the first serious incident hits, the cleanup is not a sprint. It is years of accumulated mess compressed into months, under pressure, with a deal or a crisis making everything harder.

In previous roles, I inherited environments where security debt had been building for years. Untangling it while keeping the business running is genuinely difficult. It is also far more expensive than prevention would have been. The Ponemon Institute found that organizations with well-rehearsed incident response plans saved an average of $2.66 million per breach compared to those without. That kind of saving does not come from reacting well. It comes from preparing early.

The companies that handled this well shared one thing: a leader who decided, early enough to matter, that security was not someone else’s problem.

That decision does not require a big budget. It requires a mindset. And mindset starts at the top.

Security programs do not fail because the security person was not good enough. They fail because the organization was never built to support them. If you are a founder or CTO standing up your first security function, the most valuable thing you can do is not find the right hire. It is deciding, before they start, that security belongs to everyone.

References