Vendor Offboarding Compliance: The Exit Process Most Financial Institutions Get Wrong

TL;DR

• Morgan Stanley’s $60M OCC fine in 2020 traces directly to a vendor decommissioning failure — customer data ended up on hardware sold to third parties
• The 2023 interagency guidance (OCC Bulletin 2023-17) requires financial institutions to plan vendor exits at onboarding, not at departure — exit strategy belongs in the contract
• GLBA Safeguards Rule requires documented data destruction with certification; “we told them to delete it” is not sufficient
• Most TPRM programs invest in onboarding due diligence and underinvest in offboarding — examiners know this, and they ask about it
• The checklist: access revocation, data return/destruction, documentation, post-offboarding confirmation, and retained records

Here’s how vendor offboarding works at most financial institutions: a business line decides to terminate a vendor. Legal sends a termination notice. IT disables the accounts they know about. Procurement reconciles the final invoice. Six months later, an examiner asks for the data destruction certificate from the terminated vendor’s environment. Nobody can find it.

The Morgan Stanley version of this story cost $60 million.

The Case That Changed the Conversation

In October 2020, the OCC assessed a $60 million civil money penalty against Morgan Stanley for “significant gaps in its vendor risk management program.” The failure wasn’t at onboarding — it was at decommissioning.

Morgan Stanley retained third-party vendors to decommission data center equipment in 2016 and 2019. The vendors were supposed to destroy or encrypt devices containing customer information. Instead, equipment with unencrypted data was sold on the secondary market. A company that purchased the hardware found the customer data and notified Morgan Stanley.

The OCC’s findings identified three specific failures:

1. Morgan Stanley failed to assess the vendors’ technical capabilities and information security controls before hiring them
2. Morgan Stanley failed to adequately oversee the vendors during decommissioning
3. The same control failures recurred in 2019 — three years after the first incident

The third finding is the one that matters most for TPRM programs. Morgan Stanley didn’t just fail to vet the vendors. They failed again with the same control gap. Offboarding failures compound because the institutional memory that would prevent recurrence lives inside the documentation that was never created in the first place.

What the 2023 Interagency Guidance Actually Requires

The June 2023 interagency guidance on third-party relationships (OCC Bulletin 2023-17, FDIC FIL-23-029, Federal Reserve SR 23-04) covers the full vendor lifecycle. Most TPRM teams focus on onboarding and due diligence. The termination section is shorter — and more precise about what regulators expect.

The guidance requires banking organizations to maintain “documented policies and procedures for terminating third-party relationships in a manner that ensures a strategic and efficient transition.” Three requirements stand out:

Offboarding planning starts at onboarding. The guidance explicitly states that exit strategies should be developed “prior to entering into the arrangement or shortly thereafter” — not when a termination notice is issued. The vendor contract should contain enforceable termination provisions: notice periods, data return and destruction obligations, transition assistance requirements, and the financial institution’s rights during wind-down.

Data controls get special attention. The guidance requires “special care placed on data controls and system access” during termination. This means documented access revocation, evidence of data destruction or return, and confirmation that all credentials, API keys, and system integrations have been disabled.

The institution remains responsible. Whether the vendor exit is cooperative or contentious, the financial institution owns the risk throughout. Management must “assess and document potential risks during termination, including legal, operational, and compliance risks” — regardless of how the vendor behaves during wind-down.

The May 2024 OCC guide for community banks adds specificity for smaller institutions. Exit planning requirements scale proportionally to vendor criticality, but the core obligation doesn’t disappear because the bank has 40 vendors rather than 400.

GLBA Safeguards Rule: The Data Destruction Standard Nobody Reads Carefully Enough

The FTC Safeguards Rule — which implements GLBA’s security requirements for non-bank financial institutions — sets specific standards for disposal of customer information that apply directly to vendor terminations.

The required standard is secure disposal that renders customer information “unreadable or indecipherable.” In practice:

• Paper records: cross-cut shredding, incineration, or equivalent secure destruction
• Electronic records: cryptographic erasure, physical destruction, or certified wiping meeting NIST SP 800-88 revision 2 standards (“Purge” or “Destroy” level, not just “Clear”)

“Deleting” files doesn’t satisfy the requirement. Neither does “formatting” a drive. The standard requires that the data cannot be reconstructed from what remains.

For vendor terminations, this means:

1. The vendor contract must specify the destruction standard the vendor is obligated to meet
2. The vendor must provide a written certificate of destruction documenting what data was destroyed, the method used, and when
3. You need to retain that documentation — FTC’s breach notification rule, effective May 13, 2024, creates added incentive to have clean records on disposal practices

For cloud vendors, the destruction obligation is more complex because you lack physical hardware access. The vendor contract should specify: cryptographic erasure standards (meeting NIST SP 800-88 r2), the timeline for deletion after contract termination, a certificate identifying the specific datasets deleted, and your audit rights to verify completion.

The Basel Committee’s December 2025 update to its third-party risk management principles emphasizes data portability and certified destruction as foundational exit strategy requirements. This is a global standard solidifying, not a US regulatory quirk.

The Access Revocation Gap

In Morgan Stanley’s case, the failure was with physical hardware. In most vendor terminations, the failure is with digital access — specifically, all the access points that accumulate during a vendor relationship and don’t get documented until someone tries to revoke them.

Access points that routinely get missed:

Service accounts. Backend credentials used for automated integrations that aren’t tied to individual employees and may not appear in your standard user access review. If the vendor provisioned a service account during implementation, that account exists independently of any person who left the vendor.

