Start with the question you need answered. Do you need to identify weaknesses across a defined set of assets, establish whether a particular attack could succeed, or check that an earlier fix works? Put that question into the brief before choosing a service label. For UK and US teams comparing proposals, a shared brief also makes differences in access, coverage and follow-up easier to see.
Understand the difference
A vulnerability assessment examines weaknesses in the agreed scope. It can combine scanning with analysis and validation. Penetration testing uses authorised attempts to demonstrate how security boundaries can be bypassed and what an attacker could achieve. Scanning may be part of a penetration test; buying a scan alone does not establish that exploitation or business logic testing is included.
NIST distinguishes vulnerability scanning, which identifies potential weaknesses such as missing patches and configuration problems, from penetration testing, which validates attack possibilities. These techniques can complement each other. NIST SP 800-115, sections 4.3 and 5.2
Use the following questions as a working comparison when discussing a proposal:
| Your buying question | Work to discuss | Evidence to agree |
|---|---|---|
| Where should we investigate weaknesses across these assets? | Vulnerability assessment | An asset-linked findings list, validation approach and coverage gaps |
| Can a user cross this access boundary or complete an unintended action? | Penetration testing | Observed behaviour, starting access and demonstrated impact within the authorised scope |
| Does the change address a previously reported issue? | Targeted retesting | A result linked to the original finding and the tested change |
Compare the scope behind the price
Give every prospective provider the same short scenario. For example: “We are preparing a customer portal release. We want to understand whether a customer can view another customer’s records.” This is an illustrative buying scenario, not a reported SWSAM engagement.
Then ask each provider to explain its proposed approach in ordinary language:
- Which application, API, environment and user roles are included in this price?
- What will you need from our team, and what happens if access arrives late?
- Which questions will be investigated manually, and what will automated tools contribute?
- Which activities need explicit permission, and who can stop the test?
- What will we receive if part of the scope cannot be tested?
- Does the proposal include a findings discussion and retest, or are these separately priced?
Record the answers beside each quotation. A lower price may reflect a different boundary or follow-up arrangement. Ask the provider to explain those differences before deciding which proposal fits the decision you need to make.
Ask for a report your teams can use
Ask to see a sanitised example report before commissioning work. Check whether a business owner can understand why a finding matters and whether an engineer can identify the affected component and proposed action. OWASP’s reporting guidance covers scope, limitations, findings and remediation information; for a retest, it suggests linking earlier findings to their updated status. OWASP WSTG v4.2, Reporting
Use the sample to test the conversation you will have afterwards. Can your team tell what was observed and what remains uncertain? Is an issue supported by enough context to investigate? If an example is too heavily redacted to answer those questions, request a walkthrough of its structure using fictional data.
Agree retesting before the first test ends
Retesting needs a scope of its own. Agree which findings are eligible, the period in which you can request it, how many rounds are included and what happens if the application changes substantially. Reserve time for your engineers to discuss a proposed fix before requesting verification.
Ask the retest to identify the original finding, the environment and version examined, the change being checked, and the result. NIST’s remediation guidance includes verification after changes are implemented, with retesting among the available methods. NIST SP 800-115, section 8.3
A focused retest answers a narrower question than a new assessment. When features, permissions or integrations have changed, discuss whether those changes need additional coverage.
Make the closure decision explicit
For an internal tracking worksheet, consider the following labels. They are suggested workflow labels, not a standard scoring scheme:
| Proposed label | What to record |
|---|---|
| Ready for retest | The implementer reports a change; verification is pending |
| Verified in the agreed scope | The retest evidence supports the stated closure criterion |
| Still open | The issue remains, or the agreed criterion has not been met |
| Not verified | Verification could not be completed; record the reason and next action |
| Risk accepted | A responsible owner records a decision, rationale and review date; keep this separate from technical closure |
Before closing the ticket, have the responsible owner record the evidence reference and the decision. If access expired or the environment was unavailable, keep a visible follow-up action. A reader should be able to tell whether the issue was checked, what the result means and who decided what happens next.
When preparing your brief, explore Offensive Security and Remediation. For the wider relationship between testing evidence and business decisions, read From exposure to evidence.