Presenting to the board as an IT leader

A board paper should make the requested decision clear before it explains the technology. This guide is for IT leaders preparing a risk update or an investment proposal for directors who need business consequences, options and an accountable recommendation.

Ask whether a reader can identify what needs deciding, what happens if the decision is delayed and which evidence supports your estimate.

Boards need business consequences and decisions explained without relying on detailed knowledge of systems or technical dependencies. IT leaders can practise making those connections.

Why IT presentations underperform in the boardroom

Two presentation patterns can obscure the decision. A technical deep dive explains systems without their business consequences. A reassurance-only update reports that work is under control without showing the evidence, exceptions or decisions required.

Check your draft for both problems. Keep technical detail that supports a decision and put supporting material in an appendix. Describe unresolved risks clearly enough for someone outside IT to challenge the assumptions.

Three questions to structure a board update

Before you open any presentation software, step back and ask what the board actually needs from this update. A useful starting point is these questions.

Are we at risk? Not "is our firewall configured correctly" or "are we patched against a specific vulnerability". Boards want to know if there is a material risk to the business that they need to be aware of, and whether management has a grip on it. If the honest answer is yes, they need to know the scale and the plan. If the honest answer is no, they need enough context to trust that assessment.

Are we getting value from our technology investment? Boards approve significant technology expenditure. They want to know whether that spend is producing returns. This does not mean you need a detailed ROI model for every line item. It means you should be able to speak coherently about how technology is enabling the business strategy, and where the gaps are.

Where are we headed? Use the business's actual planning horizon. Explain how the technology roadmap supports its objectives, which dependencies could change the plan and when the next investment decision is needed.

Use these questions to organise the paper, then check the board's requested agenda and decisions. They are a starting structure, not a guarantee that every governance requirement has been met.

Reframing technical risk for a non-technical audience

Translate the technical finding into the affected business process, likely consequences, options and evidence. Avoid both unexplained jargon and a simplified reassurance that removes important uncertainty.

Compare these two framings of the same risk.

Here is a hypothetical example, with illustrative costs rather than a reported client incident.

A technical statement might say: "We operate three Windows Server 2019 systems and need a migration plan." Microsoft's lifecycle record lists 9 January 2024 as the end of mainstream support and 9 January 2029 as the end of extended support for the listed editions.

The decision paper could instead say: "Three production applications depend on Windows Server 2019. Extended support ends on 9 January 2029. We request approval for a discovery and testing phase to establish application compatibility and migration cost. The planning estimate is GBP 85,000, subject to supplier quotations and a pilot. The application owner will report confirmed costs and a migration schedule at the next decision point."

That wording separates a verified supplier deadline from an estimate. It also gives the board an action without inventing a previous breach or claiming every future vulnerability will be exploitable. Check application and hardware support separately; their deadlines may be earlier than the operating system's.

The one-page risk summary

A one-page IT risk summary can make a discussion easier to prepare. The summary fits on a single side of A4 and describes the risks in prose.

Choose a manageable number of material items. Each should name the risk, explain its assessment using the organisation's criteria, describe current controls and gaps, name the owner, and state any decision required. Link the supporting evidence.

Test readability with a colleague who was not involved in the technical work. Ask them to identify the requested decisions and uncertainties. If they cannot, revise the paper before circulating it.

For example, a hypothetical risk entry could say: "Order processing depends on one database server. The last isolated restore took six hours against a four-hour recovery objective. The operations director owns the business impact; IT owns the recovery improvement. Approve a tested recovery option after costs and rollback have been reviewed." This shows a failed test and a decision, rather than an unsupported assurance that the service is resilient.

What gets boards to pay attention

Use the following practices to prepare a discussion, then seek feedback on whether they helped.

Confirm the agenda. Speak with the Chair or responsible executive about the decisions and concerns the paper needs to address. Include urgent risks even when they are not the expected topic.

Show comparable evidence over time. Report the same service definition, measurement period and exclusions when comparing reliability. Explain changes in workload or monitoring that affect the comparison. A rising percentage does not by itself establish which intervention caused it.

Record uncertainty. When an answer is unknown, state what evidence is missing, who will obtain it and when a decision can be made. Do not improvise a number to complete a slide.

Connect technology to business outcomes consistently. Every significant technology decision should have a business outcome attached to it in your framing. Explain how a firewall upgrade protects supply chain relationships, or how an ERP migration affects operating efficiency and staffing needs. Make the business case explicit, even when it feels obvious to you.

The quarterly rhythm that works

Agree the reporting rhythm with the board and risk owners. A quarterly strategy discussion and monthly exception report are one possible arrangement; material incidents or urgent decisions should not wait for that cycle.

Use the quarterly session to discuss strategy. This is where you present the IT roadmap, discuss material risks in detail, walk through the performance of major technology investments, and have the longer conversations about direction and capability. Request enough time for the actual decisions. The appropriate slot depends on the agenda and complexity, not a universal minimum.

A monthly exception report can flag material changes and decisions between strategy meetings. Agree whether the IT leader needs to attend and how directors can ask questions. Evaluate the arrangement from the quality and timeliness of decisions, rather than assuming a reporting frequency creates engagement.

Prepare the next board update

Practise explaining the recommendation, alternatives and uncertainty, and seek feedback from finance and the business owner. Clear communication supports scrutiny; it does not guarantee approval, a larger budget or a particular response from directors.

Test the paper before presenting it. Before your next board update, ask yourself: does this answer "so what?" If it does, you are probably ready to present. If you need help shaping your IT leadership approach or preparing for board-level conversations, my IT management consulting practice works with IT leaders on strategy, communication, and executive presence.

Book a consultation with your draft board paper and the decision it needs to support. We can check whether the costs, uncertainties and ownership are clear before you circulate it.