A penetration test is priced by tester-days, not by your company size or your revenue. Everything else in a quote is a function of that one number: how many days a qualified tester spends against your systems, multiplied by a day rate, plus whatever the vendor charges for reporting and a retest. Day counts in this market run from about three days for a single small web application to forty or more for an estate covering web, mobile, APIs, source code and infrastructure. That is why two quotes for "a penetration test" can differ by a factor of ten and both be honest. They are not quoting the same test.
This article is a SPOKE in Vervali's security testing cluster. It answers the pricing question specifically. For scoping and vendor selection, start at our hub, Vulnerability Assessment Services in 2026: How to Scope, Compare and Choose a Vendor. Sibling spokes go deeper on sectors and surfaces: Banking App Security Testing 2026 and Mobile App Security Testing in 2026. The delivery service itself is penetration testing.
What you will learn
- Why a penetration test is priced in tester-days, and how to estimate yours before you ask anyone
- The seven variables that move a quote, and which two of them move it most
- How to tell a scan, an assessment and a penetration test apart in a proposal that calls all three the same thing
- What a compliance requirement adds, and what it does not
- The four costs that are usually missing from the cheapest quote
- A question set that makes two quotes comparable
| Reference | What it establishes | Source |
|---|---|---|
| NIST SP 800-115 | The federal technical guide to security testing and assessment, and still the document most buyers cite | NIST, September 2008 |
| PTES | Seven defined phases, from pre-engagement through reporting, which is what a day count is spread across | Penetration Testing Execution Standard |
| OWASP WSTG | The test-case taxonomy a web application scope is counted against | OWASP Web Security Testing Guide |
| PCI DSS v4.0.1 | The current version of the standard that mandates penetration testing for cardholder environments | PCI Security Standards Council |
| CREST | Third-party accreditation of testing organisations, used as a procurement filter in several markets | CREST |
How much does a penetration test cost in 2026?
There is no single number, and any article that gives you one without asking what you are testing is selling something. What exists instead is a formula that every honest vendor is working from, whether or not they show it to you.
Cost equals tester-days multiplied by day rate, plus reporting, plus retest.
Tester-days is the variable you control, and it is set almost entirely by scope and depth. Day rate is the variable the vendor controls, and it varies by geography, by whether the testers hold third-party accreditation, and by how much of the day rate is really project management rather than testing. Reporting is where a compliance-grade deliverable separates from a tool export. Retest is the line most often quietly missing.
The practical consequence is that you can estimate your own test before you speak to anyone. Count your surfaces. Decide your depth. Multiply. If a quote comes back at half your estimate, the vendor has scoped something smaller than you asked for, and the gap is the thing to ask about.
Key finding. The single most common reason two penetration testing quotes differ by 5x or more is not vendor margin. It is that one vendor scoped the applications you named and the other scoped the applications plus their APIs, their authentication flows, and the infrastructure underneath them. Both wrote "penetration testing" at the top of the proposal.
What actually drives the price of a penetration test?
Seven variables, in rough order of how much they move the number.
1. The number and type of surfaces. A surface is a distinct thing that has to be tested on its own terms: a web application, a mobile application per platform, an API, an external network range, an internal network, a cloud configuration, a source-code base. Two web applications are not one test at double the effort; they are two tests, because reconnaissance, authentication mapping and business-logic analysis restart for each one.
2. Depth of access. Whether the tester starts with no credentials, with a standard user account, or with source code and architecture documentation changes the number of days by a large multiple. More on this below, because it is the variable most often misunderstood as a quality setting when it is really a coverage setting.
3. The number of user roles. An application with an anonymous view, a customer role, a staff role and an administrator role has four privilege boundaries to test against each other. That is not four times the work, but it is not one times it either. Authorisation flaws live exactly on those boundaries and they are the findings that matter most in a transactional system.
4. Whether exploitation is in scope. Identifying a vulnerability and demonstrating it can be exploited are different amounts of work. Controlled exploitation is what separates a penetration test from an assessment, and it is where the days go.
5. Reporting standard. A findings list is cheap. A report an auditor will accept, with methodology, evidence, risk ratings, business impact and remediation guidance per finding, is a deliverable in its own right and typically consumes a meaningful share of the engagement.
6. Retest. Whether the vendor returns to verify your fixes, and whether that is included or billed separately.
7. Accreditation and geography. A day from an accredited organisation in a high-cost market and a day from an unaccredited team in a low-cost market are both days. What differs is the assurance a third party has assessed the testing process, which is why CREST accreditation appears as a procurement filter in some tenders and is absent from others.
| Variable | Low end of its range | High end | Roughly how much it moves the total |
|---|---|---|---|
| Surfaces in scope | One web application | Web, mobile x2, API, external and internal network, source code | The largest single factor. Effectively linear per surface |
| Depth of access | Black-box, no credentials | White-box, source and architecture provided | Substantial. White-box finds more per day but needs more days |
| User roles | One | Four or more with privilege boundaries between them | Moderate, concentrated on authorisation testing |
| Exploitation | Identify only | Controlled exploitation and post-exploitation | Substantial. This is the definition of a penetration test |
| Reporting | Tool export with findings | Auditor-ready report with evidence and remediation guidance | Moderate but rarely itemised in the quote |
| Retest | Not included | Full revalidation after remediation | Usually a fixed additional block |
| Accreditation | Unaccredited team | Third-party accredited organisation | Reflected in the day rate rather than the day count |
What is the difference between a vulnerability scan, an assessment, and a penetration test?
Most price confusion in this market traces back to three different services sharing one label in proposals. They are not interchangeable and they do not cost the same because they are not the same amount of human work.
| Vulnerability scan | Vulnerability assessment | Penetration test | |
|---|---|---|---|
| Primarily performed by | A tool | A tool plus an analyst | A tester, with tools |
| Finds | Known signatures and misconfigurations | The above, triaged and risk-rated in your context | The above, plus business-logic and chained flaws a tool cannot see |
| Proves exploitability | No | No | Yes, through controlled exploitation |
| False positives | Left in | Removed by the analyst | Removed by proof |
| Typical output | A tool report | A prioritised findings list | A narrative report with attack paths and evidence |
| Repeatable on a schedule | Yes, cheaply | Partly | Not cheaply, and that is the point |
A scan is useful and you should be running one continuously. It is not a penetration test and it should not be priced as one. The test that matters is whether the deliverable contains an attack path: a sequence in which the tester chained two or three individually moderate findings into something that actually reaches your data. Tools do not produce attack paths. That is the line.
Watch out. If a proposal quotes a penetration test but the methodology section describes running a scanner and reviewing the output, you are buying an assessment at a penetration test price. Ask which phases of the PTES methodology the engagement covers. If threat modeling, exploitation and post-exploitation are absent, the label on the proposal is wrong.
How does testing depth change what you pay?
Three access models, and the pricing intuition most buyers bring to them is backwards.
Black-box. The tester starts with what an external attacker starts with: your public surface and nothing else. It is the cheapest per day and the most realistic simulation of an untargeted attack. It is also the least efficient use of a day, because a meaningful share of the engagement goes into reconnaissance that tells you nothing you did not already know about your own system.
Grey-box. The tester gets credentials for each user role, and usually a description of the architecture. This is the default for most commercial engagements and it is the best value per day for a reason: it skips the reconnaissance you could have simply told them, and spends the time on authorisation boundaries and business logic instead.
White-box. The tester gets source code, architecture documentation and often a developer contact. It costs more in days because reviewing code is slow, and it finds classes of flaw the other two structurally cannot reach.
The backwards intuition is this: buyers often choose black-box believing it is more rigorous because the tester is given less. What it actually does is spend your budget rediscovering your own architecture. If your goal is to find the flaws rather than to simulate a specific adversary, grey-box gives more coverage for the same money almost every time.
Pro tip. Ask a prospective vendor which access model they recommend and why. A vendor who recommends black-box without asking what you want to learn is optimising for a lower headline number rather than for your outcome. A vendor who asks what you are worried about, and then recommends a model, is scoping properly.
How do you turn a scope into a realistic estimate?
Do this before you request a single quote. It takes twenty minutes and it changes the conversation.
Step one, list your surfaces. Write down every distinct thing that needs testing. Be specific: not "the platform" but "the customer web application, the merchant web application, the iOS app, the Android app, the public REST API, and the external network range".
Step two, count roles per surface. For each application, how many privilege levels exist.
Step three, choose depth per surface. Grey-box for most things. White-box for the surface that would hurt most if it failed. Black-box only where you specifically want to know what an outsider sees.
Step four, decide what a finding is worth to you. If a critical finding in this system would stop a funding round, an enterprise deal or a certification, then retest and an auditor-grade report are not optional extras and you should scope them in from the start rather than discover them as a change order.
Step five, multiply. Apply a day count per surface and a day rate, and you have a range. Every vendor you speak to is doing this arithmetic. Doing it yourself first means you can tell whether their number reflects a different rate or a different scope, which are very different problems.
Vervali publishes its own rate band, which gives you one concrete anchor to run that arithmetic against. On its Clutch profile, verified on 29 August 2026, the published hourly range is $25 to $49 with a minimum project size of $25,000. Use it as a reference point for the low-cost-market end of the range and adjust upward for accredited teams in higher-cost geographies.
What does a compliance requirement add to the bill?
Compliance changes three things about a penetration test, and only one of them is the test itself.
It fixes the frequency. PCI DSS, currently at version 4.0.1, requires penetration testing for cardholder data environments on a defined schedule and after significant change. That converts a one-off purchase into a recurring line item, which is usually the larger budget impact.
It fixes the scope boundary. A compliance-driven test has a defined environment it must cover, and the boundary is not negotiable downward to save money. This is where buyers are most often surprised: the systems in scope are determined by the standard, not by what you wanted to spend.
It raises the reporting standard. An auditor needs methodology, evidence, coverage statements and remediation tracking. A findings list will not clear an audit.
A note on how to read certification claims while you shop, because this is where the market is least honest. A vendor holding a certification and a vendor testing you against a standard are two entirely different claims. A firm that helps you prepare for a SOC 2 audit does not thereby hold SOC 2 itself, and a firm that holds ISO 27001 has certified its own information security management, not your application. Ask which certifications the firm holds, which the named individuals doing your work hold, and which standards they are testing you against. Three separate questions, three separate answers, and a vendor who blurs them is telling you something.
For the record on our side: Vervali holds ISO/IEC 17025:2017, CMMI Maturity Level 3, ISO 9001:2015 and ISO/IEC 27001. It does not hold SOC 2 and does not claim it.
Which costs are hidden in a cheap quote?
Four, and they account for most of the gap between the cheapest proposal and the one you should probably accept.
Retest. The test finds issues, you fix them, and somebody has to confirm the fix worked and did not introduce something new. If retest is not in the quote, budget for a second engagement or accept that your remediation is unverified. Unverified remediation is a finding an auditor will make.
The report your auditor will accept. Ask to see a redacted sample report before you sign. It is the single most informative thing a vendor can show you and most will, because the ones with good reports are proud of them.
Remediation support. When your developers read a finding and cannot reproduce it, who explains it to them. Some vendors include a walkthrough call. Some bill it. Some are gone.
Scope creep from an under-specified proposal. The cheapest quote is frequently the one that scoped least, and the difference arrives later as a change order. This is why doing your own estimate first matters: it tells you which quotes are cheap and which are simply smaller.
Watch out. A quote that does not state the number of days is not a quote, it is a price. Days are the unit of work being sold. A vendor unwilling to state them is either unable to scope or unwilling to be compared, and neither is a good sign.
How should you compare two penetration testing quotes?
Nine questions. Ask all nine of every vendor, and the comparison resolves itself.
- How many tester-days, and how are they distributed across the surfaces in scope?
- Which access model per surface, and why that one?
- Which methodology phases are covered? Name them.
- Is controlled exploitation in scope, or identification only?
- How many user roles are being tested, and are privilege boundaries between them in scope?
- Is a retest included, and within what window after the report?
- Can I see a redacted sample report?
- Which certifications does the firm hold, and which do the individuals assigned to my engagement hold?
- What is explicitly out of scope?
Question nine is the one people forget and the one that matters most at renewal. Everything the answer excludes is a thing you will believe was tested and was not.
Key finding. Read every coverage claim as a statement about scope rather than about your security. "100% coverage of the agreed in-scope systems" is a true and useful statement: it says everything both parties agreed to test was tested. It does not say your application has no vulnerabilities, and a vendor who lets you hear it the second way is a vendor to be careful with.
What does a real engagement scope actually contain?
Abstract scoping advice is easy to nod along to and hard to apply. Here is what defined scopes have contained in practice, drawn from Vervali engagements. Every one is client-attested and anonymised at the client's request.
A digital recharge and payment platform, infrastructure penetration test. Scope covered servers, network components, exposed services and system configurations, with risk analysis, remediation recommendations and revalidation. Outcome: 100% coverage of the agreed in-scope servers and network components, critical gaps identified and risk-prioritised, with detailed vulnerability reporting. Tooling included Burp Suite, Metasploit, Tenable, OpenVAS and Wireshark.
A global marine technology organisation, web and infrastructure penetration test. Scope covered authentication, authorisation, session management, input validation, business logic and the OWASP Top 10 on the application side, plus exposed services, servers, network components and system configurations on the infrastructure side. Outcome: 100% coverage of the agreed in-scope web applications and infrastructure, with critical vulnerabilities identified and prioritised.
A finance-management platform, API penetration test. Scope covered authentication, authorisation, session management, access controls, input validation, data-exposure risk and business-logic workflows, with controlled exploitation, reporting and remediation guidance. Outcome: 100% coverage of the agreed critical API workflows across authentication, transactions and data exchange, with vulnerabilities prioritised by business impact and severity.
A SaaS gaming platform, end-to-end penetration test. The widest of the four: web applications, mobile applications, APIs, source code and backend infrastructure, covering authentication, authorisation and business logic, with threat modelling, attack-path analysis, and both black-box and grey-box testing.
Notice what varies between them. The first is one surface. The last is five. That is the difference a scope makes, and it is why the same three words at the top of a proposal can describe engagements that differ by an order of magnitude in effort and therefore in price.
One engagement worth separating out, because it answers a different question. A private-sector bank engaged Vervali to replace ad-hoc scanning with centralised risk-based vulnerability management, covering prioritisation, remediation workflows, SLA tracking, approvals and reporting. The measured outcomes were a 68% reduction in vulnerability noise, a 30% improvement in remediation time, mean time to remediate falling from over 40 days to under 16, an 80% reduction in audit-preparation effort from roughly five days to five hours, and a 3.5x improvement in the high-risk closure rate.
That engagement is relevant to a pricing article for a specific reason. The audit-preparation figure is a recurring cost most organisations never put on a spreadsheet. Five days of senior engineering time per audit cycle, recovered, is an annual number larger than many penetration testing budgets. If you are pricing a test in isolation, you are pricing only half of what the work is worth.
How does Vervali price penetration testing?
On the same formula as everyone else, with three things stated rather than implied.
The rate is published. $25 to $49 per hour with a minimum project size of $25,000, on the Clutch profile, verified 29 August 2026. Vervali's overall Clutch rating is 4.6 from 11 reviews, with Quality at 4.5, Schedule at 4.5, Cost at 4.7 and Willing to Refer at 4.9. Clutch interviews the client before publishing a review, which is why those counts are comparable with other Clutch counts and not with an unverified rating elsewhere.
The accreditation is specific. ISO/IEC 17025:2017 is an accreditation of testing laboratory competence, which is uncommon for a software QA firm and is a different class of claim from a process certification: it assesses whether the laboratory is technically competent to produce valid results. Alongside it, CMMI Maturity Level 3, ISO 9001:2015 and ISO/IEC 27001. Not SOC 2, which is not held and is not claimed.
The limits are stated too. No individual on the delivery bench holds a CISSP, OSCP or CEH. If a certified individual practitioner is a procurement requirement for your engagement, that is a real constraint and it is better learned here than in week three.
Scoping conversations start from the surface list, not from a package. If you want the estimate before the conversation, run the five steps above and bring the number.
Talk to Vervali about scoping a penetration test, or read the security testing overview for how penetration testing sits inside the wider QA lifecycle.
TL;DR. A penetration test costs tester-days times a day rate, plus reporting and retest. Days are driven by how many surfaces you have, how deep the tester goes, and whether exploitation is in scope. Count your surfaces, pick grey-box for most of them, decide whether retest and an auditor-grade report matter, and multiply before you ask for a quote. Then ask every vendor for a day count and what is explicitly out of scope. The cheapest proposal is usually the smallest one, not the best-value one.
Sources
- National Institute of Standards and Technology. SP 800-115, Technical Guide to Information Security Testing and Assessment, September 2008. https://csrc.nist.gov/pubs/sp/800/115/final (checked 29 August 2026)
- Penetration Testing Execution Standard (PTES). Seven-phase methodology: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation, reporting. http://www.pentest-standard.org/index.php/Main_Page (checked 29 August 2026)
- OWASP. Web Security Testing Guide. https://owasp.org/www-project-web-security-testing-guide/ (checked 29 August 2026)
- PCI Security Standards Council. Document Library, PCI DSS v4.0.1. https://www.pcisecuritystandards.org/document_library/ (checked 29 August 2026)
- CREST. Accreditation of penetration testing organisations. https://www.crest-approved.org/ (checked 29 August 2026)
- Clutch. Vervali Systems Pvt Ltd provider profile: overall 4.6 from 11 verified reviews, hourly rate $25 to $49, minimum project size $25,000. https://clutch.co/profile/vervali-systems (checked 29 August 2026)
- ISO/IEC 17025:2017, General requirements for the competence of testing and calibration laboratories. International Organization for Standardization.
- CMMI Institute. Capability Maturity Model Integration, Maturity Level 3.
Email Us
Call Us
