Software Security Checklist for Buyers

"They have SOC 2" is not a security review. It's a sentence a sales rep says with total confidence, and it tells you almost nothing on its own. SOC 2 Type I checks whether controls are designed correctly on one specific day; Type II checks whether they actually operated correctly over a period, usually six to twelve months. Neither tells you which systems or data were even in scope, and almost nobody reads the exceptions section, the part of the report that says where the controls didn't hold up.

This guide is the checklist for the buyer without a security team to hide behind: an ops lead, a founder, a department head handed the job of vetting a vendor with a laptop and a deadline. Once you've narrowed the field with how to build a software shortlist, security review is the gate before signature, not a task IT does after the contract is filed. Fold the result into the SaaS vendor evaluation scorecard as one weighted line, so it competes against price and features instead of getting skipped under deadline pressure.

Key Facts: software security checklist

• The global average cost of a data breach fell to $4.44 million in 2025, down 9% from $4.88 million the year before, according to IBM's 2025 Cost of a Data Breach Report.
• Third-party involvement in confirmed breaches doubled to 30%, up from roughly 15% the prior year, per Verizon's 2025 Data Breach Investigations Report. That's the vendor you're evaluating right now, one layer removed.
• Credential abuse was a leading initial attack vector in 22% of breaches, tied closely with exploited vulnerabilities at 20%, the same Verizon report found, which is exactly what SSO and enforced MFA are built to stop.
• Shadow AI, employees using unapproved AI tools with company data, added an extra $670,000 to the average breach cost when it played a role, and 97% of organizations with an AI-related security incident say they lacked proper AI access controls, also from IBM's 2025 report.

What "they have SOC 2" doesn't tell you

A SOC 2 report is an independent auditor's opinion on whether specific controls exist and, for Type II, whether they held up over an observation window. It is not a certification of the whole product, and not a guarantee that nothing has gone wrong.

Ask for the report itself, or at minimum the bridge letter that covers the gap since the last audit ended. Then check three things before you accept it as an answer:

The Trust Services Criteria matter here too. Security is the only mandatory criterion; Availability, Processing Integrity, Confidentiality, and Privacy are added at the vendor's discretion. A report scoped to Security alone says nothing about whether the vendor actually deletes your data when asked. Confirm which criteria are in scope before you assume the report covers what you care about.

The software security checklist

Score each area against the vendor's actual answers, not the marketing page. The red flag column is often more useful than the "good" column, because a vague or defensive answer is the signal that matters most.

Certifications and attestations

Authentication and access

Data handling

Subprocessors and the AI question

This is the newest real gap in most reviews, and the one buyers are least practiced at asking about. It overlaps with software integration requirements too: every middleware layer or synced system is another place your data sits, even briefly.

Shadow AI use inside your own team compounds this risk from the other direction. IBM's 2025 report puts the added cost of a breach involving shadow AI at $670,000, and nearly all organizations that had an AI-related incident say they lacked the access controls to have caught it earlier. A vendor who can't answer the subprocessor question clearly is asking you to trust a chain you can't see.

Logging and audit trail

Incident response and business continuity

Compliance and privacy

The SSO tax, and why it's a buying decision, not a security one

Charging extra for SAML-based single sign-on and SCIM provisioning, usually by gating both behind an Enterprise tier, is the single most common way a "secure" purchase turns into an unbudgeted one. The feature isn't optional once your identity team requires it; the price just wasn't on the page you evaluated.

Price the tier that actually includes SSO, not the one you screenshotted during the demo. The software total cost of ownership guide shows how to build that real number, since the SSO jump is exactly the kind of gap a sticker price hides.

How much security review is enough

A four-person team buying a $9-per-month scheduling tool with no customer data in it should not run the same forty-item review as a company buying payroll software. Match the depth of the check to what the tool can actually expose.

Price is a poor proxy for risk in one specific case worth calling out: automation platforms. A workflow tool costing $9 a month holds OAuth tokens for every system you connect it to, so its blast radius is the union of everything in your stack, not the tool itself. Review those at the tier of the most sensitive system they touch, whichever way you go on Zapier vs. Make.

Questions to ask the vendor before you sign

Paste these into an email after the demo, when the answer has to be in writing instead of improvised on a call.

1. "Can you send the SOC 2 report itself, or the bridge letter, not just a summary?" Stalling here usually means settling for the logo instead of the document.

2. "What's in scope on the report, the whole product or a subset of it?" "The whole platform" with no detail behind it isn't a real answer.

3. "Does the report have any exceptions, and what were they?" "It's clean" without offering to show you the section is unverifiable.

4. "Which tier includes SSO and SCIM, and what does that tier cost?" A callback-to-sales answer means the price on the page wasn't the real price.

