What Good Looks Like: An FFIEC-Grade Vendor Risk Management Program (The CFO Governance View)

Why Vendor Risk Is Now a Finance-and-Governance Question, Not a Procurement One

A community bank CFO who walks into a vendor risk conversation is rarely framed as a finance question. It arrives as a procurement issue (we are selecting a new vendor), a contract issue (we are renewing a major agreement), or a compliance issue (we have a vendor risk gap in the recent exam). The CFO signs the budget, the contract, or the remediation plan, and the question is treated as resolved.

The 2023 Interagency Guidance on Third-Party Relationships, the FFIEC IT Examination Handbook, and the recent enforcement record have collectively turned vendor risk into a finance-and-governance issue with implications that flow directly to the bank's books. Vendor failures show up as operational losses. Vendor breaches show up as regulatory exposure. Vendor concentration shows up as enterprise risk. The CFO whose program is sized only to sign contracts is not running the program the regulator expects.

That is the conversation worth having before the next exam asks the question for the bank.

The Five Functions a Vendor Risk Program Must Operate to Be Defensible

A vendor risk management program that holds up under FFIEC examination operates across five recognizable functions. Each is fundable, measurable, and produces evidence the regulator examines. Each is something a CFO should be able to describe and benchmark against peers.

The first function is tiering and inventory. The bank maintains a current inventory of every third-party relationship that touches consumer information or critical operations. Each relationship is tiered by risk: critical, high, medium, low. The inventory is reviewed quarterly at minimum, with new relationships triaged at onboarding and existing relationships re-tiered as their scope changes. A bank that cannot produce its tiered inventory cannot demonstrate the program operates, regardless of what else it does.

The second function is risk-proportional due diligence. New vendors and renewals trigger due diligence scaled to the vendor's tier. Critical vendors receive deep diligence including independent audit reports, financial review, control evidence, and reference checks. Lower-tier vendors receive proportionally lighter review. The discipline is that the diligence happens before the contract is signed, the results are documented, and the residual risks are visible in writing. Banks where diligence happens after the fact, or where the documentation lives only in email threads, fail this function.

The third function is contract terms that flow safeguards downstream. The bank's vendor contracts include specific HIPAA-equivalent terms (where applicable), GLBA Safeguards Rule terms, audit rights, breach notification timelines, sub-processor flow-down, termination terms, and the bank's right to require remediation. The terms are not boilerplate. They reflect the vendor's tier and the specific risks identified in due diligence. Banks where vendor contracts default to vendor-favorable templates, with no bank-specific safeguards added, are operating without contract-level controls.

The fourth function is ongoing monitoring tied to vendor criticality. The bank reviews each vendor on a cadence proportional to its tier. Critical vendors receive at least annual deep review including current audit reports, incident history, financial posture, and control evidence. Lower-tier vendors receive lighter periodic review. The output of monitoring is documented, and material changes (financial deterioration, control failures, incident reports, ownership changes) trigger immediate review regardless of cycle. Banks where vendor relationships persist for years without recurring review are running an inventory, not a program.

The fifth function is termination discipline. When a vendor relationship ends (planned termination, breach-driven termination, vendor failure), the bank executes a documented offboarding sequence. Access is revoked on the planned date, data is returned or destroyed per contract terms, the vendor's offboarding evidence is collected, and the bank's records are updated. Banks where offboarding is informal, where former vendors retain access weeks after termination, or where data return is not verified, are operating without exit controls.

A program that operates all five functions, with documentation and evidence at each step, is what good looks like. A program missing any of the five is what regulators cite.

What the Regulator Means by Evidence — And How to Produce It

The word "evidence" appears repeatedly in regulator guidance, and its meaning is precise. Evidence is documentation that an independent reviewer can inspect, verify, and rely on as proof that the function operated.

