Who owns security when a company has no CISO?

The short answer

In most companies without a CISO, nobody owns security. Everyone cares about it, the engineering team is often capable, and people say sincerely that they all share the responsibility. But shared responsibility only works when one person is accountable for the whole. Without that person, security work loses the competition for capacity to work that has a customer and a date attached.

What a buyer needs to see is not a job title. It is a named person whose role includes noticing when security work has been deferred, and saying so.

That person does not have to be a full-time CISO. A fractional CISO can do it. So can an executive with the responsibility formally written into their role. What does not work is assuming that because everyone cares, someone is watching.

What I hear in assessments

"We do not need a CISO because we all own security." I hear a version of this constantly in assessments.

Nobody is being evasive when they say it. They mean it. The engineering team is capable, they take security seriously, and there is no obvious gap to point at. If the assessment stopped at the interview, it would be easy to come away reassured.

It is an easy answer to accept. It sounds like a healthy culture, and in many respects it is one. The engineers are not wrong that they care. What the statement leaves out is what caring produces when nothing else is in place.

Then I look at the backlog.

The backlog tells a different story

The security and infrastructure items are there. Nobody has forgotten them. They are just always below something customer-facing, because sales has committed to a feature and that feature has a date attached.

The security work has no date and no one asking about it, so it moves. Next sprint. Next quarter. It does not get rejected. It gets deferred, repeatedly, by people acting entirely reasonably.

The time allocated to security work never matches what the team says security deserves. That gap is the finding, and it is visible in the backlog long before it is visible anywhere else.

None of this is hidden. The tickets are usually in plain sight, with their history attached. What makes the pattern easy to miss is that no single entry looks alarming. It is the repetition that tells you something.

That matters for anyone assessing a target. Interviews tell you what people believe about security. The backlog tells you what the organisation actually does with it.

Why "we all own it" usually means nobody does

Shared ownership is not a bad idea in itself. Engineers who think about security as they build are an asset. The problem is what happens when nobody holds the whole picture.

Without someone accountable for the whole, security competes for capacity against revenue commitments, and it loses every time. Not because anyone decided it should, but because nothing forces the comparison.

Each individual deferral is defensible. A committed feature for a customer is a reasonable thing to prioritise this sprint. The trouble is that no one is looking at the sum of those decisions over a year, and the sum is a security programme that exists in tickets but not in delivered work.

Why a buyer treats it as a finding

This is why missing security ownership shows up in diligence as a finding rather than a preference about how a company chooses to organise itself.

A buyer is not looking for a title. They are looking for evidence that someone's job is to notice when the security work has been deferred four quarters running, and to say so. A title with no influence over priorities would not meet that test either.

The deferred items themselves also carry weight. Work that has sat in a backlog for several quarters is work the company has already identified as necessary. To a buyer, that is known work that has not been done, and it becomes a cost they inherit.

It also says something about the future. If security work has lost to the feature roadmap every quarter so far, a buyer has little reason to expect that to change on its own after close, when there is a growth plan to deliver.

When there is a named owner, the conversation changes. Deferred items become decisions someone made and can explain, rather than drift that nobody noticed.

What to do about it

The fix is not necessarily hiring a CISO. A fractional CISO works. So does a formally chartered executive with the responsibility written down. What matters is that accountability for the whole sits with a named person, and that the person has a way to make deferral visible.

None of the steps below needs a large budget or a new department. They need someone to decide that the trade-off between security work and feature work will be made deliberately, rather than left to whatever has a date on it this week.

• Name one person accountable for security across the organisation, and write it into their role. A fractional CISO or an existing executive with a formal charter can both carry it.
• Give security work an owner and a date, the same way customer commitments have them. Work with no date is work that moves.
• Track how long security and infrastructure items have been open and how often they have been pushed back, and put that in front of leadership.
• Compare the time actually spent on security work with what the team says it deserves. If the two have drifted apart, that is the gap a buyer will find.
• Make sure the accountable person can influence priorities, not only record them.

If you are assessing a target

The question to ask is not whether the company has a CISO. It is whether anyone would notice, and say so, if security work kept slipping.

None of this is a criticism of the team. The people deferring the work are usually making a sensible call for the sprint in front of them. The finding is about structure rather than effort, and it lands better with management when it is framed that way.

• Ask who is accountable for security, and whether that is written down. "We all are" is an answer to probe, not to accept.
• Read the backlog. Find the security and infrastructure items and check how long they have been open.
• Set what the team says about security against how much time it has actually received.