Twelve Questions to Ask Your CISO

Start here. The answer tells you whether your CISO thinks about the business or only about the technology.

What you should hear

• Three to five risks, described in business terms: we could not take orders, we could not pay staff, we could leak the data our customers trust us with.
• Which systems and suppliers those depend on.
• Roughly how long the company could cope without each one.

Red flags in the answer

• A long list of technical threats with no link to what the business does.
• "Everything is critical." If everything is, nothing is.
• Industry headlines instead of risks specific to this company.

Follow-up

"Who in the business owns each of those risks, and have they agreed how much of it we are willing to accept?" A good answer names business leaders, not just the security team.

Why this matters: every later question builds on this one. Budget, supplier risk, recovery and reporting only make sense against a short list of the things the company cannot afford to lose. If the board and the CISO agree on that list, most other conversations get shorter and clearer.

Listen for how the CISO arrived at the list. A good answer mentions conversations with business leaders, not only security tools. If the CISO has not talked to the people who run sales, operations or finance, the list is probably a guess.

Rule of thumb:If the CISO's top risks would be the same at any company, they are not yet the top risks for yours.

Boards make decisions in money. Asking the CISO to talk the same way is fair, as long as you accept that the numbers will be estimates.

What you should hear

• A range for the likely cost of the main risks, not a single precise figure.
• How the range was worked out, in plain words, and what assumptions it rests on.
• How the range would change if a planned investment went ahead.

Red flags in the answer

• Very precise numbers with no explanation of where they came from.
• A refusal to estimate at all because "cyber is too unpredictable".
• Generic industry averages presented as if they were this company's numbers.

Follow-up

"Which single assumption, if wrong, would change this number the most?" A good CISO knows where their estimate is weakest.

Why this matters: without some sense of scale, the board cannot weigh a security request against a new product, a hire or a price cut. A range also lets you set limits, such as the largest loss the company could absorb without changing its plans, and ask whether insurance covers the rest.

Do not expect the first estimate to be good. Expect it to improve. Ask to see the same range next year and what changed it. A CISO who updates their estimate when they learn something is doing the job well.

Rule of thumb:Ask for ranges, and for the reasoning behind them. Precision without reasoning is decoration.

There is no correct figure for security spend. What you can check is whether the money follows the risks the CISO described in Q1.

What you should hear

• How spend maps to the top risks.
• What is committed (licences, contracts, salaries) and what can be moved.
• What the CISO would stop paying for if the budget were cut, and what they would add if it rose.

Red flags in the answer

• The budget is justified only by comparison with other companies.
• Spend has grown each year but nobody can say what risk went down.
• Large tools are owned but not fully used or watched.

Follow-up

"If we gave you no extra money next year, what would you stop doing, and what risk would that leave?" The answer shows how well the CISO understands their own priorities.

Why this matters: security spend tends to grow in steps after incidents or headlines, then stay at the new level whether or not it is still aimed at the right things. A yearly look at what each major line achieves keeps the budget tied to the risks.

Ask too about spend outside the security budget. Engineering, IT and business teams often buy security tools themselves. The total can be larger than the line the board sees, and it may overlap.

Rule of thumb:Ask what spend achieved, not how much was spent.

Many serious incidents start at a supplier: a cloud host, a payroll firm, an IT provider with access to your network. The company is still accountable to its own customers when that happens.

What you should hear

• A short list of the suppliers that hold sensitive data, have access to your systems, or would stop operations if they failed.
• What the contracts say about telling you about a breach, and how quickly.
• A plan for the first day after a key supplier announces an incident.

Red flags in the answer

• Every supplier gets the same questionnaire, regardless of risk.
• Nobody knows which suppliers have admin access.
• "They are certified, so we are covered." A certificate is not a plan.

Follow-up

"If our most important supplier announced a breach tomorrow morning, who would call whom, and what would we decide by lunchtime?"

Why this matters: the company's attack surface now includes every supplier with access to its data or systems. A board that only discusses its own controls is looking at part of the picture.

