All Articles

What Actually Drives Pentest Pricing

Penetration testing quotes vary by an order of magnitude for what looks, on paper, like the same deliverable: "a pentest of our application." The variance is not random or purely a function of vendor markup. It comes from five technical variables that any CISO evaluating a quote should be able to name and interrogate: scope size, methodology, tester qualifications, compliance-driven requirements, and the depth of retesting and reporting included.

Scope size

Scope is measured in concrete units, not vague descriptions like "test our app." For web and API testing, the relevant units are the number of distinct applications or API services in scope, the number of user roles that must each be tested (an app with an admin role, a standard user role, and a guest role effectively multiplies the business-logic test matrix by three), the number of unique endpoints or API operations, and, for internal or network engagements, the number of live IP addresses or hosts. A marketing site with a contact form has a handful of testable entry points. A multi-tenant SaaS platform with role-based access control, a public API, and third-party integrations can have hundreds of authenticated paths that each need to be checked for both technical vulnerabilities and logic flaws like broken object-level authorization.

Methodology: automated-only vs manual vs hybrid vs agentic-AI-assisted

An automated-only engagement runs a vulnerability scanner (commercial or open-source) against the target and packages the output into a report, sometimes with light manual triage to remove obvious false positives. A fully manual engagement has a human tester working through the target by hand, guided by a methodology like the OWASP Web Security Testing Guide (WSTG), attempting to chain findings together the way a real attacker would. A hybrid model uses automation for breadth (initial recon, known-CVE identification, low-value repetitive checks) and reserves manual tester time for business logic, authorization flaws, and exploitation attempts that automation cannot reliably find. A newer category, agentic-AI-assisted testing, uses autonomous or semi-autonomous AI agents to perform reconnaissance and exploitation attempts at machine speed and then validates findings against the live target before a human reviews and reports them, which changes the cost structure by reducing the tester-hours needed for the repetitive parts of the work while a human still validates and signs off on results.

Tester seniority and certification requirements

Not all testers cost the same, and the difference is not just brand markup. A tester holding OSCP (Offensive Security Certified Professional) demonstrates baseline hands-on exploitation competency; OSCE (Offensive Security Certified Expert) and OSWE (Offensive Security Web Expert) signal deeper exploit-development and web-application skill; CREST-accredited individual and firm-level certifications are the de facto procurement requirement in the UK and for many regulated industries globally. Reported day rates in the US market in 2026 run from roughly $850 to $2,500 per tester-day depending on firm overhead, brand, and how much of the engagement is genuinely manual versus automated, with freelance testers at the low end and Big 4 or boutique specialist firms at the high end. CREST-accredited engagements commonly add a premium over non-accredited providers, with different sources citing figures in the 15 to 40 percent range, reflecting both the higher day rates CREST-certified engineers command and the quality-assurance overhead the accreditation imposes on the firm.

Compliance-driven requirements

PCI DSS 4.0.1 (the current maintenance revision of PCI DSS 4.0, which became the only active version after PCI DSS v3.2.1 retired) is explicit and prescriptive about penetration testing in Requirement 11.4. It requires a documented penetration testing methodology based on an industry-accepted approach such as PTES or NIST SP 800-115, testing performed by a resource that is organizationally independent from the systems being tested (not necessarily an external third party, but not the team that manages the environment either), both internal (11.4.2) and external (11.4.3) penetration testing at least every 12 months and after any significant change, and documented retesting to confirm that identified vulnerabilities were actually remediated. SOC 2, by contrast, does not name penetration testing as a mandatory control anywhere in the AICPA Trust Services Criteria. There is no SOC 2 clause that specifies a required method, scope, or cadence. In practice, however, auditors commonly point to Trust Services Criteria CC4.1, which calls for a "separate evaluation" of control effectiveness, and treat an annual penetration test as the default way to satisfy it, which is why most SOC 2 reports a CISO will see in the wild do include one even though it is not technically required.

Retest inclusion and report depth

A retest is a second, shorter engagement where the tester re-attempts previously identified vulnerabilities after the development team has deployed fixes, to confirm the fix actually closed the issue rather than just changing its symptoms. Quotes that do not include a retest cycle are quietly pushing that cost to a later invoice, and PCI DSS 4.0.1 effectively requires documented retesting as evidence remediation occurred. Report depth is also a real cost driver: a report built for a compliance auditor needs mapped findings, CVSS scores, and evidence trails; a report built for engineering needs reproduction steps and remediation guidance specific to the code or configuration; and a report built for the board or executive stakeholders needs a narrative risk summary. Producing all three well is a meaningfully different amount of writing time than producing a raw scanner export with a cover page.

