Appetite, capacity and tolerance

Risk appetite is a choice about how much uncertainty an enterprise is willing to take in pursuit of an objective; it is not a colour assigned after an incident. Capacity is the outer limit the enterprise can bear before its survival or essential obligations are threatened. Operational tolerance is a permitted deviation for a particular service or metric over a defined interval, together with an action when the limit is crossed. These concepts differ. Management might accept trying a new feature with one thousand users yet lack the capacity to lose the transaction ledger or its incident-reporting channel. 'Low appetite for cyber risk' does not settle a decision. Connect the statement to an event, effect, measure and authorised decision maker.

To make appetite operational, begin with the service objective: a correct transfer whose status can be known. Define a scenario that tests the boundary, such as identity-provider failure during delayed settlement. Select a measure reflecting real harm: inconsistent transaction states per ten thousand operations, time to detect them and time to correct them. Specify the observation window and data source. If the denominator comes from the app and the numerator from the settlement ledger, transaction identifiers may need reconciliation before division. Set an alert threshold that permits early correction and a stop threshold that prevents continued harm. Not every breach needs a full shutdown. The affected function may be disabled while balance viewing continues. The ability to isolate functions is a design property to test, not an assumption.

Check whether the boundary fits organisational capacity. A declared ten-minute outage tolerance cannot work if the supplier normally takes forty minutes merely to open an urgent case and there is no alternative path. Management can alter the contract or architecture, reduce service exposure, or revise the tolerance with the risk owner's approval. Raising the number on paper to conceal a weak control is not a remedy. If continuing operations may create unknown financial entries, the relevant capacity may protect ledger integrity rather than interface availability. Boundaries can conflict: restoring speed with unreliable temporary recording may violate the integrity boundary. When they do, rank the gates that cannot be crossed and design a safe, reduced-function mode.

Do not import a threshold from another enterprise because its precision looks impressive. Begin with your own incident history if it is fit for purpose, then inspect monitoring gaps and quiet periods. Old data may reflect missed detection rather than rare failure. Replay the proposed threshold against past events and a constructed scenario. Count how often it would have alerted and what responders could actually have done. Hundreds of unactionable alerts create fatigue; a boundary that moves only after confirmed loss cannot prevent harm. Distinguish a stable baseline from transaction-volume changes. One hundred pending cases on a busy day can represent a lower rate than ten on a quiet night, while the absolute customer effect still matters. An enterprise may therefore need both relative and absolute limits, with an explanation of which initiates a response. Reassess the threshold when product, supplier or demand patterns change. Do not relax it immediately after an embarrassing incident merely to improve a dashboard.

Governance assigns authority. A service manager may be empowered to pause one function immediately to protect customers, while accepting a large residual exposure requires the risk committee's decision. Write an authority table for ordinary approval, emergency exception, temporary threshold changes and return to full operation. Exceptions should not be verbal or open-ended. Record the need, effect, compensating control, expiry date and closure test. If a boundary represents a verified binding legal obligation, no internal committee can waive it. Separate the authority to accept a discretionary exposure from accountability for applicable compliance duties in a specific jurisdiction.

Consider an operating decision when login-code delivery slows but a reliable alternative remains available. The enterprise could route high-impact operations through that channel while pausing account-detail changes instead of closing the whole service. It needs to define 'high impact', detect when a request switches channels and handle a code that arrives after the fallback has been used. If the first code remains valid, it creates a new misuse path; invalidate it when the fallback succeeds and log the attempt. Service speed cannot be measured separately from login safety. Report how many attempts were affected, the success rate after rerouting, any unauthorised access and confidence in the logs. If one value cannot be measured, show it as an evidence gap constraining expansion, not as a comforting zero.