Cloud governance in financial services: responsibilities and minimum controls

Moving workloads to the cloud does not move regulatory responsibility. A financial institution that contracts cloud infrastructure, a platform or an application is still accountable to its supervisor for the security of its customers' data, the continuity of its services and the fulfillment of its obligations. What changes is who operates each technical layer and, therefore, where the controls need to sit.

The usual problem is not a lack of controls on the provider's side, which tend to be documented and certified, but gaps at the boundary: layers each party assumes the other is managing. This article maps that boundary by service type, identifies what the institution never delegates and proposes a minimum control baseline to start with.

Shared responsibility changes with the service type

NIST's definition of cloud computing (SP 800-145) distinguishes three service models: infrastructure (IaaS), platform (PaaS) and software (SaaS). In practice, the difference between them is how far up the stack the customer's control reaches. AWS, Microsoft Azure and Google Cloud each publish their own version of the shared responsibility model and, naming differences aside, they agree on the essentials.

• IaaS. The provider operates the datacenter, hardware, physical network and virtualization. The customer manages the operating system, middleware, applications, virtual network and everything above. It is the model with the most control and, therefore, the most security tasks on the customer's side: patching, hardening, malware protection, network rules.
• PaaS. The provider also manages the operating system and the runtime. The customer deploys code and configures the service: who has access, from which networks, with what encryption, how long logs are kept. Network and application controls are shared.
• SaaS. The provider operates the entire application. The customer decides who uses it, with what permissions, what data goes in and how the security options the product offers are configured.

Two practical caveats. First, a single architecture usually mixes all three models: an application on virtual machines that uses a managed database and sends email through a SaaS service has three different boundaries. Document the matrix per service, not per provider. Second, "managed by the provider" does not mean "configured by the provider". A PaaS database arrives patched, but if it is left exposed to the internet or without the encryption your policy requires, that decision is yours.

What is never delegated

Four areas stay on the institution's side under any service model. Microsoft's documentation states it explicitly for data, identities and configuration, and the logic is the same with any provider.

Data

Classifying information, deciding which data can go to the cloud and in which region, encryption and lifecycle (retention and deletion) are customer decisions. The provider supplies the tools; it does not decide what is confidential or how long it must be kept.

Identities and access

Who gets in, with what privileges, with which authentication factor and who approves privileged access. In the cloud, the management console and management APIs are the new perimeter: a compromised administrative credential has more reach than physical access to a datacenter.

Configuration

Publicly accessible storage, open ports, disabled logging, optional encryption left off. A customer configuration error can expose data even when the provider's infrastructure works perfectly, and no contract transfers that responsibility.

Compliance

The provider's certifications (ISO/IEC 27001, SOC 2 reports, PCI DSS) cover its part of the model. They are useful evidence, but they do not show that the institution uses the service well. Before the supervisor and the auditor, responsibility for the outsourced function remains with the institution. The EBA Guidelines on outsourcing arrangements, applicable since September 30, 2019, establish this for institutions in the European Union. In Latin America, each supervisor has its own outsourcing and cloud regulations; have Compliance confirm what is required in each country where you operate.

A minimum control baseline

You do not need to implement every domain of the Cloud Security Alliance's Cloud Controls Matrix (CCM) before the first workload. Version 4, published this year, organizes the controls into 17 domains and maps them to other frameworks, which makes it a useful long-term reference. To get started, we recommend this minimum baseline, which should be operational before hosting customer data:

• Identity and access. Federation with the corporate directory, with no local users in the console. Mandatory MFA for everyone, and the strongest type available for administrators. Root or break-glass account under dual control and alerting on any use. Least-privilege roles and periodic access reviews.
• Landing zone and account structure. An account, subscription or project structure defined from the start: production separated from non-production, dedicated accounts for security and logging, and preventive policies at the organization level (allowed regions, approved services, no disabling of logs).
• Encryption and keys. Encryption at rest and in transit enabled by default. For sensitive data, customer-managed keys in the provider's key management service or in an HSM, with rotation, separation of duties between those who manage keys and those who manage data, and logging of every use.
• Centralized logging. Platform activity logs (API calls, console access, configuration changes) from every account, sent to an isolated logging account, with retention according to the institution's policy and protection against deletion. Integration with the SIEM or the security operations center.
• Secure configuration. A baseline defined from the CIS Benchmarks for the relevant provider and assessed continuously, with the provider's own tools or third-party ones. Every deviation raises an alert with an owner and a deadline.
• Provider management. Risk assessment before contracting, review of certifications and audit reports, and clauses covering access, audit, incident notification, data location and subcontracting. An up-to-date register of outsourcing arrangements.
• Exit. A documented exit strategy for critical functions: how data is recovered, in what format, within what timeframe, at what cost and who carries it out.

Each control needs an owner, evidence that can be shown in an audit and a compliance indicator. Without that, the list is a statement of intent.

Providers, audit and exit strategy

The EBA Guidelines treat outsourcing to cloud providers within the general outsourcing framework and replaced the cloud-specific recommendations the EBA had published in 2017. Three of their requirements are especially relevant to cloud governance, and they work as good practice outside the EU too:

• Assess whether the function is critical or important. That classification determines the level of due diligence, the required clauses and the communication with the supervisor.
• Access, information and audit rights for the institution and for the competent authority. In the cloud these usually take the form of independent audit reports, certifications and, when needed, pooled audits among several customers.
• A documented exit strategy for critical or important functions, covering contract termination, provider failure and service deterioration, with an impact analysis, assigned resources and success criteria for the transition.

The exit strategy is the control most often postponed and the hardest to improvise. It does not require a second active cloud. It requires knowing, with a reviewed plan tested at least on paper, how data and services would be recovered if the contract ended. Choosing exportable data formats and defining infrastructure as code lowers the cost of that exit from day one.

Provider monitoring must also be continuous: service levels, incidents, subcontractor changes. To decide what to measure, see our article on SLAs that matter, and to fit this work into a vendor management model, the one on PMO and VMO as a service.

Who does what inside the institution

The shared responsibility model has an internal counterpart that often goes undefined. A simple assignment keeps controls from falling into no man's land. The table below is an illustrative example; team names vary from one organization to another.

Control	Operates	Accountable	Oversees
Identity and access	Identity team	CISO	Internal audit
Landing zone and policies	Cloud platform team	Head of infrastructure	Security
Encryption and keys	Security	CISO	Risk
Centralized logging	Security and Operations	CISO	Internal audit
Secure configuration	Cloud platform team	Head of infrastructure	Security
Provider management and exit	Vendor management	Business service owner	Risk and Compliance

What matters is that each control has a single accountable person. When an incident happens in the cloud, the investigation crosses the boundaries between customer and provider, and between internal teams: centralized logs and clear ownership are what make it possible to reach the cause, as we explain in root cause in distributed systems.

Before approving the model, validate it with Risk, Compliance and Legal, especially the classification of critical functions and the contract clauses.