SaaS security claims: evidence to request before signing

Security review often slows down because a vendor can produce polished materials quickly, while the buyer still lacks clear answers about the actual product being purchased.

The real question is usually narrower: what evidence shows this SaaS product, on this plan and in this setup, is suitable for the data and business process your team is about to place into it?

A focused SaaS security questionnaire helps turn marketing statements into checkable answers. Instead of asking everything, ask for the evidence that matters to your risk decision: authentication options, logs, vulnerability handling, incident cooperation, subprocessors, and what happens to your data at exit. The goal is not to demand perfect security or every internal policy. It is to understand the practical limits, record any exceptions, and make sure the important points are carried into the contract set before signing.

What a first-pass security review needs to cover

If the tool will handle customer data, employee information, confidential business records, or important operational processes, focus your review on the points most likely to matter in practice.

A useful first-pass SaaS security questionnaire should usually cover:

• What product, environment, and plan are in scope
• What data goes in, where it goes, and which parties can access it
• How users authenticate and how access is controlled
• How vulnerabilities, patches, and security updates are handled
• What happens if there is a security incident affecting your data or service
• Which subcontractors or hosting providers are involved
• What evidence supports the answers, and when those answers may change

That structure keeps the review proportional. A low-risk marketing tool may need only a lightweight check. A system that stores sensitive personal information or becomes operationally critical may justify a deeper legal and security review, more evidence, and slower procurement.

The first step is to define the proposed use case. The same SaaS vendor may be low risk for a public newsletter workflow, but much higher risk if it will store payment-related information, sensitive customer notes, employee records, confidential product plans, or data that will be used to make important business decisions. The questionnaire should match the specific workflow, not the vendor's general reputation.

CISA's Secure by Demand Guide is helpful here because it is aimed at software customers asking questions of software manufacturers. It is procurement guidance, not a general binding rule for all private US SaaS purchases. One of its practical themes is that a supplier's overall enterprise security is not the same thing as the security of the delivered product you are buying.

That distinction matters for startups and small businesses because procurement teams often have limited time. You do not need to ask every possible security question at the start. You do need enough information to know whether to proceed, ask for contract protections, choose a different plan, configure the tool differently, or pause the deal.

Separate company-level reassurances from product-level facts

This is where many buyers lose time. A vendor may have polished answers about its company security program, internal training, or general certifications, while your real risk sits in a narrower place: the exact SaaS product, version, module, deployment model, or subscription tier you will use.

Ask each material answer four follow-up questions:

• Which product, version, service tier, or feature does this answer apply to?
• What evidence supports the answer?
• Who owns the control internally?
• When can the answer change, and how will we be notified?

For example, "we support SSO" is incomplete. You need to know whether SSO is available on your plan, whether it covers all user roles, whether local password login can be disabled, and whether administrators can enforce multifactor authentication.

Likewise, "all data is encrypted" leaves open basic questions. Is data encrypted in transit, at rest, in backups, in logs, and in exports? Does the answer apply to all customer content or only selected fields? Are there exceptions for troubleshooting copies or temporary files?

Do not treat an unchecked blank or a simple "Yes" as verified security. Record any qualification, exception, dependency, or planned future feature. A qualified answer may still be acceptable if your team understands the risk and the contract reflects the reality.

Evidence can take different forms depending on the question. A product security page may be enough for background information. A configuration screenshot may be better for a specific feature. A report excerpt, policy summary, support article, architecture description, or written response from a named vendor contact may be needed where the answer affects your risk decision. The point is to avoid relying only on broad sales language when the operational detail is important.

Also check whether the feature is included in the price you are approving. Some security features are standard, while others require an enterprise tier, additional module, professional services setup, or customer-managed configuration. If your approval depends on SSO, administrative logs, data residency, or a particular export format, make sure the commercial papers and technical setup match the security answer.

What to ask about identity, vulnerabilities, incidents, and subprocessors

Most buyers do not need a massive questionnaire. They do need questions that expose the security controls most likely to affect day-to-day risk.

Identity and access. Ask how your users authenticate, whether SSO is supported, whether multifactor authentication is available or enforceable, how privileged access is limited, and whether access events are logged. If the product will be used by several teams, ask whether role-based access can be tailored by function.

Vulnerability handling and updates. Ask whether the vendor has a process to identify vulnerabilities, prioritize them, and deploy fixes. Find out whether security patches are applied centrally by the vendor, whether customer action is required, and how urgent issues are communicated. You are not looking for a promise that no vulnerabilities exist. You are looking for a defined process and a realistic explanation of how issues are addressed.

Incident response and customer cooperation. Ask what types of incidents the vendor treats as notifiable, who will contact you, what information will be provided, and what cooperation is available if your team needs logs, timelines, or containment details. A useful answer should describe process, not just say the vendor "takes incidents seriously." It should also help you understand whether the vendor's process will give your team enough information to meet its own customer, regulator, insurer, or internal reporting obligations.

Subprocessors and hosting. Ask which outside providers materially support the service, such as cloud hosting, customer support tooling, email delivery, analytics, or payment processors. Then ask how the vendor approves and oversees those providers, and whether you will receive notice if major subprocessors change.

Data exit and continuity. If the relationship ends, ask how you can retrieve your data, in what format, within what period, and what happens to remaining copies. Also ask what business continuity or resilience measures are in place if the service experiences disruption.

The FTC's Start with Security guide helps frame these questions. It emphasizes keeping security current, addressing vulnerabilities, setting security expectations in service-provider contracts, and checking whether providers meet them. That does not create one universal security questionnaire or a standard private SaaS contract form, but it does show why overstated or unsubstantiated security claims and weak provider oversight can create real legal and business risk.

