How Do You Build an IT Risk Register? A Practical Template With Examples
An IT risk register is a living list of technology risks, each with a clear description, likelihood and impact rating, owner, existing controls and next action. Build it from a short workshop, keep it to the risks that matter, and review it on a fixed rhythm so it drives decisions rather than gathering dust.
Written and reviewed by The Technology Office ยท Independent technology advisory
Key takeaways
- A good IT risk register links each risk to a cause, consequence, owner, controls and a dated next action.
- Use a simple five-by-five likelihood and impact scale, and rate both inherent and residual risk so the value of controls is visible.
- Most mid-sized businesses need 15 to 30 technology risks, not hundreds, with the top handful reported to the board.
- The register only works if it is reviewed regularly and actions are tracked to completion.
The short answer
An IT risk register is a living list of the technology risks that could hurt your business, with each risk rated, owned and linked to a dated action. Build it from a short workshop, describe each risk in cause-event-consequence terms, score likelihood and impact on a simple scale, and review it on a fixed rhythm. A register of 20 well-managed risks is worth far more than a spreadsheet of 200 that nobody reads.
Why keep an IT risk register?
Technology risk is business risk. Outages stop trading, cyber incidents trigger legal obligations, and failing projects consume capital. A register makes those risks visible, assigns accountability and gives leaders a basis for prioritising spend.
It also gives directors evidence. When a board, insurer, auditor or acquirer asks how technology risk is managed, a current register with owners and actions is one of the most persuasive answers available.
What columns should the register have?
Keep the structure simple enough to maintain. A practical set of fields:
| Field | Purpose |
|---|---|
| Risk ID | Unique reference, such as TR-01 |
| Category | Cyber, availability, data, vendor, project, compliance, people, AI |
| Risk description | Cause, event and consequence in one or two sentences |
| Inherent likelihood and impact | Rating before controls, on a 1 to 5 scale |
| Existing controls | What already reduces the risk |
| Residual likelihood and impact | Rating after existing controls |
| Residual score and rating | Likelihood multiplied by impact, mapped to Low, Medium, High or Extreme |
| Risk owner | The accountable executive |
| Treatment actions | What will be done to reduce the risk further |
| Action owner and due date | Who does it, and by when |
| Status and trend | Open, in progress or closed; improving, stable or worsening |
| Last reviewed | Date of the last review |
How do you write a good risk description?
Vague risks such as "cyber attack" or "system failure" are hard to manage. Use a cause, event and consequence structure:
- Weak: "Ransomware."
- Better: "Because MFA is not enforced on all remote access and backups are not tested offline, a ransomware attack could encrypt core systems, causing several days of lost trading and potential notification obligations."
The better version tells you what to fix. Enforcing MFA and testing offline backups become the obvious actions.
What does a sample IT risk register look like?
Here is an illustrative extract for a mid-sized professional services business. Your risks, ratings and controls will differ.
| ID | Risk (cause, event, consequence) | Residual L | Residual I | Rating | Owner | Next action and due |
|---|---|---|---|---|---|---|
| TR-01 | Incomplete MFA coverage on remote access means stolen credentials could enable ransomware, halting operations | 3 | 5 | High | COO | Enforce MFA on all remote access and admin accounts within 30 days |
| TR-02 | Backups have never been restore-tested, so recovery after an incident may fail or take far longer than expected | 3 | 4 | High | COO | Full restore test of the practice management system this quarter |
| TR-03 | Reliance on a single MSP with no exit plan or performance reporting could leave the business without support | 2 | 4 | Medium | CFO | Define service levels and an exit plan at the next contract review |
| TR-04 | The core line-of-business system is out of vendor support, creating security and stability exposure | 4 | 4 | High | CEO | Business case for replacement or upgrade to the board next quarter |
| TR-05 | Staff use unapproved AI tools with client data, risking confidentiality and privacy breaches | 4 | 3 | High | General Counsel | Publish an AI acceptable use policy and an approved tool list this month |
| TR-06 | Leavers keep access to SaaS apps because offboarding is manual, enabling data loss | 3 | 3 | Medium | HR Manager | Automate offboarding via the identity platform; monthly access review |
| TR-07 | No documented incident response plan, so the response to a cyber event would be slow and uncoordinated | 3 | 4 | High | COO | Draft the plan and run a tabletop exercise within 60 days |
| TR-08 | Key system knowledge sits with one internal staff member, so their absence would stall changes and support | 3 | 3 | Medium | CEO | Document critical procedures and cross-train a second person |
How should you rate likelihood and impact?
A five-point scale for each is enough. Define the levels in business terms so ratings are consistent:
| Score | Likelihood | Impact |
|---|---|---|
| 1 | Rare: not expected in the next five years | Minimal: negligible cost or disruption |
| 2 | Unlikely: could occur within five years | Minor: brief disruption, small cost |
| 3 | Possible: could occur within two years | Moderate: a day or more of disruption, noticeable cost or customer impact |
| 4 | Likely: expected within a year | Major: multi-day outage, regulatory notification, significant cost |
| 5 | Almost certain: expected within months | Severe: threatens viability, serious legal or reputational harm |
Multiply likelihood by impact for a score out of 25. A common banding is 1 to 4 Low, 5 to 9 Medium, 10 to 16 High and 20 to 25 Extreme. Agree in advance what each band means: for example, Extreme risks need an executive-approved treatment plan within a set number of days.
How do you build the register from scratch?
- Gather inputs. Review recent incidents, audit findings, insurer questionnaires, vendor contracts and any existing risk lists.
- Run a 90-minute workshop. Include operations, finance, IT or your MSP, and someone who understands customers. Ask what would stop the business, leak data or waste significant money.
- Draft and consolidate. Merge duplicates and rewrite each risk in cause-event-consequence form.
- Rate and assign. Score inherent and residual risk and name an executive owner for each.
- Agree treatments. For High and Extreme risks, set specific actions with owners and dates.
- Set the rhythm. Schedule reviews and decide which risks go to the board.
If you want an independent baseline first, an IT department audit can surface risks internal teams may not see.
How do you keep the register useful?
- Review on a fixed rhythm. Monthly at management level works well, with a deeper quarterly refresh.
- Track actions, not just ratings. A risk whose actions keep slipping should be escalated.
- Close or merge stale risks. The register should reflect today's business.
- Add risks when things change. New systems, acquisitions, AI adoption and supplier changes all create risk.
- Report the top risks upward. Directors need the five to eight most significant risks, with trend and action status, not the full register. See technology KPIs for board reporting.
Not-for-profits can find a sector-specific example in our NFP board technology risk register guide.
How The Technology Office helps
The Technology Office builds technology risk registers that leaders actually use. We are independent and vendor-neutral, so risks are rated honestly, including risks that sit with your current providers. We bring a CIO-level, board-facing perspective, so each risk is expressed in business consequences and linked to decisions directors can make.
Through our IT governance and risk consulting, we run the workshops, draft the register, set a right-sized review rhythm and translate the result into plain-English board reporting. We work with businesses of any size and industry across Australia, and we can stay on as a fractional CIO to keep the register alive.
Frequently asked questions
What should an IT risk register include?
At minimum: a risk ID, a description written as cause, event and consequence, a category, likelihood and impact ratings, the risk owner, existing controls, residual rating, planned actions, a due date and status.
How often should an IT risk register be reviewed?
Review it monthly or quarterly at a management or governance meeting, and immediately after a significant incident, change or new project. The board should see the top risks at least quarterly.
Who should own IT risks?
Each risk should be owned by the person best placed to manage it, often a business executive rather than the IT team. IT or the managed service provider may run the controls, but accountability sits with the business.
What is the difference between inherent and residual risk?
Inherent risk is the rating before controls are considered; residual risk is the rating after existing controls. Showing both helps leaders see how much protection current controls provide and where gaps remain.
Can I use a spreadsheet for an IT risk register?
Yes. For most small and mid-sized businesses a well-structured spreadsheet is enough. Governance, risk and compliance software becomes worthwhile when risk volumes, regulators or multiple business units demand it.
Mentioned services
These service and regional NSW pages expand on the topics covered in this article.
Need help applying this?
Bring in senior technology leadership without the full-time overhead.
The Technology Office works with Sydney and regional NSW businesses on embedded CIO support, Head of IT leadership, governance, vendor management, cost optimisation, crisis stabilisation, and no-cost technology reviews as a lighter first step.