7 things to check before you trust a software vendor’s security claims

A vendor says their software is “bank-level secure,” and suddenly everybody in the meeting relaxes. Don’t do that. That phrase is usually marketing cologne — strong smell, not much substance.

If you’re buying software, you do not need to become a security engineer. But you do need to ask better questions, because a bad vendor answer now can turn into a very expensive mess later. IBM’s 2024 report put the global average cost of a data breach at $4.88 million, which is a good reminder that security isn’t an IT side quest.

Here’s the checklist I’d use.

1. Check whether their proof matches the product you’re actually buying

A vendor can wave around SOC 2 or ISO 27001 and still leave you exposed. Those can be useful signals, but they are not magic shields. Ask what exact product, environment, and region the audit or certification covers — because company-level compliance is not the same thing as product-level security.

This is like a restaurant bragging that the front dining room passed inspection when you’re really asking about the kitchen. If the software you’ll use sits outside the audited scope, the badge doesn’t mean much.

2. Ask whether it’s a point-in-time document or proof of ongoing practice

Not all reports mean the same thing. A SOC 2 Type 1 says controls were designed at a point in time; a Type 2 says those controls operated over a period of time. If a vendor leans hard on a Type 1 report, that’s better than nothing, but it’s still closer to “we set up the locks” than “we’ve been locking the doors every night.”

Also check the date. A stale security report is like a two-year-old brake inspection on a work truck — nice to know, but not something I’d bet the business on today.

3. Find out what security is on by default

This one matters more than a lot of owners realize. According to CISA’s secure-by-design guidance, customers should not be carrying the whole load of hardening a product after purchase. Ask whether multifactor authentication, logging, session controls, and basic account protections are built in and enabled by default.

If the vendor says, “You can configure that if you want,” keep pushing. Secure software should come more like a pickup truck with seatbelts already installed, not a box of parts you have to remember to bolt on yourself.

4. Ask where their responsibility ends and yours begins

A lot of security problems live in the gray area between “their system” and “your setup.” In SaaS and cloud products especially, you need a plain-English breakdown of who handles backups, access control, patching, encryption, monitoring, and incident response. If they can’t explain the shared-responsibility line clearly, that’s a problem.

This comes up a lot when businesses are comparing off-the-shelf tools with custom software development or connected systems. If data moves between tools, read How Your Data Moves Between Systems—and Where It Usually Breaks too, because security gaps love handoff points.

5. Ask how they handle vulnerabilities and updates

Modern software is built with a pile of third-party components and open-source packages. That’s normal. What matters is whether the vendor knows what’s in the stack, monitors for newly discovered vulnerabilities, and patches fast when something breaks.

I’d ask directly: Do you maintain a software bill of materials? How do you track dependency risk? What is your patch SLA for critical issues? NIST and OWASP both push this stuff for a reason — software trust is partly a supply-chain problem, not just a password problem.

6. Look at how they talk about incidents, not just how they market prevention

A mature vendor should be able to explain what happens if something goes wrong. Ask about breach notification timelines, log retention, forensic support, and how customers are informed during an incident. With the SEC’s newer disclosure pressure on many public companies, vague answers here are getting harder to hide behind.

Honestly, I trust a vendor more when they can talk clearly about ugly days. A company with documented postmortems and plain-language remediation steps may be safer than one with a spotless website and zero transparency. If you’re in Northwest Arkansas or anywhere else, the risk is the same: pretending small businesses don’t need this level of scrutiny is a mistake. This is worth pairing with Myth: Cybersecurity is only a big-company problem in Northwest Arkansas.

7. Ask for evidence of real operating habits, not just policy documents

Policies are easy to write. The harder question is whether the vendor actually follows them. Ask who reviews access, how quickly former employees lose access, whether admin actions are logged, how long logs are kept, and whether customers can export their own data if they need to leave.

That last one matters more than people think. If switching vendors is part of your risk plan, read What happens to your data when your SaaS vendor shuts down. A vendor that makes exit painful often makes everything else opaque too.

Security claims are worth exactly as much as the evidence, scope, and habits behind them.