What Determines the Cost of a Penetration Test, and How Do You Scope One Properly?

Why two quotes for the same system can differ several times over. The scoping variables behind every pentest price, the pricing models, and how to compare proposals on effort rather than the headline figure.

What actually determines the cost of a penetration test?

The cost of a penetration test is determined by the number of skilled tester-days the scope requires, multiplied by the provider's day rate, plus the overhead of the delivery model: project management, quality review, report writing, retesting and any travel. A penetration test itself is a time-boxed, authorised attempt by qualified testers to find and exploit weaknesses in a defined set of systems, followed by a report explaining what was found, how serious it is and how to fix it. Every variable a provider asks about during scoping either adds tester-days or changes the seniority of tester required.

That framing matters because every pricing conversation is really a conversation about effort. A very low figure for a large scope means little time, heavy automation or junior staff. A high figure means deeper manual work, or uncertainty being priced in because the scope is vague.

Whether the proposal says VAPT (the usual label in Pakistan and the Gulf) or penetration testing (the US, UK and EU term), the scoping logic is identical. The variables below are what a competent provider will ask about before naming a figure.

Which scoping variables move the price most?

Scope is the set of assets, access levels and test conditions that define what testers may touch and how deeply. Each variable below either adds tester-days directly or changes the seniority of tester required, and the first three usually cause the largest swings.

The primary variables, roughly in order of impact, are:

• Asset count and complexity: a brochure site with a contact form is a fraction of the effort of a multi-tenant SaaS platform with hundreds of API endpoints, file uploads, payment flows and integrations. Testers estimate by counting dynamic pages, endpoints, parameters and distinct workflows, not domain names.
• User roles: every additional role (anonymous, customer, merchant, support, administrator) multiplies authorisation testing, because access control flaws live in the gaps between roles. Five roles are not five times the work of one, but considerably more than double.
• Black, grey or white box: black box (no credentials or documentation) spends much of the budget on discovery. Grey box (credentials plus an architecture briefing) directs effort at the logic that matters. White box (source code and configuration access) is the most thorough and needs the most skilled reviewer time. Grey box is the sensible default for most application tests.
• Environments: production, staging and a separate regional deployment are three engagements with shared context, not one. Expect to be asked whether the test environment genuinely mirrors production.
• Retesting: verifying that fixes actually work. Many providers include one retest; confirm yours does, and confirm in writing whether anything beyond it is charged per finding or per day.
• Compliance reporting: if an auditor for ISO 27001, SOC 2 or PCI DSS, or a regulator such as the State Bank of Pakistan, will read the report, expect extra effort on methodology documentation, evidence, attestation letters and control mapping.
• On-site versus remote: on-site work adds travel and lost productive days and is normally only needed for internal networks without VPN access or physical assessments.
• Timelines: compressing a test into a week to meet a customer deadline means more testers in parallel and a rush premium. Most single-application engagements run two to four weeks including reporting; anything much faster is either very small or very shallow.

Secondary variables include the testing window (business hours or out of hours), whether social engineering or denial-of-service checks are in or out, and how many stakeholder meetings the provider must attend. Each of these moves the figure at the margin rather than by multiples.

Why do day-rate and fixed-scope pricing models produce different quotes?

A day-rate model bills for the time agreed: you buy a number of tester-days, sometimes with a cap, and the provider invoices for them. A fixed-scope model quotes one figure for a defined deliverable and the provider absorbs any overrun. Both are legitimate; the difference is who carries the risk of a wrong estimate.

Day rates suit uncertain or growing scopes, such as a first test of a large legacy estate or a red team exercise (an objective-driven simulation of a real attacker against people, process and technology). They are transparent about effort but need the buyer to watch how days are spent. Fixed prices suit well-defined targets, give finance a single number and are easier to compare, but only if the scope document is precise. A fixed price against a vague scope is a warning sign: the provider must either pad the figure or cut corners when the target proves bigger than assumed.

Hybrids are common and usually fairest: a fixed price for the core scope with a pre-agreed day rate for additions discovered mid-engagement. Under any model, ask for the tester-days behind the figure. If a provider cannot state them, you are not comparing like with like.

What does a cheap penetration test usually leave out?

A very low quote is not automatically bad, but it almost always means something has been removed from the engagement, and the omissions are usually the parts a buyer cannot see from outside.

The useful question is not whether the price is low but how many skilled hours it implies, and whether your scope can honestly be covered in them. In practice, budget-priced tests tend to leave out:

