Research14 min read

Pentest Pricing Models: Day Rates, Fixed Fee, and Subscription Economics

Pentest pricing is one of the least openly discussed parts of the security consultancy market and one of the most consequential decisions a buyer or a consultancy makes. The pricing model determines who carries scope risk, how retests are funded, whether continuous coverage is possible, and how a quote should be compared against an alternative. This research separates the four pricing models that actually appear in contracts (day rate, fixed fee, retainer, and PTaaS subscription), examines the economic logic behind each, and lays out the operational implications for both sides of the table.1,3,5

The argument is straightforward. A pentest is a labour-intensive engagement with three roughly fixed cost components (scoping, testing, reporting) and one highly variable component (retest and remediation support). The model that wins on price for any specific engagement is the one whose cost structure aligns most closely with the workload the engagement actually generates. Mismatch the model, and either the buyer pays for work that did not happen, or the consultancy absorbs work that was not priced in. Both outcomes are bad for the relationship.

The four pricing models that actually appear in contracts

Most contracts are a variation on four core models. Hybrid arrangements are common, but the underlying logic sits inside one of these structures.

1. Day rate (time and materials)

The buyer pays a published day rate per tester per day. Effort is estimated in advance but not capped. Common for retainers, internal red teams contracting external support, and scoping-light engagements. Carries the highest scope risk for the buyer because cost grows with discovered complexity.

2. Fixed fee (scoped quote)

The buyer pays a single agreed price for a defined scope and deliverable. The consultancy carries scope risk and prices in a margin for it. The dominant model in mid-market application security and infrastructure pentests, and almost universal where the engagement supports a compliance deadline.

3. Retainer (block of days)

The buyer prepays for a block of tester-days drawn down across multiple smaller engagements over a quarter or a year. Common for in-house security teams who need ad-hoc external testing capacity, and for firms running a lightweight continuous testing programme without committing to PTaaS.

4. PTaaS subscription

The buyer pays a recurring subscription that covers continuous testing, retests, and a portal that persists between engagement windows. Pricing is typically banded by asset count and depth tier rather than tester-days. Most efficient where the buyer genuinely needs ongoing coverage; least efficient for single annual assessments.

For the buyer-facing framing of why subscription delivery has grown, see the longer-form penetration testing as a service guide and the related research on the pentest delivery gap, which covers SLAs, retest policy, and portal economics in depth. Pricing also interacts directly with scope discipline; see the research on pentest scope creep for how each pricing model carries scope risk differently.

The cost structure underneath every model

Pricing models look different on a quote, but the underlying cost stack is the same. A pentest is built from roughly five labour categories, and each model just decides how those categories are bundled and who absorbs variance.

  • Scoping and pre-engagement. Asset enumeration, rules of engagement, authorisation, contracts, and methodology selection. Roughly fixed per engagement, regardless of how the headline price is structured. PTES Section 1 calls this out as a discrete activity for a reason.5
  • Testing and exploitation. The actual work. Scales with scope complexity, target type, and depth tier. The most variable cost in any engagement and the one most likely to be misestimated.
  • Reporting and quality assurance. Drafting, peer review, severity calibration, executive summary, and final QA pass. Roughly fixed per engagement; large engagements absorb the cost more efficiently than small ones.
  • Retest and remediation support. The cost line that distinguishes a delivery-mature firm from a delivery-immature one. Highly variable. Often unpriced or underpriced in fixed-fee quotes, then billed back as a separate engagement when the buyer needs verification.
  • Account and operations overhead. Project management, client communications, scheduling, invoicing, evidence handling, data retention, and platform cost. Usually amortised across all clients rather than charged per engagement, but real.

A defensible quote prices each of these categories explicitly, even if only the totals appear on the invoice. CREST's defensible penetration test guidance describes a similar separation between scoping, testing, reporting, and quality activities.3

Day rate: when it works, when it does not

Day-rate pricing transfers scope risk to the buyer and is most efficient where the buyer wants direct control over depth and duration. It works in three situations:

  • Retainers and follow-on work, where the buyer has internal context to manage daily priorities and the tester is augmenting an in-house programme.
  • Highly exploratory engagements, where the scope is genuinely undefined and forcing a fixed fee would either inflate the quote or compress depth.
  • Capped time-and-materials with milestone reviews, a hybrid that preserves the flexibility of day rate while capping the buyer's exposure at a defined level.

Day rate fails when used as the headline pricing model for a compliance-driven assessment with a deadline. The buyer cannot promise an auditor that the testing will complete in time and within budget, and the consultancy cannot defend the depth of the engagement against an open-ended budget. Both sides drift towards either underwork or overcharge.

Day rates are also the easiest figure to compare poorly. A senior application security tester at a specialist firm and a generalist tester at a high-volume firm can quote different day rates and still produce work of similar value, because effective coverage per day differs. The day rate is one input, not the answer.

