The Financial Services Sector's Adoption of Cloud Services

The Financial Services

Sector’s Adoption

of Cloud Services

U.S. Department of the Treasury

CLOUD REPORT n 2 n U.S. DEPARTMENT OF THE TREASURY

Table of Contents

Executive Summary ..........................................................................4

Treasury’s Strategic Vision for Supporting the Resiliency of the

Financial Sector’s Use of Cloud Services ............................................ 9

Introduction .................................................................................... 14

2.1 Background on FBIIC and the Purpose of this Report

2.2 How the Report is Organized

2.3 Background on Cloud Services

2.4 U.S. Government Approach to Cloud Computing

Cloud Use in Financial Services

........................................................19

3.1 Motivations Supporting Cloud Adoption and Types of Cloud Services

3.2 Potential Benets of Cloud Computing to Operational Resilience

3.3 Shared Responsibility

3.4 Types of Cloud Services Used by Financial Institutions

3.5 Dierent Approaches to Adoption

3.6 Cloud Use by Depository Institutions

3.7 Certain Nonbanks

3.8 Critical Market Infrastructure

Domestic and International Regulatory Framework

.........................31

4.1 U.S. Regulatory Framework and Authorities

4.2 International Approaches

Financial Institution Practices When Adopting Cloud Services ........ 45

5.1 Risk Management and Operational Resilience

5.2 Deployment and Conguration

5.3 Monitoring, Auditing, and Testing

Challenges with the Financial Sector’s Use of Cloud Services

..........49

6.1 Insuicient Transparency to Support Due Diligence and Monitoring

6.2 Gaps in Human Capital and Tools to Securely Deploy Cloud Services

6.3 Exposure to Potential Operational Incidents

6.4 Potential Impact of Market Concentration

6.5 Dynamics in Contract Negotiation Given Market Concentration

6.6 International Landscape and Regulatory Fragmentation

CLOUD REPORT n 3 n U.S. DEPARTMENT OF THE TREASURY

7. Areas for Further Consideration and Next Steps .......................... 62

Annex A: The Department of Treasury’s Cloud Strategy

.................. 65

1. Strategic Technology Landscape

2. Strategic Objectives

3. Strategic Approaches and Guiding Principles

Annex B: External Stakeholders Interviewed ................................... 69

CLOUD REPORT n 4 n U.S. DEPARTMENT OF THE TREASURY

Executive Summary

The U.S Department of the Treasury (Treasury) and its partners in the Financial and

Banking Information Infrastructure Committee (FBIIC) recognize the importance of

assessing how trends in technology use could aect the operational resilience of the U.S.

nancial services sector. This report shares Treasury’s ndings on the current state of

cloud adoption in the sector, including potential benets and challenges associated with

increased adoption. This report does not impose any new requirements or standards

applicable to regulated nancial institutions and is not intended to endorse or discourage

the use of any specic provider or cloud services more generally.

Financial institutions of all sizes increasingly view services provided by cloud service

providers

(CSPs) as an important component of their technology program, and cloud

adoption could represent a signicant change to nancial institutions’ internal operations

and delivery of services to clients and customers.

Treasury found that the adoption of public cloud services

has increased rapidly over

the last decade but that models of adoption continue to vary across the nancial sector.

Financial institutions have a wide range of use cases for cloud services, including

supporting remote work environments and advancing innovation (for example, by

harnessing cloud-native capabilities like articial intelligence). Many nancial institutions

cited reduced costs, ability to rapidly deploy new information technology (IT) assets,

shorter time to develop new products and services, and enhanced capabilities for security

and resilience as motivating increased cloud adoption.

The COVID-19 pandemic has

also accelerated cloud use given accelerated customer demand for innovative oerings

through digital channels and nancial institution demand to accommodate remote work.

Treasury expects cloud adoption will continue to increase.

Cloud adoption can take a range of forms. Many larger nancial institutions plan to adopt

a “hybrid” model involving the strategic use of both public and private cloud services and

their own data centers. Some nancial institutions have signicantly reduced their data

center footprint by hosting applications and data in a public cloud environment. Smaller

and mid-sized institutions are also adopting public cloud services, with some operating

their IT infrastructure entirely in the cloud. Some cloud adoption is the result of acquiring

cloud-native businesses. Other adoption is indirect and results from an institution’s

relationships with third-party providers, which have gravitated away from oering on-

premises solutions in favor of cloud-based ones.

1. For the purposes of this report, a Cloud Service Provider (CSP) is an organization that provides cloud

computing services to organizations other than itself.

2. This report is focused on how nancial institutions use cloud services provisioned for open use by the general

public, though observations in the report may be relevant to private cloud services as well.

3. Such motivations are not unique to nancial services. As detailed in Annex A, Treasury has developed a

strategy to harness the potential eiciency, elasticity, scalability, and security capabilities associated with

cloud services.

CLOUD REPORT n 5 n U.S. DEPARTMENT OF THE TREASURY

In assessing the current state of cloud adoption in the nancial sector, Treasury identied

six thematic challenges described below and expanded on in Section 6 of this report.

These challenges, if unaddressed, may detract from the potential benets associated with

cloud services. Some of challenges may also be more acute for small and medium-sized

nancial institutions.

Insuicient Transparency to Support Due Diligence and Monitoring by Financial

Institutions: Risk management of any third-party service requires the nancial institution

to understand the risks associated with that service. Treasury encountered a range of

views on whether the information being shared by CSPs was suicient to understand

risks. Early adopters and nancial institutions that brought signicant scale to their use of

cloud services were oen the most satised with the information they received. However,

Treasury met with several nancial institutions that wanted additional information to

improve their understanding of the risks associated with cloud services. Areas of interest

included: (i) internal soware dependencies within the public cloud environment;

(ii) subcontractor and other supply chain risks; (iii) CSP protection against pervasive

cyber vulnerabilities; (iv) results of testing resilience and security capabilities; and (v)

information regarding operational incidents, including real-time updates and aer-action

reports.

Treasury understands that CSPs limit physical access and refrain from sharing sensitive

information to reduce risk to their infrastructure. CSPs have noted that intensive in-person

audits are challenging to accommodate at scale while maintaining the security of the

multi-tenant environment. Similarly, nancial institutions, particularly small and medium-

sized nancial institutions, noted that third-party risk management was becoming

increasingly complex and resource-intensive. Treasury is aware that the industry is

considering and implementing a range of alternative approaches to one-to-one audits,

like pooled audits, certications, or real-time updates to customers. Treasury encourages

eorts that could yield eiciency gains for both CSPs and nancial institutions without

compromising outcomes.

Gaps in Human Capital and Tools to Securely Deploy Cloud Services: Public cloud

services are deployed using a “shared responsibility model,” which requires both CSPs

and nancial institutions to take actions to secure and monitor the cloud environment

(though the division of responsibility will vary depending on the service being oered).

Many security incidents are caused by user misconguration of cloud services. Treasury

identied two issues that can increase the frequency of user misconguration. These

issues are particularly acute for small and medium-sized nancial institutions.

First, there is a shortage of appropriate sta expertise for cloud services. General IT and

cybersecurity skills may not fully translate to the cloud environment without additional

training. Skills associated with deploying and securing applications on one CSP do

not necessarily translate to other CSPs. The scarcity of relevant experts may become

increasingly pressing if cloud adoption increases.

CLOUD REPORT n 6 n U.S. DEPARTMENT OF THE TREASURY

Second, certain cloud service oerings can be highly complex for nancial institutions to

implement, design, and manage. The tools oered in cloud environments may not always

be user-friendly. Financial institutions expressed a desire for further guidelines on baseline

congurations, from the CSPs or public sector, and continued evolution in cloud-related

tools, such as those for security conguration and monitoring. Some rms reported

occasional dierences in how service features were documented in CSP-provided client

materials and how the features actually functioned.

Exposure to Potential Operational Incidents, Including Those Originating at a CSP:

While cloud services can oer potential benets to resilience and security that could

result in reduced operational risk overall, these services are still vulnerable to operational

incidents, like any technology utilized by nancial institutions. Financial institutions are

still developing congurations to best protect against an operational incident that could

aect more than one geographic region of a CSP. However, these congurations may still

be vulnerable to an incident aecting multiple geographic regions or services integral to

the cloud environment, such as identity and access management.

Financial institutions can congure cloud services with dierent levels of resilience to

operational incidents, but options oered by CSPs will vary depending on the service.

Financial institutions will generally congure cloud services for a higher level of resilience

when those services support critical applications for their core businesses. Options for

resilience conguration generally include (i) relying on a single CSP (through single or

multiple regions), (ii) using separate CSPs for dierent applications, or (iii) combining

public and private cloud with on-premises infrastructure. There are potential benets and

challenges with each of these approaches. However, these options add additional costs.

Greater substitutability between CSPs might partially address this challenge, but

many practitioners noted that running the same application on two or more CSPs

simultaneously can be impractical. No nancial institution reported the capability to

do so for more complex use cases, such as running core operations on multiple public

clouds. Running an application across multiple CSPs at the same time may also be less

desirable, given the costs, staing, and complexity involved in doing so, particularly

given the complexity associated with identifying and managing risk across multiple cloud

environments.

Potential Impact of Market Concentration in Cloud Service Oerings on the Sector’s

Resilience: The current cloud services market is concentrated around a small number

of service providers. Financial institutions can also rely indirectly on other third-party

providers that may also use the same small number of CSPs. The scale these CSP

rms oer can have potential benets, like economies of scale to support investments

in cybersecurity and resilience. And services run on the cloud environment can be

patched quickly to protect against zero-day exploits. Scale may also help facilitate more

interoperability between nancial institutions and their vendors.

CLOUD REPORT n 7 n U.S. DEPARTMENT OF THE TREASURY

On the other hand, concentration could expose many nancial services clients to the

same set of physical or cyber risks (e.g., from a region-wide outage), and addressing such

risks may necessitate action on the part of each nancial services client. But the impact

from an operational incident will depend on how individual nancial institutions use and

manage the cloud service and how critical that service is to the nancial institutions’ core

operations. The key issue for policymakers and nancial authorities is in understanding

the potential aggregate impacts on nancial institutions’ functions and the services that

nancial institutions provide to consumers and businesses.

Data limitations prevent Treasury and the FBIIC from fully assessing the signicance of

the concentration in cloud services across the sector. For example, there is currently no

common approach within the nancial sector to measure critical uses of cloud services by

nancial institutions, making it diicult for nancial regulators to aggregate data.

U.S. nancial regulators assess risks based on information provided by nancial

institutions they supervise. Regulators can also evaluate how supervised nancial

institutions manage such risks. However, due to the dierent legal authorities for

each agency, no single agency can see across the many use cases and the network of

dependencies on cloud services within the nancial sector. FBIIC-member agencies have

channels for formal and informal cooperation to help develop a more comprehensive

view, though Treasury assesses that these channels can be enhanced. Treasury will

prioritize its focus on studying the concentration of cloud services most important to the

functions of the nancial sector. Treasury also believes there are opportunities to enhance

public-private coordination given the broader trends in cloud adoption. For example,

many organizations have not yet incorporated CSPs into sector-wide protocols for incident

response.

Dynamics in Contract Negotiations Given Market Concentration: Discussions revealed

that nancial sector rms of all sizes consider negotiating contracts with CSPs to be

challenging. Smaller nancial institutions noted their lack of bargaining power. Early

adopters of cloud services noted that it was particularly diicult to negotiate for audit

rights and avoid termination by the CSP without notice. Some nancial institutions noted

it was important to address the disposition of encryption keys. Larger nancial institutions

have been able to negotiate some custom provisions but on a limited basis. Treasury

will continue to assess this issue, as unbalanced contractual terms could limit individual

nancial institutions’ ability to measure and mitigate risks from cloud services, which

could result in unwarranted risk across the sector.

International Landscape and Regulatory Fragmentation: Increased foreign regulatory

scrutiny of cloud services and CSPs could pose benets and risks to the resilience,

security, and capabilities of cloud services used by U.S. nancial institutions. International

regulatory concern over cloud services also has the potential to prevent globally active

U.S. nancial institutions from deploying cloud services across their overall enterprise,

including their foreign operations.

CLOUD REPORT n 8 n U.S. DEPARTMENT OF THE TREASURY

Next Steps

Treasury believes that the six aforementioned challenges should continue to be monitored

and addressed to promote the continued resilience of the nancial sector. To promote

coordination and collaboration among U.S. nancial regulators on these challenges,

Treasury will establish a Cloud Services Steering Group. Treasury will also facilitate further

engagement between the nancial sector and CSPs. Treasury’s next steps will be guided

by its Strategic Vision for Supporting the Resilience of the Financial Sector’s Use of Cloud

Services.

Treasury’s work (further described in Section 7) will include the following:

• Promoting closer domestic cooperation among U.S. regulators on cloud services;

• Conducting tabletop exercises with industry;

• Reviewing sector-wide incident protocols in light of growing reliance on cloud

services;

• Considering ways to appropriately measure cloud service dependencies across the

sector and assessing systemic concentration and related risks on a sector-wide basis;

and

• Identifying ways to foster eective risk management practices in the nancial services

industry.

Recognizing that many U.S.-based cloud providers are also active globally, Treasury,

along with FBIIC-member agencies, will continue to support the development of relevant

standards and international policies at the G7, the Financial Stability Board, and the

international nancial standard-setting bodies, and explore ways to increase international

collaboration and coordination on nancial regulatory issues arising from cloud services.

CLOUD REPORT n 9 n U.S. DEPARTMENT OF THE TREASURY

Treasury’s Strategic Vision for Supporting the Resiliency

of the Financial Sector’s Use of Cloud Services

Treasury has developed long-term objectives to promote the nancial sector’s operational

resilience with the use of cloud services. This strategic vision will guide Treasury’s

engagement in the coming months and years with the private sector, as well as with

domestic and foreign counterparts.

PREAMBLE

• Treasury, U.S. nancial regulators, regulated nancial institutions, and CSPs have

similar objectives for the operational resilience of the nancial sector. In the face of

an increasingly complex threat environment, including from hostile actors, eective

outcomes for sector level resilience require trust, cooperation, and collaboration

among these stakeholders.

• Treasury, as Sector Risk Management Agency for the nancial sector, will periodically

assess risks and challenges that could aect the nancial sector arising from widely

used technology services, like cloud services.

• In doing so, Treasury will seek assistance from other stakeholders, including:

• U.S. nancial regulators, which (to the extent consistent with their mandate) are

responsible for assessing risks to individual nancial institutions.

• CSPs, which are responsible for providing services in a manner consistent with

agreed-upon service levels, including with regard to security and reliability.

• Financial institutions, which are ultimately responsible for their own operational

resilience and for taking steps to identify, measure, monitor, and manage the risks

from services that they select, consistent with their regulatory requirements.

• Other government agencies, like the National Institute of Standards and Technology

(NIST) and the Cybersecurity and Infrastructure Security Agency (CISA), that play a

CLOUD REPORT n 10 n U.S. DEPARTMENT OF THE TREASURY

role in promoting eective practices and leading U.S. government engagement on

cybersecurity risks.

• Treasury will work with these stakeholders to address issues arising from cloud

services use that could impact the operational resilience of the sector, including with

respect to nancial stability.

RISK ASSESSMENT AND MITIGATION:

• Eective practices for nancial institutions include taking a risk-based approach to

their chosen cloud service oerings.

• The risk and benets of these services depend on how nancial institutions use,

design, and implement services. Eective cloud adoption by nancial institutions

requires specialized expertise. Dierent services may have dierent levels of

criticality or importance from one nancial institution to another.

• Financial institutions can address cloud-related risks in a variety of ways, including

by designing for resilience and communicating their expectations for operational

resilience and security to CSPs.

• Transparency from cloud providers, including over potential risks and vulnerabilities,

is critical to enable nancial institutions to select and congure service oerings

consistent with their risk appetite.

• Contractual commitments between nancial institutions and CSPs should support

the risk management needs and responsibilities of nancial institutions.

SECTOR-WIDE CONCENTRATION:

• Policymakers and nancial regulators should continue to study concentration in

cloud services, assessing the potential for system-wide impacts.

• To assess the implications of sector-wide concentrations related to nancial

institutions’ operational resilience, nancial authorities must continue eorts to

understand the criticality of a cloud service to a nancial institution’s business

functions and operations.

• Treasury will prioritize its focus on the concentration of cloud services most

important to the functions of the nancial sector.

• If Treasury assesses that cloud services critical to the functioning of the nancial

sector do not have appropriate resilience and security, Treasury will take actions

as appropriate and consistent with its authorities in consultation with appropriate

government agencies.

• Communication and engagement by government authorities, including from Treasury

and the nancial regulators, can inform how the private sector manages risks and

help foster public-private collaboration. Treasury and FBIIC members should continue

CLOUD REPORT n 11 n U.S. DEPARTMENT OF THE TREASURY

maturing strategies for incident response and coordination associated with cloud

services (involving other government agencies where needed).

• Understanding potential system-wide risks associated with cloud services requires

appropriate coordination and information sharing among the U.S. nancial regulators

and with Treasury.

• Regulatory fragmentation or gaps in coordination among nancial authorities and

jurisdictions has the potential to negatively impact the resilience or security of cloud

services, and, ultimately the users of these services, such as U.S. nancial institutions

and the U.S. government.

• Treasury will continue supporting international eorts related to cloud services,

including work at standard-setting bodies to promote alignment around clear and

eective approaches to regulate and supervise nancial institutions’ use of cloud

services.

• Treasury believes that there are opportunities for U.S. and foreign jurisdictions to

collaborate in addressing potential risks of cloud services to the global nancial

system while limiting unintended negative consequences.

4. There are a number of existing models for this type of collaboration, such as formal or informal channels

among U.S. regulators or through the FBIIC.

CLOUD REPORT n 12 n U.S. DEPARTMENT OF THE TREASURY

ACRONYMS PAGE

ABA

ACSSS

AI/ML

API

AWS

BCBS

BSCA

CEG

CFPB

CFTC

CIO

CIS

CISA

COBIT

CSBS

CSP

DCO

DFMU

DORA

ESA

FBIIC

FDIC

American Bankers Association

American Council of State Savings Supervisors

Arti

cial Intelligence/Machine Learning

Application programming interface

Amazon Web Services

Basel Committee on Banking Supervision

Bank Service Company Act

G7 Cyber Expert Group

Consumer Financial Protection Bureau

Commodity Futures Trading Commission

Chief Information Oicer

Center for Internet Security

Cybersecurity and Infrastructure Agency

Control Objectives for Information and Related Technologies

Conference of State Bank Supervisors

Cloud Service Provider

Derivatives Clearing Organization

Designated Financial Market Utility

Digital Operational Resilience Act

European Supervisory Authority

Financial and Banking Information Infrastructure Committee

Federal Deposit Insurance Corporation

FedRAMP Federal Risk and Authorization Management Program

FFIEC Federal Financial Institutions Examination Council

FHFA Federal Housing Finance Agency

FMU Financial Market Utility

FRB Federal Reserve Board

FSB Financial Stability Board

FSSCC Financial Services Sector Coordinating Council

GCP Google Cloud Platform

GLBA Gramm-Leach-Bliley Act

IaaS Infrastructure-as-a-Service

IAIS International Association of Insurance Supervisors

CLOUD REPORT n 13 n U.S. DEPARTMENT OF THE TREASURY

IAM Identity and Access Management

IOSCO International Organization of Securities Commissions

ISO International Organization for Standardization

IT Information Technology

IDC International Data Corporation

JAB Joint Authorization Board

