The shift to the cloud is a compelling value proposition for banks. In offloading the fixed costs of maintaining in-house IT services, they can dedicate greater resources to their core businesses and build more competitive products. Once a bank has switched, there’s an understanding that the cloud provider will shoulder the responsibility for infrastructure and security, while the bank retains responsibility for its data and applications.

At least, that’s the theory. In reality, say banks, the boundaries are often blurred—and subject to endless rounds of negotiation.

“It will never be clear that ‘this entity must do this, and another entity must do this’. It is very use-case-dependent,” says Amit Lakhani, global head of IT and third-party risk management at BNP Paribas CIB. “As you mature into cloud environments, you need to spot such issues early on.”

Data-retention policies, access to data, and hiring third-party providers to plug gaps—all are among the bones of contention between banks and their cloud providers. Examples abound of situations where boundaries between a bank and its cloud providers were not well defined on initial agreement and subsequently required additional negotiations, Lakhani says.

In BNP’s own dealings with French cloud provider Oodrive—a software-as-a-service (SaaS) platform for securely storing data—the bank needed to control access to highly sensitive data, to which it was reluctant to provide access, even for underlying platform configuration purposes. Only after the data was completely anonymized, encrypted or tokenized would BNP allow the cloud provider to have access. This led to a series of difficult discussions, which required Oodrive give BNP proprietary information about its own platform—which Oodrive, in turn, was reluctant to give.

It will never be clear that ‘this entity must do this, and another entity must do this’

Amit Lakhani, BNP Paribas CIB

A critical aspect of the discussions was the boundary between the cloud provider’s responsibilities and the bank’s management and ownership of its own data, Lakhani says—resulting in a deep dive into which configurations BNP or the provider was allowed to change.

“When we first started, the initial template of roles and responsibilities between us and Oodrive did not work at all. We had to go a lot deeper in terms of the data lineage. After doing that study, we were able to resolve at what points we would need to induce certain access controls.”

And while moving to the cloud provides potential for significant infrastructural cost savings, banks must continually ensure that their agreed standards are being met.

They must also take care that they are doing their part to smooth the transition, including making sure they migrate practices as well as infrastructure.

“If you make changes manually, then when you automate, you not only have to make the changes to automation, but you must make sure that you automate the controls,” says Fred Harris, head of cyber security and technology risk at Societe Generale. “That’s the biggest mistake people make when they’re moving to the public cloud.”

Service providers lay some of the responsibility at the door of service users.

“A lot of issues [arise] where customers have misconfigured things and left storage buckets open or other incidents,” says Phil Venables, chief information security officer (CISO) at Google Cloud and a former Goldman Sachs CISO.

And with banks pressing regulators for more clarity on regulatory treatment of cloud services, there is plenty of scope for service providers to assist users along the road to regulatory compliance as well as cloud capability.

Coming to terms

Sometimes, the rules of engagement must be established with multiple cloud providers, as was the case when BNP needed to provide call recording in Microsoft Teams for Mifid II reporting purposes.

This meant bringing in a third-party provider of call-recording software, Lakhani says, and drawing more lines around roles and responsibilities. This third party needed to sit between BNP’s infrastructure and Microsoft’s infrastructure for providing Teams—introducing another layer of ‘who does what?’—because a configuration could affect several Teams users.

Such issues of roles and responsibilities tend to come up with SaaS providers, rather than with infrastructure-as-a-service (IaaS) or platform-as-a-service (PaaS) providers, whose roles are more clearly defined. With software, it’s difficult to say who controls what, especially with data, say banks.

Which is not to say that issues don’t arise with IaaS and PaaS providers, as well. In some cases, banks have required clarity on roles and responsibilities that clearly illustrate the challenges of cloud migration.

With IaaS, the cloud provider manages IT infrastructure such as storage, servers and networking, and delivers them via the internet. With PaaS, the cloud provider delivers a platform for application development via the internet. For SaaS, the cloud provider delivers applications to the end-user via the internet.

Be it IaaS, PaaS or SaaS, it’s critical there’s a clear understanding—reinforced by contractual terms—of the responsibilities for ‘security of the cloud’ versus ‘security of what is in the cloud’, say those involved.

The migration of servers and development platforms to the cloud, for instance, requires clarity with the cloud provider, say banks. The provider has responsibility for the physical security of the data centers and for the host infrastructure. For the IaaS, there is shared responsibility for host infrastructure and network controls with the customer, so the customer has oversight over the network.

