Third-Party Risk Management for Banks: A Cybersecurity Lens
In June 2023, the OCC, the Federal Reserve, and the FDIC replaced their separate vendor-oversight playbooks with a single Interagency Guidance on Third-Party Relationships. The framework is risk-based, lifecycle-driven, and unforgiving about one thing in particular: outsourcing the work never outsources the accountability. This guide walks the five lifecycle stages with a cybersecurity lens, explains concentration and fourth-party risk, and shows how a bank moves from point-in-time vendor reviews to continuous oversight.
Banks run on third parties. Core processors, cloud providers, fintech partners, loan servicers, fraud-detection vendors, and the subcontractors behind all of them now sit inside the data path for regulated activities. Z Cyber operates as a cybersecurity operating partner for banks and other financial institutions. We run the third-party risk management program on our AI-native GRC platform, Glance, mapping each vendor to its risk tier, its controls evidence, its contract obligations, and its monitoring cadence so oversight is a continuous state rather than an annual file drill. For institutions in scope, see how this fits a broader program on our financial services page. This guide is the practitioner's view of third-party risk management for banks under the current supervisory expectations.
What third-party risk management means for a bank
Third-party risk management, often shortened to TPRM, is the discipline of identifying, assessing, and controlling the risks a bank takes on when it relies on an outside party to perform an activity, function, or service. The federal banking agencies use the term "third-party relationship" deliberately and broadly. It covers far more than signed vendor contracts. It includes affiliates, joint ventures, fintech arrangements, correspondent and agent relationships, and even relationships established without a formal agreement.
The central supervisory principle is simple and old: a bank's use of third parties does not diminish its responsibility to operate safely, soundly, and in compliance with applicable law. The board and management remain accountable for the activity as if the bank performed it in-house. Cybersecurity sits at the center of this because the vendor's security posture becomes the bank's exposure. A weak vendor control is a bank control gap, full stop.
The 2023 Interagency Guidance and why it consolidated the rules
On June 6, 2023, the Office of the Comptroller of the Currency, the Board of Governors of the Federal Reserve System, and the Federal Deposit Insurance Corporation issued final Interagency Guidance on Third-Party Relationships: Risk Management. It replaced each agency's prior, separate guidance with one common framework, so that an OCC-supervised bank, a Fed-supervised holding company, and an FDIC-supervised institution now work from the same expectations.
Two ideas anchor the guidance. First, oversight should be commensurate with risk. Not every vendor warrants the same scrutiny, and the depth of due diligence, contracting, and monitoring should scale with the risk and complexity of the relationship. Second, relationships that support "critical activities" deserve heightened attention. Critical activities are those that, if disrupted or mishandled, could cause significant harm to the bank, its customers, or its ability to meet regulatory obligations. A core banking platform or a primary cloud host is a different animal than a vendor that prints branch signage, and the program should treat them differently.
Map your vendors to the lifecycle, not a spreadsheet.
Z Cyber stands up a risk-tiered TPRM program on Glance and runs the ongoing oversight for you.
The third-party risk management lifecycle
The guidance frames third-party risk management as a lifecycle with five stages. The stages are not a one-time checklist. They form a loop that runs for the life of every relationship, with the intensity of each stage set by the vendor's risk tier. The cybersecurity questions change at each stage, but they never disappear.
| Lifecycle stage | Core objective | Cybersecurity focus |
|---|---|---|
| Planning | Decide whether and how to use a third party for the activity. | Classify the data the vendor will touch and the criticality of the activity before scoping diligence. |
| Due diligence and selection | Assess the candidate's ability to perform safely and soundly. | Review the information security program, SOC 2 reports, certifications, access models, and incident history. |
| Contract negotiation | Set obligations, rights, and remedies in writing. | Bind security requirements, breach notification timelines, audit rights, and subcontractor controls into the contract. |
| Ongoing monitoring | Confirm the vendor still performs as expected. | Track control attestations, posture changes, breaches, and fourth-party shifts on a recurring cadence. |
| Termination | Exit the relationship cleanly. | Recover or destroy data, revoke access, and confirm there is no residual exposure or lock-in. |
Governance and documentation wrap around all five stages. The agencies expect the board to set the strategy and risk appetite, management to execute, and the bank to keep records that an examiner can follow. If the program cannot show its work, it does not exist as far as supervision is concerned.
The cybersecurity dimension of vendor due diligence
Due diligence is where the security lens does the most work. The objective is not to collect a SOC 2 report and file it. It is to read the report, understand its scope and its exceptions, and decide whether the vendor's control environment actually protects the data and the activity in question. A SOC 2 Type II that excludes the system the bank will use is close to worthless, and a clean opinion with a list of noted exceptions still needs someone to judge whether those exceptions matter.
A serious security review of a third party covers the vendor's information security program and governance, identity and access management, encryption of data in transit and at rest, vulnerability and patch management, logging and monitoring, incident response and breach history, business continuity and disaster recovery, and the way the vendor handles, segregates, and disposes of bank and customer data. It also covers certifications and independent attestations, such as SOC 2, ISO 27001, or PCI DSS where card data is involved, weighed for relevance rather than collected for show. For a regulated activity, the bank should be able to state where its data lives, who can reach it, and what happens to it when the relationship ends.
Fourth-party and concentration risk
Two risks routinely escape a vendor-by-vendor review because they live in the spaces between vendors. The first is fourth-party risk. Your vendor's subcontractors inherit access to your data and your activity, often without the bank ever evaluating them directly. The guidance expects diligence and monitoring to account for these subcontractors, and contracts should give the bank visibility into and some control over the vendor's use of them, including notice when a critical subcontractor changes.
The second is concentration risk. When many banks, or many activities within one bank, depend on the same provider, a single failure propagates widely. Concentration shows up in two forms. Vendor concentration is over-reliance on one provider for a critical activity, so an outage or a breach at that provider takes the bank down with it. Geographic or platform concentration stacks multiple vendors on the same underlying cloud region or data center, so a "diversified" vendor list collapses into one point of failure under stress. Mapping these dependencies is part of the program, not an afterthought, and it is one of the harder problems to solve with a spreadsheet.
From point-in-time checks to continuous monitoring
The most consequential shift in the guidance is the move from point-in-time assessment to ongoing monitoring. A vendor that was secure at onboarding can degrade in months. Certifications lapse, a breach hits the news, a subcontractor changes, key staff leave, or the vendor quietly re-architects the service. An annual questionnaire cannot catch any of that in time to matter.
Continuous monitoring means tracking control attestations as they renew, watching for breach disclosures and posture changes, refreshing risk tiers as the relationship evolves, and re-running diligence when something material shifts. This is precisely the work Z Cyber runs on Glance for the banks we operate for. Each vendor carries a living record of its tier, evidence, contract obligations, and monitoring cadence, and the forward-deployed team triages changes and drives remediation rather than waiting for the next annual cycle. Continuous monitoring is also where TPRM connects to the broader maturity model captured in our FFIEC CAT cybersecurity maturity roadmap.
How TPRM connects to NYDFS, GLBA, and FFIEC
The interagency guidance does not stand alone. It overlaps with a web of specific obligations that turn vendor oversight into a legal requirement rather than a best practice.
NYDFS 23 NYCRR 500.11 requires covered financial institutions to maintain a written policy governing the security of third-party service providers, including minimum security practices, due diligence, and periodic assessment. The GLBA Safeguards Rule requires financial institutions to oversee their service providers by taking reasonable steps to select providers that can maintain appropriate safeguards and by contractually requiring them to do so. Our deeper guide on GLBA Safeguards Rule compliance covers the service-provider obligation in detail. FFIEC guidance on outsourcing and technology service providers adds the examination lens the agencies use when they review a bank's outsourcing arrangements. Read together, these authorities say the same thing in different registers: the bank owns the risk, the contract must carry the security obligations, and the oversight must be continuous.
Building a program that survives an exam
A defensible third-party risk management program has a few non-negotiable parts. It maintains a complete inventory of third parties, because you cannot manage what you have not enumerated, and shadow vendors are where exposure hides. It tiers every relationship by risk and criticality, so effort follows exposure. It binds security requirements, breach notification, audit rights, and subcontractor controls into contracts before signing, because leverage evaporates after the ink dries. It monitors continuously and documents the monitoring, so the program can prove it acted. And it plans exits in advance, so termination is orderly rather than a scramble that strands data with a former vendor.
Most banks have the policy. The gap is execution at scale across dozens or hundreds of vendors, sustained quarter after quarter, with evidence an examiner can follow. That is the operating problem Z Cyber solves. We do not hand a bank a framework and a stack of questionnaires. We run the program on Glance, tier the vendors, chase the evidence, monitor the changes, and deliver the remediation, so the bank's team can focus on the relationships that drive the business rather than the file-keeping that proves they were managed.
Ready to make vendor oversight continuous?
We run your third-party risk program end to end, from due diligence through termination.
Frequently Asked Questions
What is third-party risk management for banks?
Third-party risk management, or TPRM, is the discipline of identifying, assessing, and controlling the risks a bank takes on when it relies on an outside party to perform an activity, function, or service. The federal banking agencies define third-party relationships broadly to include vendors, affiliates, fintech partners, and subcontractors. The core principle is that using a third party never reduces the bank's own responsibility to operate safely and soundly, so the bank remains accountable for the activity as if it performed it in-house.
What is the 2023 interagency guidance on third-party relationships?
On June 6, 2023, the OCC, the Federal Reserve, and the FDIC issued final Interagency Guidance on Third-Party Relationships: Risk Management. It replaced each agency's separate prior guidance with one common, risk-based framework. The guidance describes a five-stage lifecycle of planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination, and it directs banks to apply heightened oversight to relationships that support critical activities.
What is concentration risk in vendor management?
Concentration risk is the exposure created when many banks, or many activities within one bank, depend on the same provider, so that a single failure propagates widely. It appears as vendor concentration, where a bank over-relies on one provider for a critical activity, and as geographic or platform concentration, where multiple vendors stack on the same underlying cloud region or data center. Mapping these dependencies is a required part of a third-party risk program because a diversified vendor list can still collapse into a single point of failure.
How do banks monitor vendor cybersecurity risk?
Banks move from point-in-time checks to continuous monitoring. That means tracking control attestations and certifications as they renew, watching for breach disclosures and security posture changes, monitoring shifts in subcontractors and fourth parties, refreshing each vendor's risk tier as the relationship evolves, and re-running due diligence when something material changes. The goal is to catch degradation in a vendor's security before it becomes the bank's incident, rather than relying on an annual questionnaire.
Subscribe for Updates
Get cybersecurity insights delivered to your inbox.