NAIC National Association of Insurance Commissioners

NASAA North American Securities Administrators Association

NASCUS National Association of State Credit Union Supervisors

NCUA National Credit Union Administration

NIST National Institute of Standards and Technology

NPI Nonpublic Personal Information

OCC Oice of the Comptroller of the Currency

OCCIP Oice of Cybersecurity and Critical Infrastructure Protection

OMB Oice of Management and Budget

PaaS Platform-as-a-Service

PAM Privileged Access Management

PFMI Principles for Financial Market Infrastructure

Reg SCI Regulation for Systems Compliance and Integrity

SaaS Soware-as-a-Service

SEC Securities and Exchange Commission

SLA Service-Level Agreement

SOC Service Organization Controls

SRMA Sector Risk Management Agency

SSB Standard-Setting Body

CLOUD REPORT n 14 n U.S. DEPARTMENT OF THE TREASURY

Introduction

2.1 Background on FBIIC and the purpose of this report

FBIIC is a Treasury-chaired committee composed of 18 federal and state nancial

regulatory organizations.

The FBIIC is charged by the President’s Working Group on

Financial Markets with improving coordination and communication among nancial

regulators, promoting public-private partnerships within the 

nancial services sector,

and enhancing the resiliency of the nancial sector overall. As part of the FBIIC’s ongoing

review of cybersecurity trends and issues in the nancial sector, Treasury leadership

commissioned this report to explore how the use of cloud services may aect the sector’s

operational resilience.

In consultation with a working group of ten FBIIC-member organizations,

Treasury

developed this report through:

• Research on how the nancial services sector uses cloud services, the legal and

regulatory authorities available to U.S. nancial regulators, regulatory activity and

observations, and FBIIC-member priorities and experiences; and,

• Consultation with market participants and other stakeholders (described in Annex B).

Stakeholders included: nancial sector trade associations, research-focused think tanks,

depository institutions, insurance companies, nancial market utilities (FMUs), CSPs,

nancial sector technology service providers, and payment networks.

2.2 HOW THE REPORT IS ORGANIZED

The report is organized around ve main topics, beginning with Section 3, Cloud Use in

Financial Services. This rst section summarizes information gained from federal and state

nancial regulators’ observations of cloud use among their regulated entities, as well as

from stakeholder feedback, including sector motivations for cloud adoption. The next

section, Domestic and International Regulatory Framework, contains a discussion of the

U.S. regulatory framework for nancial services rms’ use of cloud services, as well as a

discussion of international approaches. The third section, Financial Institution Practices

When Adopting Cloud Services, describes various approaches to cloud migration and the

steps nancial sector participants typically consider when migrating to cloud. The fourth

section, Challenges with Adoption, summarizes Treasury’s observations regarding key

5. The FBIIC member organizations are: the U.S. Department of the Treasury (Chair), American Council of State

Savings Supervisors (ACSSS), Consumer Financial Protection Bureau (CFPB), Commodity Futures Trading

Commission (CFTC), Conference of State Bank Supervisors (CSBS), Farm Credit Administration (FCA), Federal

Deposit Insurance Corporation (FDIC), Federal Housing Finance Agency (FHFA), Federal Reserve Banks of

Chicago and New York, The Board of Governors of the Federal Reserve System (FRB), National Association of

Insurance Commissioners (NAIC), National Association of State Credit Union Supervisors (NASCUS), National

Credit Union Administration (NCUA), North American Securities Administrators Association (NASAA), Oice of

the Comptroller of the Currency (OCC), Securities and Exchange Commission (SEC), and the Securities Investor

Protection Corporation (SIPC).

6. Experts from the CFPB, CFTC, CSBS, FDIC, FHFA, FRB, NASAA, OCC, and SEC assisted Treasury with developing

this report.

CLOUD REPORT n 15 n U.S. DEPARTMENT OF THE TREASURY

challenges associated with increased cloud adoption experienced by nancial institutions,

CSPs, and nancial regulators. The nal section, Areas for Further Consideration and Next

Steps, outlines Treasury’s short-term actions and long-term objectives regarding the

nancial sector’s adoption of cloud services.

2.3 BACKGROUND ON CLOUD SERVICES

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network

access to a shared pool of congurable computing resources (e.g., networks, servers,

storage, applications, and services) that can be rapidly provisioned and released with

minimal management eort or CSP interaction.

Although computer scientists had

described several of the essential characteristics of cloud computing by the mid-twentieth

century, the development of cloud services has accelerated in the last twenty years due

to advancements in virtualization and other technologies, networking, connectivity, and

reduction in costs of hardware and other components.

An organization may provide cloud computing resources via several forms: (i) public

cloud, which is available to the general public on existing infrastructure owned by a cloud

provider, (ii) private cloud, which is available for exclusive use by a single organization

on or o of their premises, (iii) community cloud, which is available for use by a specic

community of users, or (iv) hybrid cloud, which combines elements of the preceding

three deployment models.

Stakeholders also use the term hybrid cloud to describe the

preceding cloud models in combination with on-premises architecture. The gure on the

following page illustrates the essential characteristics, service models, and deployment

models of cloud services.

Cloud computing is a substantial proportion of the worldwide IT market, consisting of

hardware, soware, data centers, networking, and numerous other products and services.

According to Gartner, a technological research and consulting rm, public cloud services

spending grew from $220 billion in 2016

to $411 billion in 2021, and it is estimated to

reach nearly $600 billion in 2023.

Surveys of Chief Information Oicers (CIOs) conrm

that a substantial and growing proportion of IT spending at enterprise organizations

is dedicated to public cloud services. One recent survey indicates 72 percent of CIO

respondents expect their organization to increase their public cloud spending over

the next year, while 49 percent expect to increase their private cloud and on-premises

spending.

7. NIST, Special Publication 800-145, The NIST Denition of Cloud Computing (Sep. 2011), https://nvlpubs.nist.

gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf.

8. Garnkel, Simson, The Cloud Imperative, MIT Technology Review (Oct. 2011), hps://www.technologyreview.

com/2011/10/03/190237/the-cloud-imperave.

9. NIST SP 800-145

10. Gartner, Gartner Forecasts Worldwide Public Cloud Services Revenue to Reach $260 Billion in 2017 (Oct. 2017).

11. Gartner, Gartner Forecasts Worldwide Public Cloud End-User Spending to Reach Nearly $600 Billion in 2023

(Apr. 2022), https://www.gartner.com/en/newsroom/press-releases/2022-04-19-gartner-forecasts-

worldwide-public-cloud-end-user-spending-to-reach-nearly-500-billion-in-2022.

12. Barclays Equity Research, Cloud Wars; Vendor Positioning and Private vs. Public, by Long, Tim; Wang, George;

Shreves, Alyssa (May 2022).

CLOUD REPORT n 16 n U.S. DEPARTMENT OF THE TREASURY

This report will use the three main service models described in the NIST denition of

cloud computing to characterize cloud adoption. In 2021, according to International Data

Corporation (IDC),

the SaaS applications segment was the largest of all cloud market

segments, measuring $178 billion, growing 24 percent over the prior year. IDC estimates

that Microso

led the SaaS market (11 percent) followed by Salesforce (10 percent), SAP

(5 percent) Oracle (4 percent), and Google Cloud Platform (GCP) (3 percent).

13. International Data Corporation, Worldwide Semiannual Public Cloud Services Tracker H2-2021.

14.

Cloud services oered by each of these market participants may be conducted through multiple business lines

and across legal entities within each organization. For the purposes of this report, services provided by “AWS”

and “GCP” generally refers to all cloud services provided across the corporate families of each. References

to “Microso Azure” refer primarily to IaaS, PaaS, and some SaaS services provided by Microso (but not

Microso Oice 365 and Exchange Online).

Figure 1: NIST Denition of Cloud

CLOUD REPORT n 17 n U.S. DEPARTMENT OF THE TREASURY

The IaaS segment is the second largest segment, with projected spending of $115 billion.

It is also expected to be the fastest growing cloud segment, with projected growth in 2023

at nearly 30 percent.

Analysts have identied three dominant CSPs, with some estimates

placing the top three CSPs with over 66 percent of the total worldwide market share in

IaaS. According to one measurement of public IaaS cloud services in 2021, AWS’s revenue

comprised nearly 39 percent of the worldwide IaaS segment, followed by Microso Azure

at 21 percent, and GCP at 7 percent. Two foreign providers, Alibaba and Huawei, also

compete with 10 percent and 5 percent of worldwide market share, respectively.

The PaaS segment is the third-largest public cloud services segment worldwide, with

projected spending in 2022 of $111 billion.

Views on market leadership in the global PaaS

segment are mixed; for example, one recent CIO survey identies Microso Azure as the

market leader, followed by Amazon Web Services (AWS) and GCP,

while another identies

Microso Azure as leading, followed by Salesforce, GCP, and AWS.

VMWare, IBM, and

Oracle are other providers with oerings in both the IaaS and PaaS segments.

2.4 U.S. GOVERNMENT APPROACH TO CLOUD COMPUTING

Elements of this report are informed not just by Treasury’s engagement with interested

stakeholders but also by its experience in modernizing its own IT infrastructure. The

use of cloud computing has been an important element of the U.S. Government’s

longstanding eort to modernize its IT infrastructure and improve cybersecurity across

U.S. agencies. In May 2021, President Biden issued Executive Order 14028 (E.O. 14028),

Improving the Nation’s Cybersecurity, articulating a vision of “Zero Trust Architecture” for

Federal Government networks. NIST denes zero trust as “[a] collection of concepts and

ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request

access decisions in information systems and services in the face of a network viewed

as compromised.”

Zero trust is a security model that assumes threats exist inside and

outside of network boundaries, continuously scans for anomalous or malicious activity,

and limits access to only what is necessary to perform required jobs and protect data in

real-time.

E.O.14028 also stipulates that the “Federal Government must … accelerate

movement to secure cloud services, including Soware as a Service (SaaS), Infrastructure

as a Service (IaaS), and Platform as a Service (PaaS).” In accordance with E.O. 14028, Oice

of Management and Budget (OMB) published a Federal zero trust strategy that calls upon

U.S. agencies to dene and implement cloud-based infrastructure to support their zero

15. Gartner, Gartner Forecasts Worldwide Public Cloud End-User Spending.

16. Ibid.

17. Gartner, Gartner Says Worldwide IaaS Public Cloud Services Market Grew 41.4% in 2021 (Jun. 2022), https://

www.gartner.com/en/newsroom/press-releases/2022-06-02-gartner-says-worldwide-iaas-public-cloud-services-

market-grew-41-percent-in-2021

18. Gartner, Gartner Forecasts Worldwide Public Cloud End-User Spending.

19. Morgan Stanley Research, 1Q22 CIO Survey: A Surprisingly Durable View on Growth.

20. Goldman Sachs Equity Research, IT Spending Survey: 2022 Outlook Solid.

21. NIST, Zero Trust Architecture, by Rose, Scott, et al (Aug. 2020), https://csrc.nist.gov/publications/detail/

sp/800-207/final

22. “Executive Order 14028 of May 12, 2021, Improving the Nation’s Cybersecurity.” 86 Fed Reg. 26633.

CLOUD REPORT n 18 n U.S. DEPARTMENT OF THE TREASURY

trust models,

and CISA published technical reference architecture to provide agencies

guidance on such implementation.

Zero trust-related initiatives over the last eighteen months represent an acceleration of

eorts to use cloud services to modernize U.S. agencies’ technology infrastructure, which

began with the OMB’s “cloud-rst” Federal Cloud Computing Strategy

and development

of the Federal Risk and Authorization Management Program (FedRAMP).

FedRAMP

promotes secure cloud adoption across the Federal Government by creating standardized

security requirements for the authorization and ongoing cybersecurity of certain cloud

services. This approach enables individual agencies or the Joint Authorization Board (JAB)

to work directly with cloud providers to review the security of individual services and

conduct remediation as required. Federal agencies can review and reuse cloud service

oering packages once they are designated as “Authorized” in the FedRAMP marketplace,

enabling multiple agencies to leverage assessments conducted during the initial

authorization process.

Aer authorization, cloud providers must continuously monitor

the security state of their cloud service oerings, conduct remediation as required, and

comply with incident reporting requirements.

Treasury’s own experience with cloud

services is described in Annex A.

23. OMB, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, (Jan. 2022), https://www.

whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf.

24. CISA, Cloud Security Technical Reference Architecture (June 2022), https://www.cisa.gov/sites/default/files/

publications/Cloud%20Security%20Technical%20Reference%20Architecture.pdf.

25. OMB, Federal Cloud Computing Strategy (Feb. 2011), https://obamawhitehouse.archives.gov/sites/default/files/

omb/assets/egov_docs/federal-cloud-computing-strategy.pdf.

26. OMB, Security Authorization of Information Systems in Cloud Computing Environments (Dec. 2011), https://www.

fedramp.gov/assets/resources/documents/FedRAMP_Policy_Memo.pdf.

27. See, for example, https://www.fedramp.gov/assets/resources/documents/Agency_Authorization_Playbook. pdf.

https://www.fedramp.gov/assets/resources/documents/FedRAMP_Marketplace_Designations_for_Cloud_

Service_Providers.pdf.

28. GSA, FedRAMP Incident Communications Procedures (Apr. 2021), https://www.fedramp.gov/assets/resources/

documents/CSP_Incident_Communications_Procedures.pdf

CLOUD REPORT n 19 n U.S. DEPARTMENT OF THE TREASURY

Cloud Use in Financial Services

3.1 MOTIVATIONS SUPPORTING CLOUD ADOPTION AND TYPES OF

CLOUD SERVICES

Over the past decade, nancial institutions

have been increasing their use of cloud

services, ranging from video conferencing and collaboration soware to banking and

trading platforms that support internal operations and business line functions. This trend

exists across both small and large nancial institutions. Some smaller nancial institutions

conveyed that they felt cloud adoption was imperative for their continued viability for

some of the reasons indicated below.

Primary drivers for the nancial sector’s migration to cloud services include the following:

• Faster development and scaling of new applications and services using cloud

infrastructure and tools, particularly for articial intelligence and consumer-facing

applications, such as mobile banking and trading;

• The ability to meet competitive challenges and customer demands for digital

nancial products with robust features and data, supported by cloud services to

interface with a range of partner nancial institutions and non-banks;

• The potential for increased resilience to physical and cyber incidents, with the use of

multiple data centers or regions from the same CSP and broader use of encryption

and zero trust models;

• Third-party providers migrating to cloud services and discontinuing existing on-

premises product oerings for client nancial institutions;

• The potential for lower costs when compared to a legacy IT environment; and,

• The need for a substantial expansion in IT infrastructure to support remote workers

and customers’ use of digital nancial services, hastened by the COVID-19 pandemic.

The customizable nature of cloud services allows a nancial services rm – consistent with

its responsibilities – to select or design a cloud service that meets its business, security,

risk tolerance, resilience, and operational needs. A “shared responsibility” model typically

governs cloud services, which covers the responsibilities of the CSP (as the service

provider) and the nancial services rm (as the client), including those concerning security

obligations. A CSP typically provides the various service options for the client and commits

in the contract and other service documentation to maintain specic baseline security,

performance, and resilience controls for the purchased cloud service. The contract will

specify the responsibilities of either the vendor or client with respect to the evaluation and

selection of the service architecture and the design and implementation of related security

29. The focus of this report is on how cloud services are being adopted by nancial institutions subject to

supervision and regulation by FBIIC members. Section 3.1 to section 3.5 of this report discusses how cloud

services are being used across the nancial services sector, and section 3.6 to 3.8 provides details on specic

components of the nancial services sector. See Section 4.1 for additional information on the specic

institutions and authorities within the purview of individual agencies.

CLOUD REPORT n 20 n U.S. DEPARTMENT OF THE TREASURY

and resilience controls. This responsibility will vary between the three cloud deployment

models: IaaS, PaaS, and SaaS. Notwithstanding these contractual terms, a nancial

services rm remains ultimately responsible for the operational resilience of its business,

including functions that rely on the use of cloud services.

3.2 POTENTIAL BENEFITS OF CLOUD COMPUTING TO OPERATIONAL

RESILIENCE

Industry practitioners and other technical experts generally believe that when congured

correctly, public cloud services can provide an environment that is resilient and secure.

But the resilience and security of any particular cloud service can and will vary depending

on the vendor and service, as well as how each service is congured, provisioned, and

managed. Not all of these features may be available in all circumstances.

REDUNDANCY

Cloud services oer physical redundancy beyond what most nancial institutions could

develop independently. Some CSPs structure cloud services to operate from multiple

“availability zones,” which are physically or logically isolated data centers that host cloud

services.

The availability zones are usually grouped into regions (e.g., U.S. east coast

vs. U.S. west coast), with the major cloud providers oering multiple regions across

the globe. The architecture underpinning public cloud services may allow clients to

maintain completely synchronized data sets at various data centers within an availability

zone, resulting in little or no data loss if a client switches from primary deployment

to redundant options. Each data center region is intended to be isolated to limit the

probability of concurrent disruption. But because cloud services are usually delivered

through the internet, CSPs and nancial institutions may rely on data communications

service providers to provide uninterrupted data communications. Though some on-

premises congurations used by nancial institutions may be similarly reliant on data

communication service providers as well.

SCALABILITY AND SPEED TO DEPLOY ASSETS

The ability to rapidly procure and commit new resources may be the most attractive

feature of cloud services to nancial institutions. Cloud services are deployed over the

internet and are also generally not subject to bandwidth limitations of traditional virtual

private networks.

Intermittent workloads, like risk modeling or development environments on the public

cloud, are common use cases for nancial institutions that benet from the scalability

of the cloud environment. Being able to deploy limited-use resources quickly on an IaaS

30. Specic implementation of these concepts, e.g., physical vs. logical isolation, size and capacity of a region or

availability zone can vary. See Amazon, Regions and Availability Zones, https://aws.amazon.com/about-aws/

global-infrastructure/regions_az/, Google, Regions and Zones, https://cloud.google.com/compute/docs/

regions-zones Microso, What are Azure regions and availability zones?, https://learn.microso.com/en-us/

azure/reliability/availability-zones-overview.

31. Cloud congurations may not always be reliant on data communication services providers, because some

CSPs operate their own global networks to facilitate the movement of data within the cloud and some clients

may have direct private connections to their CSPs.

CLOUD REPORT n 21 n U.S. DEPARTMENT OF THE TREASURY

environment can also oer a more exible testing environment for nancial institutions,

which helps support the transition to a more secure soware development pipeline

based on continuous integration and deployment for nancial institutions that develop or

modify their soware.

Experts note that the capability to scale resources could allow nancial institutions to

add three-, ve-, or ten-x capacity to support existing workloads. Financial institutions

conveyed that eorts to develop this capability for core processing activity were still at

the theoretical stage. In their view, public cloud services appeared to be the most viable

means to achieve this type of “burst capacity.” Assuming that relevant workloads were

fully deployed on the cloud environment, this type of capability could be valuable during a

period of heightened market stress requiring more transactions to be processed.

SECURITY

From the perspective of the nancial institutions interviewed for this report, the security

capabilities for public cloud services generally match or exceed their on-premises

capabilities. For example, a number of stakeholders mentioned that the built-in logging

capabilities associated with many IaaS services are oen superior to their on-premises

capabilities for their own assets deployed on the cloud. Cloud services also enable

nancial institutions to encrypt data more readily at rest and in transit. Some CSPs

also have processes to address lesser-known security risks, like vulnerabilities through

individual components, by fully securing their hardware supply chain.

