First phase for a CIO: learn before you change
A technology leader starts with an inventory: systems, vendors, contracts and the security posture. Ask what is running, who owns it and what happens if it stops. Many companies find systems that nobody owns and contracts that renew automatically. Listing them is the first useful output.
Then meet the business leaders and learn which systems they depend on. A technology plan that ignores how finance, operations and sales actually work will fail. People are usually clear about what annoys them. They are less clear about what would break the business, so ask that question directly.
Ask when the last real recovery test took place and what was learned. Many organizations believe their backups work because the software says so. A single honest test shows what would happen in a real failure and gives you a concrete case to take to the owner.
Second phase for a CIO: repairs people can see
The second phase closes urgent gaps in security and continuity: backups that were never tested, access that was never removed, a vendor that is the only holder of knowledge. These are unglamorous and important. Then agree a prioritized roadmap with the leadership team, with a clear statement of what will not be done.
The tradeoff is fixing against replacing. Old systems often work well enough, and replacement projects consume attention. Replace only when the old one blocks the business or carries risk that cannot be managed. Be honest with the owner about this, because replacement is an appealing story.
Clear the most dangerous access problems quickly: former employees, shared passwords, administrator rights held by people who no longer need them. These fixes cost little, reduce real exposure and can be explained to non-technical leaders without jargon.
Third phase for a CIO: make it hold
In the third phase, transfer ownership of vendors and projects with runbooks that another person can follow. Test the handover by asking someone else to do a routine task from the documents. What they cannot do is the gap.
Make vendors accountable in writing. For each important supplier, record what they are meant to deliver, who in the company manages them and when the contract comes up for decision. A leader who leaves behind a clear vendor map gives the next person a head start.
How your situation changes the CIO plan
Situation changes the first questions. In a vacancy, protect continuity and find out what the previous leader alone knew. In a system rollout, the CIO is the owner of delivery, vendor discipline and user adoption. In an integration, decide which platform survives for each function and plan data migration carefully.
In a vacancy, find what only the previous CIO knew, such as passwords, vendor relationships and unwritten workarounds. In a transaction, expect requests about systems, data and security from the other side. In an integration, decide early which data must be kept and which can be retired.
Mistakes in the CIO brief
In the brief, say whether the person needs to be hands-on technical or mainly a manager of vendors and a small team. Say which systems are in play and whether security or compliance obligations apply. Asking for a strategist when the real need is someone to run the help desk wastes everyone's time.
Say what the business expects from technology in plain words. A brief that asks for innovation but funds only maintenance sets the leader up to fail. If the real need is stability and tidy contracts, say that, and you will meet candidates who enjoy that work.
Questions to settle before you brief a CIO
Before you brief, gather a plain list of systems, vendors and who supports each, even if it is incomplete. Note anything you know to be risky and anything the business is waiting for. Candidates use this list to judge the size of the job, and the gaps in it will themselves be informative.
Decide as well how much of the work is hands-on. Some companies need a leader who can fix a server. Others need someone who manages vendors and talks to the board. Asking for both in one person narrows the pool sharply, so choose the weight and describe it clearly.
Finally, tell the business why the role exists and what will change for users. Technology leaders are often judged by the problems people notice, not the risks they remove. If users understand that some quiet work is going on in the background, such as security and continuity, they are more patient when visible requests wait. A short explanation from the owner helps considerably.