Cost-Driver Breakdown by Scope Complexity

The table below illustrates, at a technical level, why the same word ("pentest") produces such different quotes. It is organized by the kind of target, not by price tier, because price should be a downstream consequence of these technical variables rather than the starting point.

What a $2,000 Automated Report and a $15,000+ Manual Engagement Actually Buy You

The gap between a low-cost automated-scan-with-a-report and a genuinely manual or hybrid engagement is not marketing positioning, it is a difference in what kind of vulnerability class each approach can realistically find. Automated scanners are very good at finding known-signature issues: outdated software versions with published CVEs, missing security headers, default credentials, common misconfigurations, and well-known injection patterns that match existing detection rules. A report built on scanner output with light triage can reasonably be produced in a fraction of the time of a manual engagement, which is why it is priced accordingly.

What that approach structurally cannot find is business logic abuse: a workflow that lets a user skip a required approval step, a discount code that can be applied multiple times because the server does not track redemption state correctly, an API endpoint that trusts a client-supplied user ID instead of the authenticated session's user ID (a broken object-level authorization issue), or a multi-step process where reordering the steps produces an unintended and exploitable state. Finding these requires a human who has read the application's intended behavior, formed a hypothesis about how it might be subverted, and tested that hypothesis by hand. This is inherently slower work than running a scanner and is the single largest driver of manual-hour cost.

Chained exploitation is the second major cost driver. A scanner reports vulnerabilities as isolated findings. A skilled manual tester instead asks whether a low-severity information disclosure finding can be combined with a separate low-severity access control gap to produce a high-severity outcome, such as full account takeover or lateral movement into a more sensitive system. Demonstrating a chain requires deliberate, iterative manual effort and is exactly the kind of finding that most impresses (and most usefully informs) a security-conscious buyer, because it reflects how a real attacker actually operates rather than how a scanner enumerates issues independently.

Custom exploit development is the third driver. When a tester finds a vulnerability that does not match an existing public exploit or scanner signature, for example a novel deserialization issue in custom application code, building a working proof-of-concept exploit to demonstrate real impact (rather than just flagging a theoretical weakness) can take hours to days of focused effort per finding. Reputable manual and hybrid engagements budget for this; automated-only engagements simply do not attempt it, which is one reason their reports tend to be longer on low-severity, easily-scanned issues and shorter on the high-impact findings that actually change a risk posture.

Finally, retest cycles add real cost that a cheap quote frequently omits. A retest requires the tester to re-establish the same access and conditions as the original test and re-attempt each previously identified issue individually to confirm the fix holds, which is a meaningfully different task from a fresh test and needs to be scoped and priced as its own line item rather than assumed to be free.

A CISO Platform member perk. FireCompass is offering CISO Platform members a free AI pen test on their own portfolio. Run yours and get exploit-validated findings before you commit to a manual engagement.

How to Read a Pentest Quote Line by Line

A quote that cannot be broken into its component parts is a quote that has not been scoped properly, and a CISO evaluating vendor proposals should expect to see each of the following itemized rather than bundled into a single lump figure.

1. Scoping call or scoping questionnaire. This should precede the quote, not follow it. A vendor that quotes a fixed price before asking how many roles, endpoints, or hosts are in scope is pricing off an assumption, not your environment.
2. Named methodology reference. The proposal should cite a recognized framework by name, such as the OWASP Web Security Testing Guide (WSTG) for web applications, the OWASP API Security Top 10 or API-specific testing checklists for APIs, or PTES/NIST SP 800-115 for network and infrastructure testing. A quote with no methodology reference at all is a signal the engagement may be scanner output with minimal manual verification.
3. Testing days or hours, broken out by activity. Reconnaissance and enumeration, manual testing, and exploitation attempts should be distinguishable line items or at least clearly described phases, not a single undifferentiated "testing" block.
4. Report writing time. Writing a report that includes reproduction steps, evidence (screenshots, request/response captures), CVSS scoring, and remediation guidance takes real hours and should appear as its own allocation, separate from testing time.
5. Executive summary versus technical detail sections. The proposal should confirm the deliverable includes both a narrative summary suitable for non-technical stakeholders and a fully detailed technical findings section, since these serve different audiences and both are usually needed.
6. Retest. Confirm whether a retest is included in the base price, offered as a paid add-on, or not offered at all, and if included, how many findings or how much time it covers.
7. Debrief or readout call. A live walkthrough of findings with the testing team, separate from the written report, should be listed if included.

Several patterns in a quote should prompt further questions before signing.

