Bank vendor due diligence is a risk-based process that evaluates a vendor's financial stability, security controls, and operational resilience before and during a contract. The immediate action is practical: request the vendor's SOC report, audited financial statements, business continuity test results, and a list of subcontractors, then tier the vendor by criticality. This evidence standard tracks directly with FFIEC, OCC, Federal Reserve, and FinCEN expectations.
TL;DR:
- Vendors supporting critical banking functions must provide recent SOC reports, audited financials, and business continuity testing to meet examiners' expectations.
- Elevated due diligence is required if a vendor handles customer data, supports essential services, or assumes new activities beyond initial scope.
- Evidence review should focus on current licenses, financial stability, security controls, SLA clarity, encryption standards, and subcontractor mappings.
- Red flags like outdated security reports, opaque ownership, or declining finances require immediate escalation or contract termination.
- Reassessing vendor risk regularly and documenting all findings is essential to maintain ongoing oversight and compliance.
Table of Contents
- What counts as a vendor relationship, and when to scale the review
- A compact checklist organized by category
- How to read the evidence once you have it
- Turning due diligence into a repeatable process
- What examiners expect to see in your vendor files
- Red flags that call for escalation
- Verifying evidence like a practitioner, not just a collector
- Vendor due diligence as ongoing risk management
- Where Secure Techies fits into your vendor assessment work
- FAQ
- Sources
What counts as a vendor relationship, and when to scale the review
Outsourcing guidance covers any activity performed "for, through, or on behalf of" a bank, not just core processing contracts. A payroll vendor, a document shredding company, and a cloud-hosted loan origination platform all fall under the same oversight umbrella, though not at the same intensity.
OCC guidance for community banks frames third-party risk management as an enterprise-wide governance responsibility, with the board and senior management accountable for the program even when a vendor risk team handles daily reviews. Scaling matters here: critical vendors (core banking, payment processing) warrant the deepest review, important vendors get a moderate review, and routine vendors get a lighter one. Enhanced due diligence kicks in whenever a vendor touches customer data, supports a critical service, or takes on a new activity outside its original scope.

A compact checklist organized by category
Before any contract moves forward, collect evidence across six categories. This keeps the file consistent regardless of who performs the review.
- Regulatory compliance: licenses, registrations, prior examination findings, and OFAC screening results.
- Financial assessment: audited financial statements, credit reports, and liquidity indicators for recent fiscal periods.
- Security and data protection: SOC 1 or SOC 2 report, penetration test summary, and data encryption standards.
- Operational capabilities: staffing levels, service level agreement (SLA) terms, and incident history.
- Legal and contractual: audit rights clauses, termination provisions, and insurance certificates.
- Technical infrastructure: network architecture diagrams, subcontractor (fourth-party) map, and change management policy.
Flag the SOC report, BCP test results, and subcontractor list as priority items since they take vendors the longest to produce. Store everything in a centralized vendor file with version control, and retain records for the life of the contract plus the period your examiners typically look back.
How to read the evidence once you have it
Collecting documents is only half the job. The harder part is judging whether what a vendor hands over actually supports a sound decision.
- Regulatory compliance: ask for current licenses and any consent orders or enforcement actions; a vendor that cannot produce a clean compliance history for the past three years deserves a closer look.
- Financial health: read the audited statements for declining revenue, shrinking cash reserves, or a qualified audit opinion, any of which signals the vendor may struggle to invest in security or stay operational.
- SOC reports: a SOC 1 covers financial reporting controls, while a SOC 2 covers security, availability, and confidentiality controls relevant to most IT vendors. Our SOC 2 compliance guide walks through what each report type actually certifies. When a SOC report carries exceptions or a narrow scope, ask directly for a recent penetration test summary to fill the gap.
- Operational evidence: review SLA wording for ambiguous uptime commitments, check staffing levels against the vendor's client base, and ask for a 12-month incident history rather than a general assurance that "nothing major happened."
- Technical items: request data flow diagrams, confirm encryption standards for data at rest and in transit, and review the change management process for how often production systems are modified without testing.
- Substitutes: when a startup or smaller vendor cannot produce a full SOC report, FFIEC guidance on due diligence and selection supports accepting a shared assessment or third-party attestation, provided you document the gap and add compensating controls such as increased monitoring frequency.
Turning due diligence into a repeatable process
A one-time review loses value the moment a vendor's business, staffing, or security posture changes. Build a process that repeats on its own schedule.
- Assign each vendor a risk tier and map the required evidence set to that tier so reviewers are not guessing what to request.
- Standardize intake with a single checklist and store every document with a version date, so examiners can trace what was reviewed and when.
- Set clear decision gates: approve, approve with compensating controls, or decline, and record the reasoning behind each outcome.
- Define a monitoring cadence tied to risk tier, tracking SLA breaches, security incidents, and financial health signals between full reassessments.
- Use shared due diligence or consortium assessments where available to reduce duplicate work, while still weighing the results against your own risk appetite.
Pro Tip: Set reassessment dates at contract signing rather than waiting for a renewal notice; vendor risk teams that review on a fixed calendar catch deterioration months earlier than teams that review reactively.
What examiners expect to see in your vendor files
Examiners start from the premise that the board and senior management own third-party risk, even when daily reviews sit with a vendor risk team. The Federal Reserve's guide on fintech due diligence lists business experience, financial condition, legal compliance, information security, and operational resilience as the core topics examiners expect a file to cover.
In practice, that means your vendor file should contain the SOC report, audited financials, BCP test results, and a subcontractor review for any critical or important vendor. When full documentation isn't available, the file should state the limitation plainly and describe the compensating control you put in place instead of pretending the gap doesn't exist. Reading the primary agency guidance directly, rather than relying on secondhand summaries, remains the most reliable way to keep your program aligned with current expectations.

