Compare penetration-testing quotations only after normalizing what each vendor is pricing. Day counts and totals are meaningless when target inventories, authenticated roles, tenant pairs, APIs, environments, manual depth, evidence standards, report review and retesting differ. Build one comparison matrix that separates mandatory scope, quality evidence, commercial assumptions and optional coverage.
Start with the assurance requirement
Have technical and risk owners define the required security outcomes, targets and deadline before procurement requests quotes. Mark assumptions that vendors may challenge and require every exception in writing.
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.
Collect a versioned target inventory, architecture summary, applications and APIs, roles and tenants, critical workflows, environment, testing constraints, expected methodology, report and evidence needs, retest terms, deadlines, vendor assumptions, exclusions, effort allocation and pricing.
Normalize the scope baseline
Give every bidder the same targets, interfaces, identities and critical journeys.
- Count applications and APIs.
- List roles and tenant pairs.
- Name mobile and cloud components.
- State environment and access.
- Record exclusions.
Use scope units and complexity drivers rather than one vague line such as “web application VAPT.”
Compare the proposed method
Understand what work the quoted effort buys and how much is adaptive manual testing.
- Separate discovery and execution.
- Check authenticated coverage.
- Review business-logic approach.
- Identify automated tooling.
- Confirm evidence validation.
A framework name or tool list is not a work plan. Ask how the team will test your architecture.
Inspect effort assumptions
Day counts depend on readiness, parallelism, seniority, dependencies and reporting.
- Request effort by phase.
- Identify tester composition.
- Check client support assumptions.
- Review blocked-time policy.
- Confirm scope-change rates.
Do not reward artificially low days that can only work by excluding depth or relying on undisclosed assumptions.
Compare deliverables and closure
The useful output includes remediation-ready evidence and an agreed path to retest.
- Require executive and technical report.
- Confirm reproducible findings.
- Check debrief and clarification.
- Define retest allowance.
- State closure letter terms.
Price optional and included deliverables visibly; a cheap base quote can become costly after report delivery.
Calculate total engagement value
Include internal coordination, delay risk, retest, scope changes and evidence rework.
- Model total expected cost.
- Assess deadline confidence.
- Review contract exceptions.
- Score evidence quality.
- Record residual coverage gaps.
Present price alongside mandatory-gate compliance and weighted quality, not as an isolated ranking.
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.
Run a written clarification round using the same questions for all bidders. Update the comparison matrix, preserve vendor responses and obtain technical sign-off before commercial selection.
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
Provide a side-by-side matrix of normalized scope, methodology, team, effort, deliverables, timeline, exclusions, retest, price and unresolved risk. Separate facts from evaluator judgment.
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
The most comparable quotation is the one that makes coverage and assumptions explicit. Select on credible total value for the required assurance—not the lowest total or day rate.
Ask WIMD for a written comparable scope with explicit coverage, deliverables, timing and retest assumptions.