• No mention of a testing methodology or framework anywhere in the proposal.
• No named OWASP WSTG, OWASP API Security, PTES, or NIST SP 800-115 reference, or equivalent, for the relevant target type.
• Testing hours that do not add up to plausible manual coverage for the stated scope. As a sanity check, a single tester covering dozens of authenticated roles and hundreds of endpoints in two days is not performing meaningful manual business-logic testing in that window, regardless of what the report claims.
• No mention of retesting, or retesting priced with no indication of scope or time allocation.
• A single flat price quoted before any scoping conversation has taken place.
• Vague tester qualifications, with no indication of certification level (OSCP, OSCE, OSWE, CREST) or relevant experience for the specific target type (web, API, mobile, network, cloud).
• A deliverable description that only mentions a "report" with no distinction between executive summary and technical detail.

Compliance-Driven Cost Floors

For organizations in scope for PCI DSS, Requirement 11.4 in the current PCI DSS 4.0.1 standard sets a minimum viable testing scope and cadence that functions as a hard cost floor, independent of any organization's own risk appetite. The requirement calls for a documented, industry-accepted penetration testing methodology (PTES or NIST SP 800-115 are the standards most commonly referenced), testing performed by a resource organizationally independent from the team managing the environment being tested, internal penetration testing (Requirement 11.4.2) and external penetration testing (Requirement 11.4.3) at least once every 12 months and after any significant infrastructure, application, or segmentation change, and documented retesting to confirm remediation of identified findings. Where network segmentation is used to isolate the cardholder data environment from other networks, Requirement 11.4.5 requires penetration testing of those segmentation controls at least once every 12 months for all entities, and Requirement 11.4.6 tightens that to at least once every six months for service providers specifically, because a single segmentation failure at a service provider can expose every downstream client at once.

The practical budgeting effect is that an organization cannot satisfy PCI DSS with a single lightweight annual scan of its public website. The scope must cover the full cardholder data environment perimeter, both external and internal-facing systems, segmentation boundaries if segmentation is used to reduce scope, and must be backed by a written methodology and retest evidence a Qualified Security Assessor (QSA) can review. Service providers carry an additional structural cost because segmentation testing on a six-month cycle roughly doubles that specific testing line item compared to the annual cadence that applies to other entities. For SOC 2, there is no equivalent hard floor in the standard itself, since the AICPA Trust Services Criteria do not name penetration testing as mandatory, but because auditors widely treat an annual penetration test as satisfying Trust Services Criteria CC4.1's call for independent evaluation of control effectiveness, most organizations pursuing SOC 2 Type II budget for one anyway as a practical, if not strictly regulatory, cost floor.

Where Automated and AI-Assisted Testing Change the Calculus

The cost structure described above assumes a traditional, fully human-hours model, where price scales close to linearly with scope size because a human tester can only cover so many endpoints or hosts per day. Automated and agentic-AI-assisted testing platforms change this relationship by using automation for the breadth of coverage (initial reconnaissance, known-vulnerability identification across a large number of applications or endpoints) while reserving human time for validation and the business-logic and chained-exploitation work automation cannot do reliably. FireCompass has published figures showing automated, continuously-validated testing running $450 to $2,500 per application against $2,400 to $10,000 for manual, consultant-led testing per application, and reports an 11x cost reduction in one Fortune 500 deployment (from roughly $5,000 to under $1,000 per application) alongside coverage rising from 200 to over 2,000 applications, with turnaround measured in roughly one day versus two or more weeks for a traditional manual engagement, because findings were validated against the live target before being included in the report. These figures matter for budgeting specifically at the portfolio-coverage decision: a Fortune 500 organization with 2,000 or more applications, tested even once a year at manual pricing, faces a multi-million dollar annual testing bill, which is a documented reason most large enterprises test only a subset of their highest-priority applications on a traditional manual cycle and leave the remainder on a much longer cycle or untested. Where compliance requirements demand documented manual methodology and named-framework testing (as PCI DSS 4.0.1 does for the cardholder data environment), automated and hybrid approaches are typically used to extend coverage across the broader application portfolio rather than to replace the manual testing the compliance-in-scope systems specifically require.

As a CISO Platform member, you get free access. Ready to see the real cost of testing your full portfolio? Start your free AI pen test.

About Priyanka Aash
Priyanka Aash is Co-Founder of CISO Platform, the world's first online community for information security executives, and Co-Founder of FireCompass. She has been nominated for the Cybersecurity Excellence Award for leadership and AI innovation in cybersecurity, honored with the NetApp Excellerate HER award, and featured in SC Media's Women in IT Security series. She is the author of The AI Divide. Security technologist Bruce Schneier advises FireCompass.