“We need a security check before launching the portal.” That sentence can produce very different proposals: a tool-generated finding list, reviewed results with validation, or testing of possible impact within defined functions. Do not start with the strongest-sounding label. Start with the question you will use the result to answer.
You may need recurring observation of known issues across assets or deeper assessment of a sensitive application workflow. Both can belong to one program. The difference is not that one service uses tools and the other uses none, but the objectives, method, effort, coverage and evidence promised in the proposal.
An example separating two questions
In a fictional example, a venue booking company launches a customer portal. Its technical owner wants to identify known issues in included services, while its operations owner is concerned about branch employee permissions within bookings. The first question may suit structured scanning with analysis; the second needs discussion of appropriate functional and role testing depth.
This does not mean every scan ignores permissions or every penetration test covers them completely. Ask the supplier to connect each question to the proposed activity, evidence and inference limits. If the operational question remains outside scope, record that instead of treating a general security report as its answer.
A purchasing table, not a tool list
| Comparison | Ask about vulnerability scanning | Ask about penetration testing |
|---|---|---|
| Objective | Which known issues or configurations are sought? | Which risks or scenarios will have their impact assessed? |
| Coverage | Assets, available access and updated scanning data. | Functions, roles, dependencies and allocated time. |
| Validation | Are findings reviewed and how far are they confirmed? | What validation is authorized and what is excluded? |
| Report | Confirmed and potential findings, limits and priorities. | Impact, evidence, limits and remediation options. |
| Follow-up | Periodic result comparison over an identified scope. | Retesting agreed fixes or a specified version. |
These are comparison questions, not exclusive definitions of each service. Proposals may combine scanning, manual analysis and focused tests. Separate activities and deliverables to understand what increases the price and what remains uncovered despite the word “comprehensive”.
What do the references support?
NIST SP 800-115 distinguishes techniques for identifying vulnerabilities from those validating them, and discusses capabilities and limits of scanning and testing. Published in September 2008, it is used here for methodological distinctions, not as a current threat catalogue based on its older technical examples.
OWASP WSTG 4.2 discusses multiple web assessment techniques and limits of relying on testing or tools alone. The name OWASP does not establish complete coverage, and an empty finding list does not mean an application has no risks. Read the result alongside scope, version, timing and constraints.
A decision exercise before requesting proposals
- Write the intended decision: prioritizing known fixes, understanding a sensitive workflow's impact or verifying a particular correction.
- Identify relevant assets and functions and the test access and documents you can provide.
- Ask the supplier which parts a tool covers and which require specialist analysis or validation.
- Request a sanitized example report and connect its contents to your written question.
- Agree who fixes issues and what retesting establishes, without assuming it is included or covers an entire new release.
If a proposal cannot explain how the result informs your decision, request clarification before purchasing extra hours or a longer report. Preliminary scoping may be needed, but it should have a defined output rather than become another name for an undefined service.
Read limitations alongside the executive summary
A missing role account, differences between testing and production environments or an excluded connected service change the result's meaning. The report should state these boundaries. Differences between reports do not automatically establish security improvement if scope, method or version changed between them.
Actual activity requires suitable authorization, boundaries and coordination with system owners. Asking for a quote does not permit testing third-party services. The penetration testing procurement brief discusses scope and delivery details. When discussing a security assessment with Nextwave, begin with the business decision and comparison table to define an understandable service without absolute security promises.
References
NIST SP 800-115 and the OWASP WSTG 4.2 introduction were opened on 3 November 2026. The example and decision exercise are illustrative. This article provides neither attack instructions nor a company accreditation claim.
