- Security questionnaires are useful only when they ask for evidence tied to how the product is configured, patched and supported in practice.
- Prioritize secure defaults, privileged access, vulnerability handling, update capability and usable logs before generic compliance badges.
- Use the answers to make a documented accept, pilot or escalate decision—not to pretend that one vendor is risk-free.
Most software buying processes still leave security until the end: a long spreadsheet arrives after the business team has picked a favourite, the vendor returns a reassuring set of yeses, and everyone treats the exercise as complete. That is backwards. The point is not to collect the largest possible questionnaire. It is to learn how a product will behave when a credential is stolen, a serious flaw is found, an administrator leaves, or an update needs to reach every customer.
That approach is increasingly reflected in public guidance. CISA's Secure by Demand material asks buyers to make security part of procurement, while NIST's Secure Software Development Framework sets out practices for preparing, protecting and responding across the software lifecycle. The UK's NCSC Software Security Code of Practice makes a similar case: security and resilience depend on design, development, deployment and maintenance—not a point-in-time promise.
Start with product behaviour, not a badge
A SOC 2 report or an ISO certificate can be relevant evidence, but neither tells a buyer whether the particular product will expose accounts, make recovery too easy, or leave an administrator without useful logs. Ask the vendor to show how the current product works, then record what is included, what is optional and what remains an exception. A clear "not yet" with a sensible mitigation is more useful than an untestable claim that everything is covered.
The five evidence areas that matter most
1. Secure defaults and privileged access
Ask which security controls are on by default, especially for new tenants and administrator accounts. Can phishing-resistant MFA be required for privileged roles? Are weak recovery methods disabled or time-limited? Can an organisation apply least privilege and review elevated access? CISA's buyer guidance explicitly highlights strong authentication, secure controls and secure-by-default configuration as selection considerations.
2. Vulnerability disclosure and remediation
Look for a published vulnerability disclosure route, a responsible owner, and a process for notifying affected customers when a material issue is discovered. Then ask how the vendor prioritizes and fixes flaws in the product you are buying. The useful answer includes severity handling, customer communication and a way to track remediation—not just a promise to "follow best practice."
3. Updates, patches and end-of-support
For hosted software, understand who applies security updates and how customers hear about disruptions. For software you install, ask how updates are verified, whether they can be centrally managed, and how long versions receive security fixes. Buyers should also ask for the support and end-of-life policy before the contract term makes that question expensive.
4. Logging, export and incident support
A product cannot be investigated if the customer cannot see meaningful events. Confirm which login, admin, data-access and configuration-change events are retained; whether they can be exported; and which plan includes them. Ask what happens during an incident: how a customer opens an urgent case, what the vendor shares, and how quickly it can revoke access or preserve evidence.
5. Software supply-chain visibility
Not every supplier needs to hand over a complete bill of materials, but a risk-sensitive buyer should understand the dependency and third-party-service picture. Ask whether the vendor can describe critical dependencies, how it receives vulnerability intelligence, and how it evaluates changes to its build and deployment environment. The right depth depends on the data and business process involved; the goal is to expose a dependency risk before it becomes an outage or incident.
| Question to ask | Useful evidence | Decision signal |
|---|---|---|
| Can admins enforce strong sign-in rules? | Current product documentation or a scoped demonstration | Accept or pilot |
| How are critical flaws disclosed and fixed? | Published policy plus a clear customer-notification process | Accept or escalate |
| What events can we investigate? | Event list, retention period and export method for the intended plan | Accept or add a control |
| How do updates and end-of-support work? | Patch, release and lifecycle policy | Accept, contract condition or reject |
Turn answers into a real decision
Do not score a vendor just by adding up yes answers. Mark each requirement as met, met with a compensating control, planned with a date, or not met. Give the accountable business owner a short record of the residual risk and the planned follow-up. That helps a smaller team avoid two bad extremes: holding a low-risk purchase to an impossible standard, or approving a high-impact system because the sales process was smooth.
When the product handles privileged access or important customer data, run a narrow pilot. Test the settings that matter: administrator enrollment, a recovery attempt, log export, a simulated leaver and the support route. This is not a claim that a product is safe; it is a way to check whether the promised controls work in the environment where they will be used. The same practical discipline applies to identity controls, as our passkey renewal checklist explains.
Sources and further reading
- CISA: Secure by Demand Guide
- NIST: Secure Software Development Framework (SP 800-218)
- UK NCSC: Software Security Code of Practice
- CISA: Software Acquisition Guide for Enterprise Consumers
Frequently asked questions
Is a security certification enough to approve a software vendor?
No. A certification can be one input, but buyers still need product-specific evidence about access controls, updates, logging and incident handling for the service they will use.
Should a small company ask every vendor for an SBOM?
Not necessarily. Scale the request to the product's risk. For a high-impact system, ask how critical dependencies are managed and how the vendor responds to supply-chain vulnerabilities; for lower-risk tools, focus on the controls that affect your accounts and data directly.