Vendor Management Operating Guide

Position

A credit union with a modular technology stack delivers member outcomes through vendors it does not control. Regulators, members and the board hold the credit union accountable for those outcomes anyway. Vendor management is the operating system that closes that gap: it decides who gets in, on what terms, who is accountable once they are in, and when they leave.

This guide sets out one operating model for that system. It converts a three-step sourcing process (RFI, RFP, RFQ) into a seven-stage lifecycle with named owners and control gates, scales oversight to vendor criticality, and extends the model to AI and automation vendors, where model behavior, data use and change control add risk that traditional vendor reviews do not cover.

Operating Principles

• The vendor delivers; the credit union owns the outcome. Every vendor has one named business owner accountable for results, spend and risk.
• Tier drives oversight, not the buy decision. Due diligence depth and review frequency follow criticality, data sensitivity and member impact.
• Modules are replaceable by design. Open interfaces, data portability and tested exit plans are contract requirements, not afterthoughts.
• Independent challenge is built in. Risk, compliance, legal and information security approve at defined gates; they do not rubber-stamp after the fact.
• One system of record. Inventory, contracts, tiers, scorecards, evidence and issues live in one place. No gate decision exists unless it is logged.

The Vendor Lifecycle

Figure 1 shows the seven stages. Each stage has a required output, one accountable owner and a gate that must be passed before the next stage starts. Two feedback loops keep the model live: material change or incident triggers re-tiering and renewed diligence, and every renewal or exit decision feeds the next sourcing decision.

Selecting the Right Sourcing Path (Stages 2 and 3)

Selection Standards

• Sign an NDA before sharing any member, system or security information.
• Route all vendor questions through the vendor management office. Log every question and answer, and distribute answers to all participating vendors at the same time.
• Score every vendor against one pre-approved rubric, with evaluators scoring independently before any consensus session.
• Verify before you trust. Complete reference checks, financial stability review, market reputation review and a roadmap viability assessment on every finalist.
• Require evidence, not assertions. Current SOC 2 Type II or equivalent, penetration test summary, business continuity test results, insurance certificates and regulatory exam history where available.
• Document the decision. A selection report with scoring, rationale, risk acceptance and approvals is the audit trail and the basis for contract negotiation.

Vendor Management in a Modular Stack

Credit unions that have moved away from single-vendor stacks assemble best-of-breed modules (channels, core and payments, lending, data and integration, AI and automation, security) around an open integration layer, often with partners and credit union service organizations (CUSOs) supplying parts of the stack. The benefits are speed, choice and leverage. The cost is more relationships, more interfaces and more places for accountability to blur. Figure 2 shows how the model keeps ownership clear.

Module Rules

• One owner per module. A single business owner is accountable for each module's outcomes, even when several vendors contribute to it.
• Own the interfaces. Document APIs, data flows and data ownership. The credit union, not the vendor, holds the data dictionary and integration standards.
• Contract for exit on day one. Data return in usable formats, transition assistance, escrow where warranted, and a tested exit plan for every Tier 1 vendor.
• Manage concentration. Track how many critical functions depend on one vendor or one shared subcontractor, and set a limit that triggers a mitigation plan.
• Review the roadmap annually. Confirm each vendor's product direction still fits the credit union's strategy and the architecture target state.

Risk Tiers

Accountability Model

Accountability is assigned by decision, not by department. The matrix below shows who is accountable (A), responsible (R), consulted (C) or informed (I) for each lifecycle activity. Each row has exactly one A.

The AI and automation function acts as subject matter expert and governance partner on technology evaluation: it provides technical guidance, coordinates vendors and enforces AI standards, while the business owner remains accountable for the outcome the vendor delivers.

Vendor Review and Performance

Reviews are scheduled by tier and triggered by events. Each review uses the same scorecard so vendors can be compared across modules and over time.

Weights are a starting point; adjust by module and record the change.

Review Triggers and Escalation

• Event triggers: security incident, SLA breach in two consecutive periods, adverse audit finding, vendor merger or acquisition, change of key subcontractor, material model or product change, regulatory change.
• Escalation path: business owner and vendor account lead, then vendor management office and independent challenge, then governance committee. Each step carries a time limit and a required remediation plan with dates.
• Outcomes: continue, continue with remediation, restrict scope, re-bid, or exit. The decision, owner and date are logged.

AI and Automation Vendors

AI vendors follow the same lifecycle with additional controls, because the product can change behavior without a software release, and member or team member data can flow into models. Two delivery models need different handling: buy (the credit union configures and operates a vendor product) and partner-deliver (the vendor builds, hosts or runs the capability for the credit union). Partner-deliver carries more risk transfer questions and needs stronger contract terms and monitoring.

Additional Diligence and Contract Requirements

• Data use. No training on credit union or member data without written approval. Define retention, deletion, residency and subprocessor disclosure.
• Transparency. Documented model purpose, limitations, data sources and testing. Explainability sufficient for the decision it supports.
• Testing and monitoring. Pre-deployment testing for accuracy, bias and security (including prompt injection for generative AI), with agreed performance thresholds and ongoing monitoring.
• Human oversight. Defined points where a person reviews or can override output, especially for member-affecting decisions.
• Change control. Advance notice of material model, version or data changes, with the right to re-test before adoption.
• Incident and exit. Notification windows aligned to the credit union's incident response and regulatory reporting duties; documented model, data and prompt portability on exit.
• Approved platform use. Enterprise assistants and generative AI tools are used under enterprise terms only, with an approved-use policy and monitoring for unapproved tools.

Alignment to the NIST AI Risk Management Framework

Regulatory Anchors

Examiners expect a vendor management policy covering planning, due diligence and ongoing controls, applied in proportion to risk. Core references: NCUA Letters to Credit Unions 07-CU-13 (Evaluating Third Party Relationships), 08-CU-09 (Evaluating Third Party Relationships Questionnaire) and 01-CU-20 (Due Diligence Over Third Party Service Providers); NCUA 12 CFR Part 748 (security program and cyber incident reporting); GLBA safeguards requirements; the NIST AI Risk Management Framework and its generative AI profile; and model risk management principles for any vendor model used in decisioning. Confirm current guidance with compliance and legal before adopting this model.

Program KPIs

Standing the Program Up: First 90 Days