Remove a VAPT vendor from your shortlist when a warning sign shows that the provider cannot deliver the required assurance safely, honestly or reproducibly. Red flags are not minor style preferences. They are evidence of failed competence, integrity, confidentiality, legal authority or operating control that a lower price and stronger presentation cannot offset.

Red flag: a firm quote before meaningful scope questions

A provider can offer a budget range from limited facts. A final quote that appears before it understands applications, APIs, roles, tenants, workflows, environments and evidence expectations is a warning. The price probably rests on invisible exclusions or a shallow fixed routine.

Ask the vendor to state assumptions and scope units. If it cannot explain how complexity changes effort, remove it from consideration or return the quote for correction. Unpriced ambiguity becomes missed coverage, delays or disputes later.

  • No questions about authenticated users, privileged roles or tenant relationships.
  • Endpoint or page count used as the only effort driver.
  • Reporting, debrief and retesting absent from the priced work.
  • A deadline promised without checking access readiness or tester availability.

Red flag: guarantees and absolute coverage claims

No time-bounded penetration test can prove the absence of every vulnerability. Claims of “absolute security,” “all vulnerabilities found” or “complete coverage” misrepresent the nature of adversarial testing. A credible provider defines scope, sampling, methods and limitations.

Similarly, “zero false positives” should mean findings are manually validated to a stated evidence standard—not that judgment can never be revised. A vendor unwilling to acknowledge uncertainty may also hide blocked paths and weak evidence.

  • Marketing promises exceed what the statement of work can demonstrate.
  • A clean report is described as a security certificate for the whole product.
  • Limitations are treated as weakness and therefore omitted.
  • Severity or impact is presented as unquestionable rather than evidence-led.

Red flag: the delivery team remains hidden

It is reasonable to protect personal information during an open tender. It is not reasonable to withhold the roles, competence, location, employment status and accountability of people who will receive access. Ask to speak with the proposed technical lead before shortlisting.

Undisclosed substitutions and subcontractors create quality, confidentiality and jurisdiction risk. If the vendor will not describe approval and oversight of external testers, the buyer cannot complete due diligence.

  • Sales staff answer every technical question on behalf of unnamed testers.
  • Company-level certifications substitute for assigned-practitioner evidence.
  • Subcontracting is denied contractually but implied operationally, or vice versa.
  • No independent reviewer is accountable for high-impact findings and reports.

Red flag: “manual testing” means a human-operated scanner

Automated tools are normal and useful. The concern is a vendor that cannot explain manual authorization, workflow, business-logic and attack-chain analysis. Ask how identities, objects, states, sequence, value, timing and channels become hypotheses.

Present a simple multi-role scenario. If the answer remains a tool list or generic OWASP categories, the provider has not demonstrated application reasoning. Do not assume the missing depth will appear after purchase.

  • One test account is accepted for a system whose security depends on relationships.
  • Scanner coverage is reported as though it equals tested business capability.
  • Manual validation is described only as removing obvious false positives.
  • No coverage record exists for workflows, roles, tenants or blocked paths.

Red flag: sample findings cannot prove their claims

A finding should show preconditions, identity, target, steps, observed effect, impact and retest criteria. Screenshots without requests, ownership or final state may be presentation rather than proof. Generic text copied from a taxonomy does not establish what happened in the tested system.

Ask a vendor to explain one sanitised finding. If it cannot distinguish confirmed impact from speculation, or cannot tell how an engineer would reproduce the issue, remove it from the shortlist unless stronger evidence resolves the concern.

  • Evidence omits the caller, affected object or expected security rule.
  • Severity is high because the vulnerability name sounds severe.
  • Remediation is generic and disconnected from the failed control.
  • Retest status can change without new technical evidence.

Red flag: unsafe handling of credentials and evidence

Testers may receive privileged accounts, tokens, source code, customer data and unpublished vulnerabilities. Personal email, public file links, uncontrolled screenshots, shared accounts or indefinite local retention are disqualifying when the vendor cannot provide a controlled alternative.

Review how access is granted, logged, encrypted, revoked and deleted. A contract clause alone is not enough. The provider should explain its normal working systems, device controls, least privilege, retention and incident response.

  • Credentials requested through an unapproved chat or email channel.
  • Reports distributed through public or non-expiring links.
  • No inventory of personnel who can access client artefacts.
  • No defined retention or verifiable deletion process.

Red flag: operating safety is improvised

Testing production-like systems without written target boundaries, rate limits, prohibited actions, stop conditions and escalation contacts is unsafe. The vendor should establish rules of engagement before active work and adapt them to queues, notifications, payments and third parties.

Aggressiveness is not the same as depth. A vendor that boasts about disruption or unauthorised “proof” creates legal and operational risk. Safe testers know when evidence is sufficient and who can approve a more intrusive step.

  • The vendor will “figure out” production limits after testing begins.
  • Third-party services are probed merely because the application references them.
  • No marked accounts, source addresses or monitoring coordination are proposed.
  • No named person can pause testing after an unexpected effect.

Red flag: critical findings wait for the final report

A verified issue creating immediate customer or operational risk requires an agreed urgent channel. The provider should describe verification, severity confirmation, protected evidence transfer, recipient acknowledgement and the decision to continue or pause.

Immediate notification does not mean unreviewed alarm. Both delay and uncontrolled escalation are risky. A vendor unable to balance verification with speed lacks a core engagement control.

  • Critical escalation is undefined or routed only through an account manager.
  • Unverified scanner alerts are sent as emergencies.
  • High-risk evidence is transmitted through ordinary insecure channels.
  • The vendor cannot distinguish notification from full report delivery.

Red flag: contractual language defeats technical assurance

Watch for unilateral scope substitution, automatic acceptance, broad rights to reuse data, unclear intellectual property, unlimited subcontracting, weak breach notification or liability language that contradicts promised controls. Legal review should connect the contract to actual delivery.

A limitation of liability is a commercial negotiation, not automatically a red flag. The concern is material inconsistency or refusal to define responsibilities, authorisation, confidentiality, change control and evidence handling.

  • The statement of work and proposal describe different deliverables.
  • Out-of-scope discoveries can be ignored or billed without an approval path.
  • The vendor can publicise the customer or reuse evidence without consent.
  • Retest, report ownership or deletion obligations disappear from the contract.

Resolve a red flag without lowering the gate

  1. Record the observed red flag and the requirement it threatens.
  2. Ask one precise clarification and define acceptable evidence.
  3. Have the correct technical, legal or security owner assess the response.
  4. Remove the vendor when a mandatory failure remains or integrity is compromised.

Use the testing-process principles in NIST SP 800-115 and the coverage vocabulary in the OWASP Web Security Testing Guide to challenge unsupported methodology claims. Framework names alone are never proof that the process is followed.

Remove risk early enough to protect the engagement

Document the reason for removal and the evidence reviewed. A fair process allows a vendor to resolve ambiguity but does not repeatedly lower a mandatory requirement. Early disqualification protects internal time and prevents a commercial deadline from forcing acceptance of known delivery risk.

WIMD makes its assigned-team model, manual testing approach, evidence standard, data handling, safety controls and retesting process available for buyer scrutiny. The goal is not to avoid difficult questions; it is to make the delivery system auditable before access is granted.