A vendor’s SOC 2 report tells you what their auditor checked last year. It does not tell you what happens when their subcontractor in another jurisdiction mishandles a data export, or what their incident response actually looks like at 2am on a Saturday. Fintech teams sign vendor contracts constantly: cloud infrastructure, payment processing, KYC verification, fraud scoring, data enrichment. Each one of those vendors becomes part of your compliance surface the moment you integrate them, whether or not you ever audited them properly. This piece gives you a repeatable framework for vetting a vendor before you sign, not a general argument for why vendor risk matters.
Why a Vendor’s Security Gap Becomes Your Regulatory Problem
Regulators do not distinguish between a breach you caused and a breach your vendor caused. If a KYC provider stores identity documents insecurely and they leak, the enforcement action lands on you, the regulated entity, not on the vendor you hired. Your customers signed up with your brand. Your regulator licensed your business. The vendor is invisible to both until something goes wrong, at which point it becomes very visible and entirely your liability.
This is why vendor due diligence cannot be a procurement afterthought handled by whoever negotiates the contract price. A vendor review is a compliance function wearing a procurement hat. The questions you ask before signing determine whether you inherit a manageable risk or a liability you cannot see until an auditor or a regulator finds it for you.
The Four Things Every Vendor Review Has to Cover
Strip away the paperwork and every vendor review reduces to four questions.
Data handling. What data does the vendor touch, where is it stored, and for how long? A payment processor that retains full card data longer than necessary is a different risk than one that tokenizes on receipt. Get specific about data residency too: a vendor storing EU customer data on servers outside the EU creates a GDPR problem you now own.
Access control. Who inside the vendor’s organization can see your data, and how is that access limited and logged? A vendor with broad internal access and no audit trail cannot tell you who touched a record if something goes wrong, which means neither can you.
Subcontractors. Almost every fintech vendor outsources something: cloud hosting, a notification service, a document scanning tool. Each subcontractor inherits a slice of your risk. Ask for a full list of fourth parties and what data each one can reach, not just a promise that subcontractors are “vetted.”
Incident history. Ask directly whether the vendor has had a security incident or data breach in the past three years, what happened, and what changed afterward. A vendor with a disclosed incident and a documented remediation is often a safer bet than one claiming a spotless record they cannot substantiate.
Technical Readiness: What to Ask Before You Even Look at a SOC 2 Report
Certifications come later in this process, not first. Before you read a single audit report, get the vendor to answer plain technical questions in plain language.
- How is data encrypted at rest and in transit, and who holds the encryption keys?
- What does the authentication flow look like for both your staff and their own employees accessing the system?
- How often are penetration tests run, and will they share the executive summary, not just a certificate saying one happened?
- What is the actual uptime history for the past twelve months, with numbers, not a marketing claim?
- What does their incident response plan say about notifying you, and within what window?
A vendor that answers these questions fluently and specifically is signaling a mature engineering culture. A vendor that redirects every question to “it’s in our SOC 2” is signaling that compliance paperwork is doing the work their engineering team should be doing. If the vendor exposes an API as part of its service, the bar should be higher still: point to what regulators actually expect from open banking API security as the standard worth holding them to, since API-level weaknesses are where a lot of vendor risk actually concentrates.
Compliance Readiness: Which Certifications Actually Matter and Which Are Just Paperwork
Certifications are a starting filter, not a conclusion. Here is what each one actually tells you.
SOC 2 Type II confirms a vendor’s controls operated effectively over a period of months, not just on the day of an audit. Type I only confirms controls existed on a single date, which is a much weaker signal. Always ask which type you are looking at.
ISO 27001 confirms the vendor runs a formal information security management system. It tells you a process exists. It does not tell you the process is good, only that it is documented and reviewed.
PCI DSS matters specifically if the vendor touches card data at all. A vendor that is PCI compliant but does not actually need to be, because they never touch raw card numbers, is a vendor who correctly scoped their own exposure. That is worth noting as a positive sign, not a shortcoming.
GDPR and data processing agreements are not certifications at all but contractual commitments. A vendor claiming GDPR compliance without a signed data processing agreement that names subcontractors and data flows is making a marketing claim, not a legal one.
The pattern across all of these: a certification tells you a vendor passed a specific, narrow test at a specific point in time. It does not tell you whether their architecture would survive scrutiny if regulation tightens or if a new jurisdiction’s rules apply to your business next year. For a sense of what that durability actually requires, architecture built to survive GDPR and whatever comes next is a useful comparison point when you are deciding whether a vendor’s current compliance posture is built to last or built to pass an audit.
Scoring the Vendor: A Simple Tiering Model for Critical, Moderate, and Low-Risk Vendors
Not every vendor deserves the same depth of review. A cloud infrastructure provider holding your entire customer database needs far more scrutiny than a vendor providing a marketing analytics widget with no access to personal data. A simple three-tier model keeps the process proportionate.
Critical tier: vendors with direct access to customer financial data, identity documents, or payment credentials, or vendors whose outage would stop your core service. This includes cloud hosts, payment processors, and KYC providers. These vendors need a full technical and compliance review before signing, a signed data processing agreement, and a re-vetting cadence measured in months.
Moderate tier: vendors with access to operational data but not direct customer financial or identity data, such as a customer support tool or an analytics platform with pseudonymized data. These warrant the four-question review above and a lighter version of the technical checklist, with re-vetting on an annual basis.
Low tier: vendors with no access to sensitive data at all, such as an internal project management tool. A basic security questionnaire and a check on data residency is usually sufficient.
Tiering matters because exhaustive due diligence on every vendor, including the ones that pose almost no risk, trains your team to skip the process entirely once it becomes exhausting. Match the depth of the review to the actual exposure, and the process stays sustainable.
Red Flags That Should Pause Any Contract Negotiation
Some signals should stop a vendor conversation regardless of how good the product demo looked.
- Refusal to share a SOC 2 or ISO 27001 report, or only sharing a summary letter instead of the actual report.
- Inability to name their subcontractors or describe what data each one touches.
- No documented incident response plan, or a vague answer when asked who gets notified first if something breaks.
- A data processing agreement that leaves data residency undefined or reserves the right to change subcontractors without notice.
- Sales teams that cannot connect you with anyone technical when asked specific architecture questions.
None of these automatically disqualify a vendor on their own. Together, or combined with a critical-tier risk classification, they are reason enough to pause and escalate before signing anything.
Keeping the Relationship Honest: Re-Vetting Cadence After the Contract Is Signed
Vendor risk does not freeze at signature. A vendor’s security posture, subcontractor list, and compliance certifications can all change over the life of a contract, often without you being told directly.
Build re-vetting into the contract itself, not into a calendar reminder someone might forget. Critical-tier vendors should provide updated SOC 2 reports annually at minimum, and should be contractually required to notify you of subcontractor changes, not just disclose them if asked. Moderate-tier vendors can be re-reviewed on a longer cycle, but the review should still happen on a set schedule rather than only after something goes wrong.
Treat a vendor’s annual report renewal date as a trigger to re-run your original checklist against the new version, not just file the new report away. Certifications expire, scopes narrow, and subcontractor lists grow. A vendor that passed your review two years ago is not automatically the same vendor today.
Pair this vetting framework with the stage-by-stage priorities in a founder’s roadmap to fintech compliance so vendor risk management fits into your broader compliance plan rather than sitting apart from it.