Define the service and the risk decision boundary

Risk assessment begins with an operational question: which objective, service and decision are we trying to improve? Saying that a municipality's service may fail is too broad to rank action. The speaker might mean appointment booking, application review or permit issuance. Each has a different owner, users, dependencies and acceptable interruption. A specialist records the service name, intended output, start and end of the workflow, location and period, affected groups, service owner and person authorized to approve risk criteria. These fields change the denominator, the kind of harm considered and who must decide. Booking and permit decisions should not be merged into one undefined risk entry.

State the objective in measurable terms and define the observation unit. The objective might be to keep booking available during business hours; the unit could be a completed booking request. Website visits are not a denominator for completed booking requests: one person might visit several times and submit nothing. For an outage log, define the start and end of an incident and how affected requests are counted. Keep the time period aligned across comparisons. A monthly service volume should not be divided by a weekly incident count without conversion and explanation. If affected volume is unknown, mark it unverified and specify how to obtain it. A plausible looking estimate is no substitute for an observed count.

Decision criteria must exist before the result is known. The service owner or other authorized role, with relevant stakeholders, defines which effects are unacceptable, which trigger immediate notice and which can wait for more analysis. In an exercise a threshold may be delayed appointments or outage duration; it is not a universal ISO 31000 threshold. The specialist records the wording, version and approval date of each criterion and who may accept residual risk. When no criterion has been approved, offer the owner options with their implications rather than silently imposing one. Record exceptions too: a threat to safety or an exposure of personal data can call for immediate containment under an organization's policy even at low case counts.

Draw a boundary sufficient for the job. Include the external provider, power, network and backup operator as dependencies if losing one could stop the service; listing a dependency does not give the specialist authority to run it. State what is inside and outside the assessment and why, then identify the contact when effects cross to another service. Reopen the scope card when the delivery channel, volume or obligation changes. This produces a risk register tied to an objective that can be revisited, rather than a generic list of bad events that cannot guide a decision.

A service name alone is not enough. Test the boundary with two questions. Would the decision change for people who need an alternative access route because they cannot use the online channel? If so, record that group and the handoff point rather than hiding them in the overall average. Does the chosen indicator measure delay to a booking, or just system activity? A high count of login attempts might be repeated attempts by the same people. Record the measure's definition, source and deduplication method, and keep observed delay separate from potential exposure. Also note when the log was extracted: incident data can be corrected after an initial report. When provider and service-owner logs disagree, do not automatically select the larger figure. Show the difference and ask for reconciliation, while allowing urgent containment to proceed if there is a separate safety or privacy effect. A useful scope card makes uncertainty visible and leaves risk acceptance with the authorized owner.