Questions to Ask a CISO
For a board member, an engineer, or a security candidate with time in front of a CISO. Twenty questions on detection and response times, asset coverage, patching, privileged access, third parties, open pen test findings, and where security has authority.
The questions
Open any question for the note
What are you most worried about right now that isn't in the compliance report?
Why ask it
Audit reports cover what is measurable, not what keeps the job difficult. This question moves the conversation to real exposure, and a CISO who names something specific, an unsupported system or a single overloaded engineer, is describing the actual risk register.
If someone wanted to hurt this company, which three systems would they go for?
Why ask it
You are asking whether defense is prioritized or spread evenly. A ranked answer with reasons shows threat modeling. An answer that everything is protected equally usually means budget is allocated by vendor category rather than by consequence.
How would you find out you'd been breached?
Why ask it
Many organizations learn from a customer, a regulator, or an extortion note. Listen for named detection sources and for whether they have ever caught something real, because the honest version of this answer includes the paths they know are blind.
At three in the morning on a Sunday, how long between an alert firing and a person looking at it?
Why ask it
Out-of-hours coverage is where response plans quietly fail. The answer reveals whether there is a genuine rotation, an outsourced monitoring service with a contractual response window, or an inbox somebody checks on Monday.
When did you last run an incident exercise, and what broke during it?
Why ask it
Every exercise surfaces something: the contact list was stale, nobody could reach legal, the backups restored slower than expected. A CISO who cannot name the failure either did not run one or did not run it seriously.
Who declares an incident, and who decides what customers get told?
Why ask it
These two decisions are often held by different people, and the delay between them is where reputational damage accumulates. If the answer routes everything through legal and communications with no time limit, disclosure will be slow when it counts.
Has the board agreed a position on paying a ransom before it happens?
Why ask it
Deciding this under pressure, at night, with systems down, produces bad decisions. A pre-agreed position, whatever it is, means the first hours go to containment instead of an argument about payment.
How many alerts does your team see in a day, and how many get closed without a real look?
Why ask it
Alert volume against team size is the clearest measure of whether monitoring is functioning or performing. High volume with a small team means tuning has been deferred, and the alert that matters will be closed with the rest.
What share of your machines can you actually see from your tooling?
Why ask it
Coverage is rarely complete: acquired subsidiaries, lab equipment, contractor laptops, and old servers sit outside it. A CISO who gives a percentage and knows which category is missing is managing an inventory. Full coverage claims tend not to survive an audit.
How long does a critical patch take to reach everything?
Why ask it
Ask for the last one and the actual date it finished, not the policy target. The tail is what matters, because the last five percent of unpatched systems is where the initial foothold usually happens.
How many people hold admin rights they don't need, and when did you last check?
Why ask it
Privilege creep is universal and unglamorous, so the date of the last review tells you more than the policy does. If the answer is that a review is planned, assume the current number is higher than anyone expects.
Does anyone look at a vendor again after they're onboarded?
Why ask it
Third-party review is usually a questionnaire at signature and silence afterwards. The useful answer describes what triggers a fresh look: a breach at the vendor, a scope change, a contract renewal, or a set review cycle.
What did your last penetration test find, and which findings are still open?
Why ask it
The open findings list is the most honest document in a security program. Watch for how old the oldest one is, and for whether anything was accepted as a risk with a named owner rather than just left.
How do you decide what not to fix?
Why ask it
No team fixes everything, so the interesting part is who signs the acceptance and whether the business owner understands what they agreed to. A CISO with no risk acceptance process is quietly carrying the decisions personally.
Where does security slow engineering down, and what have you done about it?
Why ask it
A CISO who cannot name the friction has not asked the engineers. Look for one concrete change that made the secure route the easy route, since that is the only approach that survives a deadline.
Who do you report to, and can you take a risk to the board without their agreement?
Why ask it
A CISO reporting into the CIO competes for the same budget as delivery and may need permission to escalate. Independent access to the board or audit committee is what makes bad news reportable, and its absence shapes everything else you were told.
What's your budget relative to overall technology spend, and how did you argue for the last increase?
Why ask it
The argument matters more than the figure. Increases won after an incident, an audit finding, or a customer requirement suggest security is funded reactively; a case built on quantified exposure suggests otherwise.
How much of your team's week goes to producing evidence for audits rather than defending anything?
Why ask it
In regulated and certified environments this can consume a large share of a small team. A CISO who has measured it, and who has automated some of it, is protecting capacity. One who has not may be running a compliance function with a security title.
What happens to someone who clicks a phishing link and reports it two days later?
Why ask it
This is the culture question that matters most operationally. If the answer involves discipline or naming people in training statistics, late reporting is being encouraged, and late reporting is what turns an incident into a breach.
What would you refuse to sign off on, even if the CEO asked?
Why ask it
It tests whether there is a line and whether they have ever tested it. A CISO who can describe a time they said no, and what happened next, is telling you how much authority the role really carries here.
Talking to a CISO
Practical guidance for the conversation itself
Before the meeting
Find the reporting line
Whether the CISO reports to the CIO, the general counsel, the CFO, or the CEO explains most of what you will hear about budget, escalation, and independence. It is usually visible on the leadership page or in the last annual report.
Read what has already been published
Certification scope documents, a trust page, breach notifications, and regulatory filings tell you what has already been admitted. Asking about something already public wastes the meeting; asking what changed after it does not.
Decide what you need to leave with
A board member needs a risk they can act on. An engineer needs to know which controls will be enforced on their work. A candidate needs to know the team size, the on-call load, and who says no. Ask for that first, before the general questions.
Answers worth pausing on
- Full asset coverage or complete visibility. Neither is normal, and the claim usually means nobody has reconciled the inventory against the network.
- Policy targets quoted instead of last actual dates for patching, review, or response.
- No named blind spots. Every mature program knows where it cannot see.
- Security awareness described entirely as annual training, with phishing click rates as the only metric.
- Compliance certifications offered as the answer to a question about risk.
- An inability to name any disagreement with the business, or any time they were overruled.
Follow-ups that sharpen an answer
- When did that last happen, and what date did it finish?
- Who owns that risk by name, and have they seen it written down?
- What would have to be true for that control to fail quietly?
- How would you know if that stopped working tomorrow?
- Which part of this would you fix first with one extra engineer?
After the conversation
Write down the specific numbers and dates you were given while you still remember them: coverage percentages, patch completion times, open findings, the date of the last exercise. Those are the things you can check again in six months, and the pattern across two conversations tells you more than either one on its own. If you were told something in confidence about an unresolved weakness, treat it that way.