Technology Vendor Due Diligence and Exit Testing for Banks
The Supplier Assessment That Ends When the Contract Is Signed
Most technology vendor assessments in banks follow the same arc. A questionnaire goes out, comes back completed, gets reviewed, findings are logged, a risk rating is assigned, the contract is signed, and the file goes into a repository. Three years later the vendor has changed ownership, moved its hosting, added four subcontractors, and become impossible to leave, and nobody revisited any of it.
Vendor due diligence banking technology programmes are supposed to answer two questions. Can we rely on this supplier, and can we get out if we need to. The first is answered thinly and the second is usually not tested at all.
Why does due diligence fail to protect anyone?
Because it collects assertions at a single point in time and treats collection as assurance.
The pattern is recognisable: a large questionnaire, a review that checks for completeness rather than substance, a set of findings the vendor promises to address, and no mechanism for revisiting any of it. Nothing in that process establishes that a control exists, that it operated, or that it still exists two years later. It also concentrates all the effort at the moment of least leverage for learning and the moment of most commercial pressure to proceed, since by the time due diligence runs the selection decision has usually been made.
Why does a vendor-completed questionnaire prove so little?
Because it establishes what the vendor says, and the vendor has an incentive.
A questionnaire is a reasonable starting point for structuring a conversation and a poor basis for reliance. Its answers are self-reported, frequently completed by a sales-adjacent function, and rarely qualified. The value comes entirely from what happens next: which answers are independently verified, which are corroborated by evidence, and which are accepted as claims with that status recorded. An assessment that does not distinguish verified facts from accepted assertions is presenting both to decision-makers as though they were equivalent. Broader supplier discipline sits alongside this, as covered in vendor management strategies.
What should due diligence depth depend on?
Criticality of the service, not the size of the invoice.
| Tier | Definition | Assessment depth | Reassessment |
|---|---|---|---|
| Critical | Failure materially disrupts a customer-facing service or a regulatory obligation | Full assessment, on-site or live evidence review, exit testing | Annual, plus on material change |
| Important | Failure degrades service or delays an obligation | Full questionnaire plus targeted verification of key controls | Every one to two years |
| Standard | Failure is inconvenient and workable around | Questionnaire, certification review, contract baseline | Every two to three years |
| Low | No access to data or systems, easily replaced | Baseline checks only | On renewal |
Contract value is the wrong axis and it is the one most estates use. A small monitoring tool with production access can matter more than an expensive commodity service, and a cheap library embedded in a payment path can matter most of all. Tier by what breaks if the supplier stops, which is the same mapping exercise that underpins operational resilience and impact tolerances.
Are your supplier tiers based on dependency, or on how much you pay them?
What should be verified rather than accepted?
The claims where being wrong would change the decision.
| Vendor claim | Weak evidence | Verification that means something |
|---|---|---|
| We are certified | A certificate | The report itself, its scope, its exclusions, and its findings |
| Data is encrypted | A policy statement | Configuration evidence, key custody arrangements, who can decrypt |
| We can restore in four hours | A recovery objective in a document | Their most recent test result, including what failed |
| We patch promptly | A patching policy | Current outstanding vulnerability figures and ageing |
| Access is controlled | An access policy | The list of their staff with access to your data, and how it is reviewed |
| We do not use subcontractors | An assertion | The current sub-processor list and the notification obligation in the contract |
| Your data stays in region | A regional statement | Where support, backups, and monitoring actually run from |
| We are financially stable | A brochure | Filed accounts, ownership structure, funding position |
The last row matters more than technology teams expect. A supplier's financial position is the single best predictor of a stressed exit, and it is checkable from public filings rather than from the vendor.
Why does a certification report need reading rather than collecting?
Because the scope statement and the exceptions carry the information.
An assurance report can be entirely clean and cover a different service, a different region, a different period, or exclude the components you depend on. Certification scope regularly omits exactly the part of the estate that matters, and a report with several qualified findings tells you more than a clean one with a narrow boundary. Read the scope, the period, the exclusions, the findings, and the management responses, and record which of your dependencies fall inside the boundary and which do not. The parts outside the boundary are the ones you still have to verify yourself.
Which contract terms actually matter?
Audit rights, subcontracting, exit assistance, data extraction with a format, and continuity when things are going badly.
The EBA's guidelines on outsourcing arrangements, published 4 March 2019 and applicable from 30 September 2019, define outsourcing and set criteria for assessing whether a function is critical or important, which is the determination that drives most of the contractual requirements that follow. The FSB's toolkit on third-party risk management and oversight, finalised 4 December 2023, addresses identifying critical third-party services, lifecycle risk management, and the supervision of systemic dependencies and concentration.
The terms that repeatedly prove their worth: information and audit rights that extend to material subcontractors, notification and consent for subcontracting changes, a defined exit assistance period with an obligation to cooperate, data return in a specified machine-readable format with documentation, incident notification within a defined time, and service continuity obligations that survive a dispute or a termination for cause. Accountability does not transfer with the function, which is the argument made in outsourcing without outsourcing accountability.
Why is a data extraction clause worthless without a format?
Because an obligation to return data is satisfiable in ways that leave you no better off.
A vendor can meet a bare clause with a proprietary export, an undocumented schema, no reference data, and no explanation of derived fields, and be fully compliant. Specify the format, the schema documentation, the inclusion of reference and configuration data, the medium, the timeframe, and a test right that lets you exercise extraction before you need it. The test right is the clause that converts the others from aspiration into something you can prove, and it is the one most often absent.
How do you monitor after signature?
Continuously on a few signals, periodically on the rest, and always on change.
Ongoing monitoring should track financial health, ownership change, incidents notified and unnotified, sub-processor changes, service performance against the agreement, current assurance reports, and any concentration that has developed since the assessment. The trigger-based part matters as much as the scheduled part: a change of control, a move of hosting, a material incident, or a new subcontractor should each prompt reassessment rather than wait for the annual cycle. Vendor-delivered change into your own estate needs its own evidence discipline, which is covered in audit-ready CI/CD evidence trails.
What is exit testing, and why is a plan not enough?
Exit testing is executing part of the exit for real, and a plan is a description of intentions.
Almost every critical supplier arrangement in a regulated institution has an exit plan. Very few have ever had any part of that plan executed. The distinction matters because exit plans fail on specifics that only appear on contact: the export omits configuration, the identifiers are internal to the vendor and meaningless outside it, the derived fields cannot be reproduced, the history is truncated, the volume takes far longer than assumed, or the alternative provider cannot ingest what comes out. None of that is visible in a document.
| Exit test level | What it proves | Effort |
|---|---|---|
| Extraction test | Data can be exported, in what format, how completely, how quickly | Low, run annually |
| Load and reconcile test | The export can be parsed, loaded elsewhere, and reconciled to source | Medium |
| Functional replication | An alternative can reproduce the key functions with that data | High |
| Parallel operation | The alternative runs alongside for a period on real data | Very high |
| Full simulated migration | The whole exit is rehearsed end to end | Highest, for the most critical only |
Most institutions should be running the first two annually for every critical supplier, and the third at least once for the handful where dependency is greatest. The cloud-specific version of this discipline is covered in cloud exit planning for financial services.
Why does an untested exit plan overstate readiness?
Because it records what someone believed was possible, and belief is not evidence.
An exit plan is written by people who have not attempted the exit, using information supplied by a party with no interest in making departure easy. Every untested assumption in it is a risk carried at full value while being reported as mitigated. Running even the cheapest test, a full data extraction, typically converts several assumptions into facts and produces at least one surprise, which is exactly why it is worth doing before the circumstances are adversarial.
When did you last extract your data from a critical supplier and try to load it somewhere else?
What changes in a stressed exit?
Cooperation disappears, so anything depending on vendor goodwill is unavailable.
A planned exit at contract end has notice, an assistance period, and a motivated supplier. A stressed exit follows insolvency, a serious breach, a regulatory intervention, or a sudden termination, and in that scenario the vendor's staff may have left, their systems may be degraded, and their administrator's priorities are not yours. Design the exit position so the essential steps do not require them: hold your own copies of data at a useful frequency, hold documentation of the schema, understand which functions must be replaced immediately rather than eventually, and know how long you can operate without the service at all. That last number links directly to impact tolerances and to the wider question of continuity in extreme scenarios addressed in recovery and resolution planning technology.
How do you handle concentration and downstream dependency?
Look through the supplier to what they depend on, and count exposures across the portfolio.
Two suppliers with different names running on the same infrastructure are one exposure. A dozen unrelated services all depending on a single identity provider or a single data centre region form a concentration nobody assessed, because each assessment considered one supplier at a time. Maintain a view of shared downstream dependencies across the supplier portfolio and assess them as a set, which is the analysis developed in third-party concentration risk. Selection decisions should carry this weight from the beginning, alongside the ordinary evaluation criteria set out in a technology vendor scorecard.
How should the programme be sequenced?
Tier the portfolio, fix the contracts at renewal, then start testing exits.
| Phase | Duration | Deliverable |
|---|---|---|
| Supplier inventory and criticality tiering | 1 to 2 months | Every technology supplier tiered by dependency, not spend |
| Assessment redesign | 1 month | Verification-based assessment, verified facts separated from accepted claims |
| Contract baseline | 1 month | Required terms by tier, including data format and exit test rights |
| Renewal-driven remediation | 12 to 24 months | Terms improved as contracts come up, prioritised by tier |
| Ongoing monitoring | 2 months to build | Financial, incident, sub-processor, and performance signals with triggers |
| Extraction testing | 3 months to start | Annual data extraction test for every critical supplier |
| Load and reconcile testing | 3 to 6 months | Proven ability to use what comes out |
| Concentration analysis | 2 months | Shared downstream dependencies across the portfolio |
Contract remediation is slow because leverage exists only at renewal, which is why the testing programme should not wait for it. Extraction can usually be tested under existing agreements, and a refusal is itself a finding worth recording.
Which metrics matter?
Tier coverage, verification rate, exit test recency, overdue findings, and concentration exposure.
Report the proportion of suppliers assessed at the depth their tier requires. Report the verification rate, meaning how much of each critical assessment rests on verified evidence rather than accepted assertion, since that ratio is the honest measure of assurance quality. Report exit test recency per critical supplier, with anything never tested shown as never rather than as a date in a plan. Track overdue remediation findings by supplier and by age. And report the count of services sharing a single downstream dependency, because that is the number that turns several independent-looking risks into one.
Due diligence is not a file and an exit plan is not an option. The programme is worth what it can demonstrate: which claims were verified, which were accepted, and whether anyone has ever proved that leaving is possible.
Frequently Asked Questions
Why does vendor due diligence often fail to protect anyone?
Because it is performed once before signature, based on the vendor's own answers, and produces a file rather than a set of verified facts that anyone revisits.
What does a questionnaire completed by the vendor actually prove?
That the vendor has a person who completes questionnaires. It establishes claims, not controls, and its value depends entirely on what gets independently verified.
How should due diligence depth be decided?
By the criticality of the service to customer outcomes and to the institution's ability to operate, not by contract value, which correlates poorly with dependency.
Which contract terms matter most for technology suppliers?
Audit and information rights, subcontracting notification and consent, exit assistance duration, data extraction in a specified format, and continuity of service during a stressed exit.
Why is a data extraction clause worthless without a format?
Because a vendor can satisfy a bare obligation to return data with an undocumented dump nobody can load, which meets the contract and fails the purpose.
What is exit testing, and why is a plan not enough?
Exit testing is executing part of the exit for real, such as extracting and loading data into an alternative. A written plan records intentions and reveals nothing about feasibility.
What is a stressed exit and why does it change the design?
It is an exit forced by vendor failure, insolvency, or sudden termination, where cooperation cannot be assumed, so anything depending on vendor goodwill is unavailable.
What should be measured?
Criticality coverage of assessments, verification rate versus accepted assertions, exit test recency for critical suppliers, overdue findings, and time since the last full data extraction test.
