From driver to risk event and consequence

A risk register is more than a list of worries. For a service with a defined boundary, write the statement so a reader can identify a driver or preceding condition, an uncertain event and the effect on the service objective. For example: if server power is lost and backup power does not start within ten minutes, appointment numbers may not be issued, delaying requests received during the interruption. Heat might be a contributing driver; power loss is the event; delayed issuance is the consequence. Writing only 'missing generator' does not specify the threatened service or the conditions of harm. Writing only 'delayed requests' describes an effect without its possible cause.

Identify evidence sources that relate to the scope card: incident records, dependency diagrams, equipment maintenance and an interview with the process owner. An operator's recollection and a system measurement can both matter, but they have different reliability and limits. Separate observed events from anticipated ones. A report that a user could not log in may reflect a forgotten password rather than an outage. Check incident code, time and user path before counting it. Reports about the same outage are not independent outages for a frequency calculation. Preserve that distinction in the register so later analysis does not exaggerate recurrence.

An existing control is something operating now that changes the chance of an event or the size of its effect, not a proposal on an improvement list. Record its name, owner, last test and reviewable result. A generator on an asset diagram does not prove it can carry the booking server's load; a contact list does not prove its numbers still work. A control may be marked 'present, effectiveness unverified'. Do not discount risk as though the control works in that state. Link each control to the part of the chain it addresses: prevention may reduce the chance of power loss, while impact mitigation may shorten restoration. This link prevents a receptionist's training from being offered as a cure for the power supply.

Use disaster vocabulary in its context. UNDRR describes disaster risk through the interplay of hazard, exposure, vulnerability and capacity; that can help frame a flood or storm scenario, but an ordinary technical failure is not automatically a disaster. A service register may use threat source, exposure and weakness if the team defines them. Do not import regional disaster frequency or geography into a local service without evidence. If the facts reveal a safety or privacy effect, pass the information promptly to the role responsible for containment under the organization's procedure, then continue the register analysis. Waiting for a score must not postpone urgent containment.

Test the causal chain against an alternative before fixing it in the register. If appointment numbers stop while power remains available, the network or application may be responsible. A power alarm coinciding with an outage is not proof of causation. Compare the power log, booking-server log and start time of each event, then state confidence in the link. Two competing hypotheses can be kept temporarily with a distinguishing test, rather than merged into a vague sentence. In a small table, give each hypothesis its expected sign, the sign actually observed and the evidence still missing. A power failure might imply loss of server heartbeat and feed; an application fault might leave both intact while requests error. That distinction guides evidence collection and control choice. Check the reach of the effect as well: did only new-number issuance stop, or could users also not view existing appointments? Do not generalize one path's observation to every function. The output of this lesson is a testable risk statement, not a final diagnosis of the fault.