← All insights

Security leadership

Before you change an inherited security function, find out what already works

What I have learned about inheriting security functions, protecting useful capability and knowing which risks cannot wait.

5 min read

Taking over a security function creates immediate pressure to show momentum. People expect a new plan, visible decisions and a clear view of what will change.

That pressure is understandable. But changing a team, supplier or control before you understand why it exists can remove protection the business is relying on. Visible activity is not automatically progress.

My starting point is simple: understand what is protecting the business today. Act immediately where the risk is clear, then make the bigger changes in the right order.

What working both sides taught me

I have worked on both sides of this problem.

In one role, I inherited an established security environment that needed stabilising and substantial change. In another, I had to build security capability after a divestment, deciding what needed to exist immediately and what could mature over time.

The situations were different, but the lesson was similar. The visible gaps were only part of the picture. I have worked through small direct teams, internal technology and business owners, consultancies and specialist providers. Each held knowledge or provided protection that was not always obvious from an organisation chart, supplier list or technology inventory.

My career has moved from hands-on technical work into broad CISO accountability. That has made me less interested in how tidy something looks and more interested in whether it works, who relies on it and what happens if it disappears.

The question is not simply, “What would I build?” It is, “What is protecting the business today, who understands it, and what could break if I change it too quickly?”

Map the function before changing it

I use five areas to build an honest view of how the function works.

Decision rights

Who can accept risk, fund remediation, pause work or approve an exception? The documented answer matters, but so does what happens in practice. Recent decisions often tell you more than reporting lines.

People and knowledge

Find the people who understand critical controls, incidents, recovery, customer commitments and difficult integrations. Knowledge held by one person can be extremely useful and a serious risk at the same time. Capture it before changing roles.

Suppliers

Understand what each supplier genuinely contributes, what access it has, who depends on it and what would be lost if the relationship changed. Apparent overlap is not automatically waste. A provider may be covering a recruitment gap, specialist skill or out-of-hours need that is easy to miss on a contract summary.

Controls and technology

For each important control, ask direct questions:

  • Who owns it?
  • What does it actually cover?
  • Is its output trusted?
  • Does anyone act on it?

A familiar product name does not prove useful protection. Equally, an inelegant control may be doing a job that cannot yet be removed safely.

Commitments

Check upcoming contractual, regulatory, customer and audit requirements before changing controls. Something that looks redundant may produce evidence or support a commitment with a near-term deadline.

Separate weakness from inherited reality

A weakness is not defined simply by being different from my preferred model.

Manual work can be a responsible temporary answer. A supplier may be covering a gap while recruitment continues. An imperfect control may still be dependable enough to protect a critical service while a better option is built.

I look at recent incidents, recovery exercises, exceptions, audit findings and how decisions were made. Where does work repeatedly fail? Where do decisions stall? Is the problem the control, its owner, available time or unclear priorities?

The history explains why a compromise exists; it does not excuse it forever. It helps me decide whether to fix, replace or temporarily protect it without blaming people for conditions they did not create.

Preserve what works

I am careful with things that have proved dependable: a recovery process that has been exercised, an escalation route that gets the right people into the room, a useful relationship with Engineering or Operations, or a control that consistently catches failure.

The same applies to institutional knowledge and practical supplier support. They can be improved or replaced, but first I want to understand the value they provide and how I will replace it. Otherwise a cleaner diagram can produce a weaker function.

Know what cannot wait

Diagnosis is not a reason to delay when the risk is clear. Active compromise, exposed privileged access, failed critical recovery capability, an unowned material vulnerability or a missed legal or contractual notification need action.

I separate immediate containment from permanent redesign. The first move may be to restrict access, add monitoring, pause a risky change or give the problem a named owner. That buys time to choose the lasting answer without leaving the business exposed.

For every temporary measure, I record what was observed, what was decided, who owns the next step and when it will be reviewed. Temporary controls have a habit of becoming permanent when nobody records the exit.

Practical checklist

First 30 days: inherited security function checklist

The aim is not to produce a finished strategy in 30 days. It is to build a reliable view of what needs protecting, what needs fixing and what cannot wait.

Understand

  • Confirm formal and practical decision rights.
  • Identify the most material known risks, incidents and overdue actions.
  • Map near-term regulatory, contractual and customer commitments.
  • Identify critical knowledge held by individuals.

Test

  • Test incident and out-of-hours escalation routes.
  • Review recovery ownership and recent exercise evidence.
  • Map critical suppliers, their access, expected outcomes and escalation contacts.
  • Identify controls that are imperfect but currently dependable.

Decide and record

  • Separate urgent containment from structural redesign.
  • Record assumptions, owners, dates and trade-offs.
  • Agree how provisional findings will be communicated.
  • Protect useful capability while the longer-term model is developed.
Download as text

Closing perspective

Security leaders are hired to improve outcomes, and difficult decisions will sometimes be necessary. But speed and sequence are not the same thing.

Understand what is protecting the organisation today. Act where the exposure demands it. Then change the function from evidence rather than assumption.