Before comparing VAPT vendors on price, procurement should ask internal stakeholders what decision the test must support, what systems and identities are in scope, which attack paths matter, when evidence is due, what access is available, which legal constraints apply and how findings must be closed. Without those answers, vendors will quote different engagements under the same label.
Start with the assurance requirement
Identify the trigger: audit, customer request, launch, material change, incident, programme cadence or risk review. Each changes the scope, urgency and required deliverables.
Record the requesting party, framework or contract clause, assessment boundary, evidence period, due date and decision the evidence must support. Confirm the interpretation with the auditor, assessor or customer where possible. A penetration test can contribute strong assurance, but a report cannot guarantee an audit outcome or replace the organization’s wider control evidence.
Create a traceable evidence index
- Requirement or control identifier and the assertion being supported.
- In-scope systems, interfaces, environments, identities and important exclusions.
- Assessment dates, methodology, tester identity or competence evidence and authorization.
- Finding identifiers, severity rationale, remediation owner, status and exception reference.
- Retest evidence, closure date, residual risk and the location of protected technical detail.
Gather business sponsor, technical owner, security owner, system inventory, architecture, applications and APIs, mobile and cloud components, environments, roles and tenants, data sensitivity, critical workflows, known constraints, target dates, report consumers, confidentiality, procurement budget and retest expectation.
Clarify the assurance objective
Ask what question the organization expects the engagement to answer.
- Name trigger and decision.
- Identify report audience.
- Reference compliance need.
- State risk priorities.
- Define completion evidence.
Avoid a generic request for “VAPT certificate” when the real need is technical or audit evidence.
Build the technical boundary
Have system owners identify surfaces and trust relationships vendors must assess.
- List applications and APIs.
- List roles and tenants.
- Include admin and integrations.
- Identify mobile and cloud.
- Record excluded dependencies.
Use a versioned inventory and architecture summary rather than procurement guessing from public URLs.
Confirm readiness and safety
Pricing assumes access, support and stable environments.
- Choose environment.
- Prepare accounts.
- Assign allowlisting.
- State production constraints.
- Name emergency owner.
Identify which prerequisites are uncertain so vendors can price contingency honestly.
Define deliverables and recipients
Technical teams, leaders, auditors and customers need different views of the same evidence.
- Specify finding evidence.
- Request remediation guidance.
- Require executive summary.
- Define sanitized version.
- Set retest letter need.
Do not ask for separate conclusions that conflict; use controlled derivatives from one source report.
Set commercial and legal boundaries
Tell vendors about contract, data, location and schedule constraints that affect effort.
- State deadline.
- Identify data restrictions.
- Review subcontractor rules.
- Set insurance requirement.
- Define purchase process.
Keep budget guidance from silently becoming the technical scope; require explicit tradeoffs.
Operate the evidence workflow
- Confirm the requirement, evidence owner, reviewer and deadline.
- Freeze a versioned scope and record every approved change or exclusion.
- Collect assessment artifacts through a controlled, access-limited repository.
- Map findings and closure evidence without changing the tester’s original conclusion.
- Perform a completeness and consistency review before external sharing.
Facilitate one internal scope meeting and publish an approved procurement brief. Permit vendor clarification, then issue the same updates to all bidders.
Preserve evidence integrity and confidentiality
Keep the original signed or versioned report, evidence manifest and retest artifacts. Redact copies rather than overwriting the source. Restrict exploit steps, credentials, personal data and internal architecture to approved recipients. Record who received which version, under what authorization and for what purpose.
Quality checks before reliance
- Scope, dates and environment agree across the report, statement of work and evidence index.
- Every closure claim points to a finding identifier and retest result.
- Exceptions name an owner, rationale, review date and compensating controls.
- Control mappings distinguish direct evidence from supporting context.
- Sanitized summaries do not imply broader coverage or stronger closure than the source report.
Use framework language carefully
Use the applicable official control text and assessor guidance as the authority. The NIST Technical Guide to Information Security Testing and Assessment supports disciplined assessment planning and reporting, while the OWASP Web Security Testing Guide provides application testing context. Neither substitutes for framework-specific interpretation by the responsible auditor or assessor.
Report the assurance conclusion
The brief should state objective, technical scope, readiness, methods, deliverables, deadline, legal constraints, evaluation criteria and known unknowns.
State observed facts, limitations and management decisions separately. Do not use “compliant,” “certified,” “secure” or “all vulnerabilities fixed” unless the authorized assessor and evidence genuinely support that precise claim.
The GRC decision
Procurement can compare value only after technical stakeholders define what is being bought. Internal questions prevent false price competition and late scope surprises.
Ask WIMD to help build the scope from your assurance trigger, architecture, identities and evidence deadline.