Cloud Provider Concentration Risk: What OCC Examiners Now Expect When AWS, Azure, or GCP Is Critical Infrastructure

In October 2025, AWS US-EAST-1 suffered a 15-hour DNS failure. Ten days later, Azure experienced a global identity management disruption. Between August 2024 and August 2025, the three major cloud providers together had logged more than 100 service outages. For financial institutions that had migrated critical workloads to the cloud without fully thinking through what happens when the cloud fails, those incidents were a wake-up call.

For the ones that had thought it through, it was a stress test they mostly passed.

The difference, in nearly every case, came down to whether the institution had treated its cloud provider as a critical third party under OCC Bulletin 2023-17—with documented due diligence, contract review, monitoring, and a tested exit strategy—or had treated it as infrastructure and assumed someone else managed the risk.

TL;DR

• AWS, Azure, and GCP control 62%+ of the global cloud market — three providers your bank may depend on for critical operations, directly or through vendors
• October 2025 brought major outages at both AWS and Azure within 10 days; one AWS event lasted 15 hours and affected 1,000+ companies
• OCC Bulletin 2023-17 requires banks to manage cloud providers as critical third parties, with documented due diligence, contracts, and exit strategies
• The most common examination findings: dependency mapping done after the contract, and exit strategies that exist on paper but have never been tested

What OCC Bulletin 2023-17 Actually Requires for Cloud

OCC Bulletin 2023-17 is the governing framework for national bank third-party risk management, and it explicitly covers cloud service providers. There is no carve-out for providers that are large, widely used, or whose terms are non-negotiable.

The bulletin structures third-party risk management around a lifecycle: planning, due diligence, contract negotiation, ongoing monitoring, and exit. For cloud providers that support critical banking operations, the OCC expects documentation at every stage.

For critical cloud relationships—those where failure would have significant customer impact or present safety and soundness concerns—the depth of documentation and oversight is expected to match the risk. A loan origination platform on Azure and a noncritical marketing analytics tool both live in “the cloud.” They do not require the same governance.

A May 2026 joint trade TPRM roundtable between industry groups and regulators identified the two cloud-related deficiencies examiners keep seeing: due diligence conducted after the contract is signed, and exit strategies that exist on paper but have never been tested.

The Concentration Problem Goes Beyond Your Bank

Most bank TPRM programs assess cloud risk at the institution level: does our bank have too much exposure to a single provider? That’s the right starting question. It’s not the complete one.

The Financial Stability Board has identified third-party service providers—including cloud providers—as potential single points of failure for the financial sector as a whole. An estimated 94% of enterprise services worldwide rely on at least one major cloud provider. AWS, Azure, and GCP together control more than 62% of the global cloud market.

The implication: an AWS failure isn’t just your operational risk event. It’s a simultaneous operational risk event for hundreds of other banks, clearinghouses, and financial market utilities. Credit settlement, payment processing, and market data systems may all be affected at once. The FSB’s guidance to supervisors explicitly recommends analyzing concentration of cloud providers within the banking sector—not just firm-level exposure.

The OCC Spring 2026 Semiannual Risk Perspective reinforced this concern, flagging cybersecurity and operational resilience as elevated risks for the banking sector, with specific attention to third-party technology dependencies and legacy system vulnerabilities that cloud modernization sometimes creates rather than eliminates.

Banks that have moved core processing to the cloud without full dependency mapping may have traded one category of risk for another.

Dependency Mapping: The Step Most Programs Skip

Your bank may have no direct relationship with Google Cloud Platform. But if your core banking processor’s disaster recovery environment runs on GCP—and yours does, even if you don’t know it—you have concentration exposure that isn’t captured in your vendor inventory.

This is the dependency mapping problem. OCC examiners are increasingly asking not just which cloud providers your bank uses directly, but which cloud providers your critical vendors depend on. Following that chain one level down changes the concentration picture considerably for most institutions.

A complete cloud dependency map covers three layers:

1. Direct cloud relationships: services your bank contracts for directly with AWS, Azure, GCP, or other providers
2. Vendor cloud dependencies: which cloud infrastructure do your critical third parties use for the services they provide you?
3. Sub-processor concentration: where do your vendors’ vendors host their systems?

For banks that have recently completed vendor risk assessments, layer 2 is usually documented. Layers 1 and 3 are where the gaps consistently appear. The average large bank has security-relevant dependencies on more than 4,000 third-party components, according to 2025 industry data. The cloud concentration picture that emerges from mapping three layers rarely matches what anyone expected.

What Cloud Contracts Actually Give You—And Don’t

Cloud provider contracts are offered largely on standard terms. You are probably not going to negotiate away AWS’s liability cap or get Azure to offer audit access rights that aren’t in their standard agreement. That’s a real limitation.

