Somebody has asked you for a pentest: an overseas client's procurement team, an auditor working through your SOC 2 readiness, or a buyer who will not countersign without a report. So you sent a few emails, and a week later four quotes are in front of you: PKR 120,000, PKR 450,000, USD 2,500 and USD 9,000, all apparently for the same job on the same application.
That spread is not a haggling game. It is the market quietly telling you that "penetration test" is an unregulated phrase: nobody licenses it, and nobody audits who prints it on an invoice. In practice the cheapest quote in a Pakistani inbox is often a Nessus or Acunetix scan exported to PDF, given a cover page with your logo, and sold as a penetration test. The tooling costs a few hundred dollars a year and the labour is forty minutes, which is how it undercuts everyone fivefold.
This guide is for the founder, CTO or compliance lead making that call without a security background. It is a set of criteria you can apply to any penetration testing company, provider or consultancy, ours included. We would rather you asked hard questions than picked us because our email was warmest.
The one question that decides everything: is a human testing this?
Every other criterion here is downstream of this one. Every serious tester runs a scanner, but a scan is a starting point, not a deliverable. Scanners cannot reason about your application. They do not know that your "viewer" role should never approve an invoice, that tenant A must never see tenant B's uploads, or that your password reset token survives the password change. Those are the findings that get a company breached, and they come from a person thinking, not a tool crawling. More in penetration testing vs vulnerability assessment.
What the quote tells you
Read the quote as a document about labour. A real one states how many days of testing you are buying and who is spending them. A resold scan cannot, so it changes the subject: it prices per IP or per URL, arrives within an hour, and describes the deliverable rather than the work ("comprehensive report covering 150+ vulnerability classes"). Vulnerability classes are what the tool checks. Days are what you are purchasing.
So ask directly: how many tester-days are in this quote, and what is your day rate? A firm doing manual work answers immediately, because that is how it built the number. A scan reseller deflects, because the honest answer is "half a day, mostly formatting."
What the sample report tells you
Tool output has a signature you can spot without any security knowledge. Findings appear in plugin-ID order rather than by risk, descriptions are boilerplate that never once names your endpoint or your parameter, and severity is a colour word with no scoring behind it. A manual report reads like somebody sat with your product: fewer findings, each specific to you.
Credentials that actually mean something
Certification is a noisy signal, but not a useless one. The trick is knowing which badges mean someone demonstrably broke into something.
Signals worth weighting
- OSCP, and its harder siblings OSWE, OSEP and OSCE3. Practical exams: you are given real machines and either compromise them in the time limit or fail. The holder has proven they can exploit a vulnerability, not just define one.
- CREST, at firm level as well as individual. It assesses process, quality control, legal handling and report standards, and Western procurement teams ask for it by name.
- A public bug bounty record: HackerOne or Bugcrowd profiles, CVE credits, published writeups. The least fakeable signal there is.
- ISO 27001 Lead Auditor or Lead Implementer, if you are testing for compliance. Your report then arrives in the control language your auditor reads.
- References you can call. Not logos on a slide, a person at a comparable company who will spend ten minutes on the phone.
Signals worth discounting
Reseller and partner badges mean the firm bought a licence, not that anyone there can test. Team size is close to irrelevant too: two independent penetration testing consultants who do the work themselves beat a fifty-person firm that assigns you two juniors and a scanner. You are hiring specific humans, so ask which humans. Ours are named on our about page for exactly that reason.
Ask for a redacted sample report before you sign
This is the highest-value thing you can do, and almost nobody does it. Every credible penetration testing provider keeps a sanitised sample ready. A refusal, or a slide deck sent instead of a report, has answered your question.
When it arrives, read one finding end to end, ideally a medium-severity one, since criticals are written carefully by everyone. Check for six things:
- A CVSS v3.1 or v4.0 score with the vector string visible, so the rating is auditable rather than a mood.
- Reproduction steps precise enough that your developer follows them without asking a question: exact request, parameter and expected response.
- Business impact in your language. "A free-plan user can read any other organisation's invoices" is impact; "insecure direct object reference" is a category.
- Remediation specific to your stack. Generic advice to "validate all user input" means nobody looked at your code.
- Evidence: screenshots, request and response pairs, a proof of concept. Redacted is fine. Absent is not.
- A re-test section, showing verification is part of the document rather than an upsell.
If the report must satisfy an auditor or an overseas customer, structure matters as much as findings. We broke that down in what a SOC 2 ready pentest report contains and your US client asked for a VAPT report, and we treat reporting as a service in its own right.
Scope and methodology questions to ask
These answers tell you whether a vendor has a repeatable process or improvises. Ask which methodology the engagement follows. For a web application you want the OWASP Web Security Testing Guide, PTES, OSSTMM, or an in-house process mapped to one of them. For an API, the OWASP API Security Top 10. For mobile, MASVS. A vendor who cannot name a framework is improvising, and improvisation is not repeatable across your next three annual tests. Ours is on our methodology page, so you can compare it against anyone else's.
Then ask about access. A black box test with no credentials is legitimate, but for most SaaS products it burns half the budget on reconnaissance and never reaches the authenticated area where the real risk lives. Credentialed testing finds far more per rupee, and multi-tenant products need two accounts per role so cross-tenant isolation is proven rather than assumed.
Finally, pin down what is out of scope in writing: third parties you do not own, production payment rails, denial of service, social engineering of staff. Undocumented exclusions are how a report ends up with a hole your auditor finds first. Our scoping call checklist doubles as an interview script for any vendor.
Legal and safety: the paperwork that protects you
Testing a system without written authorisation is a criminal act under Pakistan's Prevention of Electronic Crimes Act, and under equivalent laws wherever your infrastructure sits. Five things should exist in writing before anyone touches your application.
An authorisation letter, sometimes called a rules of engagement document, signed by someone with authority to grant it and naming the in-scope targets, the testing window and the testers' source IPs. A mutual NDA covering everything the testers see, which for a pentest is your entire system. A data handling clause: where evidence lives, whether your data leaves the testers' machines, and when it is destroyed. A named escalation contact reachable within thirty minutes. And a clause covering what happens if testing affects production.
Press on that last one. The answer you want is that they stop, call your escalation contact, document exactly what they sent, and help you recover. Ask whether they carry professional indemnity insurance, and whether destructive payloads go near production. A vendor who has never thought about this has never gone deep enough for it to come up.
Re-testing: the clause that changes the real price
A pentest that ends at report delivery is half a service. Your developers fix the findings, and somebody has to confirm the fixes closed the issue rather than moved it. That verification is what your auditor wants, because a report full of open criticals proves nothing except that you were tested.
Re-test terms vary enormously and are rarely on page one of a quote. Ask three things: is it included, how long do we have to use it, and does it cover all findings or only high and critical? Thirty days is tight for a small team; ninety is comfortable. Ask what the deliverable is, too: an updated report with each finding marked verified and closed, not an email saying it looks fine now. That is the document you forward on.
Red flags
Any one of these should slow you down. Two or more, keep shopping.
- A quote with no scoping call. A number that arrives before any questions is either padded for uncertainty or too low to cover real work, and the second returns as change orders.
- Per-IP or per-URL pricing with no other context. Effort scales with roles and business logic, not address count.
- Guarantees about findings. "We will find at least fifteen vulnerabilities" means informational tool output is going into your report to hit the number.
- No named tester. If the contract says "our team" and nobody will say who is assigned, you cannot tell a senior specialist from an intern with a licence key.
- Tool output as the deliverable. If the sample report is visibly a Nessus or Burp export with a cover page, that is the whole product.
- No sample report, no references, no methodology document. Any one is a gap. All three is a marketing company.
- Pressure to skip the paperwork. "We will sort the letter out later" treats your legal exposure as an inconvenience.
The checklist to send a vendor
Paste these into one email and send it to every firm on your shortlist, ours included. The answers, and their speed and specificity, separate the field faster than any amount of website reading.
- How many tester-days does this quote include, and what is the day rate behind it?
- Who specifically will test our application, and what is their track record?
- Can you send a redacted sample report from a comparable engagement?
- Which methodology do you follow, and can we see it written down?
- Will testing be credentialed, and how many accounts per role do you need?
- What is out of scope, and will that appear in the statement of work?
- What share of the engagement is manual testing versus automated scanning?
- Do you score findings with CVSS, and will the vector strings be in the report?
- Is a re-test included, for how long, and at every severity?
- What happens if testing disrupts our production environment?
- Where is our data stored, and when is it destroyed?
- Do you provide a letter of attestation we can forward to our client or auditor?
- Can you give us two references from companies our size?
Frequently asked questions
How much should a penetration test cost in Pakistan?
For a typical SaaS web application, a genuine manual engagement runs five to ten working days of tester time, and local pricing tends to land between PKR 350,000 and PKR 1,200,000 depending on complexity, API surface and reporting needs. Treat anything far below that band as a scan unless the vendor can show the tester-days behind it.
Do I need a local company, or should I hire abroad?
Your client or auditor cares about independence and evidence quality, not the tester's postcode. A local provider is usually far cheaper for equivalent skill, shares your working hours, and can sit with your engineers for the debrief. What matters is independence from the team that built the software.
How long does a penetration test take?
Scoping and paperwork take a few days, testing is typically five to ten working days, and reporting adds two to three more. Budget three to four weeks from first email to final report, plus the re-test window. Anyone offering a finished pentest report in forty-eight hours is selling a scan.
How often should we test?
Annually is the baseline most compliance frameworks and enterprise buyers expect. Test again after a major architectural change, a new authentication system, or before a launch that expands your attack surface. A mobile client is a separate surface needing its own mobile application test rather than being folded into the web application engagement.
The short version
Choosing a penetration testing company comes down to three facts. A named, credentialed human does the testing rather than a tool. The report explains impact, proves it, and tells your engineers how to fix it. And paperwork bounds the engagement, with a re-test verifying the work landed.
Ask for the sample report. Ask who is testing. Ask for the tester-days. Any provider worth hiring will be glad you asked, because those questions are what separates them from the cheapest quote in your inbox.