In August 2025, Marquis Software Solutions was hit by a ransomware attack. Marquis provided marketing and compliance services to financial institutions across the United States. The breach was traced to a vulnerability in a SonicWall firewall — one that had been publicly disclosed and patched months earlier. Within weeks, over 70 banks and credit unions had been notified. At least 400,000 consumers were affected.
The entry point wasn’t a sophisticated zero-day. It wasn’t an advanced persistent threat. It was an unpatched firewall at a vendor most of those 70 institutions had never thought twice about.
Fintech is living versions of this story constantly — just with less coverage.
The vendor risk problem that nobody maps at seed stage
Almost half of your breach risk isn’t in the code you write, the servers you manage, or the access controls you configure. It’s in the API you use for KYC. The fraud detection service your transactions run through. The data enrichment vendor your onboarding depends on. The embedded analytics tool your operations team added last quarter.
Each of those vendors has access to your production environment, your customer data, or both. And at seed stage, most fintechs haven’t evaluated any of them with the rigor they’ve applied to their own stack. There simply wasn’t time. You were shipping.
That’s understandable. It’s also a real liability that compounds as you grow.
How third-party breaches actually work
The mechanics vary, but the common thread is access. A vendor has legitimate access to your environment: read permissions on a database, API keys that can retrieve customer records, authentication credentials that were set up during integration and never rotated. When the vendor gets breached, that access is what the attacker inherits.
The attacker doesn’t need to breach you. They breach the vendor, find the credentials for your environment in the vendor’s systems, and use those credentials to access your customer data. Your access controls are working as designed. The credentials are legitimate. The breach happened elsewhere.
This is why your own security posture, however strong, isn’t sufficient on its own. Third-party access creates a perimeter that extends beyond your control.
The vendor review process most fintechs skip
Minimum vendor security review for any third party with access to customer financial data takes about two hours. Here’s what it covers.
Not a badge on their website. Not a checkbox saying they’re ‘SOC 2 compliant.’ The actual auditor’s report covering an observation period in the last 12 months. Read the scope section and the exceptions section. The scope tells you what was actually audited. The exceptions tell you what wasn’t working.
From the last 12 months, scoped to the systems that touch your integration. A VAPT that covered their marketing website but not their API infrastructure isn’t useful.
A contract specifying what data the vendor can access, how they must protect it, and what they’re required to do if they experience a breach. Their breach notification obligation to you — ’72 hours’ versus ’30 days’ is a material difference when you have your own notification obligations to customers and regulators.
Who else touches the data you give this vendor? Your KYC provider uses their own cloud infrastructure, their own database vendor, their own analytics tools. Each one is a sub-processor. You need to know who they are and that they’re operating under equivalent protections.
The access hygiene that changes your risk profile
Beyond vetting vendors before you onboard them, access hygiene for active integrations matters as much.
-
✓
Every vendor integration should operate with the minimum access required. Your fraud detection service needs read access to transaction data. It doesn’t need write access to your customer database. -
✓
Vendor credentials should be rotated on a defined schedule — at minimum annually, and immediately when there’s any indicator of compromise at the vendor. Most fintech companies never rotate vendor API keys after initial setup. Attackers know this. -
✓
Vendor access should be logged separately and reviewed regularly. If your fraud detection service suddenly makes 10x its normal API calls in a 6-hour window, that’s an anomaly worth investigating. The only way you catch it is if you’re monitoring vendor access patterns.
Making vendor risk management sustainable at 30 people
The goal isn’t a full enterprise vendor risk management programme with dedicated headcount. At 30-50 people, it’s a lightweight process that covers the critical exposures.
| Tier | Who they are | What you do |
|---|---|---|
| Tier 1 | Read or write access to production customer data | Full review before onboarding and on annual renewal |
| Tier 2 | Access to non-production or aggregate data only | Lighter review |
| Tier 3 | No access to customer data | Standard contract terms |
Build the DPA template once, review it with your legal counsel, then use it for every new vendor relationship. The template negotiation is one-time work. The ongoing process is disciplined application.
You can’t control whether your vendors get breached. You can control what access they have, what they’re contractually required to do when it happens, and how quickly you’d find out.
The companies that handle third-party breaches well aren’t the ones that prevented their vendor from getting breached. They’re the ones that had minimal access grants, current credentials, clear contractual obligations, and monitoring in place. So when it happened, they knew quickly, contained it fast, and had the documentation to manage the regulatory conversation.
That’s the realistic goal. Not zero third-party risk. Well-managed third-party risk.
Vendor access monitoring, credential management, and continuous posture management are part of what Osto runs on your behalf — so your team isn’t doing this manually across every integration.