Vendor Management Begins Before The Contract Is Signed
A vendor proposal arrives with visible numbers: licensing, implementation, professional services, support, and projected savings. The financial exposure that determines strategic outcomes often stays outside the proposal entirely.
The true cost of a vendor relationship is the acquisition cost plus the dependency it creates.
Every strategic vendor therefore has two deliverables: the capability being purchased and the dependency the organization accepts to obtain it. That dependency belongs in the original investment decision. The strategic question is how much reversibility the organization gives up when that dependency is accepted.
Technology executives routinely evaluate what a vendor will cost when the relationship works. The equally important question is what the vendor will cost when the relationship fails, deteriorates, or ends on someone else’s schedule. In complex implementations, that second number exceeds the first.
Three documented cases make the argument concrete. Each illustrates a different form of dependency. Each produced consequences that could have been anticipated, priced, and mitigated before the dependency became critical.
When Outsourcing the Work Does Not Outsource the Accountability
Implementation dependency: the cost travels back to leadership regardless of where the work was delegated.
In April 2018, TSB Bank executed what it described as one of the most complex migrations in UK banking history. The project carried substantial resources: three years of planning, eighty-five specialized subcontractors, multiple board-level reviews, independent audits, and comprehensive testing frameworks. The data migration itself succeeded. The new platform failed immediately.
Branch, telephone, online, and mobile banking all experienced disruption. A significant portion of TSB’s 5.2 million customers lost access to accounts, generating 225,492 complaints over the following year. TSB’s 2018 Annual Report documents £330.2 million in post-migration charges across customer redress, fraud losses, and incremental resource and advisory costs. The bank recovered £153 million from IT provider Sabis. The FCA and PRA added £48.65 million in fines for outsourcing risk management failures. Across primary documented sources, total costs exceeded £400 million. The PRA subsequently fined TSB’s former CIO personally, concluding he had provided board assurance of supplier readiness without independently establishing the basis for that assurance.
The architectural dependency here preceded the 2018 event by years. When Sabadell acquired TSB from Lloyds Banking Group in 2015, it inherited a technology estate running on a platform it no longer owned, serving 5.2 million customers through 1.3 billion records embedded in infrastructure controlled by a former parent. The exit from that dependency required Proteo4UK to absorb 221 integrated applications, 1.3 billion records, multiple legacy languages, and decades of accumulated batch interdependencies.
The practitioner argument is precise: a supplier’s readiness declaration is evidence, and evidence stops short of executive assurance. Technology leadership has to establish an independent basis for believing a critical implementation is ready. That obligation travels across the outsourcing boundary. The questions that belong in the original program design include who independently validates readiness, what the rollback criteria are, how long the legacy environment can remain operational, and which dependencies have been tested at production scale.
The investment and migration decisions needed to account for implementation dependency, rollback capability, independent assurance, and the cost of maintaining a viable legacy alternative until migration risk materially declined.
When the Vendor Owns the Map to Your Own Data
Operational and data dependency: legal ownership of records provides little protection when another party controls the logic required to interpret them.
Synapse Financial Technologies operated as middleware: a technology bridge connecting fintech platforms with traditional banking partners. It maintained ledgers for banks and their fintech clients, managed transaction records, and handled the reconciliation mapping between consumer accounts and the underlying bank deposits. The relationship worked until Synapse filed for Chapter 11 bankruptcy in April 2024.
The bankruptcy exposed the operational dependency the relationship had created. More than 100,000 consumers lost access to over $265 million in deposits across fintech platforms including Yotta, Juno, and Mercury. Partner banks attempted to retrieve accurate customer balance records and found the task unworkable. Former FDIC Chair Jelena McWilliams, appointed as bankruptcy trustee, identified a ledger shortfall estimated at $65 million to $96 million. The CFPB confirmed the reconciliation discrepancy was traceable to at least September 2023, meaning the dependency had been accumulating risk long before the bankruptcy filing. The CFPB put the shortfall at $60 million to $90 million, allocated $46.2 million from its Civil Penalty Fund in November 2025 to reimburse affected consumers, and confirmed that many still had not been made whole.
The dependency Synapse’s partners had accepted without fully pricing was operational intelligibility, not data access. Data portability requires operational portability. The fintech companies and banking partners legally retained rights to their data. What they could not do without Synapse was interpret it, reconcile it, and operate on it. An exported database has limited value when the organization lacks the schemas, reconciliation logic, business rules, mappings, and institutional knowledge required to use it. The vendor had become a critical source of the logic required to explain and reconcile transactions across the ecosystem. That created a material business dependency regardless of what the contracts stated about data ownership.
Technology leaders have to draw this distinction clearly before approving any platform that mediates between the organization and its operational records. Data ownership has limited strategic value without data intelligibility, reconciliation portability, and independent operational usability. The questions that belong in the original commitment include who holds the authoritative system of record, how the organization independently interprets its own transaction data, what reconciliation responsibilities transfer with termination, and what the operating model looks like if the vendor becomes unavailable.
The business case needed to price operational dependency on Synapse’s ledger, reconciliation logic, and continued cooperation, including what reconstructing those capabilities independently would cost.
When Redundancy and Independence Are Not the Same Thing
Architectural dependency: redundancy only protects against failure domains the architecture actually separates.
Australian pension fund UniSuper managed approximately $135 billion Australian dollars for 647,000 members. Its technology architecture included redundancy across two geographic locations, a configuration designed to protect against outages and data loss. In May 2024, an inadvertent misconfiguration during provisioning by Google Cloud operators resulted in the deletion of UniSuper’s Private Cloud subscription. The deletion affected both geographic locations simultaneously. In a joint statement, UniSuper CEO Peter Chun and Google Cloud CEO Thomas Kurian confirmed the sequence: duplication across two geographies existed as protection, yet when the subscription deletion occurred, it caused deletion across both. Two weeks of member-facing disruption followed.
The architectural lesson has nothing to do with frequency. Google described the event as an isolated, one-of-a-kind occurrence. That framing is accurate and beside the point. The strategic question is what the redundancy actually protected against.
UniSuper’s two geographies were independent at the infrastructure layer. They shared a higher-level dependency within the same Google Cloud Private Cloud subscription. The deletion therefore operated above the geographic redundancy and affected both locations simultaneously. The geographic redundancy provided genuine protection against hardware failure, regional outage, and localized data loss. It provided no protection against failure modes that originated above the layer it addressed.
What made recovery possible was a prior investment in backups held by an independent third-party provider, outside the Google control plane entirely. The joint statement confirms those backups minimized data loss and significantly improved restoration speed. The architectural decision that ultimately mattered most had been made before the incident.
Reversibility is the strategic property at stake. UniSuper’s geographic redundancy was real. Its vendor independence was not. Technology executives who treat geographic redundancy as equivalent to vendor independence have accepted a concentration risk without pricing it. The test is not whether the architecture includes redundancy. The test is which failures the redundancy actually survives.
The business case needed to identify which failure domains remained concentrated inside Google Cloud and what genuinely independent recovery capability would cost.
The Four-Cost Vendor Model
This is the practical center of the argument. Every material vendor commitment should carry four financial numbers, not two.
Entry cost covers licensing, implementation, integration, and internal labor.
Run cost covers recurring fees, support, infrastructure, and vendor management.
Failure cost includes expected business interruption, emergency remediation, regulatory exposure, and replacement resources under time pressure.
Exit cost includes data extraction, migration engineering, parallel operation, contract termination penalties, redevelopment, retraining, and stranded investment.
Procurement normally has visibility into the first two. Technology leadership needs visibility into all four. A vendor charging eight million dollars with a credible three-million-dollar exit path may represent less strategic exposure than a six-million-dollar vendor whose replacement requires twenty million dollars and two years. That comparison belongs in the original business case.
The four costs need a fifth input alongside them: the dependency profile. Before commitment, leadership should document which critical capabilities, data, integrations, people, and downstream programs will depend on this vendor. That profile determines how the four costs are likely to move over time.
Reversibility is the strategic property connecting all five inputs, and it almost always declines after implementation begins. Integrations multiply, proprietary interfaces spread, internal expertise shifts toward the vendor’s tooling, and downstream programs inherit the vendor’s data model. The dependency that costs three million dollars to exit at signing may cost twenty million in year four. Reversibility is cheapest to design before commitment and most expensive to discover during a failure.
The portfolio dimension compounds this further. Program B gets designed around Vendor A. Program C consumes Vendor A’s proprietary APIs. Program D assumes Vendor A’s data model. Three years later, replacing Vendor A requires changing four programs, and the reversibility that existed at selection has been systematically spent. Making the dependency profile and exit cost part of the original investment decision is how technology leadership maintains strategic optionality across the portfolio.
Make Dependency a Gate, Not a Footnote
Every material technology investment should pass a pre-commitment vendor dependency review. Senior technology leaders should require five documented answers before approval.
Dependency. Which critical capabilities, data, integrations, people, and programs will depend on this vendor after implementation?
Failure. What happens operationally if the vendor becomes unavailable, deteriorates significantly, or exits the market?
Recovery. Can the organization recover without the vendor’s active cooperation, and how long would that take?
Exit. What would an orderly migration cost today, and which factors are likely to increase that cost as the relationship matures?
Ownership. Which executive owns the dependency after the procurement process ends?
That last question matters as much as the first four. Vendor dependencies that lack a named owner after contract signature tend to accumulate without governance until a business event forces the organization to price them under pressure.
The review should end with one of four decisions: accept the dependency, mitigate it before implementation, require contractual or architectural safeguards, or select another solution. Documentation without a decision is not governance.
Material dependencies should return to review when contract renewal approaches, architecture materially changes, acquisitions alter vendor strategy, financial viability deteriorates, or downstream programs materially increase switching costs. The governance lifecycle is: identify, quantify, decide, monitor, reassess.
Before approving a material technology vendor relationship, leadership should know what the relationship costs when it succeeds and what it costs when it fails, deteriorates, or must be exited. Put entry cost, run cost, failure cost, exit cost, and the dependency profile in the business case. Review them again when the architecture changes, when the vendor’s condition changes, or when downstream programs deepen the dependency.
The leadership obligation across TSB, Synapse, and UniSuper is identical: understand the dependency being purchased alongside the capability, price it before commitment, and govern it for as long as the relationship continues.
Vendor management begins before the contract is signed because that is when the organization has maximum leverage to design reversibility, preserve alternatives, price failure and exit, and decide whether the dependency is worth purchasing. After implementation, every integration, workflow, skill shift, and downstream program can make that decision progressively more expensive to reverse.
Nabeil Sarhan, MBA, is a dynamic technology delivery manager with over 15 years of experience in tech, cybersecurity, and computing scalability. He excels in leading diverse teams and delivering enterprise-class systems across industries such as healthcare, finance, and retail. Nabeil’s passion for solution design, systems architecture, and performance optimization makes him a sought-after consultant. He holds degrees from Harvard, MIT, and Bryant University. Connect with Nabeil on LinkedIn