Ask whether the company has ever walked away from a supplier, or changed a contract, because of security. If the answer is never, supplier reviews may be paperwork that does not change decisions.

Rule of thumb:The supplier you have never discussed at board level may be the one with the keys.

In an incident, confusion about who decides costs more time than almost anything else. This is a question to settle while things are calm.

What you should hear

• One named incident lead, and a deputy.
• Who can decide to take systems offline, even if it stops trading.
• Who decides on outside help, legal advice and communication.
• When and how the board is told, and what threshold triggers that.

Red flags in the answer

• "It depends on the situation" with no named people.
• The plan relies on email or chat systems that may be down.
• The board has never agreed which decisions it wants to be part of.

Follow-up

"Show me the contact list you would use if email were down. When was it last checked?"

Why this matters: the first day of an incident sets the course for the weeks that follow. Systems are shut down or not, evidence is kept or lost, and the first message to staff and customers goes out. Those calls need clear owners who already know they own them.

Ask about deputies too. Incidents do not wait for holidays. If the incident lead or the CEO is unreachable, someone else must be able to decide without waiting.

Rule of thumb:Decide who decides before you need to decide.

A plan that has never been practised is a guess. Exercises reveal gaps in a safe setting: missing phone numbers, unclear authority, steps nobody knew they owned.

What you should hear

• The date of the last exercise and who took part, including senior leaders.
• What went wrong. Every honest exercise finds something.
• What was changed afterwards, with owners and dates.

Red flags in the answer

• "It went perfectly." Then it was too easy, or the findings were not written down.
• Only the technical team took part.
• The same findings appear year after year.

Follow-up

"What was the most uncomfortable moment in the last exercise, and what did we change because of it?"

Why this matters: in a real incident people fall back on what they have rehearsed. If senior leaders have never practised together, they will meet the hard decisions for the first time under the worst conditions.

Vary the scenario. Ransomware is common, but so are supplier breaches, insider misuse and the loss of a key cloud service. A different scenario each year tests different parts of the plan and different people.

Rule of thumb:An exercise that finds nothing was not hard enough.

Many companies have backups. Fewer have proved they can restore from them under pressure, and fewer still have checked that an attacker inside the network could not delete them too.

What you should hear

• The date of the last full restore test of an important system, and whether it succeeded.
• How long that restore took, compared with how long the business could cope.
• Whether some backups are kept where an attacker with admin access could not reach them.

Red flags in the answer

• "Backups run every night" with no mention of a restore test.
• Recovery time estimates that have never been tested.
• Backups managed with the same accounts as the systems they protect.

Follow-up

"If our main systems were encrypted tonight, what would be working by Friday?"

Why this matters: when prevention fails, recovery is what decides whether an incident is a bad week or a crisis for the company. It is also one of the few security questions with a clear, testable answer.

Ask what would be restored first and who decided that order. Restoring everything at once is rarely possible. The order should follow the business priorities from Q1, agreed in advance rather than argued about during an outage.

Rule of thumb:A backup you have never restored is a hope, not a control.

If your company is listed in the United States, there is a specific rule to know. The SEC requires a company to determine whether a cybersecurity incident is material without unreasonable delay after discovery. If it is material, the company must file a Form 8-K under Item 1.05, generally within four business days of that determination. The clock starts at the materiality decision, not at the attack. Disclosure can be delayed only in narrow cases where the US Attorney General decides immediate disclosure would pose a substantial risk to national security or public safety.

Companies outside the US, or not listed, may have other reporting duties to regulators or customers. Ask your counsel which apply.

What you should hear

• A named group that makes the materiality decision, usually including legal, finance and the CISO.
• How the CISO's facts reach that group, and how quickly.
• A written record of how each decision was reached.

Red flags in the answer

• Nobody is sure who decides.
• The process starts only once the investigation is complete.
• Materiality is treated as purely a technical question.

Follow-up

"Walk me through the last time we had to consider whether something was material. Who was in the room?"

Why this matters: the decision is made under pressure, with incomplete facts. A group that has never practised it will be slower and less consistent than one that has.

