Vendor Software Security Questionnaire: The 20 That Matter

A vendor security review usually lands on a PMO lead as a spreadsheet of 200 to 300 rows, most of which every SaaS vendor answers the same way. A software security questionnaire for a vendor works better as 20 questions you can score, because the rows that separate a safe tool from a risky one are few. According to IBM's 2025 Cost of a Data Breach report, as reported by CyberScoop, the global average breach cost $4.44 million and supply-chain compromises were the second most prevalent attack vector at nearly 15%, so the vendor you adopt is part of your own exposure.

The short answer. Ask 20 questions across five areas: identity, data protection, audit, compliance evidence and exit. Score each answer as specific, general or evasive. Three answers should end an evaluation on their own: a compliance claim with no named standard, no committed breach-notification window, and no documented way to export and delete your data.

What belongs in a software security questionnaire for a vendor?

The 20 questions fall into five areas, and each area maps to one thing you will have to defend to your own security team. The table gives the questions and what a strong answer contains.

#	Question	A good answer names
1	Is two-factor authentication available to every user?	The method (for example TOTP) and which plans
2	Is SSO supported, and through which protocols?	SAML 2.0 or OIDC, and the plan it starts on
3	Is automatic deprovisioning supported?	SCIM and what happens to the user's other memberships
4	What stops a compromised admin granting themselves more rights?	A specific control, such as owner-only permission edits
5	Can session length and password policy be set by the customer?	Which settings and their defaults
6	How is data encrypted in transit?	A minimum TLS version
7	How is data encrypted at rest?	The algorithm and where keys are stored
8	Can the customer hold the encryption keys?	A precise yes or no, and the plan or deployment option
9	How is one customer's data isolated from another's?	The mechanism, not the word "isolated"
10	How are secrets managed in production?	A named vault and what happens if one is missing
11	Is every configuration change logged?	Before and after values, and who can read the log
12	Can the audit log be exported?	Formats and filters
13	How long is data retained, and can the customer set it?	Presets or a configurable period
14	Which compliance standards apply, and where is the evidence?	A named standard and a report, or a stated audit status
15	Is customer data used to train AI models?	A direct no or a described exception
16	Which sub-processors handle customer data?	A published list
17	What is the breach-notification commitment?	A number of hours or days, in writing
18	How are vulnerabilities reported and handled?	A contact and a process
19	How do I export my data on leaving?	Formats a rival tool can open
20	How is my data deleted on exit, and how soon?	A period and a confirmation

Questions 1 to 5 test identity, 6 to 10 test data protection, 11 to 13 test audit, 14 to 18 test compliance evidence, and 19 and 20 test exit. The diagram below shows the three answers that stop a review and where each sits in that sequence.

How do you score the answers?

Score each answer on three levels rather than pass or fail, because few vendors fail outright and most differ in how specific they are.

Specific. The answer names a control, a plan or tier it applies to, and a limit. "TOTP two-factor on every plan, with single-use backup codes" is specific.
General. The answer is true but names nothing. "We take security seriously and use industry-standard encryption" is general.
Evasive. The answer restates the question, links to a policy page without naming the control, or says "contact sales" for something that should be a yes or no.

Sum the scores across 20 questions and compare vendors on the total plus the count of evasive answers. Two vendors with the same total but different evasive counts are not equal: evasion on questions 8, 14 and 17 matters far more than on question 16.

What should a good answer look like?

A good answer concedes its own limits. Onplana's own security and compliance overview is a worked example of the format, and it includes a "What's Not Here Yet" section: it states that there is no SOC 2 report today, that the formal third-party audit is in progress, and that a customer-facing data subject request portal is still on the roadmap. A vendor listing only strengths and no gaps has either not looked or is not saying.

On question 8, the precise form matters. The correct answer for a dedicated deployment is bounded: in a dedicated deployment, the encryption keys live in your own Azure subscription. Anything broader than what the vendor can demonstrate, such as promising customer-managed keys on every plan, should be probed.

What answers should end the evaluation?

Three answers justify stopping, whatever else the vendor says.

A compliance claim with no standard. "Fully compliant" with no named framework, report or audit status cannot be checked, and an unverifiable claim is worth nothing in your own audit.
No committed breach-notification window. If the vendor will not put hours or days in writing, you cannot meet your own notification duties.
No way out. If question 19 or 20 gets a vague reply, the vendor holds your project history hostage. Data portability is a control, not a convenience.

How do you verify what a vendor tells you?

A questionnaire records what a vendor says, so verify the high-stakes answers yourself during the trial. Create a test user with the lowest role and try to reach another project. Change a policy setting and look for the entry in the audit log. Export your data and open it in a tool that is not the vendor's. Ask the vendor for evidence, such as a sample audit-log export, instead of a sentence.

For the surrounding decision, the PM tool evaluation criteria set the weights and the PM tool RFP template puts these questions into a procurement document. If you are weighing a tool that uses AI agents, the agent security review for buyers adds the questions specific to them. The Onplana security page lists the current controls, and Onplana answers SIG, SIG-Lite and CAIQ spreadsheets through support@onplana.com, usually within two business days.

Read how Onplana answers these 20 questions The security and compliance overview covers identity, data protection, audit and retention control by control, including what is not built yet. → Open the security overview

Frequently asked questions

How many questions should a vendor security questionnaire have?

Twenty well-chosen questions cover the risk for a project management tool. Longer standard formats such as the CAIQ or SIG exist for formal reviews, but a short list you can score is what gets read and compared.

What answers should end a vendor security evaluation?

Three: a claim of compliance with no named standard or report, no committed notification window after a breach, and no documented way to get your data out and have it deleted. Each leaves you unable to prove anything later.

Is a vendor without a SOC 2 report automatically disqualified?

No, but it must say so plainly. A vendor that states its audit is in progress, offers its control evidence in the meantime and gives a date range is answering honestly; one that implies a report it does not hold is not.

Who should own the security review at a PMO?

The PMO lead owns the scoring and the decision, and the security or IT team owns the technical answers. Splitting it that way stops a buyer from approving what nobody technical read.

Can a vendor answer a security questionnaire with a link to its security page?

Partly. A security page answers the common questions, but a questionnaire answer should name the specific control, the plan it applies to and its known limits, which a marketing page rarely does.

Where does a questionnaire fall short?

It records what a vendor says, not what it does. Pair it with a trial that tests permissions and exports yourself, and ask for evidence such as an audit log sample rather than a written assurance.