Questions to Ask a CIO
Questions to ask the CIO of a company, written for whoever has the time in front of the chief information officer: the CEO or a board member, a business partner, a vendor, a manager or engineer in the CIO's own organization, or a candidate deciding what to ask a CIO in an interview. The 66 questions run in six groups: priorities, budget and vendors, risk and security, systems and data, people, and the role itself. The last ten in People are the ones for a job interview.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Priorities
What are your top two or three priorities for the next twelve months?
Why ask it
Holding it to two or three makes the CIO choose, and the short list is often narrower than the published strategy. Write the answers down in their words. A request, a product or a proposal you bring later has an easier time if it serves one of them.
What is the hardest problem on your desk right now?
Why ask it
The honest answer is often not a piece of technology at all. It tends to be funding, a peer who will not commit, a supplier, or a seat nobody can fill, and if you hear a product name instead, ask what is hard about it.
Which business goal is your biggest project this year meant to serve?
Why ask it
A sharper form of the alignment question, because it needs a goal and a project in the same sentence. A good answer names the revenue line, cost or customer problem and the person in the business who owns it. If the only owner is IT, the project is a technology refresh with a strategy label on it.
How do you show the CEO and the board that technology spending is paying off?
Why ask it
Uptime and tickets closed measure IT's own effort. The stronger answers use something the business would count for itself, such as orders processed, days to close the books or hours handed back to staff. Then ask which of those figures the board actually asks to see.
What is on the plan that you expect to slip, and what is holding it up?
Why ask it
Priorities say what is wanted, and this says what is in the way: a vendor, an unfilled role, another department's people. If the thing holding it up is something you control or can influence, say so before the meeting ends.
How does a business team get a request onto your list?
Why ask it
The answer may be a queue, a steering committee or a quiet word with the right person. Where no intake path is written down, the real one runs through relationships, and it helps to know whose.
Once something is approved, how long until it's actually in production?
Why ask it
Business teams feel the wait between a yes and a working system more than almost anything else IT does. If the reply is that it depends on the project, ask about the last three things that shipped and how long each took from decision to live.
What project have you killed, and how did you know it was time?
Why ask it
Stopping work is harder than starting it. Listen for the signal they acted on and how long it had been visible before anyone moved, since a troubled project of yours would probably get about the same patience. Having no example at all is worth noticing too.
What would make you say no to a proposal in the first minute?
Why ask it
The disqualifiers are worth more than the criteria. Common ones are unfunded headcount, a new vendor relationship, and anything that touches identity, payroll or the general ledger.
What has technology changed for your customers in the past year?
Why ask it
This is the digital transformation question with the slogan taken out. A good answer is something a customer could notice: a quote that arrives faster, an order they can track, a form they no longer fill in twice. If every example is internal, ask which customer complaint IT is closest to fixing.
What are you hearing about IT from the rest of the business right now?
Why ask it
You find out which complaints have reached the top and which have not. If your own team's daily pain is missing from the list, that explains why nothing has moved on it, and you can decide whether to raise it now.
Budget
How does your budget split between keeping things running and building something new?
Why ask it
Keeping existing systems running usually takes the larger share, and what is left over is the real budget for anything new. If the two cannot be pulled apart, ask how the last new project was paid for. Quite often the money came out of another project.
If the CFO cut your budget by ten percent tomorrow, what would go?
Why ask it
This forces a ranking that the strategy slides avoid. The order reveals genuine priorities, and if the answer is that nothing could go, the budget has no slack and neither will any commitment they make to you.
Which part of your spending is growing fastest, and did anyone choose that?
Why ask it
Cloud bills and per-seat subscriptions can climb on their own, while a new hire needs a signature. Knowing which line is running ahead, and whether usage or price is behind it, is the mark of someone who reads the invoices and not only the annual plan.
How do you know whether you are spending too much or too little on technology?
Why ask it
Comparisons with other companies are only as good as what each one counts as IT, so ask what the figure includes before trusting it. The more useful reply describes what the company would have to stop doing on a smaller number and what it could start on a larger one.
How do you decide whether to build something or buy it?
Why ask it
You are hoping for a stated boundary. One common version is that anything close to how the company makes money gets built and the rest is bought. Without a line of some kind, the decision drifts to whoever pitched most recently.
Who can buy a new SaaS tool without talking to you, and how much of that do you think is happening?
Why ask it
Software bought on a department card turns up in most companies of any size. The useful reply gives a rough scale and says how it gets found, whether through expense reports, sign-in logs or a finance review. A flat claim that it does not happen here deserves a gentle second question.
What do you do when a vendor's roadmap stops matching what you need?
Why ask it
Ask for one real case, not the principle. The interesting part is what leverage they actually had: contract terms, a migration threat, a user group, or nothing at all.
Which contracts are you locked into, and when do the big ones come up for renewal?
Why ask it
A renewal date is the moment a CIO can change course, and a missed notice period can roll a contract over for another term. Ask how far ahead the review starts. If you are selling, this is the calendar your proposal has to fit, whatever your own quarter says.
Risk
What is the security risk you worry about most, and what would it take to close it?
Why ask it
The second half matters more than the first. A named exposure with a cost and a date attached is a funding request you can support, while an answer about threats in general means the worry has not yet become a plan.
How are staff taught to spot a phishing email, and how do you know it is working?
Why ask it
A yearly video and a quiz is the minimum. Fuller answers mention test messages sent to staff, a one-click way to report something suspicious, and what happens to a person who clicks. Where clicking gets people blamed they may stop reporting, so ask how that part is handled.
What personal data does the company hold on customers and staff, and who can get to it?
Why ask it
Expect the main stores to be named, such as the customer database, payroll and old backups, along with who has access to each. Privacy rules differ a great deal by country and industry, so ask which ones this company answers to and who would have to report a breach.
If ransomware locked every screen tomorrow morning, what happens in the first hour?
Why ask it
You are asking whether the plan exists outside the systems it protects. Who gets called, who has the authority to take things offline, and how people reach each other with email down should all be answerable from memory.
When did you last restore a critical system from backup as a test, and how did it go?
Why ask it
Having backups and having restored from them are separate claims. A date, a system and a duration make a complete answer, and a surprise found during the test is good news because it was found on a quiet day.
Which system would hurt the most if it went down for a day, and how long would recovery really take?
Why ask it
Set the honest estimate beside the recovery time written in the plan, because the distance between the two is the exposure. Then ask what the business would do by hand in the meantime, and whether the people who would have to do it have ever been told.
When was your last unplanned outage, and what caused it?
Why ask it
Recent incident detail shows whether there is a real post-incident habit. Listen for a root cause in terms of process and dependencies rather than a person, and for what changed afterwards.
Which outside supplier are you most exposed to if it is breached or goes dark for a week?
Why ask it
Much of the estate now sits on somebody else's servers, so part of the risk does too. Ask what the contract promises in that case, and whether anyone has checked how and when the supplier would tell them.
How is responsibility split between you and the security team?
Why ask it
Where the security lead reports to the CIO, protection and delivery can end up competing for one budget. Where security sits elsewhere, the strain tends to show up as slow approvals. Ask which decision the two of them last disagreed on and who settled it.
Which risks has the company decided to live with, and who agreed to that?
Why ask it
Accepted risk and unknown risk are different things. Knowing which items are deliberately parked stops you raising them as discoveries, and the second half shows whether the choice was made by someone with the authority to make it.
Which audit, regulator or contract takes up most of your calendar?
Why ask it
Compliance work is close to invisible from inside a delivery team and can take a surprising share of a CIO's year. Which obligations apply depends on the industry and the country, so ask which one is live right now. It often explains why unrelated requests keep sliding.
Systems
Where's the worst of the technical debt, and what would it cost to deal with?
Why ask it
Push for the one system, not the general condition. A rough figure and a rough date mean the case has already been put to finance, and you can ask what finance said. With no figure, the debt is being carried, so ask which piece of work it slows down most.
What's on your list to switch off, and what's stopping you?
Why ask it
Decommissioning is unglamorous and rarely funded, so the blockers are revealing: one team still depends on it, the data cannot be migrated, nobody knows what calls the API. This answer maps the awkward corners of the estate.
What still runs on your own servers, and is that a decision or a backlog?
Why ask it
Some systems stay put for good reasons: a license, a regulator, a machine on a factory floor that cannot tolerate a slow link. The reply sorts those from the ones nobody has had time to move, which is a truer picture than a percentage in the cloud.
Which platform decisions do you consider settled and not open for debate?
Why ask it
Mostly useful if you work there. It saves you from reopening a choice that may have taken years and a good deal of political capital to make, and it marks the edges of any architecture proposal you bring later.
When two reports disagree on the same number, who decides which is right?
Why ask it
This is a governance question disguised as a data question. The answer names an owner or it does not, and where there is no owner, each team quietly keeps its own version of the number.
What question does the business keep asking that your data still can't answer?
Why ask it
Most companies have one, often as plain as profit by customer or stock by location. Why it remains unanswered points at the real blocker, whether that is two systems that define a customer differently or a spreadsheet one person maintains.
What have you tried with AI tooling, and what did you stop doing?
Why ask it
The stopped experiments are more informative than the live ones, because they show what was measured. Answers that are entirely pilots and enthusiasm with nothing retired suggest nothing has been evaluated yet.
What are staff allowed to put into AI tools, and who made that call?
Why ask it
In many companies people were pasting documents into chat assistants before any policy was written. You want to hear a rule short enough to remember, a named owner, and some way of finding out what is really in use. Rules on data and AI differ by country and industry, so ask which ones apply to this company.
How do you decide which new technology gets a pilot and which gets ignored?
Why ask it
Without a filter, a CIO is pulled toward whatever a board member read about on a flight. Good filters are dull: a sponsor in the business, a small budget, an end date, and a rule for what happens when the pilot is over.
Which everyday tool generates the most help desk tickets, and what is being done about it?
Why ask it
Most staff judge the whole of IT on laptops, logins, wifi and the meeting room screen. The top ticket category is the cheapest place to win goodwill, so ask whether the plan is to fix the cause or to close the tickets faster.
People
How is the team organized: around systems, around business units, or around products?
Why ask it
The structure decides who a business partner calls and how many handoffs a change needs. A reorganization in the past year means roles are still settling, so find out what it was meant to fix.
How much of the team is contractors or outsourced, and is that mix changing?
Why ask it
The mix decides how much know-how leaves when a contract ends. A rising contractor share alongside flat headcount can point to a hiring freeze that nobody has announced, and it is fair to ask about that directly.
What's the hardest role on your team to fill, and why?
Why ask it
The gap names the constraint on everything else they described. Pay, location policy, and legacy technology all show up here, and the reason given tells you which one they can actually influence.
Who left in the past year that you wish you had kept, and why did they go?
Why ask it
Retention plans sound alike everywhere, while one real departure is specific. Pay, a manager, dull maintenance work and an office rule each call for a different fix, and whether the CIO knows the true reason shows how well exit conversations travel upward. No names are needed.
What skills will this team need in two years that it does not have today?
Why ask it
It turns a vague conversation about development into a named gap, and the follow-up is whether the plan is to hire for it or train for it. If you work there, the answer is also a hint about what to learn next.
What does someone on your team have to do to move up without becoming a manager?
Why ask it
Many IT departments have a single ladder, so their best engineers either take on people they do not want to manage or leave. If a senior technical track exists, the number of people on it today says whether it is real.
How do you find out what is really happening two or three levels below you?
Why ask it
Status reports turn greener at each layer on the way up. Skip-level meetings, sitting in on incident reviews and a regular shift on the service desk are all workable answers. Relying on direct reports alone is the one to notice.
What would you want a new hire on your team to have done by the end of their first ninety days?
Why ask it
The first of the questions for a candidate, and it works for a manager who has just joined too. A named system taken over or a backlog cleared means the role has been thought through. If the answer is mostly meetings and getting to know people, the job is still being defined, which is useful to know before you accept it.
Do you meet every candidate at this level, or is this role an exception?
Why ask it
A CIO who sees every candidate at this level is showing you how the department is run. One who makes an exception for this role is telling you something about the role, so ask what. Either way you find out how near the top the job sits and how often you would see this person again.
What complaint about IT is this hire meant to answer?
Why ask it
A hire is often the reply to a complaint somebody made: releases that slip, a system only one person understands, a business unit that feels ignored. Hearing it in the CIO's words tells you what you would be measured against, whatever the posting says.
Is this role funded as a permanent post or out of a project budget?
Why ask it
Some IT jobs are paid from a project's money and are expected to end or change when it goes live. Ask what happened to the people on the last big project once it closed. Contract terms and notice differ by country and employer, so check how it works in this one before you rely on the answer.
Which business teams would I be working for, and how do they feel about IT today?
Why ask it
IT has internal customers, and a newcomer inherits whatever they already think of the department. Finance may be friendly and the warehouse may have stopped calling. Knowing which is which tells you how your first meetings will start.
Which decisions could I make without bringing them to you or to a change board?
Why ask it
The same title carries very different authority from one IT department to the next. Offer examples to make it easy to answer: choosing a tool, moving a go-live date, turning down a request from the business. Whatever has to go back up is the part of the job you would not own.
In a normal week, how much of this job is planned work and how much is interruption?
Why ask it
Tickets, incidents and urgent requests from senior people can swallow a week that was meant for projects. A rough split is enough, and it is worth setting beside what the hiring manager told you. Where the two accounts differ, the manager's is probably the one nearer the work.
What has surprised people who joined your organization from outside?
Why ask it
It invites the unflattering detail without demanding it: the number of approval steps, the age of a core system, how much of the work runs through a supplier. One real surprise is worth more than a paragraph about culture.
A year from now, how would you know this hire had worked?
Why ask it
A first-quarter plan is about settling in, and this asks about results. Hope for something that could be checked, such as a system retired, an audit passed or a team that no longer waits on one person. If you take the job, bring the answer to your first review.
What would you want me to understand about this business before my first day?
Why ask it
The reply shows what the CIO thinks IT people tend to miss about the company: how it earns its money, what month-end is like, what a day on the shop floor involves. It is also a gentle way to hear where your background looks thin to them, while there is still time to say something about it.
The role
Who do you report to, and how does that shape what you can get done?
Why ask it
A CIO under the CEO usually gets to argue from growth, and one under the CFO or COO is more often asked to argue from cost. Neither is wrong, but it explains which proposals travel easily and who else you need on your side.
Which relationship with another executive most determines whether IT succeeds?
Why ask it
Often it is finance, or whoever owns the largest operational budget. Once you have the name, you understand why some projects glide through and others never get scheduled at all.
What does the rest of the executive team bring you that isn't really your job?
Why ask it
Most CIOs absorb work that landed nearby: facilities, procurement, data privacy, anything with a cable in it. The answer maps how the company sees the function, and how much of the week goes to things nobody planned for.
Where does your week really go?
Why ask it
Ask about last week, not a typical one. The split between vendors, peers, the team and firefighting shows what the job is in this company, which can be a long way from the job description.
How has the job changed since you first took it?
Why ask it
Many will describe a move from running infrastructure toward arguing for investment, along with a longer list of things they answer for. What they say they had to stop doing personally is the part worth writing down.
How did you become a CIO, and which earlier job taught you the most?
Why ask it
Good for a mentoring conversation or a skip-level, and a poor use of a sales meeting. Routes vary widely, through infrastructure, applications, consulting or finance, and the job they single out tells you what they think the role is really about.
What would you tell someone on your team who wants your job one day?
Why ask it
Expect advice about time spent outside IT: owning a budget, running an operation, presenting to people who do not care how it works. If you are that someone, ask which of those you could start on this year.
What do you wish the rest of the business understood about how long this work takes?
Why ask it
The answer is usually the unseen middle of a project: integration, testing, moving data, the compliance step nobody outside IT watches. If you work alongside this person, that is the expectation you can help reset with your own team.
What do you need from the rest of the business that you are not getting?
Why ask it
Save it for the end, and ask it only if you can deliver: as a CEO, a board member or a peer. Typical answers are a decision that has been waiting, a sponsor who skips the steering meeting, or people promised to a project and never released. Pick one you can act on and say when you will.
Talking to a CIO
Practical guidance for the conversation itself
Ask in the units they manage in
Ratios and dates, not adjectives
Run versus change budget, lead time from decision to production, incident count and severity, contract renewal dates. Questions framed this way get answered from memory. Questions framed around innovation get answered from the deck.
Anchor to a recent event
The last outage, the last renewal, the last project stopped. Specific recent events pull the conversation out of strategy language. If none comes to mind, ask who on the team would know, and whether you could talk to them.
Ask what they cannot control
Regulatory deadlines, a parent company's platform choice, a system inherited through acquisition. Naming these constraints early stops you spending the meeting on options that were never open.
If it's your own CIO
- A CEO, owner or board member is asking as the person who funds the answer. Start in Priorities and Budget and ask for figures you can check again next quarter.
- Ask the Risk questions before an incident, not after one. The ransomware and restore questions are quick to ask, and nobody enjoys hearing the answers for the first time on a bad day.
- Finish with the last question on the list, what the CIO needs from the rest of the business. A decision that has been waiting, a peer who will not release people, a budget line split across two owners: these are yours to fix.
- Do not ask for a yes or no on whether the company is secure. Ask what has been tested, when, and what was found.
If you're selling to them
- Find out who signs and at what value the approval moves up to the CFO or the board.
- Ask what the security review involves and how long it took the last comparable vendor.
- Ask which of your competitors is already inside, and in which department. Displacement and expansion are different sales.
- Ask when the incumbent contract renews. That date, not your quarter, sets the realistic timeline.
- Ask what would have to be switched off for you to be switched on, and who owns that system.
If you meet the CIO in an interview
- The last ten questions in People are written for a candidate, and the ninety-day one opens them. Its answer shows whether the role has been thought through, and it gives you something concrete to respond to.
- Ask what the on-call rotation looks like in practice, including how many pages a typical week brings.
- Ask what share of the roadmap for this year is already committed to other departments.
- Ask how the last two people in this role left, and where they went.
- Ask who you need to convince to get a technical decision made, and how long that usually takes.
- Ask which system you would inherit that nobody else wants to touch.
If it's a skip-level or a career conversation
- Pick three or four questions from People and The role. Half an hour goes quickly, and one question the CIO has to think about is worth more than ten rushed ones.
- Bring one observation from your own level that a status report would not carry, and offer it without naming colleagues.
- Leave budget cuts and contract terms to the people who own them. Asked from several levels down, those questions sound like fishing.
- End by asking what you could take on this year that would show you more of the business.
What tends to go wrong
- Asking whether technology is aligned with the business. Nobody answers no, so you learn nothing. Ask which goal the biggest project serves instead.
- Leading with trend words. A question about a named technology gets a positioning answer; a question about what was retired gets a real one.
- Confusing the CIO with the CTO. In many companies one runs internal systems and the other builds the product, and the wrong questions signal you did not check.
- Spending the whole meeting on your own request. Ask about the queue first, then place your request inside it.
- Taking a roadmap slide as a commitment. Ask what is funded and staffed, which is usually a shorter list.