How to Evaluate a Software Vendor's Security
When you adopt a vendor, you inherit their security posture. A breach at a tool you trusted with your data becomes your incident, your notification, and your reputation.
Every tool you adopt becomes an extension of your own security surface. The vendor holds your data, and their weaknesses become your exposure. Yet security is often the least-examined part of a software decision, deferred to a checkbox at the end when the tool has already been chosen. That order is backward for anything handling sensitive data.
This guide is neutral and applies to any vendor. It covers what to evaluate, how to read certifications without over-trusting them, the data-handling questions that matter, and the signals of a vendor that takes security seriously versus one that treats it as marketing. You do not need to be a security expert to ask these questions well.
Certifications: necessary, not sufficient
Independent certifications and audit reports are a reasonable starting signal that a vendor has invested in security practices. Common ones attest to controls around security, availability, and data handling, and a vendor that has none for a product holding sensitive data is a concern.
But treat certifications as a floor, not proof. A certification shows a vendor met a defined standard at a point in time; it does not guarantee they are secure today or that the certification covers the product you are buying. Ask what a certification actually covers, when it was last assessed, and whether it applies to the specific service you will use. A vendor waving a badge without being able to explain its scope is a small red flag in itself.
How your data is handled
- Encryption: is data encrypted both in transit and at rest, using current standards.
- Data location: where is your data stored, and does that meet your residency requirements.
- Access: who at the vendor can access your data, under what controls, and is it logged.
- Retention and deletion: how long is data kept, and can you have it fully deleted on request.
- Subprocessors: which third parties does the vendor share your data with, and are they disclosed.
- Backups: how is data backed up, and how quickly could it be recovered.
Access control and operational security
Beyond how the vendor stores data, examine the controls they give you and the practices they follow internally. The tools you have to secure your own account matter as much as the vendor's infrastructure, because many breaches begin with a compromised user account rather than a broken server.
- Authentication: is multi-factor authentication supported and can you enforce it.
- Permissions: can you control access granularly, so people see only what they should.
- Audit logs: can you see who accessed and changed what, for your own accountability.
- Single sign-on: for larger teams, does it integrate with your identity provider.
- Vulnerability management: does the vendor test for and patch vulnerabilities systematically.
Incident history and transparency
How a vendor handles security incidents tells you more than their marketing. Ask whether they have had breaches, and if so, how they responded and communicated. A vendor that has never had an incident either is fortunate, is small, or is not telling you; how they talk about the possibility matters more than a spotless claim.
Look for transparency as the deeper signal. A vendor with a public security page, a clear incident-response commitment, a disclosed subprocessor list, and a way for researchers to report vulnerabilities is demonstrating a security culture. A vendor that is vague, defensive, or annoyed by security questions is showing you how they will treat your data once you are locked in. Consolidating onto fewer vendors, incidentally, reduces the number of these surfaces you must evaluate and monitor, which is a security argument in its own right.