A customer sends you a spreadsheet with 200-plus security questions, halfway through closing the deal. You reach the vulnerability scanning section and realise you have nothing ready to show them. Someone handled the finding from March, but where is the record confirming the fix?
To answer a customer security questionnaire, describe what you do, state the scope, and attach records that support each claim. This guide focuses on vulnerability management: coverage, scan frequency, prioritisation, and proof of remediation.
The five steps below give you example responses and an evidence-pack checklist. Replace the bracketed details with your records, and use each statement only where it describes your current practice.
What is a customer security questionnaire?
A customer security questionnaire is a due-diligence form a customer sends to assess how your organisation protects data and systems. It is also called a vendor security questionnaire or a supplier security questionnaire, because the customer is assessing you as a supplier. Questions can cover governance, access control, staff training, business continuity, and vulnerability management.
Standard questionnaires file the vulnerability questions under different names. The Shared Assessments Standardized Information Gathering (SIG) questionnaire places them in its Threat Management domain, one of 21. The Cloud Security Alliance's Consensus Assessments Initiative Questionnaire (CAIQ) asks yes/no questions against the 207 controls of the Cloud Controls Matrix, grouped into 17 domains. Its Threat & Vulnerability Management domain covers remediation schedules, prioritisation, and reporting. Look for those headings first.
A scan report shows which systems the scan tested and what it found. Your policy sets the schedule, and remediation records show who fixed each finding and when. Use the table to identify which records each answer needs:
| Customer question | Evidence to reference | What it establishes |
|---|---|---|
| Which systems do you scan? | Asset scope and completed scan records | Coverage of named systems, with exclusions |
| How often do you scan? | Approved schedule and dated scan history | Intended frequency and whether scans ran |
| How do you prioritise and fix findings? | Ranking method and remediation records | Decisions, owners, deadlines, and progress |
| How do you verify a fix? | Original finding, remediation record, and retest | Whether a retest confirmed the specific fix |
| Which controls does this support? | Relevant control mappings and supporting records | Which controls your vulnerability records help meet |
| Do you have access and continuity policies? | Approved policies and implementation records | Organisational controls outside scan output |
Why might a regulated customer ask?
The EU's second Network and Information Security Directive (NIS2) requires regulated customers to manage supply-chain security. Article 21(2)(d) lists it among their risk-management measures, so a customer may ask for evidence about your service even if your organisation is outside NIS2's scope. Our NIS2 guidance covers what Article 21 asks of those customers.
1. Define exactly what your vulnerability evidence covers
State the systems, environments, and test types covered by your answer. Tie them to the service the customer is buying. Specify whether testing includes external websites, internal servers, or authenticated application functions.
Customer question: "Which systems are included in your vulnerability assessments?"
Example response: "For [service], we scan [asset groups] in [environments] using [test types]. The attached scope record identifies exclusions, including [excluded systems or test types]. The latest completed assessment of this scope was [date]."
Evidence to attach: the asset scope and scan summary, including completion status and any failed or unauthenticated tests. Explain incomplete scans and give a follow-up date.
2. Explain a risk-based scan cadence you can demonstrate
Give the schedule you follow and show when the scans ran. Explain how asset criticality, exposure, material changes, and new vulnerability disclosures affect that schedule. Check the customer's requested frequency against your policy before answering yes.
Customer question: "How often do you conduct vulnerability assessments?"
Example response: "We scan [asset group] every [interval], based on [risk factors]. [Defined events] trigger additional scans. Our most recent completed scans were [dates], recorded in [evidence reference]. We retest affected assets after remediation."
Evidence to attach: the schedule or policy excerpt and completed scan history for the requested period. If a scan was missed, name the gap and corrective action.
3. Show how you prioritise what to fix first
Explain how you rank findings, assign responsibility, and set remediation deadlines. Support the answer with a representative record showing the decision and its outcome. Include overdue findings and their current status.
Customer question: "How do you prioritise vulnerabilities and ensure timely remediation?"
Example response: "We prioritise findings using [severity method], exposure, asset importance, and available exploitation information. Each finding has an owner and a deadline under [policy]. We escalate overdue findings through [escalation process]. The attached record shows the priority decision, target date, and current status for [finding reference]."
Evidence to attach: your prioritisation method and remediation records. Label accepted risks and include the reason, approver, and review date. For the reasoning behind ranking by exploitability rather than severity alone, see risk-based prioritization.
The EU Agency for Cybersecurity (ENISA) technical implementation guidance, section 6.10, gives examples including scan reports, follow-up logs, and evidence that critical findings have been addressed.
4. Show that the vulnerability fix worked
Link the original finding to the fix and to a retest, which runs the original check again on the affected asset. Name the asset, test date, result, and anything the retest could not check.
Customer question: "Can you provide evidence that identified vulnerabilities were remediated?"
Worked example: The following answer and records are fictional. They show how to support a claim about one resolved finding.
Example response: "Finding VM-104 identified an exposed administration interface on portal.example.com on 3 September 2026. We restricted access to the management network on 5 September. A completed external retest on 6 September confirmed that the interface was no longer reachable from the tested public network. Attachment A, pages 2 to 4, links the finding, approved change, and retest."
Each page supports a specific part of the answer:
| Supporting record in this example | What the customer can check |
|---|---|
| Attachment A, page 2: finding VM-104, dated 3 September | The affected host, interface, external test scope, and original evidence of public access. |
| Attachment A, page 3: change CHG-218, completed 5 September | The access restriction applied, responsible administrator, approval, and link to VM-104. |
| Attachment A, page 4: retest RT-109, completed 6 September | The VM-104 reference, the same host and interface tested from an external network, successful test execution, and a result confirming the restriction. |
The matching asset and finding reference let the reviewer follow the fix across all three records. A closed ticket alone would leave the retest claim unsupported. The answer claims only what the retest checked, one interface from one network, and says nothing about the rest of the service.
Evidence to attach: those three linked records. If remediation is complete but the retest is pending, say so and provide its planned date. If the retest could not reach the asset or did not run, do not describe the result as verified closure.
If your system keeps a tamper-evident record history, include its integrity check. It lets the customer detect later edits to the recorded history. It cannot show that the original entry was accurate.
5. Send a curated evidence pack
Send a focused set of attachments that the customer can trace back to individual answers. Keep answers in the requested questionnaire format and reference the relevant attachment or page. Agree the scope and reporting period before collecting a large export.
Check that your pack includes the records needed for the questions asked:
- Coverage: service, environments, asset groups, and exclusions.
- Scan history: completed assessment dates and results for the requested period.
- Remediation: priorities, owners, deadlines, and current status.
- Closure: original findings linked to remediation and confirming retests.
- Exceptions: unresolved findings, accepted risks, approvals, and review dates.
- Control references: mappings where requested, with the records supporting each mapped control.
For example, an answer to question 4.2, "How do you verify remediation?", could reference finding [reference] and the dated retest on page [number]. The reviewer can then follow the claim to its evidence without searching the whole report.
Review attachments for unrelated customer information, credentials, or sensitive technical details before sharing. Agree redactions and the delivery method with the reviewer. Redact only what you must, so the reviewer can still assess the answer.
Vornin's auditor packs contain finding history, comments, evidence, compliance mappings, and verification results. Exports depend on your plan (see plan availability). Select only the records this customer asked for. The vulnerability management lifecycle explains how those records accumulate through scanning, remediation, and verification.
Frequently asked questions
Can a vulnerability scan answer the whole questionnaire?
No. Scan output supports answers about the systems tested and findings detected. Remediation and retest records support claims about fixes. Governance, access control, staff training, and business continuity require their own policies and implementation evidence.
What if we do not have the evidence the customer requests?
State what you have, what is missing, and who owns the next action. Distinguish a control that exists but lacks records from a control you have not implemented. Ask whether the customer will accept alternative evidence or a dated remediation plan. A new scan establishes current results; it cannot recreate missing historical evidence.
Can we send a vulnerability scan when asked for a penetration test?
Only if the customer agrees to accept scanning evidence for this review. Identify the assessment as a vulnerability scan and describe its scope and limitations. If the customer requires a penetration test, arrange a separate engagement.
Is continuous attack-surface monitoring the same as a vulnerability assessment?
No. Attack-surface monitoring tracks changes in observable assets and exposure. A vulnerability assessment evaluates systems for weaknesses, often using scanning and additional analysis. Give the coverage and frequency of each activity in your answer.
Reusing your answers next time
Keep each approved answer with its evidence reference and a review date. When the next questionnaire arrives, update the facts and check them against the new customer's requirements.
Read-only access · Working scan data deleted after each scan · EU-hosted