When UBS moved its infrastructure to Microsoft Azure, multiple tenants were set up in the Azure cloud to host engineering, testing and production, and those different tenants had to be directly subject to the bank’s controls.

For IaaS and PaaS, the physical infrastructure and network controls were clearly the responsibility of the cloud service provider, and were negotiated as such for the contracts.

“There were some commonalities and some areas where the cloud service provider was completely responsible when servers were being moved into the cloud,” says Charles Forde, former head of third-party risk management at UBS.

The controls for application level, identity and access management, client end-point, and data classification remain within the company.

Especially problematic are critical applications with strict confidentiality requirements, where the provider retains control of access to the application, including identity and access management, but the end-user is responsible for controls covering data classification and accountability.

Forde cites a case of two large European banks that use an application providing anonymous reporting of whistleblowing events. Such information is provided to the firm’s human resources department only if the whistleblower agrees to talk directly to the firm. Most of the controls sit with the whistleblowing application provider—physical security, host, network, identity and access management—which it provides through its primary cloud service provider.

“This is a unique case,” Forde says. “Only when something was agreed to be released could that data be disclosed to the bank.”

The timing of when such issues are addressed is extremely important in Lakhani’s view, based on his own experiences and those of his peers at other institutions: “The use cases are slightly different, but the themes are similar. These problems are here to stay. The earlier you can identify these issues, the better—because, by the time you are into deployment, it’s too late.”

Division of labor

In a typical shared-services model, the cloud provider is responsible for running the security of the underlying infrastructure, and the customer is responsible for the secure configuration within the cloud. Failure to clearly delineate the roles and responsibilities in a shared-services model can lead to problems—as when banks try to leverage the cloud to perform autoconfigurations of servers, but neglect to add controls to ensure the automation works.

This means understanding clearly who’s doing what—and when—in the shared-services model, says Societe Generale’s Harris. “Those two things are where firms get into trouble: they automate without automating controls; they look at the cloud platform at a macro level, and don’t ensure that everything is applied correctly at the micro level.”

Banks must be vigilant that the shared-responsibilities model is understood at all levels of the organization when evaluating a move to the cloud, Harris says. For example, they need to set up a trust-and-control framework for cyber security within the cloud provider. Every environment brought into the cloud provider needs to be validated to ensure the firm has correctly applied that trust-and-control framework.

Some cloud providers are modifying the shared-services model by reaching across the line of shared responsibility to provide more secure defaults, more tools and more blueprints, to make sure the customer is running safely and securely.

Closing those potential loopholes is an area of particular focus for Google Cloud, says CISO Venables.

“We’re focused on how we provide secure defaults and secure blueprints to reduce the risks,” he says. “It’s not just defense from attacks, but defense from configuration errors.”

For financial institutions, this poses a challenge. Regulators expect banks to retain data for a certain amount of time. Just because they’re not writing anything new in that cloud provider’s environment doesn’t mean the cloud provider should just delete everything, Harris says.

Moving petabytes of data from one cloud provider to another, or from a cloud provider back onto premises, may take more time than the cloud provider is willing to spend. That risk needs to be addressed by negotiating terms related to data-handling, post-system usage, he adds.

“You need to have an exit strategy. Just because I’m not running a thousand applications in AWS [Amazon Web Services] any more doesn’t mean that all the data associated with those applications can be deleted,” Harris adds. “You need to be aware of that dynamic because if you’re not, then you can get into trouble.”

And as banks seek more regulatory guidance on the unique risks presented by the cloud, providers have an obligation to satisfy both banks and regulators that they are fully compliant with all terms and conditions.

Google maintains a large team practiced in mapping cloud controls to financial services’ regulatory expectations. The team is made up of former bank professionals who’ve spent their careers working with regulators, as well as CISOs from financial services who are adept at helping customers make the transition to the cloud.

Indeed, cloud providers are keen to cast themselves as part of the solution with financial services companies and regulators—not part of the problem.

“If we have a major bank customer, and they’re having discussions with their regulators as part of migrating critical services to the cloud, we will partner with [them] to work with the regulators to make sure the process is well governed,” says Google Cloud’s Venables.

Cloud providers could yet bring some daylight to the issue.