Third-party risk management covers the risks arising from an organisation’s continuing business arrangements and from their termination. For prototype programmes in regulated institutions it is the review that actually determines whether work proceeds, and it engages earlier than teams expect.
The arrangement exists before the contract does
The 2023 US interagency guidance addresses supervised banking organisations and frames business arrangements as capable of existing without a contract and without payment.
That sentence disposes of the most common assumption in prototype work. A vendor running an unpaid proof of concept against institutional data, on the vendor’s infrastructure, is in a business arrangement. Nothing about the pilot being free, short, or exploratory removes it from the framing, and using a third party does not diminish the institution’s underlying responsibilities.
Two qualifications belong with that. The guidance states it has no force and effect of law and imposes no new requirements. And it calls for risk-tailored management, so the depth of review scales with the arrangement — a low-risk supplier does not receive the examination a critical service gets. Neither qualification makes the arrangement invisible.
The dependencies underneath
Scope extends past the counterparty you signed with. The guidance addresses reliance on subcontractors, the third party’s own oversight of them, and relevant geographic and concentration risks, with monitoring running throughout the relationship at an intensity that adapts to changing circumstances.
For an AI prototype the subcontractor chain is the substance of the system. A vendor builds the application, hosts it on one cloud provider, calls a model from a second, and retrieves from an index built on a third. The institution’s exposure runs through all of them, and the prime vendor’s own oversight of those providers is part of what gets assessed.
What survives the ending
The termination discussion covers moving an activity in house or to another provider, and considers transition capability, the time required, fees, jointly held intellectual property, and data and access risks. It also contemplates control concerns requiring management and monitoring after the relationship has ended.
That last point is the one prototype transfers get wrong. Take an institution that accepts the code and begins operating the application itself, while the original vendor still hosts the logs, retains an administrator account, and purchases the model API on the institution’s behalf. Repository acceptance did not end the business relationship. It ended one part of it and left three dependencies unassigned.
The register that resolves this classifies each dependency as continuing, reassigned, replaced, or terminated — and only once the supporting facts exist. Technical control of the code and continued vendor access are separate fields, because they move independently.
Which regime, before which checklist
The institution’s charter determines the applicable guidance, and the commercial label does not.
NCUA’s 07-CU-13, with supervisory letter SL 07-01, is addressed to federally insured credit unions and describes planning, due diligence, and monitoring proportionate to complexity and risk, with lighter methods available for less complex arrangements and institutional responsibility continuing when functions are outsourced. NCUA’s AI material states that it has not issued AI-specific regulations while explaining that existing technology-neutral regulations apply, and that examiners review controls, compliance, monitoring, and vendor diligence.
OSFI’s Guideline B-10 states a different scope: federally regulated financial institutions in Canada, including specified foreign branches, with accountability retained by the institution and expectations scaled to risk and criticality.
Two customers both described as credit unions can therefore sit under entirely different authorities, and copying one checklist onto the other skips the step that matters.
Reading the assurance you are handed
A SOC 2 report is a report on a service organisation’s controls relevant to specified trust services criteria. A Type 2 report contains a system description, a management assertion, the service auditor’s report, and the tests performed together with their results. Those particulars are what the review consumes.
Prior assessments can be reused. The recognised method is to check credibility and applicability to current conditions, record the original date and type, and supplement the gaps — taking account of changed conditions, elapsed time, and required assessor independence. Inherited controls still require verification that this system actually uses them, and system-specific portions require their own assessment.
Penetration testing sits in the same frame: an assessment conducted under specified attacker assumptions and engagement rules at a particular time. It is worth doing before authorisation and after relevant environmental changes, and it uncovers weaknesses rather than establishing their absence.
The rule
What stays fixed is that the institution’s responsibility does not transfer with the activity. What changes is the depth of review, which follows the risk of the specific arrangement rather than a uniform standard applied to every supplier.
Where programmes get caught
The free pilot is treated as outside the process. No invoice, no contract, no review — and then institutional data is already on vendor infrastructure when someone asks the question.
One diligence report is treated as continuing oversight. The guidance describes monitoring throughout the relationship. A report obtained at selection answers a question about that date.
Transfer is read as vendor exit. Covered above, and the reason the closeout register exists. A checklist cannot create rights the parties never agreed, so the exit terms have to be in the contract before they are needed.
Not to be confused with
Model risk management. Different scope, different trigger, and under current Federal Reserve guidance generative and agentic AI sit outside it. Third-party risk has no such carve-out.
A legal conclusion. Which supervisor applies, what the executed contracts say about assignment, support, access, data, intellectual property, and survival, and which downstream providers remain after handover are facts about the specific institution and deal.