Cloud Computing for Banks: Security, Compliance, and Implementation
7/24/2026
Most community bankers believe they have limited cloud exposure because the institution has not migrated anything. That belief is almost always wrong, and the reason is worth stating first: the bank's core processor, digital banking platform, monitoring system, and document repository are running on someone's cloud infrastructure. The institution's exposure is real, it is indirect, and it is largely invisible in a vendor file that describes the provider without naming what the provider runs on.
Supervisory expectations here are not new requirements. The agencies' position has been that existing governance, outsourcing, information security, and resilience expectations apply to cloud arrangements — which means the work is applying disciplines the institution already has to an environment where the control boundaries fall in unfamiliar places.
The Distinction That Determines Everything
Three service models, and the institution's responsibilities differ substantially across them.
Infrastructure as a service. The provider supplies compute, storage, and networking. The institution is responsible for the operating system, the applications, the configuration, the identity model, the data, and nearly every control. Community banks rarely consume this directly.
Platform as a service. The provider manages the underlying platform; the institution is responsible for its applications, its data, and its access model.
Software as a service. The provider runs the application. The institution is responsible for how it is configured, who has access, what data goes into it, and — critically — for the administrative control plane.
Most community banks are SaaS consumers, and that produces a specific and underappreciated position: the institution's direct cloud responsibilities are narrow, its indirect exposure is broad, and the indirect exposure is a fourth-party question. The vendor runs on a hyperscaler; a regional outage or a provider-side incident reaches the bank through the vendor, with the bank holding no contract with the party that failed.
The Shared Responsibility Model, Concretely
The organizing principle is that the provider is responsible for the security of the cloud, and the customer is responsible for security in the cloud.
Provider side: physical security, the hypervisor, the underlying network, and the availability of the service itself. These are the areas where hyperscale providers generally perform better than a community bank's own data center, and it is fair to say so.
Customer side: identity and access management, configuration, data classification and encryption choices, network controls the customer defines, logging and monitoring, patching of anything the customer operates, and backup arrangements.
The consequence that matters more than any other in this subject: the dominant cause of cloud security incidents is customer misconfiguration, not provider compromise. Publicly exposed storage, over-permissive access policies, disabled logging, unrestricted administrative interfaces. The provider's controls were working correctly the entire time.
For a SaaS-consuming bank, the equivalent is the administrative configuration of the application — who has admin rights, whether multifactor authentication is enforced, what the session and password settings are, whether audit logging is enabled and retained, whether data export is unrestricted. These are the institution's decisions, they are frequently left at the vendor's defaults, and they constitute the bank's actual cloud control surface.
Due Diligence You Cannot Perform the Usual Way
A bank cannot audit a hyperscale provider, and no provider will accommodate an on-site examination by a community bank. The available approach is documentary and it is genuinely sufficient when done properly.
Read the assurance reports rather than filing them, applying the discipline described in our vendor management post: does the scope cover the services and regions actually used, what exceptions did the auditor find, and what period is covered.
Read the complementary user entity controls. This is the single most important section for a cloud arrangement, because it is where the provider enumerates the controls it assumes the customer performs. A bank that has never read this list is relying on controls nobody is executing, and in cloud arrangements that list is long.
Read the shared responsibility documentation for the specific services in use, since the boundary shifts between services within the same provider.
For SaaS, ask what the application runs on, in which regions, and what the vendor's own arrangements are for resilience and exit. Vendors answer this question when asked and rarely volunteer it.
Identity Is the Perimeter
In an on-premises environment, network location provided a meaningful control boundary. In the cloud it does not, and the practical replacement is identity.
The controls that matter most:
Multifactor authentication on every administrative account, without exception. A compromised cloud administrative credential is not an incident with a blast radius — it is potentially total, including the ability to delete backups and disable logging.
No long-lived static credentials. Access keys embedded in code or configuration are the recurring finding, and short-lived, rotated credentials are the answer.
Least privilege, reviewed. Cloud permission models are expressive enough that over-permissive grants are the path of least resistance. Periodic entitlement review has to include cloud and SaaS administrative roles, which most institutions' access reviews omit entirely.
Separation of production from development and test, with different credentials and different approval paths.
Logging of the control plane — every administrative action, retained long enough to investigate. Default retention periods on many services are far shorter than an institution would want after discovering a problem, and extending retention is a configuration choice someone has to make.
Break-glass procedures for emergency access, defined, restricted, and monitored, so that emergency access is not a permanent standing privilege held by several people.
Encryption and Who Holds the Keys
Encryption at rest is standard and largely uninteresting; every major provider offers it and most enable it by default. The substantive question is key management.
Provider-managed keys are simple and protect against the loss of physical media or a storage-layer exposure. They do not protect against a compromised customer account, because a legitimate request from an authorized identity gets decrypted data.
Customer-managed keys give the institution the ability to revoke access and provide separation between the party holding the data and the party holding the key — at the cost of real operational responsibility, since losing a key means losing the data.
Encryption in transit should be enforced rather than available, including between services inside the provider's environment.
The point institutions frequently miss: encryption addresses a narrow set of threats. It does very little against the misconfiguration and credential compromise scenarios that cause most cloud incidents, and an institution satisfied by "the data is encrypted" has answered a question nobody was asking.
Resilience and Backup
Cloud infrastructure fails differently from a data center, and the design assumptions have to reflect that.
Understand the failure domains. Availability zones and regions are the provider's isolation boundaries, and a service deployed within a single zone inherits that zone's fate. For a SaaS-consuming bank, the question to the vendor is what its deployment looks like and what a zone or region failure means for the bank's service.
Backups must be outside the failure domain and outside the account. The ransomware scenario that has damaged organizations most severely is one where the attacker, holding administrative credentials, deleted the backups before deploying the payload. A backup that can be deleted by the same credential that manages production is not a backup.
Test restoration, end to end, with a measured time. This is the same discipline as any recovery test, and cloud arrangements make it easier to skip because the provider's availability figures are reassuring — availability of the platform is not the same thing as recoverability of the institution's data.
Reconcile the vendor's recovery objectives with the institution's expectations, which is exactly the exercise covered in Assessing the Effectiveness of Your Vendor's BCP. Institutions routinely assume a recovery time the contract does not commit to.
Concentration Nobody Mapped
The fourth-party concentration problem is more acute in cloud than anywhere else.
Several of the institution's apparently unrelated vendors likely run on the same provider, and possibly in the same region. A regional event therefore affects systems the institution's continuity plan treats as independent — the core, the digital banking platform, the monitoring system, and the document repository all becoming unavailable simultaneously in a scenario nobody modeled.
The remedy is unglamorous: ask each critical vendor which provider and which region it runs in, and map it. Institutions that do this for the first time generally find more overlap than they expected, and the value is not that it can be eliminated — it usually cannot — but that the continuity plan then reflects reality.
Structured coverage is available through the Certificate in Cybersecurity, Cybersecurity Management, the Certified Regulatory Vendor Program Manager program with its business continuity level, and the Certificate in Operational Risk Management.
Contract Terms Specific to Cloud
Beyond the general vendor terms, cloud arrangements need:
- Data location, and notice before it changes
- Subcontractor disclosure, which in cloud means the layers beneath the vendor
- Regulator access to information necessary for examination
- Incident notification with specific timeframes, including incidents affecting the underlying provider
- Data return and deletion on exit, in a specified format, with certification of deletion
- Portability, addressed concretely rather than as a principle
- Service levels with meaningful remedies, recognizing that service credits are not a substitute for availability
- The right to receive assurance reports for the term of the agreement, not just at onboarding
- Notice of material changes to the service, the architecture, or the subcontractors
Exit Is the Hardest Part
Cloud exit planning is where institutions are weakest, and SaaS exit is harder than infrastructure exit.
With infrastructure, the institution's data is in formats it controls and the exit problem is logistical — volume, egress cost, and time. With SaaS, the data lives in the vendor's schema, and an export is only useful if the institution can interpret and load it somewhere else. An export the institution has never tested is an assumption.
Questions with concrete answers required: what format is the export, has anyone loaded it into anything, how long does a full export take, what does egress cost, what happens to data the vendor holds after termination and how is deletion evidenced, and how long would a conversion actually take. An institution that cannot answer these has an exit plan in name only — a point that applies with particular force to the core processor relationship.
Where Institutions Get This Wrong
Believing they have no cloud exposure because they have not migrated anything.
No inventory of which vendors run where, so concentration is invisible.
Assurance reports filed unread, and complementary user entity controls never examined.
SaaS administrative settings left at vendor defaults — the bank's actual cloud control surface, unconfigured.
No MFA on administrative access, or long-lived static credentials in use.
Cloud and SaaS admin roles omitted from access reviews.
Control plane logging disabled or retained too briefly to investigate anything.
Backups deletable by the production credential, which defeats their purpose in the scenario that matters most.
"It's encrypted" treated as an answer to threats encryption does not address.
Recovery objectives assumed rather than contracted and tested.
Exit untested, particularly for SaaS, where the export format is the whole problem.
The framing that holds all of this together: cloud does not reduce the institution's responsibilities, it relocates them — from server rooms and patching to identity, configuration, and contracts. Institutions that recognize where their responsibilities moved manage cloud arrangements well. Institutions that read the provider's security marketing and conclude the risk has been outsourced find out otherwise, usually through a misconfiguration nobody was looking for.
Frequently Asked Questions
Does a community bank that has not migrated to the cloud have cloud risk?
Almost certainly yes. The core processor, digital banking platform, monitoring system, and document repository are typically running on hyperscale cloud infrastructure, which makes the exposure real, indirect, and a fourth-party question — the bank has no contract with the party whose failure would reach it.
What is the shared responsibility model?
The provider is responsible for security of the cloud — physical security, the hypervisor, the underlying network, and service availability. The customer is responsible for security in the cloud — identity and access, configuration, data classification and encryption choices, logging, and backups. For a SaaS-consuming bank, the customer side is largely the application's administrative configuration.
What causes most cloud security incidents?
Customer misconfiguration, not provider compromise. Publicly exposed storage, over-permissive access policies, disabled logging, and unrestricted administrative interfaces — in every case the provider's controls were functioning correctly. For SaaS consumers the analogue is administrative settings left at vendor defaults.
Why is identity the perimeter in cloud environments?
Because network location no longer provides a meaningful boundary. A compromised administrative credential can potentially delete backups and disable logging, making the impact total rather than contained. The controls that follow are MFA on all administrative access, no long-lived static credentials, least privilege with real periodic review, separation of production, and control plane logging retained long enough to investigate.
Is encryption at rest sufficient protection?
No. It addresses loss of physical media and storage-layer exposure and does very little against the misconfiguration and credential compromise scenarios that cause most incidents — a legitimate request from a compromised authorized identity receives decrypted data. The substantive question is key management and whether the institution can revoke access.
Why is SaaS exit harder than infrastructure exit?
Because the data lives in the vendor's schema rather than in formats the institution controls, so an export is only useful if the institution can interpret and load it elsewhere. An export nobody has tested is an assumption, which is why the exit questions worth answering are format, whether anyone has actually loaded it, full export duration, egress cost, and how deletion is evidenced.
