A community bank's core banking provider, cloud storage vendor, cybersecurity partner, and office software provider don't necessarily require the same level of oversight. So why would they all receive the same risk review?
Community and regional banks depend on third-party technology providers to support daily operations. These relationships can improve efficiency, expand capabilities, and give smaller institutions access to technology they might not otherwise be able to maintain internally.
But they also introduce varying levels of cybersecurity, operational, and business risk.
A vendor supporting a critical banking function may create a very different exposure than a provider with limited access to internal systems or information.
Understanding that difference is essential to making sound risk-management decisions.
And recent federal regulatory developments are bringing renewed attention to how banks evaluate and prioritize their third-party relationships.
What Is Changing in Third-Party Risk Management Guidance?
On September 11, 2026, the Office of the Comptroller of the Currency (OCC), Federal Reserve, Federal Deposit Insurance Corporation (FDIC), and National Credit Union Administration (NCUA) announced proposed revisions to third-party risk management guidance.
The proposal emphasizes aligning third-party oversight with the risks associated with individual vendor relationships.
Rather than applying a uniform approach across all providers, the proposed guidance discusses tailoring risk-management activities according to factors such as:
- The potential magnitude and likelihood of harm.
- The nature and complexity of the vendor relationship.
- The financial institution's size and risk profile.
- Material financial risks and applicable legal obligations.
- The resources needed to manage the relationship appropriately.
The Federal Reserve also released a separate proposed guide for traditional community banking organizations, addressing common third-party relationships and associated risks.
These proposals are not finalized regulatory requirements. The comment period remains open through November 16, 2026.
Nevertheless, they provide an opportunity for community banks to examine how their current vendor-management processes prioritize risk.
The broader principle is straightforward: the amount of oversight should reflect the risks a relationship presents.
Why Treating Every Vendor the Same Can Create Problems
Consistency matters in vendor management. Banks need repeatable processes for evaluating providers, recording decisions, and monitoring important relationships.
But consistency does not necessarily mean identical treatment.
Consider two hypothetical vendors.
The first provides a business application with limited access to nonsensitive internal information.
The second supports a critical banking function, processes customer information, and connects directly to the bank's technology environment.
Both relationships deserve an appropriate review.
However, a disruption, security incident, or control failure involving the second provider could have considerably greater consequences.
Applying identical review procedures to both may consume resources without directing sufficient attention toward the more consequential relationship.
For banks with limited internal cybersecurity and risk-management resources, prioritization matters.
The objective isn't to review fewer vendors simply to reduce work. It's to make sure the most consequential risks receive the attention they deserve.
Five Factors Banks Should Consider When Prioritizing Vendor Cybersecurity Risk
Third-party risk management should account for more than one characteristic.
A vendor's overall importance, access, dependencies, and potential business impact can help determine how thoroughly and frequently its risks should be evaluated.
The following five factors provide a practical starting point.
1. Access to Sensitive Information
What information can the vendor access, store, transmit, or process?
A technology provider handling sensitive customer information may warrant different scrutiny from a vendor that only accesses public marketing materials.
Banks should consider:
- Whether the vendor accesses nonpublic customer information.
- The types and sensitivity of information involved.
- Whether data is stored or processed outside the bank's environment.
- Which employees and systems can access the information.
- Whether additional service providers participate in processing or storing it.
The review should also consider whether vendor access has changed since the relationship began.
For example, a provider originally approved for one limited function may later receive additional integrations or access permissions.
That change could affect the relationship's risk profile even when the original contract remains in place.
2. Importance to Daily Banking Operations
Not every vendor has the same effect on a bank's ability to operate.
Some support routine administrative functions, while others provide services that are essential to customer transactions, internal operations, or access to critical systems.
Consider what would happen if the vendor became unavailable.
Would the bank experience a minor inconvenience?
Would employees need to temporarily change how they complete a task?
Or could the disruption affect essential banking operations?
Questions worth asking include:
- Which business processes depend on the vendor?
- How long could the bank operate without the service?
- Are alternate systems or processes available?
- Does the vendor have documented recovery capabilities?
- Has the bank considered the relationship in its business continuity planning?
These questions help determine whether a vendor's importance warrants heightened oversight.
Importantly, operational criticality and cybersecurity risk are related but not identical. A provider can be operationally critical without possessing extensive privileged access, while a less visible technology provider may create substantial security exposure.
Both considerations matter.
3. Access to the Bank's Technology Environment
A vendor's level of technical access can significantly affect cybersecurity exposure.
Some vendors may access only a limited application.
Others may maintain administrative accounts, remote connections, service integrations, or privileged access to important infrastructure.
When reviewing technology vendors, banks should consider:
- Whether the vendor has privileged or administrative access.
- Which applications, systems, and networks it can reach.
- How access is authenticated and restricted.
- Whether access is necessary for the services being provided.
- How access is changed or revoked when the relationship changes or ends.
A vendor with extensive permissions may introduce risks even if it does not directly process large amounts of customer information.
This is why access management should be an important part of technology vendor oversight.
4. Dependence on Additional Service Providers
A bank may contract with one vendor while depending indirectly on several additional organizations.
Cloud infrastructure providers, software developers, payment processors, and other subcontractors may participate in delivering a service.
These relationships can introduce dependencies that are not immediately visible in the bank's direct contract.
For example, a technology provider might rely on a separate cloud service to host important applications.
If that cloud provider experiences a major disruption, the bank could be affected even though it does not contract with the cloud provider directly.
Banks should consider:
- Whether the vendor relies on subcontractors or other technology providers.
- Which dependencies support important operations.
- How the vendor evaluates and manages those relationships.
- Whether the bank receives notice of significant changes.
- What contingency arrangements exist if a supporting provider fails.
The goal is not to assess every subcontractor as though it were a direct banking vendor.
It is to understand material dependencies that could affect security, continuity, or regulatory responsibilities.
5. Potential Impact of a Vendor Failure or Security Incident
A vendor's risk rating should also reflect what could happen if its controls fail.
The potential consequences may include interrupted operations, compromised information, financial losses, legal obligations, or reputational harm.
Banks should consider both the likelihood of relevant events and their possible impact.
For example, a vendor providing a replaceable internal tool may pose limited operational consequences if the service becomes temporarily unavailable.
A provider supporting a critical function could create substantial disruption under similar circumstances.
The bank should also examine the vendor's controls and resilience capabilities instead of relying entirely on the importance of the service.
A critical vendor with strong controls and recovery capabilities presents a different risk profile from one with significant unresolved weaknesses.
These considerations help leadership move from a general classification toward a more meaningful assessment of risk.
How Can Community Banks Put Vendors Into Risk Tiers?
After evaluating relevant factors, banks can organize vendors into tiers that guide the depth and frequency of oversight.
There is no single classification system appropriate for every institution.
One bank might use three tiers. Another may use additional categories or separate assessments for cybersecurity, operational, and compliance risks.
The following example illustrates a simplified approach.
|
Example Tier |
Characteristics |
Potential Oversight |
|---|---|---|
|
Higher Risk |
Critical operations, sensitive information, privileged access, significant dependencies, or substantial potential impact |
More detailed due diligence, defined escalation procedures, enhanced monitoring, and periodic reassessment |
|
Moderate Risk |
Important business functions or limited sensitive access with manageable dependencies |
Risk-appropriate reviews, documented controls, and scheduled reassessment |
|
Lower Risk |
Limited system access, minimal sensitive information, and relatively low business impact |
Streamlined due diligence and proportionate monitoring |
These are illustrative categories, not regulatory classifications or prescribed review schedules.
A vendor's tier should not be determined by a single question.
For example, a vendor may have little direct access to sensitive information but still support an operation the bank cannot easily replace.
Another may provide a noncritical application but maintain elevated access permissions that create meaningful cybersecurity exposure.
Both scenarios deserve thoughtful evaluation.
Banks should establish classifications and review practices appropriate to their own circumstances and applicable expectations.
Vendor Risk Ratings Should Change When the Relationship Changes
A vendor's initial risk assessment should not be the final word on that relationship.
Technology changes, business needs evolve, and vendors may introduce new capabilities or dependencies.
A provider may move from a limited application to a service supporting several departments.
A new integration may expand the information the provider can access.
An operational change may increase the bank's reliance on the service.
Any of these developments could justify reviewing the relationship's existing risk classification.
Banks should establish procedures for identifying significant changes and determining whether additional evaluation is appropriate.
This doesn't mean every software update requires a new comprehensive assessment.
It means the bank needs a process for recognizing changes that materially affect risk.
For a closer look at how AI-enabled features can alter existing third-party relationships, read our article on AI Vendor Risk Management for Community Banks.
What Should Bank Leadership Be Able to Demonstrate?
A risk-tiering system is most useful when leadership can explain how vendor classifications influence oversight.
That means maintaining documentation that connects risk assessments to actual decisions.
For important technology relationships, bank leadership should be able to answer questions such as:
- What factors were considered when assigning this vendor's risk classification?
- What information or systems can the vendor access?
- How important is the vendor to daily banking operations?
- What controls or contractual protections help manage the identified risks?
- How is the relationship monitored, and who is responsible?
- When was the classification last reviewed?
- What changes or findings would trigger reassessment?
A documented process can help management explain why certain relationships receive greater scrutiny than others.
It also helps demonstrate that vendor oversight is connected to the bank's broader cybersecurity and risk-management priorities.
Where Cybersecurity and Vendor Risk Management Overlap
Vendor risk management is not solely a procurement or compliance responsibility.
Technology relationships often involve cybersecurity decisions that require input from IT leadership, risk management, and other business functions.
For example, a vendor assessment may identify excessive access permissions.
Addressing that concern could require technical changes, updated procedures, and discussions with the vendor.
Another assessment may reveal that a critical technology provider's recovery capabilities do not align with the bank's operational needs.
That finding may require coordination between IT, leadership, business continuity planning, and vendor management.
These situations illustrate why vendor risk should not operate independently from the bank's overall cybersecurity program.
Organizations benefit when vendor oversight, risk assessments, security controls, and executive reporting are connected.
AvTek Solutions supports this kind of coordinated approach through its vCISO Services, which include cybersecurity governance, risk-management guidance, vendor and third-party risk discussions, documentation review, and executive reporting.
For community and regional banks, that support can help connect technical cybersecurity considerations with broader governance and oversight responsibilities.
A More Risk-Focused Approach to Vendor Management
The question isn't whether every vendor deserves attention.
It's whether your bank is directing the appropriate level of attention toward each relationship.
A risk-based approach helps leadership distinguish between vendors that present limited exposure and those whose access, dependencies, or operational importance call for greater scrutiny.
It also creates opportunities to use internal resources more effectively without overlooking important cybersecurity concerns.
As federal agencies consider changes to third-party risk-management guidance, community banks have a timely reason to evaluate how their current processes reflect the risks of individual relationships.
The proposed guidance may change before it is finalized.
But understanding how technology vendors affect your institution's cybersecurity and operational resilience is already an important business responsibility.
The strongest vendor-management programs don't simply document which providers the bank uses. They help leadership understand which relationships matter most, why they matter, and how their risks are being managed.
Are Your Bank's Vendor Reviews Focused on the Risks That Matter Most?
If your bank is evaluating its third-party oversight practices, a cybersecurity risk review can help identify where technical access, operational dependencies, and governance responsibilities may need greater attention.
AvTek Solutions works with community and regional banks to support cybersecurity risk management, governance, and technology-risk decision-making.
Talk with AvTek about strengthening your bank's third-party cybersecurity risk management.