However, some nancial institutions had challenges in making such determinations

regarding the security capabilities provided by CSPs based on the current level of the

information supplied by CSPs. For example, some nancial institutions indicated they

wanted to know more about CSPs’ internal soware dependencies, testing results, and

other processes relevant to assessing how CSPs address risks to the cloud environment.

It also can be challenging for nancial institutions to manage the integration of cloud

services with their on-premises IT infrastructure. As a result, there could be dierences

between theoretical security capabilities and actual results. These issues are further

explored in Section 6.

3.3 SHARED RESPONSIBILITY

It is common practice for CSPs to assume specic technical, administrative, and physical

security responsibilities for certain underlying aspects of the cloud service. For example,

CSPs in the IaaS model are generally responsible for securing the IT hardware and the

single or multi-tenant environment in which the hardware resides, while the nancial

institution is typically responsible for setting the security controls for the operating

systems and applications placed in the IaaS environment. In a SaaS model, the CSP is

customarily responsible for securing all aspects of the SaaS application and its operating

CLOUD REPORT n 22 n U.S. DEPARTMENT OF THE TREASURY

environment. At the same time, the nancial institution is usually responsible for securing

its access to the application. The level of the CSP’s involvement and control over the

security and other operational aspects of the cloud service generally increases along the

continuum of IaaS to SaaS.

This approach to allocating management of service architecture and security and

resilience controls for cloud services between the nancial institution and the CSP is

generally referred to as a “shared responsibility” approach, which makes it more practical

to scale public cloud services across thousands of clients.

The contract between

the CSP and the client typically cover their respective responsibilities in the event

there is an operational or cyber incident (like expectations around initial notication).

Notwithstanding the shared responsibility approach, nancial institutions are ultimately

responsible for managing the risks of a CSP relationship and for the security of all their

information assets, including those deployed on the cloud. To fulll this responsibility,

nancial institutions will generally conduct a risk-based evaluation of cloud service(s)

and determine if security and resilience controls (whether under the nominal purview of

the nancial institution or the CSP) are commensurate with the security obligations and

risk posture of the nancial institution. Section 5 contains further discussion of nancial

institution practices, and Section 6 describes challenges and tensions arising from the

shared responsibility model.

The graphic below shows one example of an allocation approach of operational and

security management associated with CSP and its customer entities. The approach may

vary for dierent CSPs, the cloud services they provide, and the customers they serve.

Source: GSA, Cloud Information Center, https://cic.gsa.gov/basics/cloud-security

32 GSA, Cloud Information Center,

https://cic.gsa.gov/basics/cloud-security

Figure 2: Security Responsibilities Between Clients and CSPs

CLOUD REPORT n 23 n U.S. DEPARTMENT OF THE TREASURY

3.4 TYPES OF CLOUD SERVICES USED BY FINANCIAL INSTITUTIONS

3.4.1 SOFTWARE AS A SERVICE (SAAS)

SaaS is currently the most widely adopted cloud service by nancial institutions. For

example, one survey estimated adoption in the banking industry around 91 percent.

Similar to traditional outsourcing, nancial institution management does not directly

manage, maintain, or control the underlying cloud infrastructure or individual application

capabilities of the SaaS application. Rather, the SaaS provider manages the underlying

soware application and the cloud infrastructure on which the SaaS application resides.

In addition to managing the overall risk of its relationship with the CSP, under the SaaS

model, nancial institutions typically retain operational responsibility for the data

transmitted and stored in the SaaS application, user-specic application conguration

settings, setting user access rights, and monitoring use. The CSP is responsible for any

changes to and maintenance of the applications and infrastructure. Common SaaS

applications include oice productivity systems, compliance tools (such as anti-money

laundering tools), order/portfolio management systems, and security monitoring tools.

Financial institutions generally nd SaaS applications to be the easiest cloud-based

services to deploy and manage. For example, it is common practice among small and large

institutions to use cloud-based versions of traditional soware applications like email.

Many traditional third-party nancial technology service providers are expanding their

product lines to include cloud-based soware versions of their core banking and trading

soware. A vast number of third-party service providers may provide their nancial

institution customers with applications that rely on CSP-provided SaaS.

3.4.2 PLATFORM AS A SERVICE (PAAS)

Financial institutions use PaaS to support soware development and deploy security

tools, oen in conjunction with their use of IaaS. These applications reside on the

provider’s platforms and cloud infrastructure. PaaS models necessitate similar risk

management as the SaaS model. However, a nancial institution is additionally

responsible for the appropriate provisioning and conguration of cloud platform resources

and implementing and managing controls over the development, deployment, and

administration of applications residing on the provider’s cloud platforms. The CSP is

responsible for the underlying infrastructure and platforms (including network, servers,

operating systems, or storage). Financial institutions’ current use of PaaS services is

signicant but substantially smaller than their use of SaaS cloud services. According to a

survey conducted in 2021 by the American Bankers Association, 43 percent of the surveyed

nancial institutions with cloud deployments used PaaS cloud applications. This number

was projected to increase to 64 percent in the next two years.

33 American Bankers Association, Cloud Computing in the U.S. Banking Industry (Jun. 2021).

34 Ibid.

CLOUD REPORT n 24 n U.S. DEPARTMENT OF THE TREASURY

3.4.3 INFRASTRUCTURE AS A SERVICE (IAAS)

Financial institutions commonly use IaaS to support in-house developed or acquired

core processing platforms, as well as to support data storage, business recovery, and to

increase the eiciency, agility, and scalability of their IT infrastructure. Some nancial

institutions employ a hybrid model with an on-premises data center supported by data

storage and computing facilities in a public cloud that can be accessed to support large

scale processing and storage demands or backup functions as needed.

Like PaaS, IaaS arrangements usually make the nancial institution responsible for

appropriately provisioning and conguring cloud platform resources, and implementing

and managing controls over operations, applications, and data. Additionally, the IaaS

model typically places responsibility on nancial institutions for networks, servers,

operating systems, and storage. Financial institution management may need to congure

the institution’s enterprise systems to work with the CSP’s resilience and recovery

process. The CSP is responsible for controls related to managing the physical data center.

For example, the CSP updates and maintains the hardware, network infrastructure,

environmental controls (e.g., heating, cooling, and re and ood protection), power,

physical security, data communications connections, and the “lynchpin” services that

underpin and are necessary for the provision of many cloud services (e.g., domain name

systems, identity access management, virtualization rmware or hardware).

A 2021 survey by American Bankers Association (ABA) revealed that IaaS is the least

commonly used cloud service by banks, with 29 percent of the surveyed using IaaS

applications in cloud. Respondents, however, expected this to increase to 52 percent in the

next two years.

3.4 PRIVATE VS. PUBLIC CLOUD

Public cloud is a cloud computing model in which services and infrastructure are managed

and maintained by a third-party provider and shared with multiple users remotely through

the public internet. Data centers utilize a multi-tenant system in which users share access

to services and host data on the same servers. Public cloud eliminates the need for

organizations to host and maintain services in internal data centers, reducing the cost of

on-site systems and associated operational challenges.

In a private cloud, computing services are provisioned for exclusive use by a single

organization.

Private clouds can be hosted either on-premises or through a CSP that

maintains private data centers. The private cloud establishes an additional layer of control

for users but also imposes increased operational costs.

Broad adoption of cloud computing by nancial institutions with varying scalability,

security, and compliance needs has increased demand for more exible approaches. The

dichotomy between the use cases for public and private clouds for nancial institutions

has blurred in practice as CSPs have sought to integrate components of both frameworks.

35. Ibid.

36. NIST SP 800-145.

CLOUD REPORT n 25 n U.S. DEPARTMENT OF THE TREASURY

3.5 DIFFERENT APPROACHES TO ADOPTION

Financial institutions continue to have diverse approaches to cloud use. Their use of SaaS

applications, including email, document collaboration, human resources applications,

and video conferencing, are now common. However, the use of IaaS and PaaS varied

signicantly among the rms interviewed for this report. Institutions cited a number of

dierent approaches and desired end-states in their cloud strategy, including migrating

to the cloud fully (“all-in”); combining cloud with on-premises architecture (“hybrid); or

diversifying reliance on dierent cloud vendors (“multi-vendor” or “multi-cloud”). Firms

interviewed oen developed medium- to long-term plans to cloud adoption (e.g., 3–5-year

strategic roadmaps). Several institutions also noted that the development of their cloud

strategy was accompanied by or helped inform a broader strategic evaluation of their

entire IT architecture. Examples of how the rms interviewed were implementing such

approaches are described below.

3.5.1 HYBRID APPROACHES

The most common strategy that rms pursued was a hybrid approach, where public cloud

deployment continued to be mixed with on-premises or private cloud oerings. This

method oen involved loading less critical applications to the cloud rst to build their

in-house understanding and comfort with cloud deployment. It could include migrating

sensitive data sets to the cloud, but generally not relying on the cloud for projects that

required continuous uptime (e.g., the most critical workloads). In some cases, nancial

institutions fully integrated cloud deployments to connect with customers as a complete

extension or expansion of their on-premises or private cloud capabilities, but such

extensions have typically been limited to operations that the nancial institution has

determined to be less critical. Some rms continue to consider how to develop more

technically complex resilience options on the cloud (e.g., as a potential way of rapidly

scaling up their infrastructure to meet market needs, or as a backup beyond their primary

and secondary data centers), but the development of these options appears to be in very

early phases.

3.5.2 MULTI-VENDOR APPROACH

The multi-vendor approach generally refers to a cloud program in which a rm diversies

its exposure to CSPs using multiple vendors. This approach can be divided into two

distinct methods: (i) multiple vendors, with each vendor supporting dierent applications

or workloads (referred to as “use cases”); and (ii) multiple vendors supporting the same

use cases.

An example of the rst instance is when a nancial institution uses one CSP for cloud-

based video conferencing, another CSP for cloud-based productivity services, and yet

another CSP for risk modeling. An example of the second instance is when a nancial

institution places its customer-facing online banking application on multiple CSPs and

CLOUD REPORT n 26 n U.S. DEPARTMENT OF THE TREASURY

links the applications back to the core platform for processing and recordkeeping. Only

a handful of rms interviewed were considering developing this multi-vendor, single-use

case deployment for more complex services like IaaS. Doing so would require complex

design choices to ensure that data sets were synchronized and application capabilities

were the same. It would also require sta with development expertise in multiple cloud

environments, as well as accompanying cloud security and risk management expertise.

Most rms Treasury interviewed considered multi-vendor, single-use case deployment too

technically complex (and, as a result, the accompanying operational risks too high) to even

consider developing at this time.

Financial institutions could have a range of reasons to use multiple CSPs. Sometimes rms

wanted to diversify services because they evaluated one vendor to have better capabilities

for a particular application or workload. Other times, the rm wanted to avoid being

locked into a particular vendor. Many rms also minimized using proprietary CSP services

and developed their cloud infrastructure around open-source code to reduce risks that

they may be eectively locked into a relationship with one CSP. Even with these eorts,

swapping complex workloads to another CSP or bringing services in-house was oen

estimated to take months, if not years to successfully execute in almost all cases.

3.5.3 “ALL-IN” APPROACHES

The rms that most intensively adopted the cloud to retire their existing on-premises

IT architecture oen focused on service oerings from one vendor because they judged

that this approach would reduce operational risks associated with cloud deployment.

Monitoring threats, like unauthorized activity, were made easier when all critical

information systems were running on the same platform. A single-vendor approach

reduced the burden of training sta on the use of multiple platforms. Firms most

heavily invested in the cloud stressed their strategy was to reduce their existing data

center footprint and retire legacy applications and architecture (i.e., go “all-in” on cloud

infrastructure). Several rms expressed that adopting the cloud could help re-focus their

organization on technology essential to their businesses.

3.5.4 SELECTING A DEVELOPMENT STRATEGY

Aside from an overall strategy, many rms looked at cloud adoption on a use-case-by-

use-case or application-by-application basis, noting that many legacy applications were

ill-suited to be placed in a cloud environment without modication. For each application,

rms would typically select a development strategy

from the following options (which

are listed below in order of intensity of change required):

• Rehost or “Li and shi” — moving applications to the cloud as-is.

• Replatform — moving applications to the cloud without major changes but taking

advantage of the benets of the cloud environment.

• Refactor — modifying applications to be better supported in the cloud environment.

37. Gartner, Migrating Applications to the Cloud: Rehost, Refactor, Revise, Rebuild, or Replace? (Dec. 2010), hps://

www.gartner.com/en/documents/1485116.

CLOUD REPORT n 27 n U.S. DEPARTMENT OF THE TREASURY

• Rebuild — rewriting the application from scratch.

• Replace — retiring the application and replacing it with a new or existing cloud-native

application.

3.6 CLOUD USE BY DEPOSITORY INSTITUTIONS

The cloud strategies of the banks and credit unions Treasury interviewed spanned the

broad spectrum of cloud adoption. A small number of depository institutions operate

entirely on the public cloud. Some institutions noted that the cloud was necessary to

compete with non-depository and ntech rms for reasons including speed to market,

cost, and customer experience. Still, other institutions noted an unwillingness to move to

the cloud at this time because of challenges related to contracting, skills, or condence in

being able to meet regulatory requirements in a cloud environment.

Depository institutions have started storing sensitive data on the public cloud, from

community banks and credit unions to global systemically important banks. Most

interviewed institutions generally moved workloads to the private cloud before

considering the public cloud. Some depository institutions operated sensitive workloads

in the cloud environment (like deposit and loan systems and payments and trade

processing). Many banks noted that risk modeling, particularly when utilizing articial

intelligence techniques oered by CSPs, was superior to what they could produce using

on-premises architecture.

Depository institutions’ exposure to the cloud is also indirect via third parties that also

rely on cloud services. Financial institutions noted that many of their third-party suppliers

were moving to cloud-based oerings and no longer oering on-premises compatible

solutions, forcing a migration to the cloud. Some nancial institutions noted it could be

easier and more secure to interface with third-party suppliers when they used the same

cloud environment.

SECTOR-WIDE TRENDS

According to a survey conducted in 2021 by the ABA, more than 90 percent of surveyed

banks stated that they maintain at least some data, applications, or operations in the

cloud.

Of those surveyed, more than 80 percent indicated they were in the “adoption” or

“early adoption” phase with cloud services. Only 5 percent of respondent banks described

their cloud use as mature.

According to a May 2022 survey conducted by a CSP, over two-thirds of the surveyed banks

want at least 30 percent of their applications and data to be in the cloud in three years.

This gure would represent approximately triple the rate of cloud adoption from the time

of the survey.

Similarly, a 2021 consulting company survey of banks, including North

American nancial institutions, estimated that an average of 8 percent of all banking

38. ABA Cloud Computing.

39. Publicis Sapient in collaboration with GCP, Future of Cloud in Banking - Report -- How leading banks accelerate

digital transformation with cloud (May 2022).

40. Ibid.

CLOUD REPORT n 28 n U.S. DEPARTMENT OF THE TREASURY

workloads were cloud-based.

This same survey indicated 24 percent of respondent

banks located in North America had partially migrated core services to the cloud.

3.7 CERTAIN NONBANKS

3.7.1 INVESTMENT ADVISERS, INVESTMENT COMPANIES, BROKER-DEALERS

Larger investment advisors, investment companies, and broker-dealers are adopting

cloud computing services to scale operations, build for business continuity needs, and

launching products more quickly to market. Some rms started natively in the cloud and

have built their entire technology stack in the cloud. Other rms are either in the process

of preparing to move to the cloud, piloting workloads in the cloud, or scaling operations

in the cloud, typically in an incremental fashion. Still, others have yet to transition to

the cloud signicantly and are taking a “wait-and-see” approach to gain additional

information as cloud computing matures.

Most of these types of nancial institutions are not “all-in,” nor do they plan to execute a

“li-and-shi” deployment. Rather, they are assessing cloud services as a technology to

be deployed where appropriate and not yet for core processing. Some exceptions exist,

particularly among smaller institutions with limited IT resources. Smaller institutions tend

to use cloud services largely through third-party soware providers and managed serviced

providers who, in turn, use the larger CSPs.

Lastly, as securities and investment rms make greater use of Articial Intelligence /

Machine Learning (AI/ML), they rely increasingly on cloud services and provisioning to

accommodate the large data sets and computing power required for AI/ML.

3.7.2 INSURANCE COMPANIES

Insurance companies are also migrating to the cloud environment for similar reasons. One

rm noted the importance of leveraging the cloud for its modernization and improving

the customer experience, not simply replicating existing on-premises workloads. This

approach entails the development of most, if not all, new applications in the cloud.

Some insurance companies are prioritizing the most dynamic workloads to migrate rst

to the cloud. Examples of these more high-priority activities include a company’s oicial

website or articial intelligence (AI) platforms that require regular updating, as compared

to more static workloads that could continue running on the mainframe. In contrast,

others are choosing to migrate all workloads to the cloud to minimize their on-premises

footprint. Insurance companies that operate globally are considering adopting cloud

across their enterprise, but generally will be more mature in their U.S. operations, partly

because of the dierences in regulatory requirements.

3.7.3 HOUSING-RELATED ENTITIES

Housing nance entities participating in U.S. mortgage markets by oering single- and

multi-family lending, as well as participating in mortgage securitizations and related

41. Accenture Banking Cloud, What does it mean to be a bank in the cloud?, Altimeter Volume #1 (2022).

42. Ibid.

CLOUD REPORT n 29 n U.S. DEPARTMENT OF THE TREASURY

products or loan servicing, are also utilizing cloud services. Some housing nance

entities have migrated critical business operations to the cloud, though many are

at varying degrees of cloud adoption. One basis for cloud adoption is an interest in

leveraging machine learning techniques and capabilities for the control environment

and managing IT assets. Cloud services adopted by housing nance entities support

a range of business activities and internal operations, including IT and cybersecurity

management, monitoring, logging, and reporting. Certain entities have implemented an

“all-in” approach to the cloud, and others have initiated the migration process but have

yet to determine whether a complete transition to the cloud is operationally benecial and

feasible. Through the migration process, however, some rms have ascertained that they

could “li and shi” few of their applications to the cloud. Instead, extensive refactoring is

required to complete the transition.

3.7.4 FINANCIAL SECTOR TECHNOLOGY SERVICE PROVIDERS

Several technology service providers that specialize in providing services to nancial

institutions (such as for core banking and trading soware) are also turning to cloud

services. They are particularly motivated to reduce costs and technical debt with legacy

soware in favor of on-demand costs and features desirable to their clients. These

technology service providers are also leveraging SaaS applications for business operations

(e.g., Oice 365, Salesforce), accounting, human resources (HR) soware, and high-traic

consumer-facing applications.

Many of these nancial sector technology service providers have business models that

rely on maintaining service-level agreements (SLAs) with their client nancial institutions.

The SLAs may specify uptime percentages and recovery time objectives in the event of

a disruption of services to their client nancial institutions. Therefore, these technology

service providers tend to have a low tolerance for network disruptions or outages at their

suppliers and sub-contractors. One of the nancial sector technology service providers

interviewed in connection with this report indicated that in their view, the resiliency/up-

time capabilities that CSPs oer the service providers did not always map to, or support,

the same level of resiliency/up-time that the nancial sector technology service provider

oered to its client nancial institutions.

Financial sector technology service providers are also motivated to pursue cloud adoption

and cloud-native application development to meet the demand of customers who

increasingly operate in a cloud environment. This motive is true of the activities that

service providers inherit through acquisitions (e.g., ntechs) that are mainly operating in