For vendor risk, evidence takes recognizable forms. The tiered inventory itself, with versioning and change history. Due diligence files for each material vendor, with dates and named reviewers. Contract repositories with signed agreements and amendments. Monitoring records showing reviews completed on schedule. Incident records showing the bank's response to vendor-side events. Termination records for departed vendors with offboarding artifacts attached.

A CFO sizing the program should be able to ask the program owner to produce evidence for any vendor in any tier and receive the documentation within a defensible timeframe. If the request takes weeks, the program is not operating at the cadence the regulator expects. If the request cannot be filled at all, the regulator's likely conclusion is that the function did not operate.

What a Defensible Vendor Risk Program Actually Costs to Run

The annual cost of running a defensible vendor risk management program at a community bank scales with the size of the vendor population, the proportion of critical vendors, and the bank's own complexity. The components are recognizable and benchmarkable.

The program needs an owner. This is a named role, internal or fractional, accountable for the program's operation. The owner does not need to perform every function personally, but the accountability is named and reports to the governing body.

The program needs tooling or a managed equivalent. Most community banks operate the program through a combination of internal documentation discipline and an external partner who handles vendor outreach, due diligence collection, monitoring cadence, and reporting. The cost of the partner scales with the vendor population.

The program needs review time. The board or its appropriate committee receives reporting on at least an annual basis, with quarterly briefings on critical-vendor changes. The CFO's calendar accommodates the review.

The program needs ongoing investment in vendor relationships themselves. Critical vendor renewals receive negotiation effort. Vendor incidents receive response. Vendor terminations receive offboarding work.

The total annual investment in a defensible program is meaningfully higher than the cost most community banks budget for vendor management as a contracting function. It is also meaningfully lower than the cost of a single vendor-related incident at a bank without the program.

Why "IT and Procurement Handle It" Leaves the CFO Exposed

A community bank CFO will hear, somewhere in the budget conversation, this argument: vendor risk is the responsibility of the IT and procurement functions, the program operates inside their workstreams, and the finance function does not need a separate line item for it.

That is a false choice, and recent enforcement has made it expensive to keep believing in. Vendor risk is not a procurement function. It is a governance function with financial implications, and the regulator examines it as a governance function. The CFO who treats the program as IT or procurement overhead is not seeing the program the way the regulator does, and the gap shows up at the next exam.

The right framing is not whether the program lives inside finance. It is whether the CFO is sized into the program's governance, the budget reflects the program's full cost, and the board sees the program's output through the CFO's lens. The first framing produces a fragmented program that satisfies no one. The second framing produces a program the regulator recognizes and the bank can defend.

The Program Assessment That Closes the Vendor Risk Gap

A community bank should walk through a vendor risk program assessment that maps the bank's current state against the five functions, identifies the documentation gaps, sizes the cost of closing them, and produces a one-page status document the CFO can take to the board. The exercise typically runs in a few weeks for a typical community bank, and it produces three deliverables: the gap inventory, the remediation budget, and the recurring operating budget the program requires going forward.

Banks that complete the assessment and fund the resulting program describe the next exam as recognizably different. The vendor risk findings disappear, the program output is in the room when the examiner asks, and the discussion shifts from "what are you doing about vendor risk" to "let's review the program's most recent reports."

That is the difference between a vendor risk function the bank operates and a vendor risk gap the regulator catches.

Fund the Governance Function, Not Just the Contract Process

A community bank CFO sizing the vendor risk management program is not signing off on a procurement budget line. The CFO is funding a governance function with financial, regulatory, and operational implications that the regulator will examine on the bank's books, not the partner's. Programs that operate the five functions with documented cadence produce the evidence the regulator looks for. Programs that operate three of five produce the findings the regulator cites.

If your bank has not produced a current-state benchmark of its vendor risk management program against the five functions in the last twelve months, that is the conversation worth having with your Tech-Operations partner before the next exam cycle.

Five Nines Technology Group is a Tech-Operations partner for community banks and credit unions. Translating regulatory frameworks into operating discipline at community bank scale is where our team focuses.