An IT risk accepted on the strength of a working failure alert needs another look when that alert disappears. The register may still show the original approval while the service is operating under different conditions.
A risk register records risks, their assessment, ownership and responses. Reviewing an entry means checking whether the reasoning behind the decision still holds.
The same risk, before and after a change
In this hypothetical case, a hosted order-processing application sends failure alerts to its service team. A supplier update replaces those alerts with dashboard-only notices. A controlled check confirms that notifications no longer reach the team through the old route.
The original acceptance depended on prompt notification. ITIL risk management connects assessment with ownership, treatment and continuing review. Here, that calls for revisiting the acceptance decision, rather than simply logging the supplier update.
Entry IT-017, service availability: The accountable owner is the order-processing service owner. The risk statement remains unchanged: an application failure could remain undetected long enough to delay order processing and cause missed dispatch deadlines.
Before, 5 October 2026: The risk is accepted because tested alerts support prompt intervention, limiting the expected disruption. The alert test record provides the supporting evidence. Failures remain possible, but the assessment assumes notification will reach the service team. The next review is scheduled for 2 November 2026.
After, 19 October 2026: Dashboard-only notices invalidate that assumption. The revised entry records potentially longer disruption and references the supplier notice and controlled check. The decision is to restore alerting, with temporary acceptance under additional manual checks while the replacement is arranged. The review moves forward to 26 October 2026. The risk stays open.
Separate failure frequency from business impact
The missing alert changes detection, not necessarily how often the application fails.
Review incident evidence for any change in underlying failure frequency, then assess whether slower detection could push order delays beyond the dispatch deadline. Even with the same number of application failures, prolonged, undetected interruptions could become more likely.
The entry should make that distinction clear. “Supplier changed monitoring” identifies the trigger; the assessment needs to explain which notification disappeared, how its absence was confirmed and what that means for order processing.
A narrative assessment works for this example. Where an organisation uses numerical ratings, apply its defined scales and record the reasoning alongside the score. That gives the next reviewer something to examine beyond a change of colour or number.
Make the revised acceptance conditional
The risk owner, action owner and acceptance authority have different responsibilities. One person may hold several roles, but each decision still needs a clear owner.
Here, the service owner maintains the assessment and brings the changed exposure to the decision-maker. The platform lead owns delivery of the replacement alert. Under this organisation’s arrangements, the head of operations has authority to approve temporary acceptance of the remaining disruption risk.
That acceptance is conditional on manual dashboard checks every 15 minutes while orders are being processed, until the review on 26 October. The entry names the person performing those checks and requires escalation to the service owner if they cannot be maintained.
Record the replacement alert as a planned treatment until its operation has been verified. Give the platform lead a delivery deadline, separate from the time limit on temporary acceptance.
Preserve the original approval, date and rationale in the decision history. Those details explain both why the earlier judgement was reasonable and why a different response is now needed.
Define what the next review must establish
Set the evidence requirements before marking the treatment complete. For the replacement alert, the reviewer needs a controlled failure test showing that the notification reaches the responsible team, together with confirmation of who owns its ongoing operation. Record the delivery time and recipient so the result can be checked.
Use that evidence to reassess detection delay alongside the remaining application-failure and restoration risks.
Bring the review forward if a manual check is missed, the replacement test fails or another monitoring change occurs. The scheduled date is a backstop, not a reason to wait when new evidence arrives.
Before approving continued acceptance, check five things: the changed assumption, supporting evidence, revised assessment, authorised decision and next review trigger. A useful entry makes the decision understandable and shows the conditions under which it remains valid.