the cloud environment, amounting to a signicant portion of companies’ existing cloud

activities. With these factors combined, many providers Treasury interviewed stated their

belief that their migration to the cloud is an inevitability given external trends.

These technology providers have begun integrating cloud services using a variety

of adoption strategies and with dierent long-term goals (e.g., full cloud migration,

CLOUD REPORT n 30 n U.S. DEPARTMENT OF THE TREASURY

hybrid). Some of these service providers have opted to rely heavily on the CSPs’ security

oerings, and others have emphasized portability as a design consideration. One provider

interviewed noted its intention of building its new products natively in the cloud while

largely retaining its legacy products (e.g., back-oice processing, check imaging) on-

premises.

3.8 CRITICAL MARKET INFRASTRUCTURE

FMUs and other entities subject to the SEC’s Regulation for Systems Compliance and

Integrity (Reg SCI) as well as registered entities subject to the CFTC’s System Safeguards

Regulations, are also exploring cloud services. Because of the nature of their business,

these entities prioritize investment in resiliency measures to ensure near-uninterrupted

availability of their services. These entities principally use SaaS applications in the cloud

for internal, non-critical purposes (e.g., corporate employee operations, HR systems,

Oice365, Salesforce), while many core business processes (e.g., clearing, settlement)

have remained on-premises. Further, most of these entities are focused on evaluating

which of their activities would most benet from moving to the cloud, not migrating all

their operations.

SCI and CFTC registered entities’ cloud adoption varies signicantly. One entity has used

the private cloud to host operations it has determined to be non-critical while it looks to

a more phased-in expansion to the public cloud. Another registered entity’s failback plan

involves maintaining an on-premises data center that could continue its operations for

30 days in the case of a CSP outage. Other registered entities assert that there are more

resiliency measures available in the cloud to protect against ransomware attacks than

there are on premises. Another registered entity uses the cloud for analytics, regulatory

reporting, and systems it determines to be non-critical. One larger registered entity plans

to migrate its critical services to the cloud in the next two years aer migrating systems

not covered under the SEC’s Reg SCI. One swap data repository has also transitioned to

the cloud, where it now stores all its swap data. Another registered entity has established

a partnership with a CSP, intending to consolidate and enhance the various services

provided to its customers without the need to rely on multiple vendors.

CLOUD REPORT n 31 n U.S. DEPARTMENT OF THE TREASURY

Domestic and International Regulatory Framework

4.1 U.S. REGULATORY FRAMEWORK AND AUTHORITIES

Financial institutions routinely depend on other nancial institutions, nancial market

infr

astructure, common utilities, and a wide network of other third parties to deliver

services safely and eiciently to customers. These dependencies, including on cloud

services, are oen subject to a range of institutional controls and risk management

frameworks, as well as regulatory requirements.

FBIIC members have a range of authorities and mandates with respect to nancial

institutions and their third-party risks. In general terms:

• The FDIC, FRB, and OCC supervise and regulate the safety and soundness of banking

institutions and certain related or affiliated entities, and the NCUA does the same for

credit unions;

• The SEC and CFTC oversee and regulate key participants in the securities and

derivative markets, including broker-dealers, investment companies and advisors,

exchanges, clearing entities, and financial market utilities;

• The FHFA has the authority to regulate and supervise Fannie Mae, Freddie Mac, and

the Federal Home Loan Banks;

• The CFPB has a range of authorities to regulate consumer protection issues at

financial institutions, which can include consumer harm caused by insufficient data

protection or security for sensitive information;

and,

• The ACSSS, CSBS, NAIC, NASCUS, and NASAA represent state banking, markets, and

insurance regulators, which can have a range of authorities over state-regulated

entities.

The U.S. financial services regulatory and supervisory regime is generally neutral on the

types of technology services that regulated entities use with regard to their operations or

the financial services they provide. Applicable federal regulatory requirements

place

responsibility for effective and appropriate management of technology operations and

related risks, such as cybersecurity, on financial institutions, regardless of whether any

particular activities or operations are outsourced to third parties. Financial institutions

generally have discretion to choose vendors, services, and other aspects of their

technology architecture. In certain cases, there are requirements for the financial

institution to notify its regulator of a change or planned change to a technology system or

the use of a technology service provider.

43. See e.g., CFPB, Circular 2022-04, Insuicient data protection or security for sensitive consumer information, (Aug.

11, 2022), available at hps://les.consumernance.gov/f/documents/cfpb_2022-04_circular_2022-08.pdf.

44.

The focus of this section is on U.S. federal regulatory frameworks. In certain cases, these requirements may

also be supplemented by laws, rules, and regulations from state regulatory authorities.

CLOUD REPORT n 32 n U.S. DEPARTMENT OF THE TREASURY

GENERAL REQUIREMENTS

The privacy and disclosure provisions of the Gramm-Leach-Bliley Act (GLBA) generally

reect U.S. policy that nancial institutions have an airmative and continuing obligation

to respect the privacy of their customers and to protect the security and condentiality

of those customers’ nonpublic information.

These requirements apply to nancial

institutions, which are generally dened as any institution the business of which is

engaging in nancial activities, where nancial activities are broadly dened and include

lending, transferring, investing, or safeguarding money or securities, as well as providing

certain insurance and advisory services.

GLBA generally requires nancial institutions to notify consumers of the disclosure of

their nonpublic personal information (NPI) to nonailiated third parties and requires

nancial institutions to allow consumers to opt-out of such disclosures, subject to

certain exceptions.

A notable exception to this rule is providing NPI to nonailiated

third parties that perform services for or functions on behalf of the nancial institution.

In such cases, the nancial institution must disclose the sharing of such information and

enter into a contractual agreement with the third party that requires the third party to

maintain the condentiality of the information.

GLBA also requires the FDIC, FRB, NCUA,

OCC, SEC, the Federal Trade Commission, and state insurance regulators to establish

appropriate standards for covered nancial institutions subject to their jurisdiction

relating to administrative, technical, and physical safeguards to: (i) ensure the security and

condentiality of customer records and information; (ii) protect against any anticipated

threats or hazards to the security or integrity of such records; and (iii) protect against

unauthorized access to or use of such records or information which could result in

substantial harm or inconvenience to any customer.

AGENCY-SPECIFIC STANDARDS

U.S. regulators’ rules, regulations, and guidance applicable to cybersecurity and third-

party risk management of nancial institutions can take dierent forms depending on

the issuing agency’s statutory authority. For example, the FDIC, FRB, and OCC have issued

Interagency Guidelines Establishing Information Security Standards

(“Guidelines”)

pursuant to authorities under GLBA and the Federal Deposit Insurance Act. The Guidelines

apply to customer information maintained by or on behalf of entities over which the

banking agencies have authority. The Guidelines set forth standards for covered entities

when implementing a comprehensive written information security program.

Under these

45. 15 U.S.C. § 6801.

46. 15 U.S.C. § 6809; 12 U.S.C. § 1843(k). See also 16 C.F.R. § 314.2(h) (a Federal Trade Commission rule setting out

examples of entities that are or are not nancial institutions).

47. 15 U.S.C. § 6802(a).

48. Id.

49. 15 U.S.C. §§ 6801(b), 1805(b). The CFTC is also required, under 7 U.S.C. § 7b-2, to prescribe GLBA regulations

for certain entities under its jurisdiction.

50. 12 CFR pt. 30, app. B (OCC); 12 CFR pt. 364, app. B (FDIC); 12 CFR pt. 208, app. D-2, and pt. 225, app. F (FRB). For

convenience, example citations to these Guidelines are made to the FDIC version.

51. See 12 CFR pt. 364, app. B, § II (FDIC).

CLOUD REPORT n 33 n U.S. DEPARTMENT OF THE TREASURY

Guidelines, information security programs should include administrative, technical, and

physical safeguards appropriate to the size and complexity of the entity and the nature

and scope of its activities. Under the Guidelines, an institution’s information security

program should generally be designed to:

1. Ensure the security and condentiality of customer information;

2. Protect against any anticipated threats or hazards to the security or integrity of such

information;

3. Protect against unauthorized access to or use of such information that could result in

substantial harm or inconvenience to any customer; and

4. Ensure the proper disposal of customer information and consumer information.

The Guidelines also set forth specic standards concerning an institution’s oversight of

service provider arrangements. These standards include (i) exercising appropriate due

diligence in service provider selection, (ii) obligating service providers (by contract) to

implement appropriate information security measures that are designed to meet the

objectives of the Guidelines, and (iii) ongoing monitoring of the relationships to conrm

that the service providers have satised their information security obligations (where

indicated by the institution’s risk assessment). Additionally, the FDIC, FRB, and OCC

have each issued third-party risk management guidance and have collectively proposed

updated and uniform guidance.

The SEC has implemented Reg SCI for certain entities under its jurisdiction.

With respect

to securities, Reg SCI sets standards for systems that directly support trading, clearance

and settlement, order routing, market data, market regulation, or market surveillance. SCI

Entities are required to, among other things, establish, maintain, and enforce written

policies and procedures that are reasonably designed to ensure that these systems have

levels of capacity, integrity, resiliency, availability, and security adequate to maintain their

operational capability and promote the maintenance of fair and orderly markets.

Reg SCI requires SCI Entities to maintain business continuity and disaster recovery plans

that include maintaining backup and recovery capabilities sufficiently resilient and

geographically diverse, and that are reasonably designed to achieve next business day

resumption of trading and two-hour resumption of critical SCI systems following a wide-

scale disruption. The SEC has also issued a proposed rule to prohibit registered

investment advisors from outsourcing certain services or functions without first meeting

minimum requirements.

52. 12 CFR pt. 364, app. B, § II.B (FDIC).

53. See Proposed Interagency Guidance on Third-Party Relationships: Risk Management, 86 Fed. Reg. 38182 (July

19, 2021).

54. 17 C.F.R. § 242.1000 et seq. SCI entities include self-regulatory organizations, including registered clearing

agencies, the registered national securities exchanges, and certain alternative trading systems, plan

processors, exempt clearing agencies and competing consolidators of equity market data.

55. See SEC, Outsourcing by Investment Advisers, 87 Fed. Reg. 68816 (Nov. 16, 2022).

CLOUD REPORT n 34 n U.S. DEPARTMENT OF THE TREASURY

In addition to GLBA rules that apply to certain CFTC-regulated entities,

the CFTC has

implemented system safeguards requirements for certain other registered entities.

Those

entities must establish and maintain a program of risk analysis and oversight to identify

and minimize sources of operational risk through the development of appropriate controls

and procedures and automated systems that are reliable, secure, and have adequate

scalable capacity. In addition, the system safeguards require that those registered entities

have business continuity and disaster recovery plans suicient to enable timely recovery

and resumption of operations, generally by the next business day.

And for derivatives

clearing organizations (DCOs) designated by FSOC to be systemically important,

the requirement is resumption of operations two hours following the disruption.

Furthermore, if a DCO determines to meet any system safeguards requirement using a

contractual arrangement with another DCO or other service provider, the DCO shall retain

complete responsibility for any failure to meet related safeguards requirements and the

DCO must employ personnel with the expertise necessary to enable it to supervise the

service provider’s delivery of the services.

EXAMINATION AND SUPERVISION OF FINANCIAL INSTITUTIONS

Subject to the scope of each agency’s authorities, FBIIC members’ supervision and

examination of nancial institutions may include a nancial institution’s technology

operations and related risk management programs. Agencies may review a nancial

institution’s governance related to technology and cybersecurity risks, assess the nancial

institution’s risk management program for IT security and resilience, and review the

results of tests of relevant response and recovery programs to understand the resiliency of

the nancial institution’s operations and services.

For example, the FDIC, FRB, and OCC

review whether supervised institutions’ third-party relationships and risk management

practices are consistent with the safety and soundness of those institutions. Such reviews

may also include understanding how a nancial institution manages the risks posed by

services provided to the institution by third parties.

The Federal Financial Institutions Examination Council (FFIEC),

FHFA,

and others

have issued documents that provide examples of risk management practices that

56. See 17 C.F.R. Part 160; id. at § 160.30 (providing rules for “[e]very futures commission merchant, retail

foreign exchange dealer, commodity trading advisor, commodity pool operator, introducing broker, major

swap participant, and swap dealer subject to the jurisdiction of the [CFTC]”).

57. System safeguards requirements apply to derivatives clearing organizations, designated contract markets,

swap execution facilities, and swap data repositories. 17 C.F.R. Parts 37, 38, 39, and 49.

58. 17 C.F.R. § 37.1401(c), 38.1051(d), 39.18(c)(2) and 49.24(d).

59. 17 C.F.R. § 39.34(a).

60. 17 C.F.R. § 39.18(d)(2).

61. For example, in 2021 alone, the FDIC conducted 1,271 specialty examinations for Information Technology

and Operations at state nonmember banks, assigning an IT rating using the FFIEC Uniform Rating System

for Information Technology. See FDIC, 2021 Annual Report 29, 34, https://www.fdic.gov/about/financial-

reports/reports/2021annualreport/2021-arfinal.pdf.

62. This type of review is often referred to as “indirect supervision” of third-party services.

63. See FFIEC, Joint Statement: Security in a Cloud Computing Environment, https://www.ffiec.gov/press/PDF/

FFIEC_Cloud_Computing_Statement.pdf; FFIEC, Informa ion Technology Examina ion Handbook: Architecture,

Infrastructure, and Operations, https://ithandbook.ffiec.gov/it-booklets/architecture,-infrastructure,-and-

operations.aspx.

64. See FHFA, Cloud Computing Risk Management, AB 2018-04, https://www.fhfa.gov/SupervisionRegulation/

AdvisoryBulletins/Pages/Cloud-Computing-Risk-Management.aspx.

CLOUD REPORT n 35 n U.S. DEPARTMENT OF THE TREASURY

support the safe and sound use of cloud computing, as well as specic alerts and

checklists related to cloud services.

Although agencies’ rules, guidance, examination

practices, and resources may dier, they oen draw upon or can be mapped against

common standards and frameworks, such as the NIST Cybersecurity Framework,

Control

Objectives for Information and Related Technologies (COBIT), International Organization

for Standardization (ISO) standards, Center for Internet Security (CIS) Critical Security

Controls, and CISA’s Cybersecurity Performance Goals.

The FHFA also monitors cloud

adoption among regulated entities through regular examinations and reviews of entities’

technology risk programs.

NOTIFICATION REQUIREMENTS FOR SYSTEMS CHANGES

Several federal nancial regulatory agencies require nancial institutions to notify the

appropriate regulator of changes to their technology systems. For example, U.S. banks are

required to provide ex-post notication to their primary federal regulator of the existence

of certain types of service relationships.

Certain CFTC-registered entities must inform

the CFTC of planned changes to automated systems that impact reliability, security, or

capacity and planned changes to the registered entities’ program of risk analysis and

oversight.

SCI entities must report quarterly to the SEC on completed, ongoing, and

planned material changes to SCI systems and the security of indirect SCI systems.

DIRECT EXAMINATION AND REGULATION OF THIRD-PARTY SERVICES

The FDIC, FRB, and OCC have statutory authority under the Bank Service Company Act

(BSCA)

to examine and regulate the performance of certain services provided by third-

party providers to supervised nancial institutions to the same extent as if a supervised

depository institution performed such services itself on its own premises.

This authority

does not extend to services provided to entities not covered under the BSCA or to the

service provider more generally. The BSCA covers banking services, such as computation

and posting of interest and other credits and charges, preparation and mailing of checks,

statements, notices, and similar items, or any other clerical, bookkeeping, accounting,

statistical, or similar functions, as well as activities such as data processing.

In 2022, the

FDIC, FRB, and OCC, by regulation, established a requirement on service providers that

65. See, e.g., SEC, Risk Alert: Safeguarding Customer Records and Information in Network Storage –

Use of Third Party Security Features (May 23, 2019), hps://www.sec.gov/ocie/announcement/risk-alert-

network-storage; North American Securities Administrators Association, Cybersecurity Checklist for Investment

Advisors, (2017), hps://www.nasaa.org/wp-content/uploads/2018/10/NASAA-Cybersecurity-Checklist.pdf.

66. For example, the FFIEC released a mapping of its cybersecurity assessment tool to the NIST cybersecurity

framework. FFIEC, Appendix B: Mapping Cybersecurity Assessment Tool to NIST Cybersecurity Framework,

hps://www.ec.gov/pdf/cybersecurity/FFIEC_CAT_App_B_Map_to_NIST_CSF_June_2015_PDF4.pdf.

67.

12 U.S.C. § 1867(c)(2). (“the depository institution shall notify each such agency of the existence of the service

relationship within thirty days aer the making of such service contract or the performance of the service,

whichever occurs rst.”) The scope of this Bank Service Company Act requirement is discussed further below.

See also 12 U.S.C. § 1464(d)(7)(D) (setting out similar requirements for savings associations).

68.

17 CFR § 37.1401(f), 38.1051(f), 39.18(h)(1)–(2) and 49.24(h).

69. 17 CFR § 242.1003.

70. 12 U.S.C. § 1861 et seq. See also 12 U.S.C. § 1464(d)(7)(D).

71.

12 U.S.C. § 1867(c).

72. See 12 U.S.C. §§ 1863 and 1864.

CLOUD REPORT n 36 n U.S. DEPARTMENT OF THE TREASURY

fall within the scope of the BSCA to notify their aected client nancial institutions in the

event a computer-security incident has materially disrupted or degraded or is reasonably

likely to materially disrupt or degrade covered services to such customers for four or more

hours.

Whether or not the performance of a particular service provided by a service provider is

examined (as well as the frequency and priority of any such examinations) is based on a

case-by-case analysis of the criticality of the service, the number of nancial institutions

under contract with the service provider, and the inherent risk that the service may

present to client nancial institutions, among other considerations. Each of these

examinations results in an examination report, a portion of which is available, either

automatically or upon request, to nancial institution clients of the service provider.

Other federal nancial regulatory agencies do not have examination and regulatory

authority over services provided by third parties similar to the authority provided to the

FDIC, FRB, and OCC by the BSCA. Nonetheless, there may be circumstances in which such

agencies can conduct tailored oversight of third-party services, such as cloud services,

provided to their regulated entities. Title VIII of the Dodd-Frank Act also allows supervisory

agencies of designated nancial market utilities (DFMUs)—currently the FRB, SEC, and

CFTC—to examine the provision of a service provided by another entity when such a

service is “integral” to the operation of the DFMU.

To address risks related to the Y2K

transition, the NCUA once had broad, temporary examination authority over third-party

providers to credit unions similar to that provided in the BSCA, but this authority expired

in 2001.

The Financial Stability Oversight Council has recommended that both the FHFA

and NCUA be provided adequate examination and enforcement powers to oversee third-

party service providers.

Apart from statutory authority, contracts with third-party service providers may cover

audit requests by nancial institutions and their regulators.

However, some FBIIC

members report that this means of gathering information may not be as eective as

statutory authority.

INSURANCE SECTOR

In the United States, the business of insurance is primarily regulated by state law, both

in terms of solvency and market conduct. Regulation at the state level frequently follows

model laws and regulations adopted by NAIC. Early in 2017, the New York Department of

73. 12 CFR 53.4 (OCC); 12 CFR 225.303 (FRB); 12 CFR 304.24 (FDIC). The compliance date of this final rule was May

1, 2022.

74. See FFIEC, Information Technology Examination Handbook: Supervision of Technology Service Providers,

https://ithandbook.ffiec.gov/it-booklets/supervision-of-technology-service-providers/risk-based-

supervision/roe-distribution.aspx.

