Risk registers sit at the heart of every Australian government IT project's governance documentation. Ask any project manager at a federal agency and they'll confirm one exists. Ask them whether it's been reviewed this fortnight, and the answer gets murkier. The gap between having a risk register and actively using one is where a significant number of government IT projects quietly accumulate the conditions for failure.
What a risk register is supposed to do
A risk register is a structured record of identified risks, their likelihood, their potential impact, the controls in place, and who owns each item. In a functioning project, it's a live document that changes as risks materialise, are mitigated, or are replaced by new ones. In practice, many agencies treat it as a gateway artefact: created at project initiation, submitted to a steering committee, and then revisited only when something has already gone wrong.
The Australian Government's project delivery guidance, published through the Department of Finance, specifies risk management as a continuous obligation, not a one-time deliverables checklist. That framing matters. A risk register is meant to be a decision-support tool for project sponsors and executives, not a filing exercise for audit readiness.
Common failure patterns in government IT risk registers
Several failure patterns appear consistently across large government IT programs in Australia. The first is what practitioners call "risk washing": every identified risk is recorded with a medium likelihood and a medium impact, regardless of the actual evidence. This makes the register look balanced while obscuring the genuine concentration of high-severity items.
The second failure is ownership ambiguity. A risk assigned to "the project team" has no owner. Effective registers assign a named individual, typically at senior executive level, who is accountable for monitoring and responding to each risk. Without that person's name on the record, the risk floats.
Third is the absence of residual risk scoring. Agencies often record inherent risk (the exposure before controls) but skip the residual risk assessment (the exposure that remains after controls are applied). This gap matters enormously for projects using cloud platforms, where controls may be partially managed by a vendor. It also matters for programs touching sensitive personal data, where the consequences of a residual failure are regulatory as well as operational.
These gaps connect directly to broader accountability problems. As covered in our analysis of how Australian agencies handle IT project benefits realisation, the accountability infrastructure around major projects is often weakest at the points where it matters most.
What high-quality risk registers actually contain
The better examples seen across federal and state agencies share several structural features. Risk descriptions are written as cause-and-effect statements, not vague labels. "Delayed vendor delivery" is a label. "If the integration vendor fails to complete API development by milestone 4, the agency will be unable to commence parallel running, delaying go-live by a minimum of 8 weeks and triggering contractual penalties" is a risk description.
Each entry carries four distinct fields beyond the basic description: a likelihood rating with supporting rationale, an impact rating tied to specific project consequences (not generic severity bands), a named risk owner at the SES or equivalent level, and a response type. That last field matters. Responses fall into four categories: accept, transfer, mitigate, or avoid. Choosing "mitigate" without specifying the control, the timeline, and the expected residual impact is not a response; it's a placeholder.
The strongest registers also include a risk velocity field: how quickly a risk could turn into an issue if the trigger event occurred. A risk with high velocity and no pre-planned response is far more dangerous than a high-severity risk that gives the project team weeks to react. Velocity is rarely captured in standard government templates, but it's one of the first things experienced project boards ask about when scrutinising a risk profile.
The role of the steering committee
Risk registers fail at the governance layer as often as the project layer. Steering committees that receive a static risk register in a monthly pack, scan the red items, and move to the next agenda point are not performing risk oversight. They're acknowledging that a register exists.
Effective steering committees interrogate risk trends, not just current ratings. They ask which risks have increased in likelihood since the last meeting and why. They ask which mitigations have been tested and which remain theoretical. They ask whether any risks are being deliberately underrated to avoid triggering escalation thresholds. Those are uncomfortable questions, and project teams don't always welcome them. But they're the questions that surface real exposure before it becomes a public problem.
This dynamic links to a persistent issue with how change is governed in government programs. The risk register and the change log are functionally connected: an approved scope change that isn't reflected in an updated risk register is a governance gap. Our earlier coverage of how Australian agencies handle IT project change control details the points where those two disciplines diverge in practice.
Lessons from audited programs
The Australian National Audit Office has examined risk management practices in federal IT programs on multiple occasions. Its findings are consistent. Agencies generally maintain risk registers. They less consistently update them as projects evolve. They rarely demonstrate that risk information actually influenced executive decisions. And they almost never record the reasoning behind decisions to accept a risk rather than mitigate it.
That last point is important from an accountability perspective. Accepting a risk is a legitimate choice, but it should be a documented one. When a project later encounters the exact scenario described in its risk register, reviewers will ask whether the decision to accept rather than mitigate was reasonable. If no rationale was recorded, the answer becomes much harder to construct.
The ANAO's guidance on assurance reviews, published through the ANAO website, consistently references risk registers as a primary artefact in determining whether a project has adequate controls. Agencies preparing for a gateway review should treat the risk register as something that will be read by people who have seen hundreds of them, not just checked for completeness.
Practical steps for agencies wanting to improve
Four changes make an immediate difference to register quality. First, mandate residual risk scoring. The gap between inherent and residual risk is where the project's actual exposure lives. Second, require risk descriptions in cause-and-effect format. Vague labels produce vague discussions. Third, tie risk reviews to project milestones rather than calendar months. A project that moves from design to build has a materially different risk profile, and a calendar-based review cycle will miss the inflection point. Fourth, ask the project board to sign off on the top five risks each quarter, not just receive them. Accountability changes when signatures are required.
None of these changes require new software or new policy. They require governance discipline and the willingness of senior executives to engage with risk as a substantive topic rather than a compliance artefact. That's a culture question as much as a process one, and it's the harder problem to solve.