Fixed fee: where most engagements should land

Fixed-fee pricing is the dominant model for a reason. The buyer gets a single price, the consultancy controls scope and methodology, and the contract maps cleanly to procurement, audit, and budget cycles. NIST SP 800-115 and PCI DSS 11.4 both assume a documented, scoped engagement with a retained report.1,2 Fixed fee is the contract structure that supports that assumption with the least friction.

The mistake that erodes fixed-fee economics is treating it as a sealed quote with no operational mechanics behind it. A defensible fixed fee is built from:

  • An effort estimate in person-days, derived from documented scoping (asset count, target type, authentication complexity, depth tier).
  • A scope risk margin, sized against the unknowns at scoping time, not a default percentage.
  • An explicit retest allowance, built into the headline price within a defined window.
  • A change request mechanism, so genuine scope changes (new in-scope asset, new business requirement) are handled without rewriting the contract.

Fixed fee fails when scoping was light, retests are out of scope, and every adjustment becomes a separate quote. Buyers stop trusting the headline number, and the engagement becomes a procurement exercise rather than a security assessment.

Retainers: the underused middle ground

Retainers sit between day rate and PTaaS. The buyer prepays for a block of tester-days, drawn down across multiple smaller engagements over a quarter or a year. The model is underused on the buyer side and underbuilt on the consultancy side, and it has clear advantages where the buyer needs flexibility without the overhead of a full subscription.

Retainers work when:

  • Frequency is unpredictable but real. The buyer cannot commit to a fixed schedule but knows multiple engagements will land within the year.
  • Continuity matters. The same testing team carries methodology and finding history across engagements, which a series of one-off fixed fees cannot replicate.
  • Procurement velocity is a bottleneck. A single retainer contract avoids re-procuring a quote every time a new asset launches.

Retainers fail when the day pool is consumed faster than expected and the buyer ends up renegotiating mid-cycle, or when days are unused at year-end and roll-over rules are not in the contract. Both failure modes are contract-design issues, not pricing-model issues.

PTaaS subscription: where the economics actually flip

PTaaS subscription pricing is the most architecturally different model. The buyer is not paying for tester-days; they are paying for ongoing coverage, retests, and a portal that persists between engagement windows. Pricing is banded by asset count, depth tier, and sometimes industry, rather than by effort.

The economics flip in three directions at once:

  • Retests become free at the margin. Verification cost is bundled into the subscription, so neither side has a procurement reason to defer it. This aligns the contract with verified closure rather than with discovered findings.
  • Scoping becomes incremental. New assets are added to the subscription rather than triggering a fresh procurement cycle. The marginal cost of scoping a new component drops materially.
  • Reporting becomes continuous. Findings appear in the portal as they happen rather than at the end of a project window, which reshapes how internal teams plan remediation work.

PTaaS pricing is most efficient where the buyer genuinely needs continuous coverage. It is least efficient for a single annual assessment against a stable scope. A buyer with one mature application and a once-yearly compliance test usually overpays for a PTaaS contract relative to a well-structured fixed fee. A buyer shipping multiple times a week with a fast-evolving environment usually underpays for the same contract relative to the equivalent number of point-in-time engagements.

The architectural argument for PTaaS is sound; the procurement argument depends on the workload. The same buyer can rationally use PTaaS for a fast-moving SaaS product and fixed fee for a stable infrastructure assessment in the same year, and the right choice is engagement-specific rather than firm-specific.

Retest pricing is where most contracts leak value

Retest policy is the single line item that does the most to determine whether a pentest delivers verified closure or a list of findings that may or may not be fixed. CISA's Known Exploited Vulnerabilities Catalog and the UK NCSC's vulnerability management guidance both reinforce that remediation timelines matter at least as much as detection, and retests are how a pentest contract operationalises that.6,7

Four retest pricing patterns appear in current contracts:

  • Excluded entirely. Lowest headline price, highest closure risk. Retests become a separate procurement exercise and quietly slip.
  • One retest per finding. Looks fair on paper. Penalises clients with partial remediation, dependency-driven regressions, or findings that span components.
  • Unlimited retests within a window (commonly 60 to 90 days post-engagement). The model that aligns most cleanly with verified closure.
  • Continuous retest in a subscription. Native to PTaaS. Findings persist between assessment windows and remediation status carries forward.

Pricing the retest correctly is an exercise in expected value. Most retests are short (a single tester-day or less), but a small fraction are deep (a regression that reopens a critical finding requires the full re-validation chain). A retest allowance that accounts for this distribution costs the consultancy less than re-quoting, and costs the buyer less than skipped verification. For the operational mechanics, see how to retest vulnerabilities and the remediation tracking workflow.

Effective day rate: the only honest cross-quote comparison

Headline prices are not directly comparable. A firm quoting a fixed fee at one number with retests included, methodology cited, and a portal in scope is selling a different product than a firm quoting a lower number with retests billed separately and a static report. The mechanism that makes quotes comparable is effective day rate.