75. 12 U.S.C § 5466 (b) (“the Supervisory Agency may examine whether the provision of that service is in

compliance with applicable law, rules, orders, and standards to the same extent as if the designated financial

market utility were performing the service on its own premises”).

76. NCUA, Third Party Vendor Authority (Mar. 2022), https://www.ncua.gov/files/publications/regulation-

supervision/third-party-vendor-authority.pdf.

77. FSOC,

2022 Annual Report 72, https://home.treasury.gov/system/files/261/FSOC2022AnnualReport.pdf

78. See FFIEC, Information Technology Examination Handbook: Outsourcing Technology Services, 11–15, https://

ithandbook.ffiec.gov/it-booklets/outsourcing-technology-services/risk-management/contract-issues.aspx.

CLOUD REPORT n 37 n U.S. DEPARTMENT OF THE TREASURY

Financial Services nalized its Cybersecurity Regulation, which includes requirements

related to regulated entities’ use of third-party service providers. Later that year, the NAIC

adopted a similar Insurance Data Security Model Law,

which, when incorporated into law

by individual states, establishes standards for data security and for the investigation of

and notication to the State Insurance Commissioner of a cybersecurity event. In general,

the model law requires an insurer to develop, implement, and maintain a comprehensive,

written information security program that evolves from its risk assessment, including

its use of third parties, for the protection of data and systems, and report third-party

arrangements to the board of directors. Over twenty states have adopted some form of the

NAIC model law.

ROLE OF U.S. TREASURY AND SECTOR-WIDE COORDINATION EFFORTS.

Presidential Policy Directive 21 designates Treasury as the Sector Risk Management

Agency (SRMA) for the nancial services sector. In carrying out its general responsibilities

as an SRMA, Treasury is required to coordinate with the Department of Homeland Security

and, as appropriate, other relevant Federal departments and agencies; collaborate with

critical infrastructure owners and operators within the nancial sector; and coordinate

with independent regulatory agencies, and state, local, Tribal, and territorial entities, as

appropriate. Treasury and each SRMA leverage their knowledge and expertise to:

• Support sector risk management in coordination with CISA;

• Assess sector risk in coordination with CISA, including identifying, assessing, and

prioritizing risks within the sector;

• Support sector coordination, including serving as a day-to-day Federal interface for

the prioritization and coordination of sector-specic activities and responsibilities;

• Facilitate, in coordination with CISA, the sharing of information regarding physical

security and cybersecurity threats within the sector;

• Support incident management, including supporting, in coordination with CISA,

incident management and restoration eorts during or following a security incident;

and,

• Contribute to emergency preparedness eorts, including coordinating with critical

infrastructure owners and operators within the sector and CISA in developing

planning documents for coordinated action in the event of a natural disaster, an act

of terrorism, or other disaster or emergency.

One of the key mechanisms for coordination in the nancial sector is the FBIIC. Sta from

FBIIC member organizations work on operational and tactical issues related to critical

infrastructure matters, including cybersecurity, within the nancial services industry.

The senior leaders of FBIIC are the principals from each member organization. This group

meets tri-annually to provide strategic, policy-level direction to FBIIC’s work. Topics

79. NAIC, Insurance Data Security Model Law (2017), hps://content.naic.org/sites/default/les/inline-les/MDL-

668.pdf.

CLOUD REPORT n 38 n U.S. DEPARTMENT OF THE TREASURY

include enhancing information-sharing, promoting coordination on incident-response

planning, and identifying best practices for cybersecurity controls at nancial institutions.

Treasury’s Oice of Cybersecurity and Critical Infrastructure Protection (OCCIP) works

closely with nancial sector companies, industry groups, and government partners to

share information about cybersecurity and physical threats and vulnerabilities, encourage

the use of baseline protections and best practices, and respond to and recover from

signicant incidents.

4.2 INTERNATIONAL APPROACHES

U.S.-based cloud services are increasingly used in foreign nancial sectors

and by U.S.

nancial institutions operating abroad. As a result, international regulatory frameworks,

and specic requirements from foreign jurisdictions, can signicantly inuence the

services CSPs provide and how they engage with nancial institutions and authorities.

Foreign approaches to regulating cloud and other types of third-party services also

provide a comparative reference for the U.S.

Over the last twenty years, international nancial sector standard-setting bodies

(SSBs) and individual foreign regulators have established requirements and guidance

on outsourcing, third-party risk management, and operational risk largely similar to

the approaches taken by U.S. regulatory agencies. Several FBIIC members are active

participants within the Financial Stability Board (FSB) and SSBs. Member agencies also

have been leaders in exchanging views with foreign regulators on operational resilience

and third-party providers, including cloud services.

The broader entry of technology companies and new nancial technology companies

into the nancial services sector has partly motivated international regulatory scrutiny

of public cloud services. Concerns over concentration risk and the lack of regulatory

authority over third-party service providers that may be critical to foreign nancial sectors

have led to new legislative proposals for enhanced regulation of third-party service

providers, including in the European Union and the United Kingdom.

INTERNATIONAL POLICY DEVELOPMENT

In 2005, the Joint Forum, formed jointly by the Basel Committee on Banking Supervision

(BCBS), the International Organization of Securities Commissions (IOSCO), and the

International Association of Insurance Supervisors (IAIS), issued outsourcing guidance

for nancial services. The guidance, inter alia, airms that responsibility for compliance

remains with the regulated nancial entity, recommends contingency planning for

80. Cloud Security Alliance, Cloud Usage in the Financial Services Sector (2020); Institute of International Finance,

Cloud Adoption and Regulation in Asia-Pacic Financial Services (Nov. 2021) hps://www.iif.com/portals/0/

Files/content/Innovaon/11_10_2021_cloud_asia_pacic.pdf.

81. The international standard-setting bodies in the nancial sector include the BCBS, IOSCO, IAIS, and the

Committee on Payments and Market Infrastructures. In 2009, the G20 created the Financial Stability Board

(FSB) to oversee the development of standards. The FSB is tasked with monitoring nancial stability,

coordinating between the standard-setting bodies, and undertaking tasks as requested by the G20.

CLOUD REPORT n 39 n U.S. DEPARTMENT OF THE TREASURY

nancial entities and their providers, and notes the importance of monitoring for potential

risks posed when multiple regulated entities’ outsourced activities are concentrated in

a limited number of service providers.

Each of the SSBs has continued to build upon

and rene the approach outlined in 2005 by the Joint Forum. For example, IOSCO revised

its Principles on Outsourcing

in 2021, combining and updating expectations issued

by the Joint Forum and separately by IOSCO in 2009. And the Committee on Payments

and Market Infrastructures and IOSCO jointly issued the Principles for Financial Market

Infrastructure (PFMI) in 2012, which includes Annex F: Oversight expectations applicable

to critical service providers.

Expectations included eective risk identication and

management, information security practices and policies, reliability and resilience,

technology planning, and communication with users. The IAIS Operational Resilience

Task Force (ORTF) was formed in 2020 to develop supervisory supporting materials on

issues related to cyber resilience, including implications of cyber risks from outsourcing

technology services to TSPs, and to review best practices from the industry and

supervisors. The ORTF is currently draing an Issues Paper on Operational Resilience that

is expected to be nalized in 2023, and which will address outsourcing critical IT functions,

among other issues.

DEVELOPMENTS AT THE FINANCIAL STABILITY BOARD

The FSB rst identied third-party provider oversight as an area meriting further attention

in 2017,

and published two related reports in 2019. The rst outlines the benets

and risks of cloud service utilization

and the second reviews standards and practices

applicable to third-party risk, including guidelines for the use of cloud services.

Based on

interviews with public- and private-sector entities, public sources, proprietary data, and a

survey, the FSB concluded that “there are no immediate nancial stability risks stemming

from the use of cloud services by [nancial institutions].”

Since then, as cloud use by the

nancial system has accelerated globally, foreign regulators have continued to focus on

cloud adoption as a primary reason for establishing new regulatory frameworks to oversee

technology providers they determine to be critical.

In November 2020, the FSB published a discussion paper that, among other things,

outlined nancial authorities’ views regarding the “indirect” model of supervision of third-

party risk.

An FSB survey revealed that the direct third-party examination authority was

relatively rare. Issues identied by FSB members included:

82. The Joint Forum, Outsourcing in Financial Services (Feb. 2005), hps://www.bis.org/publ/joint12.pdf.

83. IOSCO, Principles on Outsourcing (Oct. 2021), hps://www.iosco.org/library/pubdocs/pdf/IOSCOPD687.pdf.

84. Annex F of the PFMI was primarily written to cover the activities of SWIFT, a nancial sector specic technology

provider that performs necessary functions for the cross-border payments system.

85. FSB, Financial Stability Implications from FinTech: Supervisory and Regulatory Issues that Merit Authorities’

Attention (June 2017), hps://www.fsb.org/2017/06/nancial-stability-implicaons-from-ntech/.

86. FSB, FinTech and Market Structure in Financial Services: Market Developments and Potential Financial Stability

Implications (Feb. 2019), hps://www.fsb.org/2019/02/ntech-and-market-structure-in-nancial-services-

market-developments-and-potenal-nancial-stability-implicaons/.

87. FSB, Third-Party Dependencies in Cloud Services: Considerations on Financial Stability Implications (Dec. 2019),

hps://www.fsb.org/2019/12/third-party-dependencies-in-cloud-services-consideraons-on-nancial-stability-

implicaons/.

88. Ibid.

89. FSB, Regulatory and Supervisory Issues Relating to Outsourcing and Third-Party Relationships (Nov. 2020),

hps://www.fsb.org/2020/11/regulatory-and-supervisory-issues-relang-to-outsourcing-and-third-party-

relaonships-discussion-paper/.

CLOUD REPORT n 40 n U.S. DEPARTMENT OF THE TREASURY

• Practical limitations on nancial institutions’ abilities to manage the risks in their

outsourcing and third-party agreements (including risks in the wider supply chain of

third-party providers, i.e., fourth and h parties);

• Limitations on regulators’ abilities to eectively oversee nancial institutions’

outsourcing and third-party arrangements in a cross-border context; and,

• Challenges in identifying, monitoring, and managing potential systemic risks

related to nancial institutions’ use of outsourcing and third-party arrangements, in

particular, due to concentration on the provision of third-party services and a lack of

relevant information.

To address these supervisory challenges, the FSB is working with its members and the

SSBs to develop a toolkit for nancial institutions to assist in the identication and risk

management of critical third-party services for public release in 2023. The toolkit will also

provide tools to nancial authorities in their oversight of these risks.

DEVELOPMENTS AT THE G7

Established in November 2015, the G7 Cyber Expert Group (CEG) meets regularly to

identify the leading cyber security risks in the nancial sector and to propose actions to be

taken in this area. U.S. Treasury and the Bank of England chair the CEG. While not an SSB,

the CEG nonetheless helps drive the development of international cybersecurity policies

across the G7 (and beyond) through its publication of “fundamental elements.” Notably,

the group published the “G7 Fundamental Elements of Cybersecurity for the Financial

Sector” in October 2016 and the “G7 Fundamental Elements for Eective Assessment of

Cybersecurity” in October 2017.

Building on these publications, the CEG published the “G7 Fundamental Elements for

Third Party Cyber Risk Management in the Financial Sector” in 2018, with an update in

October 2022.

The fundamental elements stress the importance of nancial institutions’

governance and risk management processes, as well as their strategy to identify third

parties and the criticality of their services to the nancial institution. It also notes the

importance of due diligence, contract structuring, ongoing monitoring, and contingency

planning. The fundamental elements also note the need for relevant authorities to identify

and assess potential systemic risks and encourage eorts to improve information sharing

and coordinate across sectors regarding cyber risks stemming from third parties. The

2022 update included a new element, noting that third parties should make information

available to facilitate nancial institutions’ management of cyber risk.

FOREIGN REGULATION OF CLOUD SERVICES

Foreign jurisdictions have promulgated a diverse array of guidelines and requirements

applicable to the use of cloud services. These regulations can potentially aect a range of

U.S. nancial sector policy interests concerning cloud services. First, foreign regulatory

90. G7 CEG, G7 Fundamental Elements for Third Party Cyber Risk Management in the Financial Sector (Oct. 2022),

https://www.bundesbank.de/resource/blob/624828/91c47c36b53ca366e2950881591de0ab/mL/2022-10-13-

g7-fundamental-elements-cybersecurity-data.pdf.

CLOUD REPORT n 41 n U.S. DEPARTMENT OF THE TREASURY

frameworks directly impact how U.S. nancial institutions adopt cloud services cross-

border or globally. These requirements drive strategic decision-making around technology

architecture at many large, international nancial institutions, including U.S. banks and

insurance companies. Many nancial institutions report signicant diiculties in adopting

cloud services consistently across jurisdictions. Second, cloud services are generally

oered on a global basis. To streamline technology development and risk management,

and to cater to an international audience, the practice of many cloud providers is to

promote consistency in their global cloud oerings. A feature necessary for a local

requirement is oen replicated in multiple regions. Foreign nancial sector regulations

and requirements can therefore aect the services used by U.S. nancial institutions and,

in some cases, potentially services provided to all customers.

Several jurisdictions (notably, China) essentially prohibit the use of U.S.-based cloud

services through prescriptive requirements such as requirements to store data locally or

use only local providers. These restrictive approaches are in opposition to the favored

approach by the U.S, which pursues a policy agenda supportive of cross-border data

ows.

Foreign jurisdictions may impose prescriptive requirements limiting cross-border

data ows for a wide range of policy reasons, including for data privacy or concerns that

nancial institutions and regulators may not be able to access data held abroad; however,

these measures are oen unnecessarily restrictive and antithetical to the technology

architecture of the cloud. Even without explicit prohibitions, obtaining regulatory

approvals or non-objections for technology adoption, particularly involving cross-border

services, can be diicult. In response to some of these restrictive policies, nancial

industry trade associations have advocated for global principles for regulating public

cloud services,

arguing that regulators should recognize the benets of public cloud,

support harmonizing public cloud requirements and the free movement of data, among

other principles.

More like-minded authorities, including within the G7, have generally pursued regulatory

frameworks that are broadly similar to the U.S. regulatory framework. However, in some

cases, U.S. nancial institutions and cloud service providers report pressure to localize

data to meet local requirements, as well as diiculties in navigating the variations in

regulatory requirements. Some jurisdictions closely aligned with the U.S. are also looking

at expanding their regulatory authorities over third-party providers, either by expanding

the scope of their relevant critical infrastructure legislation or seeking direct authority for

nancial regulators to oversee certain critical third-party services.

91. U.S. Treasury and Monetary Authority of Singapore, United States – Singapore Joint Statement on

Financial Services Data Connectivity (Feb. 2020), https://home.treasury.gov/news/press-releases/sm899.

92. ASIFMA, Proposed ASIFMA Principles for Public Cloud Regulation (Mar. 2021), https://www.asifma.org/wp-

content/uploads/2021/03/final-proposed-asifma-principles-for-public-cloud-regulation.pdf.

CLOUD REPORT n 42 n U.S. DEPARTMENT OF THE TREASURY

For example, Australia adopted the Security of Critical Infrastructure Act 2018,

which

was designed to address national security risks associated with Australia’s critical

infrastructure (including by foreign providers). The Act was amended in 2021 and 2022

to apply to 11 economic sectors, including data storage and processing. The act requires

mandatory cyber incident reporting, a register of critical infrastructure assets, enhanced

cyber security obligations, and adopting a critical infrastructure risk management program

for critical infrastructure assets. It also has a smaller subset of critical infrastructure

called Systems of National Signicance to which are subject to enhanced cyber security

obligations. The Act also grants the Australian Department of Home Aairs the power to

obtain information directly from owners and operators of critical infrastructure assets

and allows the Australian Government to authorize directions and interventions during a

cyber incident. In 2018, the Australian Prudential Regulatory Authority (APRA) released an

information paper on outsourcing involving cloud services.

The report identies three

risk categories into which cloud usage typically falls — low, heightened, and extreme

inherent risk — and highlights key issues that nancial institutions must consider as part

of their risk assessment. And under APRA’s outsourcing guidelines, APRA-regulated entities

must notify APRA aer entering into a material outsourcing agreement. Regulated entities

must consult with APRA before entering into an outsourcing arrangement involving a

material business activity where oshoring is involved.

In December 2022, the European Union (EU) nalized the Digital Operational Resilience Act

(DORA), which will subject regulated nancial entities to a set of rules on IT and third-party

risk management, regulatory reporting requirements for major IT-related incidents, and

requirements for nancial entities to conduct penetration testing. In addition, DORA brings

critical ICT third-party service providers under an oversight framework. The legislation was

informed by recommendations by European Supervisory Authorities, which have noted

acute concern with concentration risk associated with CSPs.

The oversight framework

includes a regulatory structure for critical third-party service providers where one of the

three European Supervisory Authorities (ESAs) will serve as the lead overseer. The design

of the oversight framework also foresees an Oversight Forum that will support the work

of the lead overseers, a Joint Oversight Network that will strengthen the coordination

among the lead overseers, and joint examination teams that will assist lead overseers

in conducting the necessary investigations and inspections. Each oversight forum for a

critical third-party service provider will include representatives from the other ESAs and

competent authorities in each Member State (e.g., national central banks). Representatives

from national competent authorities under the EU’s Network and Information Security

Directive would also participate where appropriate.

93. Australian Government Department of Home Aairs, Security of Critical Infrastructure Act 2018 (2021), hps://

www.homeaairs.gov.au/about-us/our-porolios/naonal-security/security-coordinaon/security-of-crical-

infrastructure-act-2018.

94. APRA, Outsourcing Involving Cloud Computing Services (Sept. 2018) hps://www.apra.gov.au/sites/default/

les/informaon_paper_-_outsourcing_involving_cloud_compung_services.pdf.

95. EBA, ESMA, and EOIPA, ESAs Publish Joint Advice on Information and Communication Technology Risk

Management and Cybersecurity (Apr. 2019), hps://www.esma.europa.eu/press-news/esma-news/esas-publish-

joint-advice-informaon-and-communicaon-technology-risk.

CLOUD REPORT n 43 n U.S. DEPARTMENT OF THE TREASURY

Under DORA, the EU will designate IT third-party service providers as “critical,” based

on, among other factors, the systemic impact on the provision of nancial services if

the relevant provider faces a large-scale operational failure. The lead overseer would be

authorized to conduct investigations and onsite and osite inspections, including on

premises located in non-EU countries, impose penalties for non-compliance with access

and information requests, and issue recommendations. The legislation allows a company

to contest designation by submitting a reasoned statement containing any relevant

information for the assessment related to its identication. DORA directs the lead overseer

to minimize, to the extent possible, the risk of oversight activities disrupting services

provided to customers outside of the nancial sector. A critical third-party service provider

can provide information regarding the expected impact of oversight. DORA also authorizes

the ESAs to establish administrative arrangements with regulators in non-EU countries to

foster international cooperation on third-party risk.

The United Kingdom (UK) is also considering legislative authority to subject critical third-

party services to a framework of regulatory standards and testing developed by nancial

regulators. The UK’s Financial Policy Committee noted that “the increasing reliance by

the nancial system on critical third parties), including cloud service providers, can bring

benets to the nancial sector, including improved operational resilience.However,

the increasing criticality of the services that critical third parties provide, alongside

concentration in a small number of providers, pose a threat to nancial stability in the

absence of greater direct regulatory oversight.”

And in 2021, the International Monetary

Fund recommended that the UK supervisory authorities seek additional statutory powers

