Risk treatment and exception governance

Risk treatment selects reduction, avoidance, transfer or acceptance within defined authority, but it does not remove uncertainty. Link the choice to the scenario and the outcome being changed, then state the action, owner, due date and evidence that will demonstrate improvement. If a control cannot be implemented, document an exception with reason, scope, temporary safeguard, expiry and exit indicator. Do not let an exception become permanent approval or describe a contract as transfer when residual impact is unchanged. After implementation, reassess the remaining account or control scope: which accounts, branches or suppliers were not covered? The output states what changed, what remains and who may accept it.

An exception is not permanent acceptance; it is a bounded decision with scope, owner, expiry, and exit criterion. First identify the unavailable control and why, then enumerate covered accounts or systems instead of saying “all.” Design a testable compensating control, such as network restriction plus weekly log review, and name who stops the exception when a signal appears. At closure, test every residual account not covered by the control and retain both revocation receipt and denial result. A changed owner or elapsed date does not close the record automatically; verify that compensation continued and each identity returned to the standard path. Worked example: twelve of fifteen service accounts are covered, leaving three residual accounts. The exception remains open for those three until each is retired or migrated to a bounded mechanism and the old sign-in is proven to fail.