Cyber and AI are leadership issues, not technical ones

There is a particular pattern I've seen, more times than I can count, in boardrooms across regulated and mission-critical sectors. It goes like this. The CISO presents a quarterly cyber update. The slides are dense. Heat maps, risk registers, threat intelligence summaries, control maturity scores. The board listens politely. There are a few questions, mostly clarifying. The Chair thanks the CISO. The agenda moves on.

And afterwards, in private conversations I've had over the years, board members tell me they don't really understand what they just signed off on. They tell me they didn't want to ask the obvious question in the room. They tell me they're worried, vaguely, but they couldn't tell you what they're worried about.

This is the pattern I want to talk about. Because it isn't a problem with the CISO. It isn't a problem with the slides. It's a problem with how most boards have been taught to think about cyber, and increasingly, about AI.

Both are being treated as technical issues. They should be treated as leadership ones.

What I mean by that

When I say cyber and AI are leadership issues, I don't mean that boards should learn to read packet captures or write Python. I mean something more specific: that the decisions these topics force onto an organisation are not, at their core, technical decisions. They are decisions about risk appetite, capital allocation, culture, ethics, and accountability. Those are the things boards exist to decide. Delegating them to specialists isn't oversight. It's abdication dressed up as deference.

Take a typical example. An organisation is asked to approve a new generative AI tool for customer service. The CTO presents a recommendation. There's a vendor selected, a pilot proposed, a budget. The board nods it through. But the real decisions buried inside that proposal are not technical. They include: what level of customer harm are we willing to accept from hallucinated responses? Who is accountable if the AI gives advice that causes financial loss? How do we explain this to our regulator? What happens to the people whose jobs change as a result? Who owns the data being used to train the model, and what happens when they ask us to delete it?

None of those questions are technical. All of them are board questions. And almost none of them get asked, because the topic has been mentally filed under "technology", and technology is what we delegate.

The same is true of cyber. The decisions that matter to a board are not "have we patched our servers." They are: what level of disruption to operations are we willing to absorb before we pay a ransom? How would we know if our supplier's supplier had been breached? If our most senior executives are being targeted with sophisticated impersonation attacks, and they are, what do we do about it? Are we, as an organisation, structurally honest about the risks we are running, or are we performing assurance to make ourselves feel better?

These are not technical questions. They are questions about who we are and how we want to lead.

Why the framing matters

The framing matters because it determines who feels accountable.

When boards treat cyber and AI as technical, they unconsciously locate accountability with the technical function. The CISO is "responsible for cyber." The CTO is "responsible for AI." Board members feel they have done their job by receiving the update. If something goes wrong, it will be someone else's fault. Someone whose name is on the relevant slide.

But this isn't how accountability actually works in regulated environments. When a serious cyber incident reaches the public domain, it isn't the CISO's name in the press. It's the CEO's. When an AI system causes harm, it isn't the head of data science being cross-examined. It's the Chair. The accountability has always been at the top. The framing has just allowed the people at the top to pretend otherwise.

This is the gap I want to close. Not by making boards more technical, that's the wrong target, and it's also unachievable, but by giving them the confidence to engage these topics as the leadership topics they are.

What that looks like in practice

A board that has done this work asks different questions. They don't ask the CISO "is our cyber security good?" because they know that's an unanswerable question. They ask: "What are the three things you most need from us as a board, that you're not getting?" They ask: "If we were going to be in the press in twelve months, what would the story be?" They ask: "Where are we performing assurance to ourselves rather than achieving it?"

They are not technical questions. They are questions a leader asks. And the CISO who receives them, instead of the usual heat-map nodding, knows they are working with a board that actually understands what they do.

The same shift happens with AI. The board that treats AI as a leadership issue doesn't ask "is our AI safe?" They ask: "What kinds of decisions are we now letting machines make on our behalf, and have we agreed that as a leadership team?" They ask: "Where in our organisation is AI being used in ways the executive team doesn't know about?" They ask: "If a customer asks us how a decision about them was made, can we answer honestly?"

None of those questions require a technical background. All of them require leadership.

The harder truth

The reason this matters now, more than it did five or ten years ago, is that the velocity of these topics has overtaken the speed at which most boards have adapted. Cyber threats are no longer episodic; they are constant. AI is no longer a future consideration; it is already inside most organisations, often without leadership knowing where. Resilience is no longer a business continuity plan in a binder; it is the daily question of whether you can keep operating when something breaks.

Boards that continue to treat these as technical specialisms will keep delegating decisions they should be making. And one day, and it is increasingly when, not if, they will discover, in the worst circumstances, that the people they delegated to were never actually authorised to take those decisions on their behalf.

The good news is that the shift is not difficult. It doesn't require technical training. It requires a change in how boards see their own role. It requires confidence. The confidence to engage with these topics as the leadership questions they are, rather than retreating into the comfortable position of polite, uncomprehending oversight.

That confidence is buildable. And it starts with a single decision: that these are board topics, not delegated ones. Everything else follows from that.

David Goodacre OBE FCIIS is the founder of AmEliz, an independent advisory practice supporting boards and executive teams on cyber, AI and resilience.