to review and examine the resilience of all critical services (including, but not limited

to, cloud services) that third parties provide to regulated rms.

In July 2022, the Bank

of England, the Prudential Regulatory Authority, and the Financial Conduct Authority

published a discussion paper on how such a framework could operate.

Designation by

His Majesty’s Treasury under this framework would recognize “the systemic impact that

the disruption or failure of the services that a particular third party provides to rms and

FMIs could have on the stability of, or condence in the UK nancial system.”

Based

on current proposals, designated critical third parties would need to ensure that their

services to UK nancial institutions met minimum resilience standards and test the

resilience of these services.

96. UK Financial Policy Committee, Financial Policy Summary and Record - October 2021 (Oct. 2021), hps://www.

bankofengland.co.uk/nancial-policy-summary-and-record/2021/october-2021.

97. International Monetary Fund, United Kingdom: Financial Sector Assessment Program-Financial System Stability

Assessment (Feb 2022), hps://www.imf.org/en/Publicaons/CR/Issues/2022/02/22/United-Kingdom-Financial-

Sector-Assessment-Program-Financial-System-Stability-Assessment-513442

98. BoE, PRA, FCA, Operational resilience: Critical third parties to the UK nancial sector, Discussion Paper (July

2022), hps://www.bankofengland.co.uk/prudenal-regulaon/publicaon/2022/july/operaonal-resilience-

crical-third-pares-uk-nancial-sector.

99.

Ibid.

CLOUD REPORT n 44 n U.S. DEPARTMENT OF THE TREASURY

U.S. CRITICAL PROVIDERS DIALOGUE

In response to increasing international interest, in May 2022, Treasury and the Federal

Reserve Board launched an ongoing multilateral regulatory dialogue among foreign

counterparts to discuss cooperation around critical services to the nancial sector.

The “Critical Providers Dialogue” includes discussion among the parties on regulatory

approaches to critical third-party providers, including certain cloud services use cases.

This dialogue is designed to complement multilateral work at the G7 CEG and FSB as well

as bilateral discussions, such as at the U.S.-EU Joint Financial Regulatory Forum and U.S.-

UK Financial Regulatory Working Group.

CLOUD REPORT n 45 n U.S. DEPARTMENT OF THE TREASURY

Financial Institution Practices when Adopting Cloud

Services

5.1 RISK MANAGEMENT AND OPERATIONAL RESILIENCE

The nancial services sector primarily addresses potential risks of third-party services

through risk management practices of individual nancial institutions. This section

summarizes the steps U.S. nancial institutions may generally take when selecting and

onboarding dierent cloud services.

100

As part of typical processes, a nancial institution will determine whether its planned use

of cloud services is consistent with its internal policies and is designed to result in the safe

and sound operation of the nancial institution, the security and condentiality of its data,

and compliance with applicable laws and regulations. The nancial institution generally

will (1) conduct risk-based due diligence on the CSP and service and (2) establish a range

of internal and external (within the cloud environment) security and resilience controls,

congurations, and monitoring for the cloud services. In many cases, nancial institutions

may follow or repurpose as, according to their needs, sector-agnostic approaches such as

those outlined by NIST (e.g., NIST SP 500-291 Cloud Computing Standards Roadmap or SP

500-332 Cloud Federation Reference Architecture) or nancial sector-specic approaches,

like the Cyber Risk Institute’s “Cloud Prole.”

101

A crucial element of a nancial institution’s mitigation of risk from operational disruption

of a CSP is a comprehensive risk management and oversight program for its third-party

relationships. The robustness of the third-party risk management and oversight program

will vary depending on the function or criticality of the activity supported by a third

party. Risk management programs generally include initial due diligence and ongoing

monitoring of the third party, including evaluation of performance metrics, security, and

other risk controls, disaster recovery plans of the third party, and other alternatives for

the nancial institution to address operational disruptions of the third party. For example,

a nancial institution will oen evaluate the technology infrastructure of a CSP and the

cloud service to consider if it is capable of supporting the nancial institution’s approach

to maintaining operational resilience.

Financial institutions typically conduct due diligence consistent with their internal

risk management framework, risk appetite, and regulatory expectations. The depth

of due diligence review is generally commensurate with the risk and complexity of the

relationship. Due diligence involves reviewing the service provider’s capabilities (both

operational and nancial) to meet the terms of the proposed service engagement and

satisfy the risk management standards of the nancial institution. The nancial institution

will also review specic aspects more intensively based on the importance of the service.

100. This section is meant to provide the reader with a general understanding and does not address all steps

nancial institutions may take. It is not meant to serve as guidance to nancial institutions.

101. Cyber Risk Institute, Cloud Security Alliance, Bank Policy Institute, CRI Announces Completion of Cloud Prole

Extension (Apr. 2022) hps://cyberriskinstute.org/cri-announces-compleon-of-cloud-prole-extension/.

CLOUD REPORT n 46 n U.S. DEPARTMENT OF THE TREASURY

For example, if redundancy is critical to the proposed service, a nancial institution will

evaluate the CSP’s capabilities for business resumption and resilience for the purchased

cloud services. Among other factors, a nancial institution may be looking to assess

whether redundancy capabilities of a service are compatible with its own standards and

continuity plans, and to determine whether to purchase additional services oered by the

CSP for added redundancy.

Third-party assurance reviews, such as service organization controls (SOC) reviews,

penetration tests, and vulnerability assessments, can assist nancial institutions in

understanding a CSP’s control environment and its ability to meet a nancial institution’s

control expectations (e.g., compliance with applicable laws and regulations). One of the

most common third-party service provider audits are SOC2 reports, conducted under

the American Institute of Certied Public Accountants standards for assessing service

organizations.

102

SOC2 reports involve an evaluation of the security, availability, processing

integrity, condentiality, or privacy of information and systems across an entire entity,

of a particular subsidiary or operating unit, or for a particular function. The SOC2 report

can be a type I, a point in time assessment largely based on documented controls, or type

II, a sustained observation of a period in time. Typically, CSPs will oer options within

the contract that will allow the nancial institutions to receive SOC reports or additional

reports or evidence for an additional fee. Some nancial institutions Treasury interviewed

indicated that most CSPs provide SOC2 audit reports at least annually. SOC2 engagements

are designed to be exible and do not prescribe specic controls. This exibility could be

seen as a drawback that limits the independence and utility of the engagement. Some

nancial institutions Treasury interviewed noted that SOC2 reports were helpful but

not suicient for understanding the control environment and potential security risks for

particular services.

A nancial institution will also review and rely upon certain security and resilience controls

maintained by the CSP. Comprehensive risk management processes typically include

requirements for specic language in its contract and SLAs, including those established

with the CSPs to ensure clarity regarding the CSP’s commitment to specic security and

resilience controls for the cloud service. Internal policy and procedures documents oen

reect many aspects of the rm’s decisions regarding security and resilience controls of a

particular cloud service.

5.2 DEPLOYMENT AND CONFIGURATION

To use cloud services, a nancial institution establishes and manages a range of

communication channels between the CSP and the nancial institution’s on-premises

IT systems. These communication channels align data between the cloud and the on-

premises IT systems, allow the nancial institution to access the services provided at

the CSP, such as computing and data storage, and provide the nancial institution with

access to an interface for managing the cloud services. Options for these communication

102. Association of International Certied Professional Accountants, System and Organization Controls: SOC

Suite of Services (Accessed on Nov. 2022), hps://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/

socforserviceorganizaons.

CLOUD REPORT n 47 n U.S. DEPARTMENT OF THE TREASURY

channels include encrypted communications over the public internet, APIs, and private

networks. Malicious actors can exploit improperly secured or congured communication

channels, resulting in compromised data or unavailability of the nancial institution’s

services or the cloud services.

CSPs oen provide a baseline level of resilience for a contracted cloud service, such as

commitments to performance metrics and up-time status in the SLAs with clients. But

the nancial institution must ultimately make choices in both design and conguration

to achieve its preferred balance of security, capabilities, resilience, and cost. A nancial

institution may take advantage of cloud service conguration options oered by the CSP

that can provide a higher operational resilience. These options may include:

• SLAs for increased resilience/up-time. Some CSPs may provide the nancial

institution with the option of an additional or enhanced level of service availability

or uptime, or CSP-provided monetary compensation if the desired service availability

is not achieved. The nancial institution’s contract or SLA with the CSP may reect

these provisions. The availability of increased uptime options from a CSP may vary

depending on the CSP and the particular cloud service.

• Multiple data centers within a single CSP region. The CSP may allow the nancial

institution to maintain its applications and data in multiple, geographically dispersed

data centers located in a single region of the CSP. These multiple data centers can

provide increased resilience for the nancial institution from local operational

disruptions that could aect a single data center, such as natural disasters, power

supply interruptions, or res.

• Multiple Regions from the same CSP. Depending on the service model, a nancial

institution might elect to locate its applications in two dierent regions of the same

CSP. There are variations to this approach, including ‘multi-master’ or ‘active-active’

congurations that can recover nearly instantaneously from the failure of a single

region without user visibility degradation of performance or loss of data. There can be

challenges with the multi-region approach, including costs, sta resources, latency,

and lack of similar services in dierent regions of the same CSP.

With IaaS, clients design signicant elements of their control environment.

103

At the

nancial institution level, controls can include the nancial institution’s monitoring of

performance data provided by the CSP, as well as its conguration of certain aspects of the

cloud services within the CSP’s environment, such as selecting multi-factor authentication

to secure its users’ access to cloud features. Even with SaaS congurations, determining

appropriate user access rights is the responsibility of the client and not the cloud provider.

Setup of security controls and user access rights is among the most important aspects of

securing data and workloads in the cloud environment.

103. See Section 3.3 for a more complete explanation of the shared responsibility and its application to IaaS,

PaaS, and SaaS. For example, with IaaS, CSPs secure IT hardware and set physical controls, and the client sets

controls for the operating systems and applications placed in the cloud environment.

CLOUD REPORT n 48 n U.S. DEPARTMENT OF THE TREASURY

A nancial institution may also seek to reduce its long-term reliance on the cloud services

of a CSP by designing its applications and data for portability to another CSP. For certain

services, particularly IaaS, containerization functionality can support the portability of

applications from one CSP to another CSP. The potential for portability and the complexity

of managing the portability will vary for dierent types of services.

While nancial institutions have considered portability design in cloud deployments

as a means to reduce longer-term dependencies, nearly all of the nancial institutions

interviewed cautioned that this was not technically feasible as a means to mitigate short-

term disruptions in more complex services. Financial institutions also may consider the

potential to bring back services to an on-premises environment, but this brings its own

set of similar and dierent challenges (like attempting to develop applications that can

work on both a cloud and non-cloud environment, which could require compromises in

functionality.)

5.3 MONITORING, AUDITING, AND TESTING

Financial institutions also implement monitoring controls to avoid reliance on

historical point-in-time assessments and to execute their security and risk management

responsibilities. These controls include using dashboards and logging capabilities oered

by CSPs, or a nancial institution’s own customized, compatible solutions to monitor

operational performance and security threats.

Financial institutions may also seek to audit or test operational or security capabilities

oered by the CSP. A nancial institution can use its internal auditors or engage a third

party to conduct regular audits and tests of operational or security controls, such as access

management controls and system conguration, commensurate with the risks associated

with cloud services. It is also an increasingly common practice that cloud contracts

with nancial institutions allow for audit by the nancial institution, its designee, or its

regulator. Some industry clients have also combined their resources to conduct or hire

auditors to conduct “pooled” audits. These audit rights, however, are usually subject to

a fee-based arrangement for the time and materials associated with ad-hoc requests for

information.

Additionally, CSPs regularly refresh their independent audits and certications, such as

SOC reviews. Financial institutions can review these reports to understand how the control

environment may be changing at the CSP and better scope their own reviews over time.

Financial institutions may also test capabilities associated with cloud services. For

example, several nancial institutions Treasury interviewed relayed that they had

successfully tested certain backup capabilities related to their cloud deployment.

CLOUD REPORT n 49 n U.S. DEPARTMENT OF THE TREASURY

Challenges with the Financial Sector’s Use of Cloud

Services

Through the development of this report, Treasury identied several challenges associated

with greater cloud adoption by U.S. nancial institutions. The challenges cut across

multiple use cases, CSPs, and nancial institutions.

6.1 INSUFFICIENT TRANSPARENCY TO SUPPORT DUE DILIGENCE AND

MONITORING BY FINANCIAL INSTITUTIONS

As noted in Section 5, nancial institutions require initial and ongoing information from

CSPs to understand the potential risks of their use of cloud services and to support

the selection and implementation of mitigating controls. Typical risk management

practices in the nancial services sector preclude a nancial institution from solely

relying on contractual commitments or vendor assurance without review or independent

verication. Insuicient information from a CSP can weaken an individual nancial

institution’s risk management capabilities. Treasury encountered a range of views on the

suiciency of information from CSPs to inform nancial institution risk management. Early

adopters and nancial institutions with public and prominent relationships were generally

more satised than others. At the same time, it was a commonly held view among many

U.S. nancial institutions that Treasury interviewed, as well as industry stakeholders

and academics, that existing CSPs’ eorts did not fully satisfy nancial institution risk

management needs. Issues they noted included the following:

• Some nancial institutions did not have transparency on how many data centers they

were relying on until an incident occurred at the CSP.

• Some nancial institutions relayed instances where they thought inconsistency in the

documentation for services made use of cloud services more challenging.

• Some due diligence or monitoring requests could not be satised with written

documentation for risk management purposes, e.g., actual testing results of security

controls.

• Some nancial institutions would like to obtain information on how CSPs identify and

address pervasive security threats to the cloud environment.

• Some nancial institutions expressed concern that they did not fully understand the

internal dependencies within the cloud environment associated with particular cloud

services, e.g., dependencies from other cloud services or fourth parties.

• Some nancial institution stakeholders viewed communication from CSPs around

operational and cyber incidents as an area that all invested parties could improve.

• While the majority of the focus by nancial institutions was related to information

associated with IaaS and PaaS, some nancial institutions noted transparency

challenges with SaaS oerings.

CLOUD REPORT n 50 n U.S. DEPARTMENT OF THE TREASURY

• Some nancial institutions not yet directly using public cloud services expressed

uncertainty and concern regarding how CSPs would control access to client data,

including with respect to CSPs’ third-party contractors, and viewed such unknowns as

impediments to adoption.

• Smaller nancial institutions, in particular, noted the challenges of conducting due

diligence on the universe of vendors they rely on given resource constraints.

A wide range of industry and public sector stakeholders interviewed by Treasury conveyed

that the major U.S.-based IaaS CSPs are continuing to make progress in addressing the

regulatory and risk management needs of their nancial institution clients.

However, risks associated with third-party services have become more diicult to measure

due to several factors, including by way of “nth party” dependencies. CSPs provide

services to many other third-party service providers that a nancial institution may rely

on, and also use many sub-contractors, creating indirect dependencies for nancial

institutions that are more diicult to assess.

Some CSPs that Treasury interviewed noted their skepticism around the value of certain

requests from their nancial institution clients. They argued that recurring physical data

center audits oen provided little additional security assurance and were challenging

to accommodate at scale given the need to maintain physical and data security for the

shared tenant environment. Treasury believes that further eorts are needed to achieve

the right balance of information sharing between CSPs and nancial institutions, which

might benet both groups in terms of eiciency and eectiveness.

6.2 GAPS IN HUMAN CAPITAL AND TOOLS TO SECURELY DEPLOY

CLOUD SERVICES

The success of the shared responsibility model ultimately relies on both CSPs and their

nancial institution clients to each take on tasks to secure the overall environment

without either party having full visibility over risks and controls. Financial institutions

are generally separated from the security of the underlying cloud environment, and CSPs

generally have limited insight into customer activities. Risks can be idiosyncratic to the

user: most publicly reported incidents with the cloud have been specic to choices at the

client level. As discussed in Section 5, cloud services can be highly resilient and feature

security capabilities unavailable in an on-premises environment, but only if congured

with that intention. To be eective, the shared responsibility model relies on clients having

the expertise, tools, and information necessary to execute their responsibilities and to

ensure the contracted cloud service reects their desired risk tolerance.

CLOUD REPORT n 51 n U.S. DEPARTMENT OF THE TREASURY

MISCONFIGURATION RISKS

Industry research most oen cites “misconguration” by users as the most common

cause of data breaches.

104

For example, prosecutors stated that the individual behind

a major incident in 2019 scanned for common miscongurations among AWS clients

to identify potential victims.

105

Although the incident itself involved many complex

factors in addition to the misconguration issue, the perpetrator of this incident

identied 30 similar miscongurations that they were able to exploit to steal data and

illicitly install cryptocurrency mining soware, showing that exploitation of common

miscongurations can be easily replicated across a cloud service’s customers. Clients can

also miscongure PaaS and SaaS applications through inappropriate user access and a

failure to monitor activity, but IaaS can be miscongured at every level, from design to

access to implementation. Once malicious actors see a vulnerability, they will scan for

other customers to exploit. Customers that make similar misconguration errors can be

exploited at scale.

Treasury identied two factors that can make the shared responsibility model less

eective. First, the available talent pool to nancial institutions to support these activities

is well below demand, presenting a potential barrier to entry for nancial institutions

seeking to adopt cloud services or to maintain appropriate sta for their current needs.

Second, many nancial institutions reported technical challenges associated with cloud

service features and tools to manage cloud services.

As one major report concluded, “Shared responsibility masks the uneven maturity of

organizations and technologies on the user side of that shared line, producing much more

of a zigzag than a clean line of responsibility.”

106

This challenge is particularly acute for

small and medium-sized nancial institutions. Uneven capabilities to adopt IaaS, PaaS,

and SaaS could eventually leave the industry on an uneven footing in terms of resilience

and security and perhaps someday be a competitive driver given the nexus of cloud

services and innovation (e.g., articial intelligence).

6.2.1 CLOUD EXPERTISE

Each aspect of running applications in the IaaS environment requires the nancial

institution to make unique and individual decisions at the design, implementation,

and monitoring stages. Each of these stages also require decisions and input from

experienced nancial institution personnel in cybersecurity, business processes, and

cloud architecture.

104. Fugue Inc, The State of Cloud Security 2020 Report: Understanding Misconguration Risk, by Drew Wright

(May 2020).

105. Department of Justice, U.S. Attorney’s Oice, Western District of Washington, Former Seattle tech worker

convicted of wire fraud and computer intrusions (June 2022) https://www.justice.gov/usao-wdwa/pr/former-

seattle-tech-worker-convicted-wire-fraud-and-computer-intrusions.

106. Atlantic Council, Broken trust: Lessons from Sunburst, By Herr et al., (Mar. 2021), hps://www.atlanccouncil.

org/in-depth-research-reports/report/broken-trust-lessons-from-sunburst.

CLOUD REPORT n 52 n U.S. DEPARTMENT OF THE TREASURY

Financial institutions noted challenges in recruiting talent to manage cloud migration and

risk management. In addition to an overall skills shortage, stakeholders have indicated

that nancial services IT skills are not readily transferrable to the cloud environment. All

of the nancial institutions Treasury interviewed noted that they had to reskill or hire

new talent to manage the cloud environment. Several nancial institutions noted they

are making a deliberate eort to upskill not only technical sta but also their business

line sta to ensure that cloud computing fundamentals are at the core of their technology

modernization journey. Financial institutions have increased diiculties in retention

because cloud expertise is more in demand and more transferable than traditional

nancial services IT expertise.

These issues are particularly acute for small and medium-sized institutions wanting to