Red flags that call for escalation
Certain findings should stop an onboarding decision in its tracks rather than get filed away for later review.
- A critical service that depends on a single subcontractor with no documented backup plan.
- Audit or security evidence older than 12 to 18 months, or a vendor that refuses to share penetration test results.
- A business continuity plan that has never been tested, or test results the vendor won't produce.
- Opaque ownership structures, or indicators of sanctions exposure under OFAC screening requirements.
- Declining financial performance, open litigation tied to data handling, or frequent executive turnover in a short window.
Any one of these should trigger a deeper review, added contractual protections, or a decision to walk away from the relationship entirely.
Verifying evidence like a practitioner, not just a collector
A SOC 1 answers questions about financial reporting controls; a SOC 2 answers questions about security and availability, and confusing the two leaves real gaps unexamined. For BCP readiness, ask for the vendor's most recent drill results, including actual recovery time and recovery point metrics, not just the policy document describing the plan. Our vendor risk management guide covers the data flow and subcontractor inventory checks worth requesting alongside those drill results.
Vendor due diligence as ongoing risk management
Due diligence succeeds only when it's treated as continuous oversight rather than a one-time approval. Boards that revisit vendor risk alongside compliance, IT, and procurement catch problems the others miss alone.
— Alex
Where Secure Techies fits into your vendor assessment work
We handle the technical side of vendor due diligence that compliance teams often lack the staff or tools to verify in-house. This includes closing evidentiary gaps examiners ask about, rather than leaving them as open items in a vendor file.

Our relevant services include:
- Compliance & Security Audits: independent assessments that validate a vendor's or your own security posture against HIPAA, SOC 2, and CMMC frameworks.
- Backup & Disaster Recovery: testing and documentation that produces the RTO and RPO evidence examiners expect, rather than an untested policy binder.
- Cybersecurity Solutions: continuous monitoring that gives you current incident data instead of a vendor's self-reported history.
If your vendor files are missing current test results or audit documentation, reach out to our team to scope what a readiness review would look like for your institution.
FAQ
What are the four customer due diligence requirements in banking?
FinCEN's CDD Rule requires banks to identify and verify customer identity, identify and verify beneficial owners of legal entity customers, understand the nature and purpose of each customer relationship, and conduct ongoing monitoring to report suspicious activity. These requirements focus on customers directly, but they shape how banks evaluate any vendor that touches onboarding or transaction data.
What is due diligence for banks?
Due diligence for banks is the process of evaluating a vendor's financial condition, security controls, legal compliance, and operational resilience before signing a contract and at regular intervals afterward. The FFIEC IT Examination Handbook treats this as a core supervisory expectation tied to outsourcing risk.
What is included in vendor due diligence?
A complete vendor due diligence file includes a SOC report, audited financial statements, business continuity test results, a subcontractor map, SLA terms, and evidence of regulatory compliance such as clean licensing history. The Federal Reserve's fintech due diligence guide adds information security and operational resilience as required review topics.
Is enhanced due diligence required in banks?
Enhanced due diligence becomes necessary whenever a vendor has direct access to customer data, supports a critical banking function, or takes on a new activity that expands its original scope. Regulators expect the depth of review to scale with the risk the relationship presents, rather than applying one standard review to every vendor regardless of criticality.
Sources
- FFIEC IT Examination Handbook — Outsourcing technology services: MSSP examination procedures
- Third-Party Relationships: A Guide for Community Banks (OCC, 2024)
- Conducting Due Diligence on Financial Technology Firms: A Guide for Community Banks (Federal Reserve, 2021)
- CDD Final Rule | FinCEN
