Vendor Exit Plans: What OCC 2023-17 Requires, What Examiners Actually Test, and Where Programs Keep Failing

In October 2020, the OCC assessed a $60 million civil money penalty against Morgan Stanley Bank, N.A. and Morgan Stanley Private Bank for what became the most-studied cautionary tale in vendor lifecycle risk management. The bank had hired a moving and storage company with no data destruction experience to decommission thousands of hard drives and servers from two data center closures. The vendor sold the devices to a third party. They were auctioned online. Customer data was on them — unencrypted.

The failure wasn’t that Morgan Stanley had a third-party relationship. It’s that when the relationship ended, the bank failed to manage the exit. A nearly identical incident recurred in 2019 with different network devices, producing a pattern finding.

That’s what vendor exit planning failure looks like in enforcement: $60 million, followed by a $35 million SEC penalty for the same underlying issue.

Most TPRM programs spend their energy on onboarding due diligence and ongoing monitoring. The termination stage — Stage 5 of OCC Bulletin 2023-17’s vendor lifecycle — is where documentation is thin, testing is nonexistent, and examination findings are piling up.

TL;DR

• OCC Bulletin 2023-17 (joint with Fed SR 23-4 and FDIC FIL-29-2023) establishes a five-stage vendor lifecycle — termination is Stage 5 and carries co-equal weight with planning, due diligence, contracting, and monitoring
• For critical activity vendors, exit plans must begin in the planning stage — before vendor selection — and include identified alternatives, validated transition timelines, data return/destruction procedures, and evidence of periodic testing
• The Morgan Stanley $60M OCC penalty (2020), and 2024 enforcement actions against Evolve, Lineage, Blue Ridge, and USAA all cite inadequate third-party lifecycle management, including failure to plan for exits
• The five most common gaps that generate MRAs: no identified alternatives, untested plans, stale timelines, missing data destruction documentation, and exit planning that starts at termination rather than the planning stage
• The FDIC’s 2024 Lineage Bank consent order specifically required a formal contingency plan for orderly fintech partner termination — what starts as an MRA escalates when it remains unresolved

Where Stage 5 Gets Neglected

OCC Bulletin 2023-17 — jointly issued by the OCC, Federal Reserve, and FDIC in June 2023, replacing the prior agency-specific guidance — establishes five lifecycle stages for managing third-party relationships:

1. Planning — identifying the activity, assessing risk, developing contingency plans
2. Due diligence and selection — evaluating vendors proportionate to risk
3. Contract negotiation — establishing rights, obligations, and exit provisions
4. Ongoing monitoring — continuous oversight scaled to criticality
5. Termination — managing the exit in a way that protects the institution

The guidance gives termination co-equal weight with the other four stages. Termination isn’t an appendix. But in most TPRM programs, exit documentation gets built once (if at all), sits in a shared folder, and never gets updated or tested.

The result: when an examiner asks to review exit documentation for your core processor or primary cloud provider, you have a document that describes what you’d do — not evidence that the plan is realistic and would actually work.

As the OCC’s FY2025 Bank Supervision Operating Plan noted, third-party risk management is now an enterprise-wide supervisory priority, with examiners specifically reviewing whether risk management is applied consistently across all stages of the lifecycle. That explicitly includes termination.

What “Critical Activity” Actually Means

The interagency guidance is risk-based: the rigor of exit planning required scales with vendor criticality. What determines the level of documentation and testing is whether the vendor supports a critical activity — defined in the guidance as one where:

• Failure to meet expectations would cause significant risk to the institution
• Failure would have a significant impact on financial condition or operations

In practice: your core banking system, primary cloud infrastructure for banking operations, mortgage servicing platform, AML/transaction monitoring system, digital banking platform — these are critical activity vendors. So are fintech middleware providers if customer-facing operations route through them (see the Synapse/Evolve situation).

For critical activity vendors, the guidance requires exit planning to begin during Stage 1 — the planning stage, before the vendor is selected. The logic is practical: negotiating data portability provisions, exit rights, and termination-without-penalty clauses is dramatically easier before you’ve signed a contract than after you’re operationally dependent on the vendor.

Programs that develop exit plans after a relationship is already critical have constrained their options and created the documentation gap that examiners will eventually find.

The Five Documentation Gaps That Generate MRAs

After two years of examinations under the 2023 interagency guidance, the patterns are clear. These are the five places where exit plans consistently fail:

1. No Identified Alternatives

“We would transition to another provider” is not an exit plan. Examiners want to see: which provider? How long would the transition take? Do you have an existing relationship, or would you need to run an RFP and complete a full onboarding process?

For cloud providers, this means identifying specific multi-cloud fallback architectures or tested on-premise capabilities. For core processors, this means documenting honestly whether you’ve mapped the technical lift of migrating to a competitor platform and what that actually requires.

Exit plans that list “alternative: TBD” or “alternative: internal capability (to be developed)” signal that the plan was written to check a box, not to manage a real transition.

2. Untested Plans

The guidance expects that exit plans for critical vendors be tested periodically and that testing produces documented results. In practice, this means tabletop exercises that walk through the termination scenario, pressure-test timeline assumptions against your current vendor footprint, and generate findings.

