The Cloud Renewal Packet Should Name the Blast Radius

A practical weekly article for community bank and credit union boards and senior leaders on cloud renewal governance, focused on translating provider concentration, shared depen...

A cloud renewal can look like a normal technology purchase until someone asks the uncomfortable question.

What breaks if this provider, region, identity service, backup path, or admin workflow has a very bad Tuesday?

That question belongs in the board packet. Not buried in an architecture diagram. Not implied by a vendor scorecard. Not saved for the next cyber tabletop when everyone is already tired, caffeinated, and pretending the conference room coffee is fine.

Cloud decisions are not just infrastructure decisions anymore. For community banks and credit unions, they shape digital account opening, lending workflows, call center tools, analytics, fraud monitoring, employee productivity, backup, disaster recovery, and sometimes the security controls wrapped around all of it.

That does not make cloud bad. Done well, cloud can give a smaller institution better resilience, better security tooling, and faster delivery than it could realistically build alone.

But the governance question is not, “Are we using cloud?” Most institutions already are.

The better question is, “Do we understand the blast radius?”

The renewal is the decision moment

Cloud risk rarely shows up cleanly as a single yes-or-no vote. It sneaks into the packet through renewals, add-ons, managed service expansions, data warehouse projects, digital banking dependencies, security tools, and “standardization” proposals.

That makes the renewal packet important.

That is where boards get misled, usually without anyone intending to mislead them. The packet talks about price, term, service levels, and maybe security certification. Those are useful. They are not enough.

A good cloud renewal packet should answer four plain questions:

1. What business services now depend on this provider or platform? 2. What shared control, identity, network, or data path could fail across several services at once? 3. What would we do manually, or in degraded mode, if that path failed? 4. Who has authority to spend money, invoke contingencies, pause customer-facing changes, or accept temporary risk during recovery?

That is not a technical rabbit hole. That is governance.

Capital One showed why “cloud” is not the control

The Capital One enforcement action is still one of the cleanest reminders that cloud adoption does not magically create good risk management.

In 2020, the Office of the Comptroller of the Currency assessed an $80 million civil money penalty against Capital One. The OCC said the bank failed to establish effective risk assessment processes before migrating significant IT operations to the public cloud environment and failed to correct deficiencies in a timely manner. The OCC also said responsible innovation still requires sound risk management and internal controls. Source: OCC, “OCC Assesses $80 Million Civil Money Penalty Against Capital One,” Aug. 6, 2020: https://www.occ.gov/news-issuances/news-releases/2020/nr-occ-2020-101.html

The issue was not that a bank used public cloud. The issue was whether the institution had the risk assessment, control discipline, and follow-through to govern the move.

Community institutions should not read that case and think, “That was a big-bank problem.” Different scale, same governance pattern.

If the board approves a cloud expansion, the packet should not stop at the vendor’s security posture. It should explain the institution’s control posture: which controls belong to the provider, the institution, and any managed service provider or integrator, plus which assumptions will be tested after migration.

The shared responsibility model is simple on a slide. It gets messy in operations. Anyone who has lived through a migration knows this.

AWS showed how one dependency can become many symptoms

In December 2021, AWS published a post-event summary for a service event in the Northern Virginia, US-EAST-1 Region. AWS described congestion between internal networks that affected monitoring data for internal operations teams. AWS also said the event affected its Service Health Dashboard tooling and Support Contact Center, which complicated customer communication during the event. Source: AWS, “Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region,” Dec. 10, 2021: https://aws.amazon.com/message/12721/

That is a useful case for boards because it shows how outages rarely stay inside the neat box we draw around them.

A system problem can become a monitoring problem. A monitoring problem can become a communication problem. A communication problem can become an executive decision problem.

For community banks and credit unions, that matters more than the specific cloud provider involved. The question is not whether a hyperscaler has better engineering than your institution. It does. The question is whether your institution understands what happens when a dependency gets weird.

