Build an evidence register before filling the questionnaire. For each answer, identify the exact product and environment, the control owner, a current record that supports the wording, the date it was checked, and any exception. Answer only as broadly as the evidence allows. If you assessed two of three production repositories, say two of three at named revisions, not “all code is continuously secure.” If a requested control has not been verified, give the gap, owner and target date rather than a confident yes.
The aim for a security leader is a packet that a buyer can evaluate and that engineering can defend later. The answer changes with the buyer's scope: a SaaS service, an on-premises release, a specific region, and a particular product version may have different evidence. A questionnaire is a set of claims about a defined delivery, not a substitute for an audit or a penetration test.
Treat each question as a claim with a boundary
Buyers often ask short questions: “Do you scan your code?”, “Is MFA required?”, “Do you retest vulnerabilities?”, or “Where is data stored?” A one-word answer hides the object, frequency and proof. Break each question into five parts before responding:
- Subject: Which service, repository, release, tenant environment or data type is the question about?
- Control: What policy or technical mechanism is actually in place?
- Operation: What record shows the control ran or was enforced for this subject?
- Exception: Which scopes, dates, roles or deployment paths differ?
- Owner and freshness: Who confirmed the answer, when, and when must it be revisited?
NIST's SSDF describes secure development practices and artifacts that can be used to discuss how a supplier develops and responds to vulnerabilities. NIST's enhanced vendor-risk assessment guidance explains why purchasers may seek more detailed supplier assurance. These sources support an evidence-oriented conversation; they do not turn a questionnaire response into proof that every vulnerability was found. Use the customer's actual wording and contract context rather than pretending one template satisfies every procurement process.
Assemble a small reusable evidence packet
Keep the packet separate from the raw internal evidence. A buyer may need the policy, a dated implementation summary, a redacted sample record and a contact for deeper diligence. They rarely need a source-bearing finding, credentials, exploit steps or another customer's data. Give restricted material through an approved channel to named recipients and log which version was shared.
The minimum packet has six parts:
| Part | Useful content | Boundary to disclose |
|---|---|---|
| Product and data-flow map | Services, environments, providers, regions and data categories | Unsupported regions or omitted subprocessors |
| Secure development process | Review gates, dependency management, release provenance and owner | Which repositories and release paths follow it |
| Assessment scope | Method, pinned revision, period, selected components and review outcomes | Excluded or unexamined code and runtime-only controls |
| Vulnerability workflow | Intake, verification, priority, assignment, fix and reassessment records | Open, accepted, unresolved and rejected claims kept distinct |
| Access and protection | Identity policy, roles, permission review and relevant technical configuration | Administrative exceptions and evidence not independently exercised |
| Incident and customer communication | Decision owners, escalation route and notification commitments | Commitment owner and applicable agreement; legal interpretation for counsel to assess |
Do not attach a “clean scan” screenshot without its scan date, target revision, selected rules, exclusions and completion state. A screenshot of a configured control is different from evidence that it operated for this customer-facing service. OWASP ASVS can help specify which application security requirements were examined, but naming the standard or mapping a few findings to it does not establish full verification or compliance.
Filled example: answer five difficult questions
Illustrative case; Harborline and every number below are fictional. No statement describes CodeSecPilot or an actual customer. Harborline sells a B2B portal. A prospective customer asks for evidence covering the production portal release at revision p73 and its three associated repositories. Harborline's security lead creates this register on 18 October 2026:
| Buyer question | Bounded response draft | Evidence to attach or offer | Owner and gap |
|---|---|---|---|
| “Do you assess all application code?” | “Two of three production repositories were assessed at pinned revisions this quarter. The third is scheduled; we make no coverage claim for it.” | Scope ledger showing 2/3 repositories, revision IDs, assessment dates and exclusions | AppSec lead; third repository review due 30 October |
| “Are vulnerabilities fixed and retested?” | “Approved findings are tracked. Two of three recent fix claims were positively reassessed on new revisions; one remains inconclusive pending a deployment control check.” | Redacted finding-status register and reassessment decision records; denominator 3 fix claims | Product security lead; check deployment control before closure |
| “Do developers use MFA?” | “The current production identity policy requires MFA for the listed developer roles.” | Policy export, identity-provider configuration snapshot and dated account sample | Identity owner; sample does not prove every past session used MFA |
| “Where are prompts and source processed?” | “The flow diagram identifies the configured providers and locations for this release. Provider retention wording is under legal and infrastructure review.” | Data-flow diagram and provider terms approved for sharing | Infrastructure and counsel; do not promise zero retention yet |
| “Is the portal free of critical issues?” | “We cannot make an absence claim. The report shows approved open findings, unresolved investigations and the assessment's reviewed scope as of 18 October.” | Authorized executive report with status definitions and denominator | Security lead; refresh before submission |
This example answers the customer's question without transferring internal exploit instructions. It also makes the 2/3 repository denominator and 2/3 positively reassessed fix-claim denominator explicit. The third repository and inconclusive fix are not quietly counted as safe or fixed. A buyer may ask for a broader review before proceeding; the packet gives both sides a concrete next step.
Reuse the packet after the product changes
Assign the five rows evidence IDs E-COV-18, E-FIX-18, E-ID-18, E-FLOW-18 and E-RISK-18. Each points to the restricted source record and the separate approved external excerpt. The ID preserves provenance; it does not make the answer permanently current.
A second prospect asks the same questions on 25 October. Three changes have occurred in this fictional continuation: Harborline added a fourth production repository, identity engineering introduced an emergency account exception, and infrastructure changed the model-processing route. Reusing all five answers would be faster and wrong.
| Existing answer | New fact | Reuse decision and replacement wording |
|---|---|---|
| E-COV-18: 2/3 repositories assessed | A fourth production repository was added; no additional review completed | Expired for a current estate claim. E-COV-25 says 2/4 assessed, with two named pending reviews. The historical 2/3 statement remains true for 18 October. |
| E-FIX-18: 2/3 fix claims positively reassessed | The original three claims and results have not changed | Reusable as a dated sample of those three claims. It cannot become “all fixes are retested” or a new current-period rate. |
| E-ID-18: listed developer roles require MFA | Emergency administrator account is now exempt from that policy | Reapprove exact role scope. A question about all privileged access needs the exception; the old developer-role wording cannot answer it. |
| E-FLOW-18: configured processing locations identified | New invocation profile selected; destinations not yet reconciled | Withdraw the current location assurance until the route and related logs/support flows are checked. Keep the pending-review answer. |
| E-RISK-18: dated risk report | Product and assessment scope changed | Refresh report and denominator; do not simply change the date on the old PDF. |
One change can expire several answers. The fourth repository changes coverage and may change release-process claims. The emergency identity exception can affect administrative access and incident-response assumptions. Link answers to the control or inventory they depend on so the owner receives the right review task when it changes.
A useful excerpt for the refreshed coverage evidence is:
E-COV-25 — approved external extract, 25 October 2026
Product: Harborline production portal; internal repository aliases retained.
Inventory: four production repositories as of this date.
Completed scoped source/policy assessments: A at revision [redacted],
B at revision [redacted], during the current quarterly review cycle.
C and D: no completed assessment under this method.
Excludes runtime penetration testing and an assurance of defect absence.
Underlying records: restricted scope ledger and reviewer decisions.
It supports: “Two of our four production repositories completed the stated source-and-policy assessment this quarter; the other two remain pending.” It cannot support: “Our entire platform undergoes continuous independent security testing.” Redacting repository names does not justify removing the denominator or exclusions. Share more detailed identity or source information only if the buyer needs it and the approved channel permits it.
Handle the binary form without hiding the exception
The second buyer's exact question is: “Is MFA enforced for all privileged access, including emergency accounts?” Under the example facts, the answer is No, with the exception note:
MFA is enforced for the listed ordinary developer and administrator roles. One emergency administrator account is currently excluded. Its access procedure and monitoring are documented separately; they are not equivalent to enforced MFA. The identity owner is reviewing the exception. Evidence E-ID-25, checked 25 October 2026.
Do not answer Yes because nearly all accounts comply. Conversely, do not convert a narrowly worded developer-role question into a claim about every administrative identity. Match the answer to the actual population. If the form has no notes field, send the exception attachment with the submission or obtain the buyer's approved recording method before making an ambiguous assertion.
Before the refreshed packet leaves, control owners compare the exact external wording with the evidence. Infrastructure verifies processing and retention behavior; the commercial owner confirms applicable commitments and counsel addresses unresolved legal interpretation. The security lead approves the dated risk summary. Neither an old answer library nor a recent scan can settle those questions on its own.
Record the submission as a versioned set of claims
Keep the actual submitted answers together with the evidence versions they used. A living answer library is useful for drafting, but it cannot reconstruct what a buyer received if its entries change in place. Record the product scope, recipient, submission date, approved answer text and evidence IDs without copying restricted technical material into the commercial tracker.
If Harborline later discovers that a submitted answer was wrong at the time, the owner should issue a correction through the established customer channel. If the answer was accurate but the product subsequently changed, provide a current update when the commitment or review process requires it. Those situations have different histories; neither should be handled by silently replacing the old attachment.
A buyer's follow-up can also reveal that the original question had a wider scope than assumed. Compare the new wording with the evidence and answer the wider population explicitly. The right response may be an additional exception, an evidence request or a narrower commitment. A previously approved Yes should not be reused automatically merely because the question appears similar.
Send the narrowest useful answer and keep the gap visible
Before submission, have one person compare every yes/no response to its longer bounded statement. If the form forces a binary answer that would mislead, use the comment field or attach an exception note; ask the buyer how to record the nuance if the form offers neither. Share a date-stamped packet, preserve the approved version and record any follow-up questions. Do not broaden an answer in a sales call beyond the reviewed wording.
Take the next real customer questionnaire and fill the five-part claim record for its three hardest application-security questions. Use the coverage-and-uncertainty report template for assessment claims. For a more sensitive vendor review, the tenant-isolation evaluation guide helps turn a general “isolated” answer into evidence about actual access boundaries.