Many times in presentations, the internet is portrayed as a cartoon cloud that somehow connects various functions in one place—say, a bank—with someplace else—say, an offsite server. It's an easy metaphor to illustrate—without really explaining—how the internet and its next-of-kin "the cloud" really work.
To those in bank operations, such a fluffy white cloud portrayal is appealing, because it focuses on the promise of efficiency gains, cost savings, and added business potential. To a bank risk manager, however, the cloud is seen as a dark, rolling, creepy thing from a Stephen King novel—full of danger.
That's how Cindy Williams, senior vice-president for compliance and internal controls, Community State Bank, Des Moines, Iowa, described differing views of the cloud at the recent ABA Risk Management Conference. "For those of us in risk management, the first thing we say is, 'What could go wrong?' I think [the cloud] is somewhere in between those extremes. The way we're going to get there is to understand what the cloud is, understand how it works, and then assess the risk," she said.
Such a risk assessment process not only provides peace of mind for the bank, it's also top of mind with regulators. But, such risks are so new that regulators have yet to issue any definitive regulation, let alone official guidance. Last year, as a first step, the Federal Financial Institutions Examination Council (FFIEC) issued a statement on outsourced cloud computing activities. It discusses key risk considerations and identifies applicable risk mitigation considerations contained in the booklets comprising the FFIEC IT Examination Handbook.
As Doug Johnson, ABA vice-president and senior advisor of risk management policy, put it at the conference: "I don't think you can look at a regulatory statement as different than what you've seen in terms of regulation and guidance. It does provide some clarity."
Also on the regulatory front, Johnson noted that the National Institute of Standards and Technology (NIST) has weighed in on cloud risks with its Guidelines on Security and Privacy in Public Cloud Computing. "In our world [of risk management], as it relates to cybersecurity and technology, NIST is becoming increasingly important," he said.
Johnson added that both these entities focus third-party vendor due diligence on three main areas: data classification, data segregation, and data recovery.
"This is basic blocking and tackling," he said. "It's a reiteration of what you should be doing with all your third-party vendors, and how you should control data generally, regardless of how it is housed."
Old hand, or new kid?
Even before these three factors are addressed, however, the overriding consideration a bank should have is to find out how thoroughly a given vendor understands the unique requirements financial institutions must comply with. As cloud computing develops, both Johnson and Williams said that new and inexperienced vendors likely will try to break into the market.
"A lot of this revolves around the maturity associated with the vendor and what kind of comfort you have with it, or what kind of pushback you might experience when you try to get it to put in certain mitigation measures. [The regulators] say flat out in the regulatory statement that disengagement with a service provider is another aspect of vendor management," said Johnson.
From Williams' point of view in her community bank, where she serves simultaneously as risk manager, vendor manager, and contract renewal officer, cloud management basically comes down to asking questions.
Set the stage
First, however, there are some basics to master, such as knowing the distinction between cloud types. Again, the process simply is the transmittal of data through the internet to a physical server located somewhere else, which could be anywhere on the planet. A public cloud (e.g. Salesforce.com, Gmail) is one where data from anywhere can be stored, with minimal security measures. A private cloud is one in which the server only accepts data from one designated client. A community cloud would be a server system that serves multiple clients, but those clients tend to be in the same kind of peer group or industry, such as financial services, and generally share commonly required security measures. Most community banks, when dealing with a cloud vendor, likely will participate in such a community cloud, said Williams.
Then, there are preliminary steps that bank management must take: establishing the bank's appetite for cloud risk; determining the types of information the bank is comfortable putting in the cloud; ensuring all business lines are informed of their obligations related to cloud providers; and conducting ongoing, periodic cloud provider risk assessments of all vendors.
Only when all that is settled should vendor vetting proceed, and that's when the questioning can begin. There are a lot of very detailed questions. Williams ran through them (they follow), but she noted that reality has to be accommodated in this process.
"You are never going to have a vendor who is going to answer all of these questions and give you all you want," the banker said. "It's just not going to happen. But the important thing is to ask the questions, so upfront your bank can make a decision if it coincides with your bank's risk appetite."
Questions to ask cloud vendors
Community State's Williams detailed six categories of cloud risk, and the questions and considerations that should be asked for each.
1. Vendor health: How long has the vendor been doing this work? Does it use other third-party providers? Has it been involved in any sort of lawsuit?
2. Data segregation: What type of cloud does the vendor use? What other customers does it have? Will the bank's data also share resources with data from those other clients? What controls are in place to ensure that data is encrypted and protected? How frequently does the provider monitor its servers to confirm that data is properly segregated?
3. Data security and backup: Where are the servers physically located? What's the physical security of the service centers? Does the provider conduct regular backup and recovery tests? Is there a limit to the amount of data that can be backed up? How is old data disposed of? How is old hardware disposed of upon replacement? What's the data encryption standard during storage and transmission? Has the provider experienced any unauthorized access during the last 12 months? Is the provider required to immediately notify a client in the event of a compromise? Is the provider required to protect client data at the same level that the client does internally? Is the provider required to maintain client data in a certain area or country, or, conversely, is it prohibited from maintaining client data in a certain area or country?
Most important, said Williams, is this: "Does the contract address the provider's obligation regarding your responsibilities for compliance with privacy laws, for responding to and reporting security incidents, and for fulfilling regulatory requirements to notify customers and regulators of any breaches?"
4. Provider performance: Will the vendor transfer customer data to an alternate supplier if the need arises? What is the timeframe for data restoration in the event of a loss? Is there a contingency plan for natural disasters or other system outages? Is there an SSAE 16 (a formal reporting standard) or other documentation to support the adequacy of the provider's internal controls? What is the contractual provider liability for an interruption of service or loss of data?
5. E-discover issues: Is the provider required to notify the bank if it receives a subpoena, search warrant, or other lawful request for the bank's data? What is the provider's e-discovery request process? How is information searched for and retrieved?
6. Exit plan: Are the termination terms acceptable? Will your data be returned to you after a termination of service? If so, within what time period? What is the provider's data disposal plan at the termination of the agreement? What will happen to your data if the provider goes out of business?
Fluffy or dark, the cloud is here
There's no doubt that such a cloud vendor selection process is intense, but that's where the world is going. As an example, a banker attending the conference remarked that recently the bank's examiner asked not only where the vendor's server facility was located, but which particular server in that facility actually stored the bank's data. Another banker commented that an examiner asked very detailed questions about vendor backup data centers as well as offsite retention.
All this, or as much of it as possible, needs to be done before a bank signs an agreement with a vendor, said Williams. Furthermore, it's not a one-time exercise.
"We have vendors that we've dealt with for years and found that they might move to the cloud with a third party," Williams explained at the conference, "and they might not necessarily tell us. That's why it's important to do this up front with new agreements, but it's also going to be important to do this regularly with existing vendors."