Describe testing by method, scope, frequency and evidence. Say which scans run, on what, how often, who reviews results and how fixes are tracked. Offer a sample report or a dated log. Avoid words like "comprehensive" or "full coverage" unless you can show the coverage.
What the questionnaire is really asking
The testing section usually has three underlying questions. Do you test before release? Do you find and fix problems in a reasonable time? Can you show it? Vague answers fail the third question even when the first two are fine.
NIST's Secure Software Development Framework frames these practices as reducing vulnerabilities in released software and addressing root causes to prevent recurrence. Questionnaires often borrow that language, so answering in the same terms helps.
A four-part answer pattern
Fill in each part with facts you can prove today.
- Method: "We run dependency scanning on every pull request."
- Scope: "It covers all production repositories. Two legacy services are scheduled for the next quarter."
- Frequency and trigger: "Scans run on each change and nightly on the main branch."
- Response: "Critical findings with a fix are assigned within one business day and tracked to closure."
Naming the gaps, like the two legacy services, makes the rest more believable.
Example wording table
| Instead of | Write |
|---|---|
| "We do comprehensive security testing" | "We run dependency scanning and static analysis on every pull request, and an external penetration test each year" |
| "All code is scanned" | "All repositories in the main organisation are scanned. Archived repositories are excluded" |
| "We fix vulnerabilities quickly" | "Our policy sets target fix times by severity, and we report adherence monthly" |
| "We follow best practices" | "We map our practices to the NIST SSDF and can share the mapping" |
Only claim a mapping or a test you have actually done. If the penetration test is booked but not complete, say it is scheduled.
Evidence to offer
- A recent scan summary with date and scope
- Your written severity and fix-time policy
- A redacted penetration test summary, if you have one
- A list of what is excluded and why
Do not attach raw scanner output containing customer data or internal hostnames.
Mistakes that cost deals
- Claiming a certification or attestation you do not hold. Say what you have, and say plainly what is in progress.
- Describing a tool instead of a practice. Buyers care what you do, not what you bought.
- Answering differently on each questionnaire. Keep one reviewed master answer set.
Where Safeguard fits
Safeguard's compliance and evidence automation can keep dated records of dependency scans, policies and gate decisions, which supports the evidence step. It does not perform static or dynamic testing, so describe those separately and name whatever tools you use for them.
Quick check
Should we list our scanner names?
Only if the buyer asks. Describe the method and results. Tool names matter less than scope, frequency and follow-through.
What if we have gaps?
State them with a date for closing them. Honest gaps read better than claims that fall apart in a follow-up call.
Sources
Last reviewed: 19 October 2026.