• Manual business-logic testing. Scanners cannot tell that a discount code should not be reusable, that an invoice number can be incremented to read another customer's data, or that a password reset can be raced. These findings only come from a human spending time in the application.
• Authenticated, multi-role coverage. Testing only the unauthenticated surface skips most of the attack surface of any real application.
• Exploitation and impact. A theoretical finding with no demonstration of what an attacker could reach leaves the business unable to prioritise.
• Senior review. A single junior tester with no second pair of eyes on the findings or the report.
• A usable report. Scanner output exported to PDF, without an executive summary, reproduction steps or remediation guidance, is not a penetration test report.
• Retesting and post-report support when developers have questions about a fix.

How do you compare penetration testing quotes fairly?

Quotes are only comparable when they answer the same scope at the same depth. Before judging on price, normalise each proposal against the list below and request anything missing in writing.

Once every quote is filled in against the same list, the remaining differences are the real ones, and the cheapest proposal is often no longer the cheapest per day of skilled work. A fair comparison checks that every quote states:

• The exact assets in scope by URL, IP range, application or repository, with exclusions named explicitly.
• The tester-days or hours allocated and how many testers work in parallel.
• The box model and the access, credentials and documentation expected from you.
• The methodology, whether testing is predominantly manual, and which automated tools are used.
• The seniority and certifications of the people actually doing the work, not just the firm's credentials.
• Report contents: executive summary, severity ratings with rationale, reproduction steps, evidence, remediation advice and any compliance mapping or attestation letter.
• Whether a retest is included, its window and what it covers.
• How critical findings are communicated during the test rather than only at the end.
• Quote validity, payment terms and how scope changes are priced.

What are the red flags in a pentest proposal?

The clearest red flag is a quote produced without anyone asking what you want tested. None of the signs below proves a poor provider on its own, but two or more together deserve hard questions:

• A quote produced without a scoping call, questionnaire or any request for asset details.
• A guarantee of finding nothing, or a promised clean report for compliance purposes.
• No distinction between a vulnerability scan and a penetration test in the proposal.
• Refusal to say who will do the testing or to share a redacted sample report.
• No rules of engagement, emergency contacts or plan for production-impacting tests.
• A price that is a small fraction of every other quote for the same scope.
• Reluctance to sign an NDA or to explain how findings and your data are stored and destroyed.
• A report promised a day or two after testing ends, which usually means scanner output.

How do Pakistani and international pentest pricing models differ in structure?

The economics are the same everywhere: tester-days multiplied by a rate. What differs between markets is the structure of the engagement and the expectations around it, so a buyer weighing a Pakistani VAPT provider against a UK or US firm should adjust for structure rather than compare headline figures.

In Pakistan and the Gulf, VAPT is usually procured as a fixed-price package tied to a regulatory or customer requirement. Typical triggers are a bank's periodic testing cycle under State Bank of Pakistan technology governance expectations or a telecom operator's PTA compliance obligations. Proposals typically bundle the vulnerability assessment, the penetration test, a retest and a compliance-oriented report into one deliverable, and on-site delivery is more often expected. Formal tenders compared on the bottom line push providers to price aggressively, which makes the tester-day question even more important.

In the US, UK and EU, testing is more often quoted per tester-day, or as a fixed price against a tightly written statement of work. Remote delivery is the default and the retest is often a separate line item. Named testers, a sample report and a documented methodology are expected as standard. Day rates track local salary costs, which is why a remote-first team based in Pakistan can deliver comparable depth of manual work to international clients at a different rate. Hold the day count and depth constant, and the comparison becomes honest.

How do you scope a penetration test properly before requesting quotes?

Good scoping is the most effective cost control available, because it removes the uncertainty providers otherwise price in, and it produces better tests: the testers spend their time on what matters instead of discovering what you already knew.

Share one pack with every provider you invite to quote. Proposals arrive faster, more consistent and more honest, and the scoping call becomes a discussion about approach rather than an inventory exercise. At Zencryptix, this pack is what lets us return a quote within 48 hours of scoping. It should contain:

• An asset inventory: every application, API, host and cloud account in scope, with size indicators such as endpoint counts, user roles and integrations.
• A statement of objective: compliance evidence, pre-launch assurance, a customer requirement or a specific attack path you want tested. The objective sets the depth.
• The access you can provide: test accounts for each role, architecture diagrams, API documentation and, for white box, repository access.
• Constraints: testing windows, production sensitivity, systems that must not be touched and third-party hosting that needs its own authorisation.
• Your timeline for testing, remediation and retesting, so the provider can schedule realistically.

Frequently asked questions.

The price of a penetration test is a consequence of decisions you make before the first request for proposal goes out. Define the assets, the roles, the access model and the objective, put the same pack in front of every provider, and most of the confusion disappears. If you would like a quote scoped on that basis, the Zencryptix VAPT Services in Pakistan page explains how we work and what a scoping conversation covers.