A mid-size logistics company shared their entire customer database with the public internet for 11 days. The cause? They never asked their help desk vendor a single question about data encryption during evaluation. The breach cost them $2.4 million in fines, legal fees, and lost contracts.
That number isn't unusual. IBM's 2025 Cost of a Data Breach Report puts the average at $4.88 million globally. Smaller companies often fare worse proportionally because they lack the infrastructure to recover quickly.
Here's the uncomfortable truth: most software buyers spend more time comparing feature lists than reviewing security posture. They'll debate whether a tool has Kanban boards but never ask where their data is stored or who can access it.
This checklist exists so you never make that mistake. Print it. Share it with your procurement team. Bring it to every vendor demo. The 30 minutes you spend on security evaluation could save you millions.
The 5 Non-Negotiable Security Requirements
Before you evaluate a single feature, confirm these five. If a vendor fails any one of them, walk away. No exceptions.
1. SOC 2 Type II Certification. SOC 2 Type I means a vendor designed security controls. Type II means an independent auditor verified those controls actually work over a 6-12 month period. Always ask for Type II. Demand the most recent report. If the vendor only has Type I, they're early in their security journey. That might be acceptable for a startup tool managing non-sensitive data. For anything touching customer information, financial records, or employee data? Non-negotiable.
2. Encryption at Rest and in Transit. Your data should be encrypted using AES-256 when stored on their servers (at rest) and TLS 1.2 or higher when transmitted between your browser and their platform (in transit). Ask specifically about encryption key management. Who holds the keys? Can you bring your own keys (BYOK)? Enterprise vendors like Salesforce and ServiceNow offer BYOK. Smaller vendors often don't. That matters if you operate in regulated industries.
3. Multi-Factor Authentication (MFA). The vendor must support MFA for all user accounts, not just admin accounts. Check for support of authenticator apps (TOTP), hardware keys (FIDO2/WebAuthn), and SSO integration. A shocking number of breaches start with a compromised password. In 2024, the Change Healthcare breach affected 100 million records. It started with stolen credentials on an account that lacked MFA.
4. Role-Based Access Control (RBAC). Every user should have the minimum access required to do their job. Period. Verify the vendor offers granular permission settings. Can you create custom roles? Can you restrict access by department, geography, or data type? Flat permission structures where everyone sees everything are a breach waiting to happen.
5. Audit Logging. Every action in the system should be logged with who did it, when, and from where. Logs should be immutable, meaning users cannot delete or alter their own activity records. Ask how long logs are retained. 90 days is the minimum for most compliance frameworks. Healthcare and financial services often require 7 years. Also ask whether logs can be exported to your SIEM tool (Splunk, Datadog, etc.).
Data Privacy Compliance by Region
If your company operates internationally or serves customers across borders, you need to verify compliance with regional data privacy laws. Getting this wrong carries real financial penalties.
GDPR (European Union). The General Data Protection Regulation affects any company processing EU resident data, regardless of where the company is based. Key verification points: Does the vendor offer a Data Processing Agreement (DPA)? Can they confirm data residency within the EU? Do they support the right to erasure (deleting a specific person's data upon request)? Have they appointed a Data Protection Officer? GDPR fines can reach 4% of annual global revenue. Meta was fined $1.3 billion in 2023 for GDPR violations.
CCPA/CPRA (California). The California Consumer Privacy Act and its amendment apply to companies serving California residents. Verify: Does the vendor allow you to fulfill consumer data access and deletion requests? Do they sell or share personal information with third parties? Can they provide a record of all data categories collected? The California Attorney General has actively enforced CCPA since 2020.
LGPD (Brazil). Brazil's data protection law mirrors GDPR in many ways but has unique requirements. Confirm: Does the vendor have a legal representative in Brazil if they process Brazilian data? Can they comply with LGPD's data portability requirements? Do they support the specific consent mechanisms LGPD requires?
PIPEDA (Canada). Canada's privacy law requires organizations to obtain consent for data collection. Check: Does the vendor's data collection align with PIPEDA's ten fair information principles? Can they demonstrate accountability and transparency in data handling? Are their data retention policies documented and reasonable?
Don't assume a vendor is compliant just because they claim to be. Ask for proof. Request their compliance certifications, DPAs, and third-party audit reports. Any vendor who hesitates to provide these documents is a red flag.
Industry-Specific Compliance Requirements
Generic security is a baseline. Your industry likely has additional regulatory requirements that your software vendors must meet.
HIPAA (Healthcare). If you handle Protected Health Information (PHI), every vendor touching that data must sign a Business Associate Agreement (BAA). Not all vendors will sign one. Slack famously refused BAAs for years, forcing healthcare companies to find alternatives. Verify: Will the vendor sign a BAA? Do they offer HIPAA-compliant configurations? Can they provide evidence of HIPAA security controls? Are their backup and disaster recovery processes HIPAA-compliant? Fines range from $100 to $50,000 per violation, with annual maximums of $1.5 million per category.
PCI-DSS (Payment Card Data). Any software that processes, stores, or transmits credit card data must comply with PCI-DSS. This applies even if the vendor uses a payment processor like Stripe. Verify: What is their PCI-DSS compliance level? Do they store card data, or do they use tokenization? When was their last PCI audit? Can they provide their Attestation of Compliance (AOC)?
FERPA (Education). Schools and educational institutions must protect student records. Software vendors handling student data must comply with FERPA. Confirm: Does the vendor have experience with educational institutions? Will they sign a FERPA-compliant data sharing agreement? Can they ensure that student data is not used for marketing or sold to third parties?
SOX (Public Companies). Sarbanes-Oxley compliance requires public companies to maintain accurate financial records and internal controls. Software handling financial data must support SOX requirements. Check: Does the software maintain a complete audit trail of financial transactions? Can it enforce separation of duties? Does it support the internal controls your auditors require?
Is this starting to feel overwhelming? Good. Security evaluation should feel thorough. The companies that skip these steps are the ones that end up in the news.
The Vendor Security Questionnaire: 25 Essential Questions
Send these to every vendor before signing a contract. Group them by category and require written answers, not verbal assurances.
Data Protection (Questions 1-5). 1) Where is our data physically stored, and in which countries? 2) Is our data encrypted at rest and in transit, and what encryption standards do you use? 3) How is our data logically separated from other customers' data? 4) What is your data retention policy, and can we customize it? 5) If we terminate the contract, how do we get our data back, and how quickly?
Access Control (Questions 6-10). 6) Do you support SSO via SAML 2.0 or OpenID Connect? 7) Is MFA available for all user tiers, or only enterprise plans? 8) How granular are your permission controls? 9) Can we restrict access by IP address or geographic location? 10) How do you manage access for your own employees to our data?
Incident Response (Questions 11-15). 11) What is your incident response plan, and how quickly will we be notified of a breach? 12) Have you experienced a data breach in the past 3 years? 13) Do you carry cyber liability insurance? 14) What is your average time to detect and respond to security incidents? 15) Can you provide references from customers who have been through a security incident with you?
Compliance and Auditing (Questions 16-20). 16) What compliance certifications do you hold (SOC 2, ISO 27001, etc.)? 17) When was your most recent third-party security audit? 18) Can we review your SOC 2 Type II report? 19) Do you perform regular penetration testing, and can we see the results? 20) How do you handle vulnerability disclosure?
Infrastructure and Operations (Questions 21-25). 21) What cloud infrastructure do you use (AWS, Azure, GCP)? 22) What is your disaster recovery plan, and what is your RPO/RTO? 23) How often do you perform data backups, and are they tested? 24) Do you have a documented change management process? 25) What is your software development lifecycle, and do you perform code security reviews?
A professional vendor will answer all 25 without flinching. If they push back on transparency, consider what else they might be hiding.
Evaluating SLAs: Uptime, Response Times, and Backups
The Service Level Agreement is where promises become contractual obligations. Read it carefully.
Uptime Guarantees. Most vendors promise 99.9% uptime. That sounds impressive until you do the math. 99.9% allows 8.76 hours of downtime per year. For a help desk platform your support team relies on, that could mean a full day of lost productivity. Push for 99.95% (4.38 hours/year) or 99.99% (52.56 minutes/year) for mission-critical systems. And verify what counts as downtime. Some vendors exclude scheduled maintenance windows from their uptime calculations.
Incident Response Times. SLAs should specify response and resolution times by severity. Critical incidents (system completely down): Response within 15 minutes, resolution within 4 hours. High severity (major feature broken): Response within 1 hour, resolution within 8 hours. Medium severity (minor feature issue): Response within 4 hours, resolution within 24 hours. Low severity (cosmetic or minor): Response within 24 hours, resolution within 5 business days.
Data Backup Frequency. How often does the vendor back up your data? Daily backups are the minimum. For transactional systems, look for hourly or continuous backups. Where are backups stored? They should be in a geographically separate location from the primary data. Can you request a data restore? How long does it take? Test this before you need it in an emergency.
Financial Remedies. What happens when the vendor misses their SLA? Look for service credits with teeth. A 5% credit for an hour of downtime is meaningless. Industry standard is 10-30% monthly credit for significant SLA breaches. Also look for termination rights if SLA breaches become chronic.
Data Portability and Exit Planning
Nobody buys software planning to leave. But you should always plan your exit before you sign the contract.
Data export formats matter. Can you export your data in standard, machine-readable formats like CSV, JSON, or XML? Or does the vendor use proprietary formats that lock you in? Ask specifically: Can we export all data including attachments, historical records, and metadata? Is the export automated or do we need to request it from support? Are there any fees for data export?
Some vendors make leaving intentionally painful. They throttle export speeds, charge extraction fees, or provide data in formats that are technically open but practically unusable without significant transformation.
Create a documented exit plan before you sign. It should include: timeline for data migration (typically 30-90 days), list of all data types to extract, format specifications for each data type, responsible parties on both sides, confirmation that the vendor will delete your data after migration. Get the exit terms in your contract, not in a handshake.
What about your integrations? If you've built custom integrations through the vendor's API, understand what breaks when you leave. Document all integration touchpoints during implementation so you can plan replacements.
Red Flags During Vendor Security Evaluation
After evaluating hundreds of software vendors, certain patterns reliably predict security problems down the road.
Vague answers to specific questions. When you ask about encryption standards and they say 'we use industry-standard security,' press harder. A mature vendor will say 'AES-256 for data at rest, TLS 1.3 in transit, with keys managed through AWS KMS.' Specificity matters.
No SOC 2 report available. Any vendor serving business customers handling sensitive data should have SOC 2 Type II at minimum. If they don't, ask why and when they plan to get it. A startup in its first year gets a pass. A five-year-old company with enterprise customers? That's a red flag.
Shared infrastructure without tenant isolation. Multi-tenant architecture is standard and generally fine. But your data should be logically isolated from other customers. Ask whether a vulnerability in another tenant's configuration could expose your data.
Resistance to signing a DPA or BAA. If the vendor hesitates to sign legally binding data protection agreements, they either don't understand the requirement or know they can't meet it. Neither option is acceptable.
No penetration testing history. Regular third-party penetration testing is standard practice. Vendors who don't do it, or won't share results, are cutting corners on security.
Slow or defensive responses to security questions. Security-mature companies welcome tough questions because they've prepared for them. Vendors who get defensive or slow-roll their responses are often hiding gaps.
Remember: the vendor's security posture becomes your security posture the moment your data enters their system. Choose accordingly.