5. "What's the breach notification window in the contract, in hours or days?" A policy page with no contractual number binds nobody.

6. "Can you share your subprocessor list, including any AI model providers, and do you train on our data?" Hesitation usually means "yes, and we'd rather not say."

7. "If we cancel, what happens to our data, and by when is it deleted?" No timeline means whenever someone gets around to it.

How to test security during a trial

A vendor's answers are claims. A trial is where you check whether they're true.

Common security review mistakes

Accepting the logo instead of the report. A SOC 2 badge on a marketing page proves someone applied for an audit, not that you've seen the scope or the exceptions.

Skipping the exceptions section. It's the one page written specifically to tell you where a control didn't hold up, and it's the page almost nobody opens.

Pricing the wrong tier. Scoring a vendor's security posture against a plan that doesn't include SSO produces a confident, wrong answer about a product you're not buying.

Treating AI features as a black box. Shipping an AI assistant without asking which model providers see your data, or whether you can opt out of training, leaves a gap most checklists from a year ago don't mention.

Running the same review for every tool. A forty-item review for a low-risk internal tool wastes reviewer time, and trains the team to skip the process on the purchase that actually needed it.

What a security review actually costs

The cost here isn't a vendor line item, it's reviewer time, and it scales with the risk tier from the table above, not with how interesting the tool looks in a demo.

A low-risk tool review takes minutes: confirm SOC 2 is mentioned, MFA exists, and there's a stated deletion policy. A PII-holding tool runs a few hours across certifications, access, data handling, and subprocessors, plus whatever time it takes the vendor to produce the documents. A money-or-health-data tool adds legal review of the DPA on top, which is where the real delay lives, not in reading the SOC 2 report itself.

The fastest way to blow the budget is applying tier-three scrutiny to a tier-one purchase. The second fastest is the reverse: finding the gap after signature, when the fix costs a renegotiation instead of a follow-up email.

Frequently asked questions

What's the actual difference between SOC 2 Type I and Type II?

Type I checks whether controls are designed correctly on a single point in time. Type II checks whether those same controls operated correctly over a period, usually six to twelve months. Type II is the stronger signal because it proves the controls actually worked in practice, not just on paper.

Do we still need to ask about ISO 27001 if a vendor already has SOC 2?

Yes. They're different frameworks answering different questions: ISO 27001 certifies an ongoing information security management system, while SOC 2 is an audit opinion over a defined period. Having one doesn't guarantee the other, so ask for whichever ones matter to your compliance requirements.

Why do so many vendors charge extra for SSO?

Because they can. SAML and SCIM cost real engineering to build and maintain, and gating them behind an Enterprise tier captures budget from larger, security-conscious buyers who need the feature. Treat it as a pricing decision to budget around, not a red flag, as long as it's priced into your evaluation from the start.

What should actually be in a Data Processing Agreement?

At minimum: the categories of data processed, the purpose of processing, the subprocessor list or a reference to it, data retention and deletion terms, breach notification obligations, and the transfer mechanism (like Standard Contractual Clauses) if data crosses borders. If a vendor's standard DPA is missing more than one of these, that's worth pushing back on before you sign.

How do I find out if a vendor trains AI models on our data?

Ask directly, in writing: does the product train on customer data, is there an opt-out, and which AI model providers (OpenAI, Anthropic, Google, or others) are involved as subprocessors. A vague answer like "we may use data to improve our services" is not a policy, it's an evasion, and it belongs in the subprocessor question you ask before signing, not after.

Is it overkill to run this whole checklist for a small, cheap tool?

Yes, for a genuinely low-risk tool with no customer data. Use the proportionality table above to scope the review to what the tool can actually expose. The checklist earns its full weight on anything touching customer PII, money, or health data, not on every purchase order that crosses your desk.

Get the report before you sign, not after

"They have SOC 2" is the start of a conversation, not the end of one. The report has a type, a scope, an audit period, and an exceptions section, and every one of those details changes what the claim is actually worth. A vendor willing to hand over the real document, name their subprocessors, and put a notification window in the contract, not just the policy page, has told you something a sales call never will.

Scope the review to the risk tier, ask the questions in writing, and test the answers during the trial instead of taking them on faith. That's the difference between catching the gap in month one and finding it as a breach disclosure in month fourteen.

Related reading

• How to build a software shortlist
• SaaS vendor evaluation scorecard
• Software integration requirements checklist
• Software total cost of ownership guide
• How to run a software trial
• CRM evaluation criteria checklist
• HR software evaluation criteria
• Help desk evaluation criteria
• ERP evaluation criteria
• How to choose payroll software
• Zendesk vs. Freshdesk: which to choose
• Apollo vs. Outreach: which to choose
• Zapier vs. Make: which to choose
• Best AI accounting tools: how to choose