Questions to ask before a vulnerability assessment

The biggest mistake businesses make when hiring someone to assess their vulnerabilities is treating the interview like a box-ticking exercise. They assume all vulnerability assessors follow the same process and deliver the same report. In reality, the quality of your assessment depends almost entirely on the depth and precision of your initial conversation with the consultant. The questions you ask—and how carefully you listen to the answers—will determine whether you get a surface-level compliance document or actionable intelligence about your actual weak points.

Start with scope: what systems are actually in scope?

Ask: "Which of our systems, networks, applications and data stores will you be testing, and which ones won't you be testing? Walk me through the list." Listen for specificity. A weak answer is vague: "We'll assess your IT infrastructure." A strong answer names your ERP, CRM, backup systems, remote access tools, databases, websites, mobile apps—whatever you actually run. Ask them to confirm against a list you've prepared.

Why this matters: assessors who aren't crystal clear about boundaries often discover mid-project that they've excluded critical systems, or they test shallow and call it done. You need to know exactly what's covered and what's not before the work starts.

Probe their testing methods and how they'll validate findings

Ask: "What techniques will you use to test for vulnerabilities? Will you do code review, network scanning, penetration testing, manual inspection? How will you confirm that a vulnerability is real and not a false positive?" This is where evasion becomes obvious. Someone who says "We use industry-standard tools" without naming them or explaining how they'll use them is either inexperienced or hiding sloppy methodology.

A credible answer sounds like: "We'll use automated scanning to identify common misconfigurations and known CVEs, then manually verify high-risk findings by attempting exploitation in a controlled way. For each one, we'll document the specific steps we took so you can reproduce and fix it." They should also explain how they'll avoid breaking your systems during testing and what safeguards they'll put in place.

Why this matters: different testing methods find different vulnerabilities. A consultant who only runs a scanner will miss configuration errors and logic flaws. One who doesn't validate findings wastes your time chasing ghosts.

Ask about the report structure and how they'll rank risks

Ask: "How will you present the findings? Will you rank vulnerabilities by severity and exploitability? Will you explain the business impact of each one, or just the technical detail? Will you include remediation steps we can actually follow?" Then ask for a sample report—redacted if needed—so you can see their structure before they start.

Pay attention to whether they talk about severity in isolation or in context. Good assessors say: "This SQL injection is critical because it affects the payment database and requires no authentication." Weak reports just say: "SQL injection found—severity: high."

• A strong report includes clear risk rating, explanation of how it was discovered, step-by-step reproduction, and practical remediation advice
• A generic report lists vulnerabilities without business context or realistic remediation guidance

Why this matters: a report full of jargon and low-context findings becomes a filing cabinet item, not a tool for fixing things. You need outputs that your development and operations teams can actually act on.

Clarify the timeline and what happens after delivery

Ask: "When will the assessment take place? How long will it take? What's your turnaround time for the report? After you deliver it, will you be available to answer clarifying questions or help us prioritise fixes?" Some assessors vanish after delivery; others offer a structured follow-up conversation.

Also ask: "If we find something urgent during the assessment—a serious vulnerability—how will you communicate that to us before the final report?" A consultant who waits until the end-of-project report to mention a critical risk has poor practice. Urgent findings should be flagged immediately.

Why this matters: timing affects your ability to plan remediation, and post-delivery support makes the difference between a report that sits unread and one that actually drives security improvements.

When you're ready to move forward, look for assessors on Strove who can walk you through these questions clearly and provide evidence of their approach. The conversation itself tells you whether you're hiring a thoughtful professional or someone running a template playbook.