Blog
How to Vet a Software Vendor for Client Data Security
September 14, 2026
Every new piece of software a firm adopts — a client portal, a document automation tool, a bookkeeping add-on — is also a new party with access to client tax and financial data. Most firms spend real time evaluating whether a tool solves their problem and almost none evaluating whether the vendor behind it can be trusted with the data it touches. Under the FTC Safeguards Rule, that second question isn't optional, and skipping it doesn't protect your firm — it just means you find out the hard way.
Your firm stays on the hook, not the vendor
This is the piece firms most often get backwards. Outsourcing a task to software doesn't outsource the compliance obligation that comes with it. GLBA requires firms to assess the risk posed by any service provider or software vendor with access to client information, and to have that vendor under a written agreement covering how they safeguard the data. If a vendor is breached and your firm never vetted them, the regulatory exposure — and the conversation with affected clients — is still yours to have.
The questions worth actually asking
- Encryption — is client data encrypted both in transit and at rest, and with what standard?
- Access — who at the vendor (employees, contractors, subprocessors) can see the data, and is that access logged?
- Incident response — what's their process if they're breached, and how quickly are affected customers notified?
- Data retention and deletion — what happens to your data if you stop using the tool, and can you get a written deletion confirmation?
- Written agreement — will they sign terms that specifically address data safeguarding, not just a generic terms-of-service page?
A vendor with solid practices will usually answer these directly, often with existing documentation ready to hand over. A vague answer, a redirect to marketing copy, or reluctance to put anything in writing is the signal worth paying attention to — more than the size of the company or how polished its website looks.
Why a generic platform makes this harder, not easier
Off-the-shelf software built for every industry at once is, by design, opaque about exactly how your specific data is handled — you're trusting a shared system you didn't design and generally can't inspect. That's not automatically disqualifying, but it does mean the vetting burden falls entirely on you to ask the right questions and get real answers, rather than assuming a familiar name means the work is already done. A well-known product still needs the same written agreement and the same specific answers as a small one.
Why we build tools instead of reselling them
This is a big part of why we build client-facing tools specifically for each firm we work with, rather than pointing every client toward the same generic platform. When a tool is built around your firm's actual workflow, the data-handling decisions aren't buried in a vendor's shared infrastructure you have to take on faith — they're made deliberately, for your firm, and we can walk you through exactly where client data lives, how it's encrypted, and who can access it, because we built it that way on purpose. That's a different conversation than asking a large SaaS company to explain their multi-tenant architecture to a five-person firm.
Vendor vetting is one piece of a broader security program — see our guide to the FTC Safeguards Rule for whether your firm is in scope, and our WISP checklist for how vendor oversight fits into the full written plan. This is also part of our complete guide to AI for accountants.
Frequently Asked Questions
Why does vetting a software vendor matter for my firm's compliance, not just the vendor's?
The FTC Safeguards Rule (part of GLBA) puts the obligation on your firm, not the vendor. Handing client data to a piece of software doesn't transfer your compliance responsibility — it adds a new item to it. Regulators expect you to have assessed and documented how any vendor with data access protects that data, in writing, before you adopt the tool.
What questions should I actually ask a software vendor before signing up?
At minimum: how is data encrypted in transit and at rest, who else (subprocessors, subcontractors) can access it, what's the incident response process if there's a breach, how is data deleted when you stop using the tool, and can they provide a written agreement covering these points. A vendor that can't answer clearly, or points you to a generic terms-of-service page instead, is a signal to look closer.
Do I need a signed agreement with every software vendor my firm uses?
For any vendor that touches client financial or tax data, yes — GLBA specifically requires a written contract obligating the vendor to maintain appropriate safeguards. A vendor unwilling to sign one, or that only offers a standard click-through EULA with no data-security terms, hasn't met that bar.
Is a bigger, more well-known software company automatically safer to use?
Not automatically. Size correlates with resources, not with fit. A large, generic platform built for every industry may store and handle your client data in ways that don't map to how a small accounting firm actually needs it protected — and a big name doesn't exempt your firm from doing the vetting. The size of the vendor is a data point, not a substitute for asking the actual questions.
How is vetting a custom-built tool different from vetting off-the-shelf software?
With a generic SaaS product, you're vetting a fixed system you have to fit your firm around, and you often can't see or influence how it actually handles your data underneath the marketing page. With a tool built specifically for your firm, the security decisions — where data lives, who can access it, how it's encrypted, how long it's retained — are made with your firm's exact workflow in view from the start, and you can ask for specifics rather than accepting a boilerplate answer.
Want to know exactly how your firm's data would be handled? We'll walk you through it before you commit to anything.
Book a Free Consultation