Organisations do not operate as their charts suggest.

Security is not implemented.
It emerges.

Security is often described as a function.

It is presented as:

  • a team

  • a set of responsibilities

  • a defined scope

In practice, it is none of these things in isolation.

It is the outcome of how the organisation works.

The misconception

Most organisations assume that security can be organised.

They create:

  • structures

  • roles

  • reporting lines

These imply:

  • control

  • ownership

  • accountability

The assumption is that once defined, the system will behave accordingly.

It does not.

How security actually exists

Security is distributed across the organisation.

It sits within:

  • engineering

  • operations

  • delivery functions

  • vendors and third parties

Each operates with:

  • different priorities

  • different constraints

  • different timelines

Security does not override these.

It is shaped by them.

Why the structure does not hold

Organisational charts describe authority.

They do not describe behaviour.

In reality:

  • decisions are local

  • trade‑offs are contextual

  • priorities shift continuously

What is described as:

  • ownership

becomes:

  • shared responsibility without clear boundaries

This is a familiar pattern:

  • accountability is assumed

  • ownership is unclear

How outcomes are produced

Most outcomes are not determined centrally.

They emerge:

  • at the point of delivery

  • under time pressure

  • with incomplete information

Often they are not recognised as security‑relevant.

They appear as:

  • delivery choices

  • design adjustments

  • operational compromises

Security is embedded in these.

It is rarely defined within them.

The role of constraint

Every organisation operates under constraint.

These include:

  • deadlines

  • resources

  • commercial pressure

Security competes within this landscape.

It does not sit above it.

As a result:

  • controls are adapted

  • standards are interpreted

  • risk is accepted indirectly

This is not failure.

It is how the system functions.

Why consistency is difficult

Because decisions are local, outcomes vary.

Teams working within the same organisation may:

  • interpret controls differently

  • accept different levels of risk

  • prioritise different outcomes

From the outside, this appears inconsistent.

Internally, it reflects:

different conditions producing different decisions

What becomes visible under scrutiny

When organisations are asked to demonstrate control, this structure is exposed.

They struggle to explain:

  • why similar situations produced different outcomes

  • how risk was assessed consistently

  • where accountability resides

The issue is not effort.

It is coherence.

A useful reframing

Instead of asking:

“Who owns security?”

Ask:

“Where are the decisions that shape security outcomes being made?”

This shifts the focus from:

  • formal roles

to:

  • actual behaviour

What good practice looks like

Effective organisations do not centralise every decision.

They make decision‑making visible.

This includes:

  • clear boundaries of authority

  • shared understanding of acceptable risk

  • alignment across teams

  • the ability to explain outcomes after the fact

The goal is not uniformity.

It is coherence.

Closing thought

Security is not delivered by a team.

It is produced by a system.

That system reflects:

  • how decisions are made

  • how trade‑offs are resolved

  • how responsibility is understood

Improving security is not a matter of adding structure.

The difficulty is that many of the assumptions those decisions rely on no longer hold.

“It is a matter of understanding how the organisation already works —
and making that behaviour coherent.”

Keep Reading