The Security Questions Every Executive Should Be Able to Answer

"How long would it take someone to get to our customer data if they really wanted to?"

Ask that in your next leadership meeting and watch the room. Someone looks at the IT leader. The IT leader starts a careful answer about firewalls. The CFO wonders whether this is a budget conversation. Nobody gives a number.

The uncomfortable truth is that most organizations don't know. And what they don't know usually isn't exotic.

It's rarely the sophisticated attack

When companies get breached, it's seldom because of elite hackers with custom tools. It's usually something far more ordinary:

• Someone clicked a convincing email. AI has made these far more convincing: no spelling mistakes, the right names, the right tone, sometimes a cloned voice on the phone to back it up.
• A password was stolen or reused, and nothing else stood in the way.
• A former employee or contractor still had access months after leaving.
• A system never got patched because "it's working fine, why touch it?"
• A supplier was compromised, and their access to your systems became the attacker's access.

Sophisticated attacks happen. But you have to fix the basics before they're the thing that matters.

The questions that reveal where you really stand

You don't need to understand the technology to ask these. You do need straight answers.

"Who has admin access to our systems?"

Most companies can't produce that list in under an hour. Some can't produce it at all. Every name on it is a key to the building.

"When did we last restore from our backups?"

Having backups and being able to recover from them are very different things. And ransomware now goes after the backups first, so ask whether at least one copy is kept somewhere an attacker couldn't reach or change.

"If someone were in our systems right now, would we know?"

Many small and mid-sized companies have no way to tell. Attackers often sit quietly for weeks before they act.

"What happens if our top IT person is unavailable tomorrow?"

Do passwords and critical knowledge leave with them? Is anything written down?

"If we were hit tonight, who calls whom?"

Do you have a plan? Does it say who decides whether to shut systems down, who talks to customers, who calls the insurer and the lawyers? Has anyone ever practiced it?

"Would we know if someone asked finance to change a supplier's bank details?"

Payment fraud doesn't need any hacking at all - just a believable email and a process with no second check.

If those questions make people uncomfortable, good. That's the point.

Why security is hard - and it isn't the technology

It's invisible when it works. There's no gentle warning that you're doing it wrong. Everything is fine until suddenly it very much isn't.

It's inconvenient. Make it too hard and people find workarounds, and the workarounds are usually worse than the original risk.

It costs money now to prevent something that might never happen. That's a hard sell, right up until it happens.

Start with the boring stuff

You don't need perfect security. You need good-enough security that's actually in place and actually maintained. Almost all of it is unglamorous:

• Multi-factor authentication on everything important - and phishing-resistant methods, like passkeys or security keys, for admins and finance
• Offboarding that works - access removed the day someone leaves, and regular reviews of who still has what
• Patching that actually happens, on a schedule, with someone accountable
• Training that's more than a yearly checkbox - short, frequent and realistic, including how to spot a fake request from "the CEO"
• A second check on money - any change to bank details is confirmed by phone, on a number you already had
• Backups you've tested, with at least one copy out of attackers' reach
• An incident plan you've rehearsed, even once, around a table
• Supplier access reviewed - who can get into your systems, and why

None of that is cutting-edge. All of it stops real attacks.

Making security a board conversation

The other half of the problem is communication. Technical accuracy is worthless if the people who fund security can't make a decision with it.

Boards don't need to understand endpoint detection or encryption. They need to understand business risk: what are we protecting, what happens if we fail, and what is it worth to prevent that?

So translate:

• Instead of "We need extended detection and response," try "We need to spot attackers before they shut down operations for a week."
• Instead of "Our threat landscape is evolving," try "Attacks on companies like ours are increasing, and here's what one would cost us in downtime, recovery and lost customers."
• Instead of "We have security gaps," try "We have risks that could damage customer trust and put us out of compliance - here are the three that matter most."

Frame security spending the way you'd frame any other risk decision: impact, likelihood, and the cost of prevention against the cost of failure. It isn't a cost center; it's how the business keeps the trust it has earned.

And remember what the board's job actually is. Board members aren't security experts. Their job is to understand the risk to the business, make sure enough resources are in place, hold leadership accountable, and ask the right questions. The technology leader's job is to give them what they need to do that.

The bottom line

The companies that get breached aren't always the ones with the weakest technology. They're often the ones that knew they had gaps and kept meaning to fix them next quarter.

Security doesn't have to be perfect. It has to be deliberate.

Related reading

• The "Later" Tax: What Deferred Technology Decisions Really Cost
• AI Readiness Isn't a Technology Question

Not sure how your organization would answer those questions? Let's talk. An honest look at the basics is usually the best-value security work a company ever does.