Ask the vendor how often it releases security updates, how quickly it fixes vulnerabilities, how long it will support the version you buy, how it disrupts operations, how it tests patches, and what mitigation it offers before a fix exists. NIST publishes a sample list of exactly these questions.
Why buyers should ask
Every software product you run becomes part of your patching workload. A vendor that ships slow or disruptive fixes raises your cost and risk for years. Regulated organizations are also expected to review third parties. New York's financial services rule, for example, asks for due diligence on third-party service providers' cybersecurity practices and periodic reassessment based on risk, plus contractual guidance on matters such as notice of cybersecurity events.
Patching behavior is one of the few things you can ask about before signing and then test against reality afterward.
The questions
NIST SP 800-40 Rev. 4 proposes a sample questionnaire for new software. In plain form:
- Will you release updates to address vulnerabilities?
- How many patches and upgrades do you expect each year, how quickly do you address each vulnerability, do you bundle patches, and how often are emergency updates needed?
- For how many years will you keep correcting vulnerabilities?
- Do you release on a schedule, as needed, or both?
- Do you run a vulnerability disclosure and incident response program, and how transparent are you with customers?
- When a vulnerability is public but no patch exists, how should customers protect themselves, and will you provide an emergency mitigation?
- How disruptive is patching: restarts, reboots?
- How do you test patches, how often do customers have problems with them, and can patches be rolled back?
Turning answers into a file
| Question area | Evidence to request | What a good answer looks like |
|---|---|---|
| Support period | End-of-support policy page or contract term | A stated, dated commitment |
| Speed | Past advisories with release dates | Dates you can check yourself |
| Disclosure | Security contact and advisory archive | A public process |
| Mitigation | Sample advisory with workaround | Specific steps |
| Disruption | Release notes for restart needs | Plain statement |
| Testing | Description of release testing | Concrete stages, rollback |
Check public advisories rather than relying only on the answer. A vendor's past behavior is the best preview of future behavior.
Put it in the contract
Where possible, move key answers into contract terms: support duration, notice of security events, and cooperation on incidents. Policies change, contracts bind. This is general information, not legal advice, so involve your counsel on terms.
Revisit on a schedule
Reassess critical vendors periodically, as the New York rule contemplates for third parties. Keep the original answers so you can compare later behavior against what you were told.
Where tooling helps
Dependency and SBOM scanning shows which of your applications use a vendor's components and how many known vulnerabilities sit in them over time, giving you your own data to compare with vendor claims. Safeguard provides SBOM and dependency scanning for that purpose.
Quick check
Do these questions apply to open source too?
Mostly, with adaptation. There is no vendor to answer, so look at the project's release history, advisory process and maintainer activity instead.
Should every vendor get the full list?
No. Scale it to the risk the vendor presents. Critical systems and vendors with access to sensitive data deserve all eight.
Sources
- NIST SP 800-40 Rev. 4, section 3.7 Consider Software Maintenance in Procurement
- 23 NYCRR 500.11, Third party service provider security policy
Last reviewed: 19 October 2026.
