Remote SupportWhat a board should actually expect from IT each quarter
A practical framework for the six standing items every quarterly IT paper should cover, written for directors who are accountable for technology but not engineers themselves.
Most Australian SMBs and mid-market boards receive IT updates that are either too technical to interpret, or too vague to act on. The aim of this page is to describe what useful looks like.
Six standing items
What every quarterly IT paper should cover
Movement, not metrics
Quarter-on-quarter direction, in plain English
For non-technical boards
Designed to be read by directors, not engineers
Risk register
The board should know the top five technology risks.
Named, owned, rated, and trending.
Most Australian boards already maintain a risk register for finance, people and operations. Technology risk should sit alongside them, in the same format, reviewed at the same cadence.
Purpose
To give directors a single page that names the most significant technology risks, who owns each one, the current rating, and whether the rating has moved this quarter.
What the board should see
- Five to seven named risks, no more, no fewer.
- Each risk has a single accountable owner inside the business.
- Each risk has a rating, a target rating, and a quarter-on-quarter trend arrow.
- Risks tie back to specific operational scenarios, not abstract categories.
Common patterns to avoid
- Forty risks copied from a generic register.
- Risks owned by 'IT' as a function, with no named person.
- Ratings that never move quarter to quarter.
- Risk language so abstract that directors cannot picture what would actually happen.
Worked example
"Risk 03 : Ransomware affecting financial systems. Owner: CFO. Current rating: Medium (down from High). Movement reflects independent backup testing completed in Q2 and Conditional Access tightened in Q3."
Security posture
Security posture is a direction, not a score.
Quarter-on-quarter movement against a published framework.
A single security score on its own tells the board very little. What matters is whether the business is improving, holding, or sliding, against a framework that is published and externally recognised.
Purpose
To show the board the direction of the security posture against a recognised framework, the specific controls that moved this quarter, and any controls deliberately deferred.
What the board should see
- Posture tracked against a named framework (Essential Eight, SMB1001, ISO 27001 or NIST CSF).
- Quarter-on-quarter movement shown, not just the current state.
- Controls that moved are named, with the work that drove the movement.
- Controls that are deferred are stated openly, with reasoning.
Common patterns to avoid
- A single percentage with no context.
- Marketing slides from a security vendor presented as posture evidence.
- Posture only ever moving up, never sideways or down.
- No reference to which framework is being measured against.
Worked example
"Essential Eight maturity Q3 2026. Patching ML1 (held). MFA ML2 (up from ML1, driven by phishing-resistant rollout). Application control ML0 (deliberately deferred, scoped for Q1 2027 to coincide with the laptop refresh)."
Spend
Spend should be predictable, not surprising.
Run, change, and incident-driven cost separated cleanly.
Technology spend that surprises the board is usually a sign of poor categorisation rather than poor management. Once spend is separated into run, change, and incident-driven, the conversation becomes calmer almost immediately.
Purpose
To give directors visibility of total technology spend split into the three categories that actually drive decisions: running the business, changing the business, and responding to incidents.
What the board should see
- Spend split into run, change, and incident-driven categories.
- Run spend tracked per user or per device, not as a lump sum.
- Change spend tied back to roadmap items the board has previously approved.
- Incident-driven spend always shown separately, even if small.
Common patterns to avoid
- A single 'IT cost' line in the management accounts.
- Cloud and SaaS spend buried in operating expenses with no per-user view.
- Project spend mixed in with run-rate so growth is invisible.
- No comparison to comparable Australian businesses by sector or headcount.
Worked example
"Q3 technology spend. Run: $42 per user per month, in line with Q2. Change: $84,000 (Microsoft 365 E3 to E5 migration, board-approved May). Incident-driven: $3,200 (one phishing incident, contained inside four hours)."
Roadmap
The roadmap should be visible twelve months out.
Confirmed, planned, and proposed work, distinguished plainly.
A technology roadmap presented to a board should show what is confirmed, what is planned, and what is proposed. Conflating the three is one of the most common patterns we see in environment reviews.
Purpose
To give directors a twelve-month forward view of technology work, separated into confirmed (approved and resourced), planned (scoped, awaiting approval), and proposed (under investigation).
What the board should see
- Twelve-month rolling view, refreshed each quarter.
- Work items separated into confirmed, planned, and proposed.
- Each item linked back to a risk, a strategic objective, or a regulatory requirement.
- Dependencies between items shown plainly.
Common patterns to avoid
- A list of vendor product names with no business context.
- Roadmap that only shows the current quarter.
- Confirmed and proposed work shown identically, leading to false expectations.
- Items that have been on the roadmap for two or more quarters with no movement.
Worked example
"Q4 2026: confirm laptop refresh (capex approved June). Q1 2027: plan Microsoft 365 backup migration (vendor selection underway). Q2 2027: proposed identity governance review (subject to vCISO engagement)."
Incidents
Incidents are an input to governance, not a failure to hide.
Number, severity, mean time to recover, and lessons.
Mature organisations report incidents to their board calmly. The board wants to see that incidents are being detected, classified, contained, and learned from. Hiding incidents is almost always more damaging to a board's confidence than reporting them.
Purpose
To give directors a true picture of operational technology incidents this quarter: how many, how severe, how quickly they were contained, and what changed as a result.
What the board should see
- All incidents counted, including minor ones, with severity classification.
- Mean time to detect and mean time to recover, tracked quarter-on-quarter.
- Each major incident has a one-paragraph post-incident summary in the paper.
- Lessons learned are tied to specific roadmap items or policy changes.
Common patterns to avoid
- Only severity-one incidents counted, everything else hidden.
- Phrases like 'no significant incidents' with no underlying numbers.
- Post-incident reviews never reaching the board.
- Lessons that never change anything in subsequent quarters.
Worked example
"Q3 2026: 14 incidents recorded. One severity-two (phishing-led mailbox compromise, contained inside four hours, no data exfiltration, OAIC threshold not reached). Mean time to recover 2.1 hours, down from 3.4 hours in Q2. Lesson: legacy auth blocked tenant-wide, completed Q3."
People
Technology depends on people, and people are a board matter.
Internal capability, key-person risk, and training cadence.
Boards routinely review the people risk in finance, sales and operations. Technology people risk is reviewed less often, and when it is, the conversation tends to focus narrowly on whether the helpdesk is staffed. The framing below is broader.
Purpose
To make visible the people side of technology: who owns what internally, where key-person risk sits, and whether the workforce as a whole is being trained to operate safely.
What the board should see
- Named internal IT capability, even where most work is outsourced.
- Key-person risk identified for both internal staff and provider personnel.
- Security awareness training cadence stated, including completion rates.
- Privileged-user training treated as a separate, more rigorous item.
Common patterns to avoid
- 'IT' presented as a single entity with no named individuals.
- Key-person risk acknowledged only after that person leaves.
- Security awareness reduced to a single annual video.
- Training completion rates not measured or reported.
Worked example
"Internal capability: one IT lead (3 days/week), MSP for run and security, vCISO for governance. Key-person risk: IT lead is single point of knowledge for the legacy ERP; cross-training scheduled Q1 2027. Awareness training: 94 percent completion this quarter, simulated phishing click rate 4.2 percent (down from 7.1 percent)."
AI governance
AI use is now a board item, not an IT item.
Approved tools, sensitive data exposure, and ADM disclosure status.
AI tooling crossed the threshold from "interesting" to "material" inside the last twelve months. Boards are now expected to know what AI the business is using, what data it touches, and whether the business is on track for the Privacy Act ADM transparency rule that lands 10 December 2026.
Purpose
To give directors a single page that names the AI tools in use, the data categories they touch, the alignment to the Voluntary AI Safety Standard, and the readiness for the December 2026 ADM transparency rule.
What the board should see
- Approved AI tools listed by name, licence model and data categories they may process.
- Shadow AI assessed honestly, including free-tier use on personal accounts.
- Voluntary AI Safety Standard guardrails mapped to the controls actually in place.
- ADM transparency rule readiness tracked as a dated work item, not a vague intent.
- Where AI assists decisions about individuals, that fact is named and the human review path is documented.
Common patterns to avoid
- AI use described in vendor terms rather than data terms ("we use Copilot" with no detail on what it reads).
- Shadow AI not measured or assumed to be zero.
- AI governance reduced to a single line stating that there is an acceptable use policy.
- No reference to the Voluntary AI Safety Standard, the OAIC AI privacy guidance or the December 2026 ADM rule.
- AI-assisted decisions about people running without documented human review.
Worked example
"AI tooling Q3 2026. Approved: Microsoft 365 Copilot (tenant-wide, AU data boundary), ChatGPT Team (12 named licences, finance and marketing). Shadow AI: free-tier ChatGPT use on personal devices reduced from 38 percent to 6 percent of staff (Q3 acceptable use rollout). Voluntary AI Safety Standard alignment: 7 of 10 guardrails mapped to existing controls, 3 in flight. ADM transparency: privacy policy update scoped for Q4 2026, no AI-assisted decisions currently affect individuals outside HR shortlist support, which has documented human review."
The template, not just the framework
Download the quarterly board paper template.
The framework above is one half of the work. The other half is having a template a director or company secretary can drop into the next paper without rebuilding it from scratch. This is the Markdown template we use with clients, free to adopt.
No sign-up. Open in any editor. Convert to Word, Docs or PDF as you prefer.
Includes
- Seven standing items, ready to fill
- Risk, spend and incident tables
- Decisions-sought section for the close
- AI governance section added 2026
If you would like a board paper template
A board paper is a discipline, not a document.
We provide a quarterly IT board paper template, pre-populated with the six standing items above, to clients on our managed services agreements. It is also available as a standalone advisory engagement if your internal IT team or current provider would benefit from the structure.
A board paper is a governance instrument. It exists to support the directors, not the IT function.