But reviewing a non-negotiable contract is not the same as skipping the review. The purpose of contract due diligence for large cloud providers is to document what protections exist, identify what doesn’t, and risk-accept the gaps—not pretend they’re not there.

Four provisions examiners specifically look for evidence of when reviewing cloud contracts:

Data portability. Can you retrieve your data in a usable format if the relationship ends or the provider fails? This isn’t just about contract language—it’s about whether you’ve verified that the export actually works.

Incident notification. Does the contract require the provider to notify you of security incidents within a defined window? Cloud providers have varying obligations here, and the time at which you receive formal notification can matter for your own regulatory reporting deadlines under FFIEC, CIRCIA, and state requirements.

Service change notice. Do you receive advance notice before the provider makes material changes to or discontinues services you depend on? Enterprise-tier agreements typically include this; lower-tier agreements often don’t.

Subcontractor disclosure. Does the contract identify or require notice of material changes to the provider’s own subprocessors? The fourth-party risk embedded in cloud relationships is real, and it’s your responsibility to understand it.

The October 2025 outage revealed a practical gap beyond contracts: many banks didn’t have a technical support contact at AWS or Azure who could provide real-time status above what the public status page showed. Enterprise support agreements with dedicated technical account managers—while an added cost—proved significant during a 15-hour outage when the public dashboard was lagging behind actual conditions.

Tested Exit Strategy: The Requirement Programs Consistently Miss

Most banks have written cloud exit strategies. Far fewer have tested them.

The OCC’s expectation under Bulletin 2023-17 is not just that you have a documented plan for terminating a cloud relationship—it’s that you can demonstrate the exit is actually executable. An exit strategy document sitting in a SharePoint folder is a starting point. It’s not sufficient examiner evidence.

A testable exit strategy should address:

• Migration timeline: how long does it actually take to move critical workloads off this provider? Is that timeline compatible with your BCP recovery objectives?
• Data portability verification: have you verified that your data can be exported in a usable format within the documented timeline?
• Alternative identified: is there a documented alternative—another provider, an on-premise fallback—for each critical workload?
• Test evidence: when was the last time migration capability was actually tested, and what was the result?

Banks frequently discover during exit planning that their actual migration timeline significantly exceeds what was written in the plan—particularly for large databases or workloads with complex dependencies. Finding this during an examination is painful. Finding it during an actual cloud provider failure is worse.

What the October 2025 Outages Showed About Program Maturity

Banks that managed the October 2025 AWS and Azure outages better than their peers had three things in common.

Current runbooks. When AWS US-EAST-1 failed, banks with documented, tested runbooks for cloud provider failure activated them within the first hour. Banks without them spent that time in escalation calls trying to establish who owned the response.

Incident escalation paths that reached the provider. Enterprise support agreements with dedicated technical account managers gave some banks access to real-time status information beyond the public dashboard. That information was operationally significant during a 15-hour outage.

Pre-built customer communication templates. Banks that had built notification templates as part of their cloud outage playbooks were able to update customers faster—relevant for FFIEC notification expectations on significant operational disruptions. Template drafting in the middle of an active incident introduces delay and error that pre-built templates eliminate.

If your institution was on the other side of the ledger during those outages—scrambling to figure out the scope, the owner, and the plan—those gaps need to be addressed before the next event, not after the next examination.

So What? Your Action Items

If an examiner asked to review your cloud TPRM program tomorrow, here is what they would want to see:

1. A cloud inventory with criticality ratings, mapped to the business functions they support
2. Pre-contract due diligence files for each critical cloud provider—showing risk assessment preceded contract execution
3. Contract reviews with documented exceptions and risk acceptances for identified gaps
4. Exit strategies with tested migration capability, not just documentation of the plan
5. Ongoing monitoring evidence: SLA tracking, incident review, financial health checks
6. Board or senior management reporting showing cloud concentration appears on the risk dashboard

Practitioner resources, including vendor due diligence questionnaires, contract review checklists, concentration risk mapping templates, and monitoring scorecards structured to the OCC 2023-17 lifecycle, are available in the Third-Party Risk Management Kit.

For related context on monitoring critical vendor financial health, see the post on vendor financial health monitoring under OCC 2023-17. For how the same concentration risk logic applies to AI model providers, see AI foundation model concentration risk for financial institutions. For what examiners look for in the wake of a vendor breach, see the Marquis Software ransomware breach analysis.

Sources:

• OCC Bulletin 2023-17: Third-Party Risk Management
• OCC Spring 2026 Semiannual Risk Perspective
• FSB: Third-Party Dependencies in Cloud Services
• NYDFS October 2025 Third-Party Risk Guidance
• Joint Trade TPRM Roundtable 2026