An examiner who asks “when was this last tested?” and gets “it hasn’t been” has found an examination finding. An examiner who gets “we ran a tabletop in March 2026 and the results are in this folder” has found a program that’s working.

The USAA Federal Savings Bank cease-and-desist order (December 2024) — which replaced two prior orders from 2019 and 2022 — cited third-party risk management as among the unresolved governance failures. Persistent gaps in the same area across multiple examination cycles indicate systemic program deficiency, not isolated findings.

3. Stale Transition Timelines

Exit plan timelines are assumptions about how long a transition would take. Those assumptions age. A timeline written when your cloud footprint was 20 applications doesn’t reflect the reality of 200 applications today.

Examiners are asking: when were the transition timelines last validated against your current vendor footprint and integration complexity? For critical vendors supporting highly integrated systems, the difference between a current and a stale timeline can be the difference between a realistic plan and one that would fail on execution.

4. Missing Data Return and Destruction Documentation

The Morgan Stanley $60M penalty is the clearest illustration of what happens when data destruction at vendor exit is treated as an operational detail rather than a contractual and procedural requirement. The failure wasn’t a policy gap — it was a process failure: the exit plan didn’t adequately specify how data would be handled at decommissioning, who would verify it, or what recourse existed if the decommissioning vendor subcontracted the work without appropriate controls.

A defensible exit plan must specify:

• Contractual return provisions: the vendor must return all bank data in a usable format within a defined timeframe
• Destruction certification: the vendor must certify destruction of all copies of nonpublic information, including from subcontractors (fourth parties)
• Access revocation procedures: how system credentials, API access, and data connections are revoked after the relationship ends
• Verification mechanism: how the bank independently confirms that data return and destruction have occurred

Plans that say “data will be returned and destroyed” without the specifics have the documentation gap. The Morgan Stanley pattern finding occurred because the same process failure repeated — which is exactly the examiner escalation path for this category of deficiency.

5. Exit Planning That Starts at Termination Instead of Planning

The guidance is unambiguous: contingency plans for terminating a critical relationship should be considered during the planning stage, before vendor selection. The reason is contractual leverage — you have far more ability to negotiate data portability, notice period, and termination-without-penalty rights before signing than after you’re locked in.

Programs that don’t address exit during Stage 1 risk signing contracts with no data portability provisions, punitive early termination fees, and no requirement for the vendor to cooperate with a transition. When termination becomes necessary — whether due to vendor failure, regulatory direction, or strategic decision — those programs are managed exits on the worst possible terms.

What a Defensible Exit Plan Contains

Based on OCC 2023-17, OCC Bulletin 2024-11 (Community Bank Guide, May 2024), the 2024 Bank-Fintech Joint Statement, and NYDFS October 2025 guidance:

Cloud Provider Exit Plans Deserve Specific Attention

The cloud concentration risk post from last week covered what OCC examiners expect for AWS, Azure, and GCP dependency management. Exit planning is where that conversation gets operational.

The Financial Stability Board has identified cloud provider concentration as a systemic risk factor — a small number of hyperscalers providing critical infrastructure to most of the financial sector. For US banks, the 2023 interagency guidance applies exit planning standards to cloud providers with the same force as any other critical vendor. DORA, effective in the EU since January 2025, went further: AWS, Azure, and Google Cloud were formally designated as critical ICT third-party providers, with specific tested exit plan requirements.

What makes cloud exit plans harder than other vendor exits: multi-year migration timeframes, tight integration between application layers, data gravity effects, and the fact that some workloads may not be feasibly migrated to alternatives. Regulators understand this. What they don’t accept is a plan that acknowledges the complexity and does nothing to address it — no alternatives scoped, no partial-exit or multi-cloud strategy documented, no testing of migration capability for even representative workload samples.

The fourth-party risk framework matters here too: for cloud providers, the hyperscaler’s own subcontractors (colocation data centers, CDN providers, DNS resolution services) create dependencies that your exit plan needs to account for.

So What? The Practical Checklist

Before your next TPRM review or examination cycle, work through these:

1. Identify your critical activity vendors. Which relationships would cause significant operational or customer impact if they ended unexpectedly? Build your exit plan priority list from this inventory.

2. Pull the exit plan for your top five critical vendors. For each: Is an alternative identified? Is the transition timeline current? Is there data destruction documentation? When was it last tested?

3. Review your contracts for exit provisions. Does each critical vendor contract allow termination without penalty upon regulatory direction? Does it require data return in a usable format? Does it address subcontractor data obligations?

4. Schedule tabletop exercises. Annual for critical activity vendors; consider semi-annual for your core processor and primary cloud provider.

5. Look at your Stage 1 documentation for current vendor evaluations. Does your initial risk assessment for ongoing vendor reviews include exit contingency analysis, or does the exit section get filled in after the vendor is already selected?

6. BaaS and fintech partnership review. If you’re a sponsor bank, the 2024 Lineage, Blue Ridge, and Evolve enforcement actions are direct precedent. Do you have a documented, tested plan for orderly termination of each significant fintech partner relationship?

The vendor financial health monitoring program tells you when a vendor is deteriorating. The exit plan tells you what you do about it. Both need to exist and be connected.

The Third-Party Risk Management Kit includes a vendor exit strategy template, contract provisions checklist, and documentation framework aligned to OCC 2023-17’s termination stage requirements.