ICT Risk for Cloud Systems

ICT risk for cloud systems concerns the risks that arise when a financial service depends on technology operated remotely by a cloud supplier, on shared infrastructure, and through a service model that the entity does not directly control. The service still belongs to the financial entity, and its resilience still depends on the single ICT risk management framework, but identification, protection, detection, and recovery all operate through the supplier relationship as well as through the entity own systems.

The central shift is one of visibility and control. An entity can observe and harden its own systems directly. For a cloud service, it observes through supplier reporting, monitors through interfaces the supplier provides, and recovers through arrangements agreed with the supplier. Cloud risk management is therefore about understanding that shift for each service, and about building the contractual, technical, and contingency arrangements that close the gaps it creates.

Cloud changes the service map by adding layers that are not visible in a traditional inventory. A service may depend on a cloud application, which depends on a cloud platform, which depends on underlying infrastructure and on network connectivity, each operated under different terms and with different resilience characteristics. Mapping a cloud dependent service therefore traces those layers, and identifies which parts of the chain the entity controls, which parts the supplier controls, and which parts are shared with other customers of the same supplier.

Shared infrastructure creates a particular mapping challenge. A failure or attack affecting a shared platform can affect several services and several customers at once, and the entity service map needs to show that concentration. A map that treats a cloud service as a single box, without showing the shared elements beneath it, understates the breadth of effect when that box fails. The map is more useful when it shows concentration explicitly, even where the detail beneath the supplier boundary is partial.

Protection in cloud is divided between the entity and the supplier, and the division depends on the service model. The supplier typically protects the underlying infrastructure, while the entity protects its configuration, its access, its data, and its use of the service. That division is a common source of misunderstanding, because a gap can sit in the space between the two responsibilities, where each party assumes the other is acting. A clear responsibility mapping, for each service, prevents that gap from remaining unexamined.

Configuration is where entity protection matters most in cloud. A misconfigured storage service, an overly broad access policy, or an identity arrangement that grants standing privilege can expose data or allow compromise even when the underlying platform is well protected. Protection therefore pays close attention to cloud configuration, to identity and access management, and to the data that is placed in cloud services, including how it is protected in transit and at rest and how it can be retrieved if the service is disrupted.

Detection in cloud relies on supplier telemetry and on the entity own monitoring of service behaviour. Supplier logs, alerts, and status information provide part of the picture, while monitoring of the service from the entity side shows customer impact, data flows, and transaction behaviour. Correlating those sources is detection work in itself, because a supplier incident may appear first as a service symptom, and an entity side anomaly may have a supplier cause that only supplier information can confirm.

Recovery for cloud services depends on the recovery arrangements built into the supplier relationship and on the entity own contingency plans. Data backup and portability, the ability to restore to an alternative environment, and the time and effort required to do so are recovery considerations that need to be understood before disruption, not discovered during it. A recovery plan that assumes data can be moved freely, without checking portability and format, may prove unworkable when it is needed.

Concentration risk in cloud arises when several important services depend on the same supplier, the same platform, or the same region, so that a single supplier incident affects them together. The risk is not that cloud is inherently fragile. It is that dependence, when it is spread across services without being recognised as concentration, removes the diversification that would otherwise limit the effect of a failure. Recognising concentration requires a view across services, not only within each service map.