API keys. Particularly for SaaS integrations where keys were generated by the vendor and stored in their systems rather than yours. Deleting the API key from your configuration isn’t sufficient if the vendor’s system still has a copy and your firewall still allows their IP ranges.

SSO federation. If the vendor was connected via SAML or OAuth, the trust relationship — including metadata, certificates, and federation configuration — needs to be explicitly revoked, not just the user accounts provisioned through it.

VPN certificates and IP allowances. Remote access credentials provisioned separately from standard identity management. These often live in network team configurations that the vendor access review process never touches.

Shared secrets and symmetric keys. Payment integrations, webhook configurations, and data exchange agreements that rely on pre-shared keys rather than certificate-based authentication. These keys may have been exchanged years ago and never rotated.

A complete offboarding process requires documenting all integration types at onboarding, maintaining that record in the vendor file throughout the relationship, and including a per-item revocation confirmation in the termination checklist.

What Defensible Offboarding Documentation Looks Like

Examiners evaluating vendor offboarding want a paper trail through each phase. Here’s what a complete file should contain:

Pre-termination:

• Termination decision memo with date, basis (contract expiration, breach, strategic decision), and notice period
• Data inventory review identifying all customer information in the vendor’s custody
• Written exit plan with transition timeline, responsibility assignments, and decision points
• Internal communication to relevant stakeholders (IT, Legal, Risk, Compliance, affected business lines)

During termination:

• System access revocation log — per item, with timestamp and confirmation that access was tested as disabled
• Written instruction to vendor on data return or destruction, including the standard required and the deadline
• Transition assistance documentation (if services are transferring to a replacement vendor)
• Status communications to senior management or risk committee if the termination involves a critical vendor

Post-termination:

• Vendor’s certificate of destruction (or confirmation and documentation of data return)
• For critical vendors: independent verification, attestation, or follow-up audit of destruction
• Post-offboarding confirmation review — a structured check 30-60 days after termination confirming access is still revoked and all documentation has been received
• Final vendor record updated and archived with exit documentation attached

Retention: the interagency guidance and OCC examination standards, combined with GLBA documentation requirements and potential regulatory inquiry timelines, make five years a reasonable minimum. For critical vendors involved in regulatory-material services, retain indefinitely or until the examination cycle confirms the records are no longer needed.

When to Notify Regulators

Most vendor terminations are internal matters. But certain situations require at minimum a documented assessment of whether notification was required:

Regulatory-material service providers. If you’re terminating a vendor that provides BSA/AML transaction monitoring, OFAC screening, or another service directly tied to a regulatory obligation, document how the service will be maintained or transitioned and whether the agency overseeing that obligation needs to be informed.

Forced terminations with operational impact. If a vendor filed for bankruptcy, experienced a breach, or was terminated for material breach in a way that caused operational disruption, assess whether that disruption crosses the FFIEC 36-hour notification threshold. Document the assessment even if the answer is no.

BaaS and custodial relationships. The FDIC’s post-Synapse rulemaking created specific expectations around vendor transition planning for sponsor banks. The BaaS vendor exit planning requirements after Synapse covers the FDIC-specific framework for those relationships.

The Most Common Offboarding Failure Patterns

Based on OCC exam findings, the Morgan Stanley enforcement action, and the interagency guidance’s explicit emphasis on termination controls, the most common failure patterns are:

No exit plan until termination is imminent. The vendor contract has no enforceable exit provisions. Terms of wind-down are negotiated on the fly, after the business relationship has already deteriorated.

Data destruction is assumed, not verified. The institution tells the vendor to delete the data. The vendor says they did. No certificate exists, no attestation, no verification. The data may or may not have actually been destroyed.

Access revocation is incomplete. Human user accounts get disabled. Service accounts, API keys, and webhook integrations are still live.

No post-offboarding confirmation review. The process closes when the last invoice clears. Nobody returns 30-60 days later to verify that all items on the exit checklist were completed and documentation has been received.

Records aren’t retained. Vendor files get archived or deleted once the relationship ends. An examiner asking two years later for evidence of how a critical vendor was terminated has nothing to look at.

So What?

Vendor offboarding is the component of TPRM that most programs treat as administrative. It’s also the component that generates enforcement actions.

The interagency guidance placed offboarding on the same footing as onboarding due diligence, contract review, and ongoing monitoring. That’s not accidental — regulators know that TPRM programs frontload rigor at vendor selection and let it trail off at vendor exit. That’s exactly where they look.

The fix isn’t structurally complex. It’s a documented exit plan in the contract, a complete access inventory at onboarding, a destruction certification as a required deliverable, and a 30-day post-offboarding confirmation review. What makes it hard is building those habits before the vendor relationship becomes contentious, before the business is in a hurry, and before the data is already somewhere it shouldn’t be.

Morgan Stanley paid $60 million to learn this. Your TPRM program doesn’t need the same lesson.

For a complete vendor offboarding checklist, exit plan template, and full TPRM lifecycle documentation — including due diligence questionnaire, risk tiering methodology, and ongoing monitoring templates — see the Third-Party Risk Management (TPRM) Kit.

Further reading:

• Vendor Risk Management: The Complete Process from Onboarding to Offboarding
• Cloud Concentration Risk: When Your Hyperscaler Dependency Becomes a Regulatory Problem
• Vendor Due Diligence Techniques: What to Verify When the Questionnaire Comes Back