Almost nobody wakes up wanting a penetration test. The conversation usually starts one of three ways. A Lahore software house signs a US client, and two weeks later a vendor security questionnaire arrives asking for a recent third-party pentest report. A Karachi SaaS company starts SOC 2 or ISO 27001, and the auditor wants evidence of periodic testing. Or somebody sees something odd in the logs at 2am.
All three arrive with the same problem attached: whoever owns it has never bought a pentest before. What goes in scope? How long does it take? What separates real penetration testing services from a vendor who runs a scanner and rebrands the PDF?
This guide answers those questions in plain English, for Pakistani software houses, SaaS companies and enterprises selling into Western and Gulf markets. No jargon for its own sake, no invented price list.
What Penetration Testing Actually Is
A penetration test is a controlled, authorised attempt to break into a system so its owner learns what a real attacker could do. A tester takes the position of an adversary, works through your application or network methodically, and tries to reach data or functionality they should not. Everything they achieve is written down with evidence, so your engineers can close the gap.
The word that matters there is authorised. The techniques are the ones a criminal would use, and in Pakistan, as everywhere, using them without written permission from the owner is a crime under the Prevention of Electronic Crimes Act. A legitimate engagement starts with paperwork, and a vendor willing to skip it is telling you something.
How it differs from a vulnerability scan
This is the most common confusion, and it costs Pakistani companies money, because they buy one thinking they bought the other. A vulnerability scan is a tool matching your system against a database of known issues: outdated libraries, missing patches, absent security headers, default configurations. It is fast, cheap, worth running often, and it lists things that might be wrong.
A penetration test is a person. The scanner is one of their tools, used early to clear the obvious ground, but the value comes after. A scanner cannot know that invoice 8841 belongs to another company's account, so when a tester edits an ID in a URL and reads a competitor's data, it sees two identical successful responses. Broken access control and business logic flaws are where breaches come from, and finding them needs a human who understands what your product is for.
For the full comparison see penetration testing vs vulnerability assessment, and for a wider map of the field, what is security testing. In short: a scan tells you what might be wrong, a pentest proves what an attacker could do, and cybersecurity penetration testing done properly is mostly the second thing.
The Types of Pentest a Pakistani Business Actually Needs
What you need follows from your attack surface, the list of things an outsider can reach. These are the six engagements we are asked for most.
Web application
If you sell a SaaS product, run a customer portal, or expose an admin panel to the internet, this is your starting point and usually your highest-value test: authentication and sessions, access control between users and tenants, injection, file upload, configuration. For a multi-tenant product, tenant isolation alone justifies it. See web application penetration testing.
API
Most Pakistani product companies ship an API before a UI, and APIs fail differently: broken object-level authorisation, endpoints returning far more fields than the front end shows, no rate limit on anything involving a one-time code, old API versions still running after the new one shipped. A browser-driven test walks past most of it. See API security testing.
Mobile
Fintech, delivery, health and e-commerce apps need both halves: the package itself (hardcoded keys, secrets in the APK, insecure local storage, weak certificate handling, root and jailbreak checks) and the backend behind it. The backend usually holds the serious findings, so mobile work often pairs with an API test. See mobile penetration testing.
Cloud
The failure mode on AWS, Azure and GCP has moved from unpatched servers to misconfigured identity: over-permissive IAM roles, public buckets, keys committed to a repository, a security group opened during a late deploy and never closed. A cloud review reads the configuration, not just the perimeter. See cloud penetration testing.
Network
For enterprises, banks, telcos and anyone with an office network, VPN and on-premise servers. External testing looks at what your public IP ranges expose. Internal testing assumes an attacker is already inside, via a compromised laptop or guest Wi-Fi, and asks how far they can move. See network penetration testing.
Desktop
Less common, but it matters for ERP clients, trading terminals, POS software and licensed tools shipped to customers: local privilege escalation, credentials on disk, unsigned updates, and what a determined user can do by modifying the client. See desktop application testing.
Most first engagements we scope are a web application test plus the API behind it, because that is where the customer data sits.
How an Engagement Runs, End to End
A good engagement is boring in the best sense: predictable stages, known deliverables, no surprises.
1. Scoping
A call, usually 30 to 45 minutes, in which the tester establishes what exists and what matters: how many applications and endpoints, which roles exist and where the security-relevant boundaries sit, staging or production, whether test accounts are provided, and what your client's questionnaire asks for. That is what makes a quote accurate rather than a guess. We list all of it in the 17 questions we ask before quoting.
2. Authorisation and NDA
Then paperwork: a statement of work fixing scope and dates, an NDA in both directions, and a signed authorisation letter naming the exact assets that may be tested and the window for testing. If you are hosted with a third party, provider notification happens here. Keep the signed letter; auditors sometimes ask for it.
3. Testing
The tester maps the surface first (pages, endpoints, parameters, subdomains, roles), runs tooling for breadth, then spends most of the time on manual work: replaying requests across two accounts to hunt access-control flaws, probing authentication and password reset, walking business-logic flows for steps that can be skipped, chaining small issues into one serious finding. Expect near-daily updates, and anything critical to reach you immediately. Our methodology page has the full sequence, and our 5-day web pentest breakdown shows it against a real clock.
4. Reporting
Findings are delivered within a few days of testing ending. A good vendor walks your engineers through the document on a call instead of emailing a PDF and disappearing.
5. Re-test
Your team fixes what was found, and the tester verifies each fix and confirms it introduced nothing new. Without a re-test nobody can honestly say the issues are closed, and the dated result is often exactly what your client wants to see.
What a Real Report Contains
The report is the product, and two audiences read it, so it has two registers.
The executive summary is for your CEO, your client's procurement team and your auditor: scope, dates, methodology, an overall risk position, and a count of findings by severity. One page should be enough for a non-technical reader.
The technical section is for engineers and lives or dies on reproducibility. Each finding carries a CVSS severity rating, the affected endpoint, step-by-step reproduction, evidence in requests and screenshots, plain business impact, and a specific fix. "Implement proper access control" is not remediation. "Enforce a tenant ID check server-side on GET /api/v2/invoices/{id}" is.
Overseas clients ask for this because it is the only evidence they accept. "We take security seriously" carries no weight in a vendor review; an independent, dated report with a named tester, a defined scope and a completed re-test does. SOC 2 and ISO 27001 auditors expect one too, though a pentest is not either certification, a distinction we untangle in SOC 2 vs ISO 27001 vs a pentest. Most vendors also issue a letter of attestation you can share without the technical detail. See security audit and reporting.
What Drives Cost and Timeline
We will not publish a price, because a number quoted without seeing your scope is marketing rather than information. What we can be specific about is what moves it, so you can compare vendors on the same basis.
- Scope size, counted in applications, endpoints, user roles and IP ranges, not in vague size labels.
- Application complexity. A brochure site and a multi-tenant fintech platform are not comparable, even if both are "one web app".
- Manual depth versus automated coverage. The biggest single driver, and where cheap quotes hide. Ask what share of the days is manual.
- Whether a re-test is included. Some vendors quote low and bill the re-test separately. Get it in writing either way.
- Environment and access. Out-of-hours production testing, an environment with no test data, or waiting on credentials all add days.
- Reporting requirements. A standard report is quicker than one mapped clause by clause to a client's own template.
- Cadence. A one-off test costs more per engagement than a standing relationship where the tester already knows the codebase.
Honest timeline ranges look like this. A focused web application test is typically 3 to 5 business days of testing plus 2 to 3 days of reporting. Full scope across a web app, its API and the cloud behind it runs 1 to 2 weeks. A mobile app with its backend lands at 5 to 8 days. Add a day or two for the re-test.
Worth saying plainly: the cheapest quote is almost always a scan with a cover page. A "full pentest" delivered in a day is a tool run, and that report will not survive a serious vendor review.
How to Prepare Before Testing Starts
Preparation is the cheapest way to get more out of the days you pay for. A tester who spends day one chasing credentials has lost a fifth of the test.
- Inventory your surface honestly: every domain, subdomain, API, admin panel and staging environment. The forgotten server is the one that breaches you.
- Provide at least two accounts per role. Access-control testing means comparing what user A can reach against what user B can reach.
- Populate test data. An empty database hides the findings that only appear when records belong to different owners.
- Fix the free wins first: dependency updates, the exposed
.env, debug mode, missing security headers. Do not pay a specialist to rediscover them. - Whitelist the tester and warn your team, so a WAF does not silently block the test and on-call does not page at midnight.
- Name one point of contact who can answer questions and approve decisions during the window.
- Freeze deployments if you can. Testing a moving target produces findings that no longer reproduce.
Common Mistakes
Four we see repeatedly, each with a real cost attached.
Treating a scan as a pentest. The client asks for a penetration test, the company buys a scan because it is cheaper, the report gets rejected in the vendor review, and the real test gets bought a month later under pressure.
Testing once a year and calling it a programme. An annual test is a snapshot of an application that ships every fortnight. Test after significant releases too, especially anything touching authentication, payments or file handling.
Skipping the re-test. Findings get closed in a ticket tracker with nobody verifying the fix. Partial fixes are common with access control, where a check gets added to one endpoint and missed on the three that share the flaw.
No authorisation letter. Testing without written permission is illegal, and it leaves you nothing to show an auditor about how the engagement was governed.
Frequently Asked Questions
How long does a penetration test take in Pakistan?
Testing on a focused web application usually runs 3 to 5 business days, with the report 2 to 3 days behind it. Full scope across a web app, API and cloud is typically 1 to 2 weeks. Allow two to three weeks from authorisation to final report.
Do we need to test production, or is staging enough?
Staging is preferred when it genuinely mirrors production: same configuration, same authentication, realistic data. In practice it often differs exactly where it matters, so the common compromise is to test staging thoroughly and run a light, scoped confirmation against production in an agreed window.
Will our international client accept a report from a Pakistani firm?
Yes, provided the work stands up. Buyers examine independence from your development team, a defined scope, a recognised methodology such as OWASP and PTES, reproducible evidence, and a completed re-test. Location is rarely the objection. A thin report is.
How often should we run a pentest?
Annually as a floor, because that is what most frameworks and client questionnaires require. Beyond that, test after any significant change to authentication, payments or cloud architecture, and before onboarding a customer much larger than your current ones. Scanning fills the gaps; it does not replace the engagement.
Penetration testing in Pakistan is neither a mystery service nor a formality. It is a defined engagement with a defined output: an evidence-backed account of what an attacker could do to your product, and a document your clients and auditors will accept. The companies that get the most from it scope honestly, prepare properly, fix what comes back, and insist on the re-test.
If you are staring at a client questionnaire trying to work out which test you need, that is a short conversation. Tell us what you have built and we will tell you what belongs in scope.