How to treat SOC 2, ISO, and other certifications. Certifications and audit reports can be useful, but they are not the end of the review.

If a vendor offers a SOC 2 report, ISO certification, or similar assurance material, check the scope, period covered, and whether it actually applies to the product and environment you will use. A parent company certification may not tell you much about a newly acquired product. A report covering one date range may not answer how current controls are being maintained now. A broad certification may also say little about whether a specific feature exists in your plan.

That matters because these materials usually do not prove every point a buyer cares about. They do not automatically confirm that SSO is available on your tier, that certain logs are accessible to customers, that a particular data export exists, or that the vendor will meet a notification or cooperation timeline you need in a contract.

Ask the vendor to connect the assurance material to your questionnaire responses. For example, if the vendor says logging is enabled, ask whether the evidence is a report excerpt, a policy, a screenshot, a service description, or a control summary. If the answer depends on a paid add-on, managed configuration, or custom implementation, capture that clearly.

In short, a SOC 2 or ISO document can support trust, but it does not replace product-specific diligence or negotiated commitments.

Turn the material answers into contract terms before you sign

A questionnaire is a decision tool. It is not a substitute for a vendor agreement.

When an answer matters to your risk decision, tie it to a named document and defined scope. That may be a security schedule, order form, service description, SaaS data processing addendum, incident-cooperation process, or subprocessor notice clause.

The points most often worth elevating into the contract include:

• Which service, modules, environments, and customer tiers are in scope
• Required security features such as SSO availability or logging access, if they are deal-critical
• Incident notification and cooperation expectations
• Access to reports, summaries, or other agreed evidence of controls
• How and when subprocessor changes will be communicated
• Data return, export assistance, and deletion expectations at exit
• Any known exceptions, temporary workarounds, or roadmap dependencies

Each material item should identify the response owner, review timing, and any limitation. For example, if a vendor says a feature is available only in a premium tier, your papers should say that. If a security report is available once per year under confidentiality restrictions, document that rather than assuming open-ended audit access.

This handoff is especially important because security marketing language is often broad, while contracts are where scope, timing, remedies, and exceptions are clarified.

Keep the review proportional, and know when to pause. NIST's due diligence quick-start guide is a useful due-diligence resource for information and communications technology suppliers, and it treats due diligence as researching available, pertinent information so buyers can make informed acquisition decisions. It is a risk-assessment resource, not a blanket legal requirement for every buyer or vendor.

Use that mindset to decide how deep to go. The more sensitive the data, the more integrated the tool, and the harder the service would be to replace, the more evidence and contractual clarity you should expect.

Pause procurement or escalate to specialized legal or security support where, for example:

• The vendor cannot say which product or plan its answers apply to
• Critical answers rely on future roadmap items
• The vendor refuses to explain exceptions behind "Yes" answers
• Incident cooperation, subprocessor transparency, or exit rights are too vague for your use case
• The service will handle regulated or especially sensitive data

Federal sector-specific rules and state privacy or breach laws can also change the legal review. Health, financial, education, biometric, children's, or employment-related data may trigger additional requirements, and state rules may affect contract expectations, breach response, or vendor oversight. There is no single nationwide answer that fits every SaaS purchase, so the buyer should confirm the requirements that apply to its data, customers, and operating states.

Make your questionnaire a living record. The best buyer questionnaires do not disappear once the contract is signed. Keep the final version with the contract papers, note any exceptions, and set a review point if the tool is high risk or business critical.

A practical record should show what was asked, who answered, what evidence was provided, what assumptions were made, and what follow-up is due after launch. That makes renewals easier and helps if a later incident raises questions about who promised what.

It also helps internal teams stay aligned. Legal, finance, IT, security, product, and operations may all care about different answers. Keeping a concise record reduces the risk that a deal is approved on one assumption, implemented on another, and renewed without revisiting the original limitations.

FAQs

Do we need a SaaS security questionnaire for every vendor?

Not every vendor needs the same level of review. Use a short questionnaire for low-risk tools, and ask for more evidence where the product will handle sensitive data, important workflows, or systems that would be hard to replace.

Is a SOC 2 report enough to approve a SaaS vendor?

Usually not by itself. A SOC 2 report can be useful evidence, but you still need to check whether it covers the exact product, environment, time period, and controls that matter to your purchase.

What if the vendor will not answer security questions?

Ask whether the vendor can provide an alternative evidence pack, standard security documentation, or responses under confidentiality. If key answers remain unclear, treat that as a procurement risk and consider whether the use case should be narrowed, escalated, or paused.

Which security answers should go into the contract?

Put deal-critical answers into the contract set, especially incident notice, subprocessor notice, security features you are relying on, access to agreed evidence, and data return or deletion at exit.

Key Takeaways

• Use a short, risk-based questionnaire to test security claims against the exact product, tier, environment, and data use in your deal.
• Ask for evidence behind material answers, and record exceptions, paid add-ons, configuration dependencies, and roadmap items.
• Focus on identity, logging, vulnerability handling, incident cooperation, subprocessors, and data return or deletion at exit.
• SOC 2, ISO, and similar materials can support diligence, but they do not replace product-specific answers or negotiated commitments.
• Move deal-critical security points into the contract set, and escalate where scope, incident support, or sensitive-data handling is still unclear.

If you need help turning SaaS security responses into a vendor agreement, SaaS data processing addendum, incident notification terms, subprocessor clauses, or data return and deletion provisions, readers can reach our team on (888) 449-8437 or team@sprintlaw.com. Where legal services are required, they are provided by licensed US lawyers at ElevateNext US, LLC, a trusted US law firm, through the Sprintlaw platform.