Effective day rate normalises four things into a single number:

  • Total fee, including expected retest and minor scope adjustments.
  • Tester-days actually spent on testing, separated from project days, account days, and reporting days.
  • Methodology coverage, mapped against a public standard such as NIST SP 800-115, OWASP WSTG, or PTES so depth is comparable.1,4,5
  • Deliverable scope, including whether a portal, retests, and final report are included or billed separately.

A disciplined buyer asks each shortlisted firm for the same breakdown and computes effective day rate consistently. A disciplined consultancy publishes the breakdown without being asked, because it is the single most effective procurement document the firm can hand a buyer who is comparing four quotes.

For the consultancy-side detail on building the underlying numbers, see how to price pentest services, the penetration testing scope of work template, and the practical guide to scaling a security consultancy with automation.

What buyers should actually ask in procurement

The questions below cut through pricing-page marketing and surface the structure under the headline number. They are designed to be answered in writing before a contract is signed.

  • Pricing model: is the engagement quoted as day rate, fixed fee, retainer, or subscription, and what triggers a switch?
  • Effective day rate: on the proposed scope, what is the implied effective day rate (total fee divided by tester-days actually spent on testing)?
  • Retest policy: how many retests are included per finding and per engagement, within what window, and what triggers a billable retest?
  • Scope change mechanism: what is the contractual mechanism for genuine scope changes during the engagement, and how is the price recalculated?
  • Reporting depth: is a downloadable, signed final report produced for every engagement, and is it included in the headline fee?
  • Portal access: is there a live findings portal, does it persist after the engagement closes, and is access included or priced separately?
  • Methodology mapping: is the engagement mapped to a public methodology (NIST SP 800-115, OWASP WSTG, PTES) and does the report cite which checks were performed?1,4,5
  • Tester continuity: if the testing team changes between engagements, how is methodology and finding history preserved?

What consultancies should change first

For consultancies still pricing engagements as a single round number with a vague retest clause, three structural changes account for most of the commercial improvement:

  1. Publish the breakdown. Show scoping, testing, reporting, retest, and overhead components inside the headline number, even if the contract is fixed fee. Procurement teams trust quotes they can compare.
  2. Move retests inside the headline price. Unlimited retests within a 60 to 90 day window, costed into the base fee. The pattern is operationally cheap and commercially distinctive.
  3. Adopt a delivery platform. Engagement management, findings tracking, AI-assisted reporting, invoicing, and a branded client portal in one workspace remove the coordination overhead that erodes margin under any pricing model. The platform becomes a margin lever, not a line item.

The persona pages for cybersecurity firms, security consultants, and MSSPs map this delivery model to different organisational shapes. The blog on managing multiple security engagements covers the day-to-day mechanics that hold up when retests are free at the margin.

Conclusion

Pentest pricing is a procurement problem and a delivery problem at the same time. The pricing model decides who carries scope risk, how retests are funded, and whether continuous coverage is feasible. The cost structure underneath every model is identical (scoping, testing, reporting, retest, overhead); only the allocation of those costs across the contract changes. Day rate, fixed fee, retainer, and PTaaS subscription each have a workload they fit best, and choosing the wrong fit is more expensive than choosing a slightly higher headline number under the right one.

The buyers who win on price over the next decade are the ones who normalise quotes on effective day rate, insist on retests inside the headline number, and treat the portal as a procurement deliverable rather than a nice-to-have. The consultancies who win on margin are the ones who publish the breakdown, price retests into the base fee, and run engagements through a delivery platform that absorbs the coordination overhead their competitors are still paying in person-time. Both sides benefit from the same structural shift; the pricing model is just where it shows up first.

Frequently Asked Questions

Run pentests with cleaner economics, not bigger spreadsheets

SecPortal gives security consultancies engagement management, findings tracking with CVSS scoring, AI-assisted reports, invoicing with Stripe Connect, and a branded client portal on a subdomain you control. Hold day rates without losing margin to coordination overhead. See pricing or start free.

Get Started Free

Sources

  1. NIST, SP 800-115: Technical Guide to Information Security Testing and Assessment, September 2008
  2. PCI Security Standards Council, PCI DSS v4.0.1 Requirement 11.4 (Penetration Testing)
  3. CREST, Defensible Penetration Test Specification
  4. OWASP, Web Security Testing Guide (WSTG)
  5. PTES, Penetration Testing Execution Standard
  6. UK National Cyber Security Centre, Penetration Testing Guidance
  7. CISA, Known Exploited Vulnerabilities Catalog
  8. NIST, Cybersecurity Framework (CSF) 2.0
  9. SecPortal, Engagement Management Feature
  10. SecPortal, Findings & Vulnerability Management
  11. SecPortal, Invoicing & Billing
  12. SecPortal, Branded Client Portal