Cloud Service Levels vs Tolerances

Cloud service levels and tolerances answer different questions. A service level is a provider commitment about its own performance, such as the availability of a platform or the responsiveness of support, usually measured over a period and across a provider estate. A tolerance is a firm statement about a specific service: what disruption that service can absorb, in terms of users affected, transactions blocked, or records unavailable, before harm becomes intolerable. DORA expects firms to set tolerances for important services and to manage ICT third party risk in relation to those services. A service level can support a tolerance, but it cannot replace it, because a provider can meet its service level while a particular service still fails beyond what the firm can tolerate.

Measurement scope is the first reason the two concepts diverge. A provider service level is often measured across many customers, regions, or components, so a failure affecting one firm, one service, or one subset of users may be absorbed into an average that still looks healthy. A tolerance, by contrast, is measured from the service outward: what do users of this service experience, and how many are affected. A firm that judges resilience by a provider average will miss concentrated harm. It may also miss timing: a short failure at a critical moment for a service, such as a settlement window or a claims surge after a major event, can breach tolerance even though a longer measurement period still shows acceptable average performance.

An insurance claims illustration shows the divergence. Suppose a claims portal depends on a hosted document service with a strong general availability commitment. During a surge following a storm, document uploads slow for a large group of claimants, while the provider's overall platform remains within its commitment because other customers are unaffected and the measurement period smooths the effect. From the provider perspective, performance is acceptable. From the service perspective, claimants cannot submit evidence, claims handling stalls, and harm accumulates for the people most in need of the service. The tolerance for the claims service, expressed in users unable to submit and in the effect on handling, captures that harm. The service level does not, because it was never designed to measure it.

Relating the two concepts requires translation, service by service. The firm asks which provider components support the service, what service levels apply to each, how those levels are measured, and what service effect follows when a level is missed or when performance degrades without breaching a level. That translation may reveal that a service level covers only part of the chain, that it excludes a component the service depends on, or that its measurement excludes the very failure mode the service fears. Where such gaps appear, the firm needs additional monitoring, contractual protection, design changes, or a revised tolerance discussion, rather than a reassurance drawn from the headline service level alone.

Credits and remedies also deserve careful reading. A service credit compensates a firm financially after a provider failure, but it does not restore a service, help affected customers, or reduce harm already caused. A firm that treats credits as a resilience measure confuses compensation with recovery. Resilience measures are the design, monitoring, recovery sequence, and provider cooperation that limit harm and restore the service. Credits may have a commercial role, but they sit outside that picture. Contract discussions that focus on credit percentages while leaving recovery sequence, notification, and data questions vague have spent negotiating effort on the least important part of a disruption.

The practical discipline is to keep both concepts visible in governance. Provider performance is reviewed against its service levels, so that the firm knows whether the provider is meeting its own commitments. Service performance is reviewed against tolerance, so that the firm knows whether users are experiencing harm the firm cannot accept, whatever the provider metrics say. Where the two reviews disagree, the disagreement itself is the finding: it shows that the provider measure is not capturing the service reality, and it prompts investigation into measurement, design, or dependency. A governance forum that reviews only one side will always have an incomplete picture, and will learn about the other side only when a disruption forces it into view.