If you sell software out of Lahore, Karachi or Islamabad, two emails can land in the same week asking for the same thing in different words. A client in Dubai wants "your latest VAPT report" before onboarding is complete. A client in Austin asks whether you have "had a pentest done recently." Same request. The vocabulary just changed at the border.
VAPT is short for Vulnerability Assessment and Penetration Testing, the phrase that dominates tenders, RFPs and vendor onboarding forms across Pakistan, India and the Gulf. In the US and Europe the same work is simply called a penetration test. That mismatch wrecks the job of comparing quotes: one vendor prices a two hour automated scan as VAPT, another prices two weeks of manual exploitation as VAPT, and the buyer holding both PDFs cannot easily tell the proposals apart.
So this is the buyer's version of the term, for Pakistani software houses, fintechs and enterprise teams: what VAPT services in Pakistan cover, what lands in your inbox at the end, and what moves the price and the calendar.
VAPT Meaning: Two Halves, One Engagement
The acronym is doing real work, and it pays to take it literally. The first half, vulnerability assessment, is the broad one. Scanners sweep the whole in-scope surface and flag known CVEs, weak configurations and exposed services. It is fast, repeatable, and it tells you what might be wrong.
The second half, penetration testing, is the deep one. A human takes the interesting findings and tries to use them: exploiting a flaw, chaining three small issues into one serious one, escalating to administrator, and producing evidence that the impact is real. It tells you what an attacker can do.
Neither half is optional, because they fail in opposite directions. Scanning alone gives a long list padded with false positives and no sense of which items would hurt. Manual testing alone can miss the unpatched library on a forgotten staging box because nobody swept for it. Running both, in that order, is the whole idea behind the term. The full comparison is in penetration testing vs vulnerability assessment.
What Goes In Scope
VAPT is not a single product. It is a method applied to whichever assets you put inside the boundary, and the first honest step of any engagement is agreeing that boundary in writing. These are the surfaces that come up most often.
- Web applications. The customer portal, the admin panel, the partner dashboard. Usually the highest risk scope, because it faces the whole internet. See web application VAPT.
- Mobile applications. Android and iOS builds tested on the device and against their backend: local storage, certificate handling, hardcoded secrets. See mobile app VAPT.
- APIs. Most fintech products are an API with screens attached. Broken object level authorisation, missing rate limits and token flaws live here, invisible to a UI-only test. See API security testing.
- Cloud environments. AWS, Azure and GCP fail at the identity and configuration layer far more often than in code: over-permissive roles, public storage, exposed management endpoints. See cloud security VAPT.
- Internal and external networks. External testing looks at what an outsider can reach. Internal testing assumes a foothold already exists (a compromised laptop, a contractor on the office Wi-Fi) and asks how far it gets. See network penetration testing.
- Desktop applications. Thick clients in banking, ERP and point of sale still carry insecure local data, weak update mechanisms, and misplaced trust in the client. See desktop app testing.
A written scope names the exact hosts, URLs and builds, lists every role to be tested (anonymous, user, merchant, admin), states the environment, and fixes a test window. If a quote lacks that detail, ask for it before comparing prices: two numbers attached to two different boundaries are not comparable.
What You Actually Receive
Testing produces knowledge; the deliverables are how it reaches your engineers, your management and your client's procurement team.
The findings themselves
Every issue is written up as its own entry with a severity rating. Serious providers use CVSS, the industry standard that turns attack complexity, required privileges and impact into a number and a band from informational up to critical. It is what auditors expect. A good report adjusts priority for context too: a critical on an internal tool with four users is not the emergency a critical on your payments flow is.
Each entry also gives the affected asset, the exact request that triggers it, and reproduction steps precise enough for a developer to recreate the issue. If a finding cannot be reproduced from the report alone, it is not finished.
Proof of concept evidence
Evidence is what separates a verified finding from a scanner's guess: annotated screenshots, request and response pairs, a short recording for a multi-step exploit, or the sanitised data retrieved. Real data is redacted and nothing destructive is left behind. This is the section your client's reviewer skims to judge whether the testing was genuine.
Business impact and remediation guidance
For each finding, a plain sentence on what an attacker gains: read every customer's KYC documents, place orders as another merchant, mint an admin session. Then remediation guidance specific to your stack rather than a paragraph copied from a standards document, plus an interim mitigation where the real fix is a large project.
Executive summary, attestation letter and re-test
The executive summary is one or two pages your board or your client can read without a security background: what was tested, the overall risk posture, the severity counts, the headline issues. We covered how reviewers read these in your US client asked for a VAPT report, and mapped the full structure in what a SOC 2 ready pentest report contains.
The letter of attestation is a short, shareable statement confirming that an independent party tested a defined scope on defined dates using a recognised methodology. It exists because you cannot hand a prospect the full report, which is a map of your weaknesses.
Finally, the re-test. After your team fixes the findings, the tester verifies each one and reissues the document showing what is closed. That version is the one buyers want to see, so ask whether a re-test is included or billed separately. Our approach sits under security audit and reporting.
How VAPT Maps to Compliance
Most VAPT purchases in Pakistan are triggered by somebody else's requirement, so it helps to know which one you are satisfying. SOC 2 and ISO 27001 name no tool and no vendor, but both expect you to identify and manage technical vulnerabilities on an ongoing basis, and auditors have converged on an independent penetration test plus continuous vulnerability management as the evidence. PCI DSS is more prescriptive for anyone touching cardholder data, calling for regular internal and external scanning as well as periodic penetration testing. We compared these routes in SOC 2 vs ISO 27001 vs just a pentest.
For Pakistani fintechs the local layer matters too. The State Bank of Pakistan's technology governance and risk expectations for banks, electronic money institutions and payment system operators include periodic independent security assessment of critical systems, and the SECP applies comparable expectations to the entities it regulates. Confirm the exact obligation for your licence category with your compliance advisor, then scope the engagement so the report answers it.
Then there are client security questionnaires, the real driver for most software houses. They ask when you last had an independent penetration test, whether findings were remediated, and whether you can share evidence. A current report plus a re-test plus an attestation letter answers that whole block in one attachment, which is often the difference between a deal moving and a deal stalling.
What Drives Cost and Duration
Pricing varies too much by vendor and scope for a published number to mean much, but the drivers are consistent.
- Scope size. The count of applications, hosts, IPs and endpoints is the primary lever. Five applications is five times the work, not marginally more.
- Number of user roles. Each privilege level is tested against every other, so authorisation testing grows faster than the role count itself.
- Application complexity. Feature depth, not page count, takes the time. A brochure site with a contact form is not a multi-tenant lending platform.
- Credentialed versus unauthenticated testing. Working accounts for every role find more, because the serious flaws live behind the login.
- Black box versus grey box. Black box spends budget on discovery. Grey box supplies credentials, architecture notes and API documentation, so more of the budget goes into finding bugs.
- Retest included or not. A quote that bundles a verification round after your fixes is worth more than a cheaper one that bills the re-test as a fresh engagement.
- Reporting depth. A report written for an auditor, with an executive summary and attestation letter, takes more effort than an exported tool output.
As a rough calendar guide, a focused test of a single web application typically runs 3–5 business days plus reporting time. That application with its API and a modest cloud footprint tends to run 1–2 weeks. Broader scopes run longer and are better split into phases. Plan the re-test for a few weeks later, once developers have shipped fixes. Our scoping call questions cover what a vendor should ask before quoting.
How Often to Run VAPT
The default cadence for the penetration testing half is annual. That is what compliance frameworks assume, what client questionnaires ask about, and what keeps an attestation letter current.
Annual is the floor, not the answer. Test again before or shortly after a major release that changes authentication, authorisation, payments or how data is stored. Test again after an infrastructure change: a cloud migration, a new third party integration, a change in network segmentation. Test when a large client asks for a report dated within the last twelve months, a common contractual threshold.
The vulnerability assessment half should not wait a year. Automated scanning is cheap enough to run monthly, or continuously in your pipeline, across servers, containers and dependencies. That is what catches the newly published CVE in a library you shipped six months ago. Yearly depth, monthly breadth.
What a Good VAPT Engagement Looks Like End to End
From the buyer's seat, a well-run engagement is predictable, with no surprises in it except the findings.
- Scoping. A call that establishes assets, roles, environments and constraints, ending in a written scope and a test window.
- Paperwork. An NDA, a signed authorisation to test, and rules of engagement covering what is off limits and who to call if something breaks.
- Access and setup. Test accounts for each role, allowlisting so your WAF does not block the tester, and documentation for the grey box work.
- Vulnerability assessment. The broad automated sweep across the agreed surface, producing the raw candidate list.
- Manual penetration testing. Verification, exploitation, chaining and business logic testing. Critical findings are reported immediately, not held for the report.
- Reporting. Findings, evidence, impact and remediation, plus the summary and attestation letter, followed by a walkthrough call with your engineers.
- Remediation and re-test. Your team fixes, the tester verifies, and the report is reissued with closed status recorded. That version is what you send to clients.
For how the middle steps run, our methodology page walks through the standards we follow.
Frequently Asked Questions
Is VAPT the same as a penetration test?
Almost. VAPT explicitly bundles the automated breadth of a vulnerability assessment with the manual depth of a penetration test, whereas a Western buyer saying pentest assumes the scanning is included anyway. One well-scoped engagement satisfies both. Confirm in writing that manual exploitation is included, because that is the half low-cost vendors quietly drop.
Can I share the VAPT report with my clients?
Share the attestation letter freely: it confirms scope, dates, methodology and independence without exposing exploitation detail. The full report should go out only under NDA, ideally after a re-test. Many enterprises accept the letter plus a redacted executive summary.
Do we need a vulnerability assessment if we already run scanners?
Keep it running, it is genuinely valuable. What it cannot provide is independence, and independence is what auditors and clients are buying. A vulnerability assessment performed by an outside party also finds the assets your inventory forgot, which is where the interesting problems hide.
What if the test finds something critical?
You get told immediately, not six weeks later with the report. A responsible tester pauses, notifies your named contact out of band, and gives you enough to mitigate while testing continues. Finding something critical is not a failure. It is the process working, in private, before somebody else found it.
VAPT is a regional word for a global practice, and the confusion around it costs Pakistani buyers real money in mis-scoped quotes. Strip it back and it is simple. You are buying breadth and depth across an agreed set of assets, plus a reproducible body of evidence your engineers can act on and your clients will accept. Get the scope in writing, confirm manual testing and a re-test are included, and check the deliverables against what your client or auditor asked for.