What a Board Should Actually Ask the CTO (The 10 Questions)

Most boards ask the CTO the wrong questions. They ask about roadmaps, sprint velocity, and whether the new data platform will be ready by Q3. These are reasonable operational questions. They are not governance questions. And the gap between what boards ask and what they should ask is where technology risk lives — quietly, until it doesn't.

I've prepared CTOs for board presentations at companies ranging from Series B scale-ups to reinsurance groups managing billions in claims liability. The boards that catch problems early share one trait: they've learned to ask questions the CTO can't deflect with a dashboard.

Here are the ten questions that actually work.

Why Standard Board Q&A Fails

A board that receives a polished 12-slide technology update every quarter is not doing technology governance — it's receiving marketing from its own team. The CTO has every incentive to present progress, capability, and upside. Risk is framed as "managed." Debt is called "legacy modernisation." Outages become "learning opportunities."

This isn't dishonesty. It's the natural pressure of presenting upward. The board's job is to construct questions that get underneath the presentation layer — not to embarrass the CTO, but to discharge the fiduciary obligation of understanding actual exposure.

The 10 Questions

1. "If our most critical system went down for 24 hours starting right now, walk me through exactly what would happen."

This is not a hypothetical. This tests whether disaster recovery planning is real or theoretical. A CTO with genuine operational maturity will give you recovery time objectives (RTOs), name the runbook, identify the people who get called, and describe the last time this was actually tested. A CTO operating on hope will tell you it's all in hand.

The red flag: "We have backups in place." Backups are not recovery. Ask when the restore was last tested in a production-equivalent environment.

2. "What does our technical debt cost us per quarter in developer productivity?"

Technical debt is not an abstract concept — it has a measurable tax on engineering velocity. Teams that have actually done this analysis can give you a number, usually in the range of 20–40% of engineering capacity consumed by debt servicing. Teams that haven't done the analysis usually haven't done the remediation either.

What a good answer looks like: "We estimate approximately 25% of engineering time goes to debt-related work — that's roughly €X in labour cost per quarter at our current burn rate. We have a roadmap to address the highest-cost items by Q4."

3. "What is our single biggest technology risk that doesn't appear in the board risk register?"

This question works precisely because it forces the CTO to disclose something that hasn't been formally escalated. Not every risk makes it into the register — sometimes because it's genuinely being managed, sometimes because surfacing it is politically uncomfortable. This question separates the two.

Competent CTOs will have an honest answer ready. It might be a vendor concentration risk, a key-person dependency, a known architectural weakness, or a compliance gap being worked through. If the answer is "nothing significant," probe further — there is always something.

4. "How many engineers, if they resigned tomorrow, would cause a production incident within 30 days?"

Key-person risk is the most underestimated technology risk in companies below ~200 engineers. It is often a single engineer who wrote the payment system, understands the legacy integration layer, or is the only person who knows how the production infrastructure was set up. If that person leaves — and they will eventually — what is the exposure?

The follow-up: "Is that knowledge documented? Has anyone other than that person successfully operated the system without them present?"

5. "What did our last three security incidents teach us, and what changed as a result?"

Every company above trivial scale has had security incidents — probes, credential exposures, misconfigurations, failed phishing attempts. The question isn't whether incidents occurred. It's whether the organisation learns from them.

A culture that learns from incidents will have a crisp answer: the incident, the root cause, the control that was added or changed. A culture that treats incidents as embarrassments to be contained will give you vague assurances about "enhanced monitoring."

6. "What percentage of our systems and data would be accessible to an attacker who compromised one set of internal credentials?"

This is a blast radius question. In a well-segmented environment, a compromised credential exposes a limited scope. In a flat network with broad service account permissions, a single compromise can cascade across the entire estate. Most companies are closer to the latter than they realise.

The answer reveals the maturity of identity and access management, network segmentation, and privilege management. It also reveals whether the CTO has actually thought about attack scenarios — or just compliance checkboxes.

7. "What is our architecture's biggest constraint on the next 3× of growth, and what is the plan to address it?"

Not 10×. Not "infinite scale in the cloud." Three times current scale, within the next 12–18 months, based on actual growth plans. This anchors the conversation to reality. It surfaces whether scalability is being actively engineered or passively assumed. It also tests whether the CTO's technology roadmap is connected to the business plan or floating independently of it.

8. "Are we in compliance with every applicable data privacy regulation, and how do you know?"

GDPR, DSGVO, CCPA, NIS2, DORA — the regulatory landscape for technology-handling organisations has materially expanded. The question is not whether the legal team has reviewed the policies. It's whether the engineering implementation actually matches what the policies claim. Consent management that works on paper but not in the production event stream is the norm, not the exception.

The follow-up that matters: "When was the last time we did a technical audit of our data flows — not a policy review, but an actual inspection of what data moves where?"

9. "If we were acquired tomorrow and the acquirer's technical team did a two-week review, what would they find?"

This question has a clarifying effect. It cuts through internal narratives and asks the CTO to think from the perspective of an informed external observer with no political stake. What would they find? Architecture documentation that doesn't exist? Undisclosed outages? Security controls that are more aspirational than operational? Key dependencies on personal relationships with vendors?

CTOs who have led or been through acquisitions will engage with this question seriously. Those who haven't may underestimate how forensic a good technical due diligence process is.

10. "What should I be worried about that nobody is talking about?"

This is the last question. Ask it after building some conversational trust. It signals that you can receive difficult information — and that you expect it. Most CTOs, given genuine space, will tell you something real. It might be team morale, a vendor relationship at risk, a technology bet that isn't paying off, or a regulatory exposure that's being quietly managed.

The boards that get honest technology oversight are the ones that have made it safe to deliver bad news. This question is how you signal that.

How to Use These Questions

These are not interrogation tactics. The goal is not to embarrass the CTO or manufacture a crisis. The goal is to build a board-CTO dynamic where real information flows — because the cost of not knowing is always higher than the cost of knowing.

I'd recommend using two or three per quarter in rotation, rather than deploying all ten at once. Pair them with genuine curiosity and follow the interesting answers. A board that asks consistently incisive questions will get consistently honest answers — because CTOs adapt to the expectations set for them.

The difference between boards that catch technology risk early and those that discover it in a crisis is not intelligence — it's the quality of the questions they ask. These ten are a starting point.

If you're a board member, NED, or executive who wants to sharpen your technology oversight practice — or if you're a CTO preparing your team for more rigorous board engagement — let's talk. I work with both sides of that relationship. Book a 30-minute discovery call and we can assess where the real gaps are.