take advantage of IaaS benets for cloud storage but lacking expertise. In some cases,

these institutions may overly rely on consultants or intermediary companies to access

public cloud oerings. Suppose the consultant or intermediary provider has made an

error that results in a vulnerability in the deployment of an application running in an IaaS

environment. In that case, nancial institutions may not be able to detect it until too late.

6.2.2 GAPS IN TOOLS

Some external stakeholders stated that another root cause of misconguration is that

the cloud environment is not always built with user design in mind. IaaS oerings look

signicantly dierent from provider to provider, and may even have some dierences

between regions served by the same provider. Additionally, while supporting exibility

and customization for the client, the rapid pace of innovation associated with service

oerings can be challenging for nancial institutions to keep up with. Even larger, more

resourced nancial institutions reported backlogs in their ability to validate new updates

continually. Occasionally, incidents occur because of a new incompatibility introduced by

an update.

For example, to use cloud services, a nancial institution must establish and manage

various communication channels between the CSP and the nancial institution’s on-

premises IT systems. These communication channels align data between the cloud

and the on-premises IT systems, allow clients to access the services provided at the

CSP, such as computing and data storage, and provide the nancial institution with

access to an interface for managing the cloud services. Options include APIs, encrypted

communications over the public internet, and private networks. If not secured, malicious

actors can exploit these communication channels. Stakeholders and other sources

identied the following challenges associated with securing communications to the cloud

services: (i) an increasing number of cloud service oerings by providers and related APIs

increasing the complexity of identifying, securing, and managing such connections; and

(ii) understanding and eectively overseeing a CSP’s approach to the security of those

communication connections under control of the CSP. There are some mitigating controls

CLOUD REPORT n 53 n U.S. DEPARTMENT OF THE TREASURY

for these challenges through encryption or private data connections, but the fundamental

problem is identifying when and how to deploy these mitigating controls. This approach

will, in turn, depend on how nancial institutions understand the necessity of these

controls and the cost associated with them.

Financial institutions and CSPs have taken steps to address both aspects of this challenge.

Industry and nancial authority toolkits and best practices for nancial institutions

continue to evolve. For example, the Cyber Risk Institute’s cloud prole provides nancial

institutions with a framework to evaluate cybersecurity risk with cloud services. Some

nancial sector stakeholders suggested that the FBIIC and FSSCC could play a role

in convening key nancial institutions to discuss best practices as they evolve. While

misconguration is generally seen as a user issue, CSPs seem to recognize the challenges

of trying to market the security benets of cloud services if clients experience prominent

data breaches. CSPs are increasing educational events and deploying more automated

tools and dashboards to help users identify key miscongurations. Some nancial

institutions suggested that CSPs should attempt to provide some guidance on appropriate

or baseline security and resilience congurations. Others noted that the complexity

associated with IaaS is magnied when using multiple CSPs, which can increase risk.

6.3 EXPOSURE TO POTENTIAL OPERATIONAL INCIDENTS, INCLUDING

FROM INCIDENTS ORIGINATING AT A CSP

As discussed in Section 3, many nancial institutions report that cloud services can oer

a number of opportunities to increase the resilience of a nancial institution’s technology

architecture. However, many of these options are oen self-contained within the service

oerings of a single CSP. When nancial institutions consider trade-os accompanying an

increased reliance on a third-party service, they usually consider (i) the importance of a

business function and then the importance of a service to that business function; (ii) the

expected resilience of the service; and (iii) substitutability of the service, including whether

they could replace the service in the short-term.

In interviews, some nancial institutions conveyed that there were gaps in their ability to

assess the resilience of their conguration of a cloud service. Contributing factors included

(i) diiculty in understanding their responsibilities or eectiveness of their choices for

conguring the cloud services for the appropriate level of resilience; (ii) the lack of specic

recovery time objectives in some contracts with CSPs; (iii) the lack of specic incident

notication and response procedures in some contracts with CSPs; and (iv) the lack of

detail in cloud service documentation regarding resilience dependencies, such as a CSP’s

reliance on other suppliers of IT services or internal CSP resources (such as other CSP

operating regions).

Financial institutions and other sources indicated that some CSPs may provide limited

cooperation in direct testing of a nancial institution’s business resumption and recovery

capabilities. Some nancial institutions noted a lack of clarity on how CSPs test and stress

CLOUD REPORT n 54 n U.S. DEPARTMENT OF THE TREASURY

their business continuity capabilities. One nancial institution expressed concern that

it is challenging for them to validate or test whether the CSP could support the nancial

institution’s contracted resilience option in a second, separate CSP region if there was a

severe disruption in the primary CSP region impacting many CSP clients.

Cloud services, like any service, have the potential for technical vulnerabilities that can

negatively aect the condentiality, integrity, or availability of cloud services for all

customers. Technical vulnerabilities in underlying cloud service infrastructure are similar

to a vendor disclosing a vulnerability in commonly used soware that may impact all

the users of that soware. However, when the CSP is responsible for and controls the

vulnerable systems in the aected service, cloud service users are entirely dependent on

the CSP for the timing and eectiveness of the vulnerability remediation. For example, the

extensive Log4j vulnerabilities announced in December 2021 revealed that cloud users

across multiple providers had been susceptible to a previously unknown vulnerability and

were le exposed from the time of the vulnerability’s disclosure until the implementation

of xes by the cloud providers.

107

Compounding this problem, cloud users were also

responsible for remediating the same vulnerabilities in the systems running on cloud

services but under their control.

In eect, widespread vulnerabilities may require action by both the service provider and

the service user. From the service provider perspective, vulnerability mitigation is oen

an all-or-nothing scenario, meaning the service provider has either xed the issue for all

its users or for none. Cloud users, on the other hand, may implement xes on their side at

their discretion. In the Log4j example, major cloud service providers provided transparent

updates to their customers about the remediation status of vulnerabilities on their side of

the shared responsibility model and encouraged their customers to remediate the systems

under the cloud user’s control.

108

Soware failures can cause cloud service outages. For example, in December 2021, several

AWS services in an entire AWS region suered a service disruption. The incident was

caused by an unexpected internal system behavior that ultimately congested the network

leading to further cascading issues that led an outage for those services.

109

The incident

lasted several hours while AWS engineers identied and then resolved the problems and

made changes to prevent the same type of issue from occurring in the future.

Many industry stakeholders noted the risk that a soware failure could aect a key service

that underpins other cloud applications, potentially aecting multiple regions. In March

2021, an update to an authentication system caused a nearly global outage of Microso’s

107. Palo Alto Networks, Log4j - Initial Access to the Cloud, by Arazai et al. (Mar. 2022) https://www.

paloaltonetworks.com/blog/security-operations/log4j-initial-access-to-the-cloud/.

108. AWS, Apache Log4j2 Issue (CVE-2021-44228) (Dec. 2021), hps://aws.amazon.com/security/security-bullens/

AWS-2021-005/; GCP, Apache Log4j 2 Vulnerability (Last updated Mar. 2022), hps://cloud.google.com/log4j2-

security-advisory; Microso, Updated: Azure DevOps (and Azure DevOps Server) and the log4j vulnerability, by

Gloridel Morales, (Dec. 2021), hps://devblogs.microso.com/devops/azure-devops-and-azure-devops-server-

and-the-log4j-vulnerability/.

109. AWS, Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region (Dec. 2021), hps://aws.

amazon.com/message/12721/.

CLOUD REPORT n 55 n U.S. DEPARTMENT OF THE TREASURY

cloud services.

110

Microso conrmed that any service that relied on its identity and

access management (IAM) Azure Active Directory might have been aected. Services like

Microso 365, as well as Microso’s other cloud service oerings, were aected by this

issue because IAM is a key underlying service that supports nearly all of Microso’s cloud

service oerings. The failure of this underpinning soware had widespread eects for the

operational resiliency of reliant services.

Although the SolarWinds incident in December 2020 yielded no known operational

resilience impact to cloud service customers, the incident revealed weaknesses in IAM

and privileged access management (PAM) that the threat actor used across multiple

cloud service users in the cloud environment.

111

Exploitation like this could enable other

malicious activity that could potentially aect the operational resilience of the users of

those services, reinforcing the importance of security and resilience of lynchpin services

like IAM.

112

Another soware failure involving a lynchpin service aected Akamai in July 2021. In this

case, Akamai’s Edge DNS Service suered an outage following a soware update that

introduced a bug in the domain name system service.

113

This service outage le many

websites, including those of major nancial institutions and other major companies

around the world, unreachable. Further, this critical service outage impacted access to

internet resources to such an extent that other CSP services were also negatively aected

until Akamai rolled back the update.

114

Because using cloud services can require internet connectivity to cloud data centers,

physical events can potentially disrupt services. For example, a power outage in December

2021 in AWS’s us-east-1 region caused an outage at one of its data centers.

115

In addition to

aecting a variety of services, the single sign-on service within the area also started to see

increased failure rates, suggesting that services not directly aected by an outage may still

suer ill eects from diminished capability within a region. AWS recommended customers

fail away from the aected zone even if the outage did not directly impact them.

Another physical event involving a cooling system failure at a data center impacted

multiple GCP services in July 2022 in the europe-west2-a zone.

116

In this case, however, the

outage aected services outside of the aected region because early mitigation attempts

inadvertently modied traic routing to avoid three zones rather than just the one with the

110. Caroline Donnelly, Microso cloud users hit by global outage linked to Azure Active Directory issue,

Computerweekly.com (Mar. 2021), hps://www.computerweekly.com/news/252497921/Microso-cloud-users-

hit-by-global-outage-linked-to-Azure-Acve-Directory-issue.

111. Louis Columbus, SolarWinds breach exposes hybrid multicloud security weaknesses, VentureBeat (May 2021),

hps://venturebeat.com/2021/05/15/solarwinds-breach-exposes-hybrid-mul-cloud-security-weaknesses/.

112. Atlantic Council, Broken Trust.

113. Mehta et al., Websites back up aer brief global outage linked to Akamai, Reuters (July 2021) hps://www.

reuters.com/technology/websites-airlines-banks-tech-companies-down-widespread-outage-2021-07-22/.

114. Ibid.

115. Frederic Lardinois, AWS just can’t catch a break, TechCrunch (Dec. 2021), hps://techcrunch.com/2021/12/22/

aws-just-cant-catch-a-break/.

116. GCP, Multiple Cloud products experiencing elevated error rates, (July 2022), hps://status.cloud.google.com/

incidents/fmEL9i2fArADKawkZAa2.

CLOUD REPORT n 56 n U.S. DEPARTMENT OF THE TREASURY

data center cooling system failure. Additionally, with the regional traic routing change,

GCP’s regional storage services that replicate customer data across multiple regions became

inaccessible. GCP recommended workarounds for some of the impacted services, including

failing over to other zones when possible.

These incidents stress the importance of nancial institutions understanding the risk of any

cloud service, as well as the eorts that CSPs are taking to remediate and lower the risk of

technical vulnerabilities in the future. While nancial institutions have limited control over

risks from system-wide technical vulnerabilities, they choose what workloads to deploy

on public cloud services and with which vendors. Depending on the service, nancial

institutions can make a number of design choices that aect the resilience of the service,

including deploying on multiple geographic regions. Interviews with smaller institutions

revealed that they would be challenged in achieving the scale to take advantage of some

of these options. First, these institutions may use managed service providers or other

intermediaries because the inherent cost and complexity of running IaaS and PaaS is

beyond their capabilities. These intermediary providers may not oer the same options

in terms of redundancy on dierent data centers or with a separate geographic region.

Second, even if operating directly in a major CSP environment, these enhanced resilience

options may be cost-prohibitive for smaller nancial institutions.

While many nancial institutions can increase resilience by operating in multiple regions

of the same CSP, few experts believe that complex use cases can be developed to support

seamless failover from one CSP environment to a dierent CSP environment. Reasons

include the inherent dierences among service oerings, the associated complexity of

designing across multiple cloud environments, and the need to hire multiple sta familiar

with various environments. While complete portability appears to be the idealized solution

to solve dependencies, it is not currently, nor is it likely to become, technically practical for

many complex services. One key impediment is a lack of interoperability in identity and

access management services across the major cloud providers and third-party solutions.

Even if it became more practical, instantaneous substitutability might come with

challenges that may make it inadvisable for many nancial institutions and use cases (e.g.,

due to greater risks and costs required to design and secure multiple environments).

Some nancial institutions may rely on multiple providers for dierent services and

emphasize portability over the medium or long-term, but this is generally not a strategy

that can address operational continuity in the short-term. Financial institutions also plan

for how to exit a cloud relationship. But at a practical level, most exit plans are oriented

around a time frame of months to years, given the diiculty in transitioning either back to

on-premises or another provider.

In contrast to nancial institutions that used multiple CSPs for dierent use cases,

some nancial institutions preferred relying on a single CSP. These institutions argued

that deploying on multiple cloud environments had signicant xed costs in terms of

developers, engineers, and risk specialists who are familiar with or need to be trained on

CLOUD REPORT n 57 n U.S. DEPARTMENT OF THE TREASURY

the specic nuances of each vendor’s oerings. Even if these teams were in place (which

would be diicult, given the shortage of talent), they assessed that the benets would

not outweigh the risks, including decreased capabilities to monitor the whole cloud

environment.

6.4 POTENTIAL IMPACT OF MARKET CONCENTRATION IN CLOUD

SERVICE OFFERINGS ON THE SECTOR’S RESILIENCE

As discussed elsewhere in this report, there is evidence that the nancial sector’s adoption

of cloud services is notable and growing, particularly with the three major CSPs: AWS,

GCP, and Microso Azure. A large system failure or data breach at one of these CSPs could

impact multiple nancial institutions or U.S. consumers, though there are open questions

about the extent of that impact. Such an incident could take several forms, including:

• A service interruption or degradation in performance to a single systemic nancial

institution or nancial market infrastructure that depends on cloud services for

functions critical to the nancial sector;

• A service interruption or degradation in performance to a signicant segment of

smaller nancial institutions that depend on cloud services for material business

lines; or

• An interruption or degradation to cloud services that a signicant number of nancial

institutions rely on for critical functions or material business lines. Additionally, a

widespread incident could aect other service providers used by nancial institutions

that also rely on cloud services.

These incidents could have a range of causes. For example, a soware vulnerability

discovered in a widely deployed cloud service could aect several nancial institutions

that have adopted the service. There also could be a scenario where existing CSP clients

exhaust the available computing resources in a particular region, resulting in degraded

performance for all other institutions in contention with the same resources for cloud

services.

At the same time, the mere presence of large CSPs is not necessarily an issue for the

nancial sector’s operational resilience.

117

Evaluating the operational risks that could arise

from concentration in cloud services depends on how rms use and design these services.

The scale that some CSPs oer have potential benets, for example in faster patching

against zero-day exploits.

A lack of aggregated data to assess concentration is a key impediment to understanding

the potential impact of a severe, but plausible operational incident at a CSP on the

nancial sector. The following issues are signicant barriers to such a mapping exercise: (i)

117. As noted previously, this report focuses on assessing operational risks associated with cloud services. Broader

issues with cloud services, such as those associated with competition and market concentration more

generally, are outside of the scope of this report. Some potential implications between market concentration

and its eect on bargaining power are explored under the related issue of contracting for cloud services.

CLOUD REPORT n 58 n U.S. DEPARTMENT OF THE TREASURY

the lack of common denitions or identication approaches for critical or material cloud

services used by nancial institutions, (ii) the lack of a common and reliable method to

measure concentration, (iii) dierent data collection authorities and mandates across

FBIIC-member agencies.

The lack of common denitions focusing on the criticality of cloud services or third-

party services more generally is a signicant hurdle. The full range of services that

nancial institutions consume is not necessarily relevant to assessing the resilience of

core business operations or critical functions provided by the nancial sector. Common

denitions recognized by nancial institutions and regulators would aide in mapping

critical dependencies more consistently and precisely. Meaningfully aggregating this data

may require specicity in how nancial institutions measure and set thresholds for (i) the

importance of the business line or activity that is supported by a cloud service, and (ii) the

importance of the cloud service to that business line or function.

Other jurisdictions, like the UK and EU, have experimented with registries for outsourcing

and other third-party relationships in recent years but have yet to devise a model to avoid

capturing too many, or too few, service relationships. Still, it may be helpful to generate

an initial starting point for identifying concentration even if such inventories would have

limited sensitivity to the criticality of a particular service.

While there are data gaps in terms of how critical specic cloud services may be to the

nancial sector as a whole, FBIIC-member agencies have a range of tools derived from

applicable statutory authorities to evaluate the risk of cloud services with respect to the

institutions they supervise. No single agency can view the entire nancial sector, however.

Agencies can collaborate through many formal and informal channels, but Treasury

assesses that there are opportunities to expand these eorts. Expanding interagency

coordination and closing existing data gaps will be more important as critical nancial

sector applications are moved to the public cloud.

Treasury also sees opportunities to enhance public and private sector coordination

on cloud services. For example, nancial sector incident response plans, including at

the FBIIC and at the G7, typically contemplate incident coordination among nancial

authorities and the nancial sector but have not considered direct involvement by a

CSP. Given the increasing trend of cloud adoption in the industry, strengthening direct

coordination and communication channels may support resiliency eorts in the event of a

major cloud-related incident. More specically, several nancial institutions stressed the

need for CSPs to participate in sector-specic exercises to help regulators and nancial

institutions better understand the impact of an operational incident to cloud services.

CLOUD REPORT n 59 n U.S. DEPARTMENT OF THE TREASURY

2022 TABLETOP EXERCISE

In April 2022, Treasury conducted a tabletop exercise examining a hypothetical service

interruption at a major IaaS provider that featured participation from large nancial

institutions, CSPs, law enforcement agencies, nancial services sector information

sharing organizations, nancial regulatory agencies, and other relevant U.S. government

departments and agencies. The exercise aimed to:

• Discuss information sharing practices between large nancial institutions, CSPs, and

government entities (including regulators) during an incident aecting cloud services.

• Identify resilience and recovery options and socialize resources available to CSPs and

large nancial institutions during the management of a cloud service disruption.

• Improve understanding of how a cloud outage may cause operational impacts for the

nancial sector.

The discussion highlighted the importance of maintaining existing client-vendor

communication channels. Participants also agreed on the need for follow-on work to

facilitate a better understanding of potential operational consequences to the nancial

sector stemming from an impact to an IaaS provider.

6.5 DYNAMICS IN CONTRACT NEGOTIATION GIVEN MARKET

CONCENTRATION

Stakeholders noted that contract negotiations between CSPs and nancial institutions

were particularly challenging. Because cloud services are oered across multiple

jurisdictions and to many clients, CSPs have strong incentives not to negotiate individually

where possible.

Among IaaS oerings, while nancial institutions and other rms report there is still

competition among the three major U.S. CSPs, even the largest nancial institutions

reported diiculties in negotiating contracts. One nancial institution stated that when

negotiating with a CSP as one of the nancial sector’s early adopters, the oered contract

would have provided the CSP with unilateral termination rights without notice, which it

could not accept. Eventually, the nancial institution was able to negotiate a notice period

for termination.

Negotiations are even more inexible for SaaS oerings and smaller nancial institutions.

One smaller nancial institution reported diiculty securing its preferred backup

conguration because they did not have the scale for the SaaS provider to oer backups

as part of its normal conguration. Another nancial institution noted the importance of

addressing how CSPs will handle encryption keys to allow access to data should they exit

from the service arrangement with the provider. Some nancial institutions stated that

they believed obtaining audit rights within a cloud service contract was more diicult

