What questions should I ask a penetration testing vendor?

As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.

What should a sample report actually contain?

A report that a developer could act on without a meeting. That means each finding has a title in plain language, the affected asset and endpoint, reproducible steps, the request and response that demonstrate it, the impact on your data or money, a specific remediation, and a severity with a reason. Tool output and plugin counts are the opposite: they prove a scanner ran, not that anyone understood the system. Ask for a redacted report from work that resembles yours, in the same technology stack. A report for a static WordPress site tells you nothing about an assessment of a multi-tenant application with payment integrations. If a vendor will not show a redacted sample at all, treat that as a disqualification rather than a minor gap.

Why does the retest matter more than the report?

Because the report is a snapshot and the retest is the outcome. Every finding should leave the process as fixed, partial or open, with evidence. A report you never close is an expensive list; the cost of a vulnerability in production does not fall because it was documented. The retest also gives you the audit trail your customers and auditors increasingly ask for, and in an incident or an insurance claim, a closed remediation record is worth more than a fresh vulnerability count. Ask whether the retest is included, whether it is scoped to fixed findings only, and how long you have to apply the fixes before it expires. At AAVETech the retest after your fixes is included as standard on assessment work.

Which red flags mean you should walk away?

Six. A price arriving by return email with no questions about roles, endpoints or hosts. A complete web application assessed and reported within 48 hours, which is not physically possible at professional depth. No named methodology and no sample report. A sample report that is mostly tool output. A CERT-In empanelment claim you cannot find on CERT-In's published list. And no retest, or a retest billed as a fresh engagement. Separately, be careful with the word certificate: a genuine tester will describe scope, method and evidence, and will be visibly uncomfortable with a request that is not authorised testing. For legal comfort, the Ministry of Electronics and Information Technology has stated in Parliament that ethical hacking with the owner's permission attracts no liability under the Information Technology Act, 2000.

What should the proposal and the contract look like?

A proposal should state the scope as a list of systems and environments, the number of tester-days, the methodology, the named deliverables, the delivery dates, the retest terms and the price with GST as a separate line. It should name a technical contact. The contract should add a signed authorisation naming the systems, a rules-of-engagement document with the test window, permitted techniques, explicitly prohibited actions, an emergency contact and a stop word, an NDA, and a data handling clause covering how findings and credentials will be stored and destroyed. AAVETech works on fixed-price engagements rather than hourly billing, and a scope and price are agreed in writing before any work begins.

What are the frequently asked questions?