Operating Model & The Questions To Ask

Reading time ~13 minutes · No technical prerequisites · Day 3, Module 3.5

Security is not a project that finishes; it is a governed capability a leader steers with questions and funding. This lesson provides the operating model to run that capability — the roles, structures, and frameworks that make good decisions the default — and, most importantly, the questions that expose your real posture rather than a comfortable version of it.

A programme, not a project

Projects end; threats do not. Treating security as ongoing capability means it is governed and run, with clear owners, a regular cadence, and real accountability, and that resilience is built in peacetime and funded continuously. The leader's role is to steer with questions and budget rather than day-to-day control. "We did a security project last year" is not a posture; a living programme is.

Who owns what

Accountability must be unambiguous. The board provides oversight and assurance that risk is managed to appetite. The CEO owns the risk — it cannot be fully delegated away. The CISO runs the programme, translating risk into controls. And everyone owns their own behaviour, because culture is itself a control. The classic failure, flagged on Day 1, is the belief that "IT owns cyber": the CISO runs the programme, but the accountability for risk sits with leadership.

Three lines of defence

A widely used governance structure separates three roles. The first line — operational management — owns and runs the controls. The second line — risk and compliance — sets policy and provides oversight. The third line — internal audit — offers independent assurance. Separating "do," "oversee," and "assure" prevents the people operating a control from being the only ones who grade it, and the independence of the third line is what gives the board confidence.

Frameworks that structure the work

Beyond a shared language, an information security management system such as ISO/IEC 27001 provides a governed, auditable way to run security, certifiable against a recognised bar and built around continual improvement. It is worth remembering that certification is evidence of a managed system, not a guarantee of safety — "we passed an audit" is a floor, never a ceiling, exactly as Day 1 warned. Frameworks structure the work; they do not equal security.

Metrics that matter

What you measure shapes what you get. Metrics that matter track outcomes and risk reduction: time to detect and respond, control coverage of the crown jewels, and backup restoration success and time. Vanity metrics — emails blocked, raw alert counts, numbers that only ever rise — feel reassuring but measure activity rather than safety. A leader should insist on the former and be suspicious of the latter.

"Are we secure?" invites a comforting yes. "When did we last successfully restore from backup, and how long did it take?" forces evidence — or reveals a gap.

The questions that expose posture

The heart of the operating model, for a leader, is a handful of evidence-forcing questions. Ask about your crown jewels — what matters most and who can reach it. Ask about detection — how you would know you are breached, and how fast. Ask about recovery — when you last tested your backups and your incident plan. Ask about risk — your biggest unfunded exposure right now. And ask about the supply chain — which supplier could take you down. You do not need to run the controls; you need to ask the questions that make evidence, or gaps, visible. Yes/no questions invite reassurance; questions that demand a date, a duration, or a name cut through it.