CLOUD REPORT n 60 n U.S. DEPARTMENT OF THE TREASURY

for U.S. nancial institutions. They pointed to foreign regulatory guidance as making a

dierence, like the European Banking Authority’s outsourcing guidelines, which requires

nancial institutions to obtain audit rights.

118

Financial institutions reported that some of these contractual challenges have been

resolved as CSPs gained more experience working with nancial institutions and became

more familiar with the rationale for the regulatory expectations underpinning requests

from the nancial sector. Interviews with larger nancial institutions indicated that, in

some cases, they have more favorable treatment than smaller nancial institutions when

it came to certain issues like audit rights and access to information.

6.6 INTERNATIONAL LANDSCAPE AND REGULATORY FRAGMENTATION

Financial institutions, CSPs, and other external stakeholders raised the challenges

associated with the increasingly complex and diverse international nancial regulatory

landscape for cloud services. Several stakeholders noted foreign regulators had a higher

level of scrutiny over the use of cloud services, which they attributed to several factors,

including unfamiliarity by some regulators, historical lack of cooperation by CSPs in the

early days of adoption, and concerns regarding the privacy of data. Some global nancial

institutions reported that because of dierences in regulatory and supervisory approaches

across the globe, consistent adoption of cloud in dierent jurisdictions is practically

impossible. This impediment potentially increases operational risks associated with the

cloud because of the complexity of either managing multiple small cloud deployments or

trying to manage two dierent cloud strategies between their U.S. technology footprint

and foreign technology footprint.

Requirements for data localization pose another challenge. Such requirements can lead

to a fragmentation of the technology architecture for internationally active nancial

institutions, which can decrease their cyber and operational resilience. To the extent that

data privacy concerns drive data localization, greater cooperation among like-minded

authorities (such as through the Trans-Atlantic Data Privacy Framework)

119

should ease

these pressures.

CSPs and nancial sector stakeholders noted the lack of common denitions, particularly

concerning what may constitute “critical” or “material” services under dierent regulatory

frameworks. These inconsistencies can cause confusion regarding complying with

various regulatory expectations relevant for cloud services, for example, understanding

which policies and expectations do and do not apply to dierent service oerings and

congurations. Some jurisdictions have also implemented specic requirements or

118. EBA, EBA Guidelines on outsourcing arrangements (Feb 2019), hps://www.eba.europa.eu/regulaon-and-

policy/internal-governance/guidelines-on-outsourcing-arrangements.

119. The White House, United States and European Commission Announce Trans-Atlantic Data Privacy Framework

(Mar. 2022), hps://www.whitehouse.gov/brieng-room/statements-releases/2022/03/25/fact-sheet-united-

states-and-european-commission-announce-trans-atlanc-data-privacy-framework/.

CLOUD REPORT n 61 n U.S. DEPARTMENT OF THE TREASURY

guidelines for cloud or third-party providers that may be technically impractical, like

mandates to use local cloud providers for primary and backup applications.

Several stakeholders Treasury interviewed noted that new foreign regulatory approaches

in the EU and the UK for critical third-party providers to the nancial sector could have a

major eect on how CSPs engage with the nancial institutions. These frameworks could

increase the overall resilience of cloud services, providing positive spillovers to the U.S.

nancial system. But such frameworks may be challenging for CSPs to accommodate

if requirements are conicting or pose potential security risks. The impetus for these

regulatory reforms includes increasing cloud adoption by larger foreign nancial

institutions in these jurisdictions. As such, the resilience and security of the services

oered by U.S. CSPs are not just relevant to the resilience of U.S. nancial system but may

also be relevant to the global nancial system. Treasury has led U.S. engagement on both

frameworks, including through ongoing bilateral regulatory dialogues with the EU and

UK, and will consider how to engage on a technical and operational level moving forward.

Potential avenues include bilateral engagement, as well as the G7 CEG and the Treasury-

FRB Critical Provider Dialogue.

Some stakeholders noted that cloud services lack a mature regulatory framework

in emerging markets. Like small and medium-sized institutions in the U.S., nancial

institutions in these jurisdictions may be considering or adopting cloud services but

outside a mature regulatory framework for operational risk. As cloud adoption in these

jurisdictions increases, regulators in these jurisdictions may also consider expanding

their regulatory perimeter over CSPs. This reality could amplify the risks of regulatory

fragmentation and ultimately impact the consistency, security, and resilience of services

that CSPs oer. The lack of a mature framework makes the regulatory environment for

nancial institutions unpredictable in certain jurisdictions. Some stakeholders conveyed

that the U.S. and other advanced economies might reduce the risks of regulatory

fragmentation by sharing best practices and providing more transparency over their

regulatory activities.

Additionally, international coordination among nancial regulators on identifying

vulnerabilities or joint exercises involving CSPs – i.e., pre-incident oversight and

preparation – is still being developed. It is possible that the nancial authorities in one

jurisdiction may identify a vulnerability that is relevant to other jurisdictions but are

not committed to sharing their ndings. Foreign nancial authorities may also need to

establish clearer protocols for how supervisory and regulatory activities involving CSPs are

shared and coordinated with authorities for economy-wide cybersecurity or technology

procurement.

Stakeholder concerns over regulatory fragmentation are not only limited to the

international landscape. Some small banks stated that regulatory requirements applicable

to banks were more rigorous than those applicable to non-bank competitors, suggesting

that there may not be a level playing eld for sensitive nancial data.

CLOUD REPORT n 62 n U.S. DEPARTMENT OF THE TREASURY

7. Areas for Further Consideration and Next Steps

Treasury recognizes that the U.S. nancial services sector employs a wide range of

cloud adoption models and that it is highly likely that cloud adoption will continue

to accelerate. This adoption is driven in part by cloud services facilitation of remote

working arrangements and enhanced data analytics, as well as the potential for nancial

institutions to use the cloud environment to connect with third-party providers and clients

more eiciently and securely. For some entities, cloud services represent a signicant

evolution in the back-end processing for nancial services transactions. However, these

benets can only be harnessed if the selected services are adequately designed and

managed for the appropriate level of security and resilience.

Ultimately, cloud adoption is a decision that should be and is made by each U.S. nancial

institution based on its own risk tolerance, risk management framework, and business

needs and objectives. Treasury neither endorses nor discourages cloud service adoption

by the sector. But given the growing importance of cloud services to the sector, Treasury

assesses that it is appropriate to take actions to support a resilient environment for cloud

adoption.

NEXT STEPS

Treasury plans to continue engagement with U.S. nancial regulators, the private sector,

and international partners to address the challenges identied in this report. Such steps

will include:

• Establish an interagency Cloud Services Steering Group to coordinate on issues raised in

this report.

• Follow-up tabletop exercises involving CSPs and the nancial sector.

• Further domestic collaboration on areas implicated in this report, including developing

options or approaches with respect to the following:

• Interagency coordination and collaboration regarding potential risks posed by cloud

services, including additional information-sharing opportunities;

• Common denitions and terms across the sector, such as for “critical” services;

• Sector-wide measurement of the concentration of critical uses of cloud services and

similar third-party services;

• Incident response involving cloud services, such as updating processes to expand

communication channels between U.S. nancial regulators, CSPs, and nancial

institutions; and

• Financial institution risk management practices for cloud services (e.g., discussing

with U.S. nancial regulators where regulatory guidance could be enhanced).

CLOUD REPORT n 63 n U.S. DEPARTMENT OF THE TREASURY

• Continued support for the development of international standards, principles, and

recommendations, as appropriate, including by the G7, Financial Stability Board, and

the international nancial standard-setting bodies.

Improved international coordination with key partners, building on existing bilateral

relationships and dialogues, as well as further developing multilateral relationships,

including through the new Treasury-FRB Critical Provider Dialogue.

Treasury also will consider other collaborative projects regarding cloud services. Such

work could include:

• Fostering industry consensus around eective security controls, risk management

practices, and contractual requirements, particularly for the benet of small and

medium-sized nancial institutions, and;

• Strengthening avenues for communication with the private sector, such as around

threat intelligence sharing.

CLOUD REPORT n 64 n U.S. DEPARTMENT OF THE TREASURY

PAGE LEFT INTENTIONALLY BLANK

CLOUD REPORT n 65 n U.S. DEPARTMENT OF THE TREASURY

Annex A: The Department of Treasury’s Cloud Strategy

1. STRATEGIC TECHNOLOGY LANDSCAPE

To address unique mission priorities, Treasury and many of its Bureaus have adopted

cloud using various service delivery models, oen through duplicative contract actions

and engineering eorts. This approach, while oering faster deployments, does not

capitalize on opportunities for operational eiciencies, standardized security, and cost

reduction through service deduplication and consolidated procurement.

Treasury’s Oice of the Chief Information Oicer (OCIO) has established three strategic

objectives in its adoption of the cloud:

• Support the Treasury mission by enabling infrastructure eiciency, scalability, and

elasticity;

• Reduce ineiciencies across the Department by developing enterprise shared services

that Oices and Bureaus can readily consume; and

• Secure Treasury systems using a zero trust security model.

Treasury will use these objectives to develop a detailed strategic implementation

approach for managing its data, infrastructure, and application landscape. While Treasury

intends to use multiple cloud providers for the delivery of its government and citizen-

facing services, there will likely be some residual on-premises infrastructure that must

be maintained for mission-specic purposes. Treasury will use its Cloud Program Oice

to provide and promote eective governance and technology management for cloud

services. Through policies, solutions architecture, and knowledge sharing, the Cloud

Program Oice will be a mechanism for the entire Department to achieve its enterprise

cloud infrastructure goals.

2. STRATEGIC OBJECTIVES

Treasury is transforming its infrastructure to accommodate modern demands and better

enable mission delivery by improving the reliability, security, and resiliency of technology

services. Today, Treasury has a hybrid multi-cloud infrastructure that serves as a general-

purpose platform for Department-wide use cases (e.g., human resources management)

and a t-for-purpose cloud specically for tailored use cases. Treasury has managed IaaS,

PaaS, and SaaS service delivery models.

While adopting the existing cloud environment has been consistent, Treasury will be

developing a new enterprise cloud oering that will accelerate adoption and enable

the Department and its Bureaus to gain eiciencies in access, scale, cost, contracting,

and security. By combining purchasing power and reducing duplicative capabilities,

Treasury can achieve greater cost control through economies of scale at the enterprise

level that exceeds those that the Bureaus can reach independently. Treasury can use

CLOUD REPORT n 66 n U.S. DEPARTMENT OF THE TREASURY

these savings to capitalize on future investments and allow Treasury to obtain higher

levels of service. This enterprise infrastructure cloud strategy enables centralized

infrastructure management, which lessens the operational burden for Bureaus while

providing Treasury leadership an overall view of utilization, costs, and security posture.

During Fiscal Year 2023, a contract will be awarded for “Treasury Cloud” - a fully managed

multi-cloud environment. The decision to pursue a multi-cloud contract is largely

based on the diversity of our mission activities. Treasury bureaus are engaged in broad-

ranging technical and operational activities, from the manufacture of currency in factory

environments (e.g., the Bureau of Engraving and Printing and the U.S. Mint) to the

administration of taxes through physical and digital intake channels. While there is a high

degree of parity in the foundational capabilities of each CSP, there are nuanced dierences

that make it preferable for Treasury to rely on dierent CSPs for certain use cases.

2.1 SENABLE INFRASTRUCTURE EFFICIENCY, SCALABILITY, AND ELASTICITY

By implementing a hybrid infrastructure solution that links on-premises and cloud-based

compute, storage, and network capabilities, Treasury has accomplished a highly reliable,

eicient, and agile infrastructure. This infrastructure brings cost-eicient scalability and

elasticity to long-term and episodic requirements, which limits capital outlays and avoids

the cumbersome and lengthy acquisition and implementation cycle of traditional IT

infrastructure.

The adoption of cloud infrastructure technologies in the Treasury enterprise has alleviated

challenges in managing computing, storage, and networking. It provides exibility,

empowering Treasury to redirect scarce resources to mission-critical eorts instead of

owning and managing commodity infrastructure technologies. Many of our data centers

are in facilities that have not been appropriately modernized or do not reside within

purpose-built structures (e.g., inside a federal oice building). Some reside in geographical

regions where technical talent is in shorter supply. By consolidating our data center

footprint to commercial facilities and transferring workloads to the cloud, we will be less

hindered by insuicient computing, storage, and network capacity and the potential for

catastrophic failures introduced by the physical plant.

By implementing an on-demand scalable infrastructure, Treasury has started gaining

signicant eiciencies in the execution of its mission, as the shared cloud infrastructure

enables teams to deploy and scale rapidly. Additionally, enterprise cloud solutions will

allow Treasury to further consolidate much of its legacy on-premises assets, increasing

compliance with OMB data center consolidation initiatives.

2.2 REFORM IT AT THE DEPARTMENT BY EMBRACING CLOUD

To meet modern computing and storage practices, Treasury has adopted a consumption

model by gradually trading capital expenses for operating expenses to optimize costs

across its technology portfolio and allow for adaptation to changing priorities, budgetary

conditions, and industry developments. The cloud environment provides nancial

CLOUD REPORT n 67 n U.S. DEPARTMENT OF THE TREASURY

exibility through the provisioning and de-provisioning of resources automatically to

provide optimum asset management when compared to traditional IT infrastructure,

which is constantly in operation even when utilization is low or nonexistent.

This eiciency will gradually improve the Government’s budgeting, billing, and payment

practices by providing detailed resource usage reports for all mission owners while

creating transparency to drive further eiciencies. The Treasury’s Cloud Program Oice

is integrating with Treasury’s Technology Business Management (TBM) processes for

reporting to better track nancials and cloud resources.

2.3 IMPLEMENT MODERN CYBERSECURITY FRAMEWORKS TO SECURE

TREASURY SYSTEMS

Treasury’s cloud platform has begun to shi its security focus from perimeter defense

to a zero trust model of securing data, users, and services. We will accomplish this shi

through strong authentication for users and machines, encryption of data both at rest and

in transit, and cloud-based policy enforcement points for all traic. The Treasury cloud

infrastructure environments leverage native and third-party cloud services to encrypt

communications, endpoints, and storage by default. Treasury plans to further implement

zero trust principles, leveraging concepts such as TIC 3.0 for systems and applications,

following the NIST, CISA and OMB guidance, building on the zero trust architecture offered

by its current cloud platform.

3. STRATEGIC APPROACHES AND GUIDING PRINCIPLES

Treasury utilizes a multi-cloud approach, which provides an environment of private,

public, and hybrid clouds. To achieve the objectives outlined previously, the Treasury

Cloud Strategy is based on a set of principles, guiding the eicient utilization of cloud

resources: Cloud Infrastructure Sharing; Cloud Infrastructure Best Practices; Cloud

Infrastructure Workforce; and Cloud Infrastructure Strategic Sourcing.

3.1 CLOUD INFRASTRUCTURE SHARING

To achieve the strategic principles outlined, the Treasury OCIO has built a cloud

infrastructure specically to be used for shared services called Workplace Community

Cloud (WC2). It currently resides on AWS and is expanding to Microso Azure and will likely

expand to other CSPs in the future. The WC2 program provides migration and hosting

of Department and Bureau applications and data, supporting plans for reducing the

existence of data centers. As previously mentioned, the program is assessing WC2 platform

upgrades to implement TIC 3.0 policy enforcement points as part of our overall zero trust

architecture.

3.2 CLOUD INFRASTRUCTURE BEST PRACTICES

To support an enterprise cloud infrastructure strategy, Treasury leverages best practices

across the Treasury Department, Federal Government colleagues and partners, NIST, and

CLOUD REPORT n 67 n U.S. DEPARTMENT OF THE TREASURY

CLOUD REPORT n 68 n U.S. DEPARTMENT OF THE TREASURY

the commercial industry. Treasury’s Cloud Program Oice has been leveraging commercial

cloud oerings to benet from the natural competitive processes between CSPs that

force them to evolve and mature their products quickly. Treasury is positioning itself to

get the best value in today’s market of cloud computing capabilities to support business

requirements and to grow its capabilities as the industry evolves.

3.3 CLOUD INFRASTRUCTURE STRATEGIC SOURCING

To facilitate its cloud strategy, Treasury has developed governance approaches for

standardization and centralization, in line with the Department’s IT shared services

approach, that provides secure, eicient, and cost-eective business innovation. The

acquisition and procurement cycles for IT and cloud infrastructure services are lengthy

and occasionally negate many of the just-in-time benets associated with cloud services.

As such, Treasury has implemented a shared service cloud infrastructure model to capture

Treasury-wide eiciencies in access, contracting, and security.

This enterprise-wide acquisition strategy enables Treasury to leverage long contract

lifecycles with the necessary scope to provide customers the exibility in cloud usage.

This will also take advantage of the economies of scale at the Department level when

buying cloud products and services and is in alignment with the Federal Strategic Sourcing

Initiative and the larger Federal Information Technology Acquisition Reform Act mandate

intended to streamline acquisitions, foster the sharing of best practices, and further

opportunities to increase cost savings and value. Bureaus will have the chance to achieve

zero trust and TIC 3.0 alignment using Treasury Cloud.

3.4 FULL EMBRACE OF THE API ECOSYSTEM

To facilitate the adoption of enterprise cloud, our consumers expect our services to be

predictable, reliable, and consumable. In the current technological context, consumption

is most appealing when there are dened inputs, dened outputs, and aggressive SLAs.

Treasury has gravitated toward an API-driven ecosystem with standardized formats for

data interchange of at les. Common capabilities such as key management, secrets

management, or identity and access management would be catalogued such that they can

be easily expressed in code. Conceptually the idea is to transition the focus on stacking

capabilities to drive business outcomes, with fewer resources put toward the supporting

infrastructure.

CLOUD REPORT n 69 n U.S. DEPARTMENT OF THE TREASURY

Annex B: External Stakeholders Interviewed

Treasury and certain FBIIC-member agencies met with a broad array of organizations and

individual companies to gain insights from practitioners on cloud adoption in the nancial

services industry. This included roundtable discussions with representatives of nancial

sector associations, cloud services providers, and research-focused think tanks. Treasury

also conducted talks with individual stakeholders.

This outreach was organized under an open discussion without attribution focused on the

current and future state of cloud adoption, viewpoints on the unique risks related to cloud

adoption and third-party risk management processes.

PARTICIPATING EXTERNAL ORGANIZATIONS

American Bankers Association

AIG

Amazon Web Services

Atlantic Council

Bank Policy Institute

Barclays

Bank of New York Mellon

Bank of America

Capital City Bank Group

Capital One

Carnegie Endowment

Citigroup

CLS-Bank

CME Group

Commonwealth Credit Union

Center for Strategic and International

Studies

Cyber Risk Institute

Depository Trust & Clearing Corporation

Deutsche Bank

Fannie Mae

Financial Services Sector Coordinating

Council

Financial Industry Regulatory Authority

Fiserv

Goldman Sachs

IBM Cloud

Intercontinental Exchange

International Monetary Fund

Independent Community Bankers of

America

Institute of International Finance

Jack Henry

JP Morgan Chase

KeyBank

Kyndryl

Lewis & Clark Bancorp

Mastercard

Microso

Morgan Stanley

First United Corporation

Options Clearing Corporation

Program on International Financial

Systems

Prudential Financial

Queensborough National Bank & Trust

Company

Santa Cruz County Bank

SIFMA

Simmons Bank

SWIFT

TruWest Credit Union

Wells Fargo

U.S. Department of the Treasury

TREASURY.GOV