Rule of thumb:The four business days start when you decide. Make sure you know who decides.

Many security reports to boards count activity: attacks blocked, emails filtered, training completed. Those numbers say the team is busy. They do not say the company is safer.

In the United States, listed companies must describe in their annual report how the board oversees risks from cybersecurity threats. NIST's Cybersecurity Framework 2.0 also places oversight inside its Govern function. Both are reasons to make sure the reports you receive actually support oversight.

What you should hear

• A small number of measures that change when risk changes.
• Trends over time, with an explanation when something moves the wrong way.
• Decisions the board is being asked to make, clearly flagged.

Red flags in the answer

• Every chart goes up and to the right, every quarter.
• Large numbers with no context.
• Nothing the board is asked to decide.

Follow-up

"Which of these numbers would worry you if it moved, and what would you do?"

Why this matters: a board that only ever sees reassuring numbers cannot challenge, and cannot later show it oversaw the risk with care. Clear, honest reporting protects both the company and the directors.

Rule of thumb:If a report would read the same in a good quarter and a bad one, it is measuring activity.

CISOs often carry responsibility without matching authority. This question gives them a safe way to say so, and gives you a way to fix it.

What you should hear

• A specific answer: a decision, a reporting line, access to a committee, a budget line, a hire.
• Where they feel unable to act on a risk they own.
• Which business leaders they struggle to get decisions from.

Red flags in the answer

• "Nothing, everything is fine," every year.
• A CISO who only ever meets the board with their manager present and never privately.
• Requests that have been raised before and quietly dropped.

Follow-up

"Is there a risk you have raised that you feel has not been decided? Who owns that decision?"

Why this matters: if the CISO lacks authority over the systems they are judged on, problems will be raised but not fixed. The board is one of the few bodies that can change reporting lines, settle disputes between executives and make sure security has a voice in big decisions.

Watch for a mismatch between what the CISO is held accountable for and what they can actually change. If a CISO is responsible for cloud security but has no say over cloud spending or design, the board should know that.

Rule of thumb:A CISO who never asks for anything is either unusually lucky or not telling you something.

AI tools are arriving faster than most approval processes. Staff use them to write, code and analyse, often before anyone has decided whether they should. The board does not need to understand the models. It needs to know the company is in control of how they are used.

What you should hear

• A list of the AI tools and systems in use, including those bought by business teams.
• Clear rules on what data may and may not go into them.
• Who approves a new AI use, and how risk is checked before it goes live.
• Who owns the decision when an AI system acts on its own, such as sending messages or changing records.

Red flags in the answer

• "We have banned it." Bans without alternatives push use out of sight.
• No one can say which tools staff actually use.
• AI is treated as only an IT matter, with no business owner.

Follow-up

"What is the most sensitive data that has gone into an AI tool here, and who decided that was acceptable?"

Why this matters: AI can change how a company handles data, makes decisions and serves customers, and it can do so quickly. A board that hears about AI only as an opportunity misses half of what it is overseeing.

Rule of thumb:You cannot govern what you have not listed.

After an incident, boards often find that someone inside the company knew about the weakness. It was in a report, a ticket or a conversation, and it never reached the board. The question that would have surfaced it is simple.

"What are you worried about that you haven't told us yet?"

Ask it plainly. Ask it privately. Then wait, and do not fill the silence.

What you should hear

• Something specific. A system that cannot be patched, a supplier they do not trust, a risk someone accepted that they think was a mistake.
• Why it has not come up before: no forum, no time, or a sense the board did not want to hear it.
• What it would take to deal with it.

Red flags in the answer

• "Nothing." Every CISO worries about something.
• A vague answer followed by a change of subject.
• A worry that turns out to have been raised internally many times without action.

Follow-up

"If this were to cause an incident next year, what would we wish we had done this month?"

Why this matters: most of the questions in this book test the company's preparation. This one tests whether the board is told the truth.

Rule of thumb:The board sets the tone for bad news. Reward the people who bring it.