Can lending still close loans, branches authenticate users, the call center see enough customer information, and executives get reliable updates if the normal dashboard, vendor portal, or support channel is impaired?

If the answer is “we would figure it out,” that is not a plan. That is hope wearing a fleece vest.

UniSuper showed why backup architecture is a board topic

The 2024 Google Cloud and UniSuper incident is another useful example because it moves the conversation from uptime to recoverability.

Google Cloud said an internal tool misconfiguration during deployment of a Google Cloud VMware Engine private cloud left a parameter blank, which later resulted in one customer’s private cloud being deleted at the end of a system-assigned one-year term. Google said the incident affected UniSuper in Australia, and that recovery was assisted by UniSuper’s architecture, including backups stored in Google Cloud Storage in the same region. Source: Google Cloud, “Sharing details on a recent incident impacting one of our customers,” May 24, 2024: https://cloud.google.com/blog/products/infrastructure/details-of-google-cloud-gcve-incident

There is a board-level lesson here.

Backups are not just an IT control. They are an operating promise.

If the institution cannot explain what data is backed up, where it is backed up, who can restore it, what dependencies are needed to restore it, and how long the business can tolerate the degraded state, then the board is approving resilience by adjective.

“Robust.”

“Redundant.”

“Enterprise-grade.”

Those words are fine in a sales deck. They are not sufficient in a governance packet.

A board packet should translate backup and recovery into business language. Which products are unavailable? Which customer promises are delayed? Which manual processes start? Which regulatory, liquidity, fraud, or member-service risks increase while the institution is recovering?

That is how directors can govern without pretending to be cloud engineers.

The packet should show concentration, not just compliance

The federal banking agencies issued final joint guidance in 2023 on third-party risk management. The Federal Reserve’s release said the guidance is designed to help banking organizations manage risks associated with third-party relationships, including fintech relationships, and covers the life cycle of planning, due diligence, contract negotiation, ongoing monitoring, and termination. It also says the guidance includes examples intended to help community banks align practices with the nature and risk profile of their third-party relationships. Source: Federal Reserve, FDIC, and OCC joint release, June 6, 2023: https://www.federalreserve.gov/newsevents/pressreleases/bcreg20230606a.htm

That life-cycle language is important. Cloud governance does not end when legal signs the contract.

For board and executive purposes, I would add a simple renewal exhibit: the concentration map.

Not a giant architecture poster. Nobody wants that in the packet, including the person who made it.

A useful concentration map names the few dependencies that matter most:

• Primary cloud provider or managed platform
• Critical regions or availability zones
• Identity provider and privileged access path
• Backup and restore location
• Customer-facing systems that depend on the above
• Manual or degraded-mode workarounds

The board does not need every subnet. It needs the business blast radius.

That is the difference between technical transparency and executive noise.

The board’s job is not to approve architecture

Directors do not need to pick regions, storage tiers, encryption services, or monitoring tools.

They do need to approve the risk posture around major technology dependencies. That means asking whether management has translated the architecture into business consequences, decision rights, and recovery expectations.

A strong cloud renewal packet should make three things obvious: what changed since the last approval, what could fail together, and what management is prepared to do through degraded mode, communication, spending authority, escalation thresholds, and post-incident review.

That is not anti-cloud. It is pro-governance.

Cloud can be a powerful operating advantage for community banks and credit unions. But only if leaders stop treating it like a cleaner data center invoice and start treating it like a set of business dependencies that need adult supervision.

No offense to invoices. They have their place.

Just not as the whole story.

Discussion questions for the next board or committee packet

1. Which customer-facing and internal services now depend on our top three cloud or managed platform relationships, and what changed since the last renewal? 2. What single identity, network, support, backup, or administrative dependency could impair several services at once? 3. If that dependency failed during business hours, who has authority to move us into degraded mode, spend emergency funds, communicate with customers, and accept temporary risk?