Cloud Service Models and Resilience

Cloud service models describe how much of a system the provider operates and how much remains with the firm. In an infrastructure model, the provider supplies computing, storage, and networking, while the firm builds and operates much of the software stack above it. In a platform model, the provider also supplies the runtime and supporting services on which the firm's applications run. In a software model, the provider supplies a finished application that the firm configures and uses. DORA does not treat the choice of model as a compliance shortcut. Whichever model is chosen, the firm keeps responsibility for the service that depends on it, and the model determines where the firm's visibility ends, where provider action begins, and where recovery steps must be joined together.

The three models are best understood as a sliding boundary of control. With infrastructure, the firm retains wide control over operating systems, middleware, and application behaviour, and therefore carries a wide share of patching, configuration, and recovery work. With a platform, the provider absorbs more of that work, but the firm's application logic, data, and integration choices still shape resilience. With finished software, the firm may have little control over the internals of the application, and resilience depends heavily on configuration choices, data handling, and the provider's own recovery arrangements. None of these positions removes the firm's need to understand the service. Each one moves the point at which the firm must ask the provider for information, for action, or for evidence.

A fund valuation service illustrates the point without needing a real firm. Suppose valuation inputs arrive from market data feeds, calculations run on a platform service, and results are presented through a finished reporting application. A failure in the platform layer could halt calculation even though the reporting application itself is healthy, while a failure in the reporting application could hide correct calculations from users. Recovery in that situation is not a single action. It is a sequence that crosses model boundaries: restoring the platform, re-running calculations, checking results, and restoring presentation. If the firm has not mapped which layer each step belongs to, recovery becomes a series of separate provider conversations rather than one ordered sequence for the service.

Visibility follows the same boundary as control. A firm using infrastructure services may see detailed telemetry for its own stack but little about the provider's underlying hardware. A firm using finished software may see only the provider's status page and its own usage data, with limited insight into the causes of a failure. DORA's ICT third party risk provisions therefore place weight on contractual and governance arrangements that preserve access to information, monitoring, and audit, proportionate to the dependence involved. The practical question is not whether the firm can see everything, since in a cloud model it cannot, but whether it can see enough, early enough, to decide about its own service, to inform affected users, and to support recovery.

Testing must respect model boundaries as well. A test that exercises only the firm's application code will not reveal a weakness in a platform dependency, and a provider test of its own platform will not show whether the firm's service recovers in the right order. Useful testing therefore joins the layers: the firm rehearses its own steps, the provider's role is understood and, where possible, exercised, and the result is judged against the tolerance of the service rather than the health of a single layer. A test that passes at platform level while the service remains unavailable to users has not tested resilience. It has tested a component, and components are not what customers experience.

Choosing a model is also choosing a future constraint. Infrastructure gives flexibility and a larger operational burden. A platform reduces that burden while binding the firm to the provider's tooling and upgrade path. Finished software reduces operational work further while binding the firm to the provider's release cycle, data model, and support arrangements. None of these trade-offs is inherently wrong. The error lies in choosing a model for cost or speed alone, without asking how the firm will recover the service, how it will obtain information during a disruption, and how it will leave the arrangement if it must. Those questions, answered before adoption, are what turn a cloud model from a procurement choice into a resilience choice.