Review a sample VAPT report as evidence of the vendor’s delivery system, not as a design brochure. The report should show how the provider turns testing observations into reproducible, risk-based and fixable findings while preserving scope and limitations. A beautiful template cannot rescue weak proof, generic remediation or inconsistent severity.

Ask for a sanitised example that resembles the service you are buying. A web scanner export does not demonstrate API authorization testing; an infrastructure report does not show mobile or business-logic depth. The vendor must protect its former client, so evaluate structure and reasoning without demanding confidential identifiers or live exploit details.

Request the right kind of sample

State the product and assessment type you are considering. Ask for a report or finding set with comparable technical characteristics: authenticated web, REST or GraphQL APIs, Android or iOS, multi-tenancy, payments or complex workflows. The sample may be assembled or heavily sanitised, provided the vendor labels that fact.

Do not reward a provider for exposing another customer. Names, URLs, IPs, tokens, screenshots and business facts should be removed or replaced. What must remain is the reasoning chain: precondition, action, observed result, violated rule, impact and remediation direction.

  • Comparable assessment type and level of access.
  • Preserved technical sequence without client-identifying data.
  • Clear notice when content is synthetic, combined or reformatted.
  • Enough context to judge the vendor without reusing a former client’s secret.

Read scope and limitations before findings

A report is interpretable only when it states what was assessed. Look for targets, versions, environments, dates, access model, roles, tenants, interfaces, exclusions and constraints. Confirm whether production differences, unavailable accounts or blocked paths are visible.

A limitation is not automatically a quality failure. Hidden limitations are. Mature providers distinguish tested, sampled, observed, inaccessible and excluded areas so readers do not treat “no finding” as proof of complete coverage.

  • Targets map back to the authorised statement of work.
  • Authentication and account coverage is explicit.
  • Sampling decisions and unreachable paths are described.
  • The assurance statement does not exceed the actual test boundary.

Inspect one finding from start to finish

Choose a finding involving identity, data or workflow—not only a missing header. A technically useful entry names the affected component and version, states required privileges and data, provides safe reproduction steps, preserves the relevant request or sequence, and shows the actual security consequence.

Ask a developer who did not perform the test whether the entry is actionable. If that person cannot determine what failed, where to inspect and how closure will be judged, the evidence is too weak even if the vulnerability name is correct.

  1. Identify the actor, access and state required before exploitation.
  2. Follow the exact action, request or workflow sequence.
  3. Find the observed response or authoritative final effect.
  4. Connect the evidence to a violated security or business rule.
  5. Check that remediation and retest criteria address the same rule.

Separate screenshots from proof

Screenshots can orient a reader but frequently omit identity, ownership, requests, timing or final state. A report should preserve the minimum technical evidence needed to reproduce the behaviour. For APIs, that usually includes method, path, identity context, relevant fields and response. For workflows, it includes sequence and authoritative outcome.

Evidence should also be safe. Tokens, customer records and credentials should be redacted. Redaction must not remove the fact being proved—for example, whose object was accessed and why the caller lacked permission.

  • Evidence demonstrates the claim instead of merely illustrating a page.
  • Sensitive values are minimised, masked or represented by controlled test data.
  • Time, version and identity context can be reconstructed.
  • The report distinguishes confirmed impact from plausible but unproven escalation.

Evaluate severity discipline

Read the technical severity factors and the environmental context separately. The rating should reflect attacker prerequisites, reach, confidentiality, integrity, availability, reversibility and the business process affected. A generic score copied from a taxonomy is insufficient.

Check consistency across examples. Similar evidence should produce explainable ratings, while materially different identity or data reach should change the conclusion. The report should state assumptions when business context came from the customer rather than testing.

  • Severity is tied to demonstrated access and effect.
  • Uncertainty and unverified impact are labelled rather than inflated.
  • Chained weaknesses explain dependencies without double-counting impact.
  • The customer can challenge a rating through an evidence-based process.

Judge remediation by control quality

Generic advice such as “validate input” or “use encryption” is rarely sufficient. Guidance should identify the control objective and likely enforcement layer without pretending the tester has complete design knowledge. It should help engineers fix the shared cause and identify affected variants.

Look for defence in depth only when it is relevant. A WAF rule may reduce exposure but not repair missing server-side authorization. Client-side checks may improve user experience but cannot enforce a privileged operation. The report should preserve these distinctions.

  • The expected secure behaviour is stated clearly.
  • Root-cause direction is separated from optional hardening.
  • Related paths and regression risks are identified.
  • The retest can determine whether the unsafe condition is gone.

Review executive synthesis for accuracy

The executive section should explain what was assessed, what material risk was demonstrated, which themes require attention and what limitations constrain the conclusion. It should not simply count findings or use alarming language disconnected from evidence.

  • Risk themes link to affected business capabilities.
  • Critical decisions and immediate actions are visible.
  • Limitations accompany any statement about overall assurance.
  • The summary avoids claims that the tested product is completely secure.

Look for coverage evidence outside the findings

A finding list cannot show what the team attempted without success. Look for asset reconciliation, role and tenant coverage, workflow sampling, API or feature coverage and blocked paths. The exact format varies, but the provider should be able to describe the record it maintains.

Coverage evidence lets future testers and internal teams understand residual uncertainty. It also helps distinguish a clean outcome produced by robust testing from one produced by shallow access or missing prerequisites.

  • Roles, accounts and tenant relationships exercised.
  • Critical workflows and major interface families tested.
  • Unavailable features, credentials, environments or dependencies.
  • Tests curtailed for safety, rate or third-party reasons.

Examine report QA and delivery control

Ask who reviews findings, evidence, severity, language and report completeness. Important findings should be reproduced or peer checked. The final report should use consistent identifiers, statuses and dates so it can be managed through remediation and retesting.

  • Technical peer review is distinct from spelling or formatting review.
  • Finding identifiers remain stable across draft, final and retest versions.
  • Changes after customer factual review are traceable.
  • Report distribution and retention follow agreed controls.

Review the retest example

A retest entry should state the version and date, reconstruct original preconditions, describe the evidence observed and record an unambiguous outcome. “Developer says fixed” is not independent verification. A screenshot of a changed response may be insufficient when the authoritative effect remains unsafe.

Look for partial and variant handling. A fix may block one endpoint while the same object remains exposed through search, export or mobile APIs. The retest should be proportional to the shared control and should not relabel accepted risk as technically closed.

The NIST SP 800-115 guidance connects planning, testing, analysis and mitigation. The OWASP Web Security Testing Guide supplies testing context. Use both to ask whether the sample records evidence and limitations from a disciplined process.

Convert the sample into a shortlisting decision

Score the sample against pre-agreed criteria: context, reproducibility, evidence safety, severity, remediation, coverage, executive usefulness, QA and retest traceability. Record unresolved questions and ask every vendor the same clarification. Do not rank visual design above technical truth.

WIMD reports are designed to connect manually validated behaviour with the affected identity, object, workflow and control. Findings are reviewed for evidence and severity, limitations remain explicit, and retest status is supported by new technical verification rather than a label change.