The Universal Service Administrative Company's public PTaaS solicitation described 16 current systems, with possible expansion to 20, and asked bidders to address different user types, per-system testing and ad hoc work. That is the commercial problem behind an enterprise penetration testing purchase: the buyer is buying a repeatable program for a changing estate, not a single test with a bigger quantity field.
Quick answer. To compare enterprise PTaaS prices, first make every bidder quote the same application inventory, role depth, cadence, retest entitlement, delivery capacity and growth rules. Compare a planned-year total and a priced expansion scenario, not just the base fee. Stingrai's Enterprise offering is custom quoted for portfolios and can be arranged as one-time or continuous work; its published fixed packages cover one web application and associated APIs.
This guide is a buying worksheet for a mid-market or enterprise security leader, finance partner and procurement team. It does not publish a portfolio price range because a price without scope and effort is not useful. For published single-application offers and their stated units, see our PTaaS pricing comparison. For the technical question of which products, roles and shared identity boundaries to test, see our enterprise SaaS portfolio scoping guide. Here, the issue is how to buy that coverage and compare the resulting proposals.
Why a portfolio quote needs a different unit
A portfolio does not contain interchangeable applications. A customer portal with delegated administration may need several authenticated roles and tenant boundaries. A public marketing property may need a narrower pass. A shared API gateway may require coordinated testing across products. The number of hostnames is therefore a poor substitute for an agreed test unit.
The USAC solicitation makes the distinction visible. It identifies current systems, describes their relative complexity, asks for testing of major user types, and calls for per-system plans and reports. Its public Q&A asks for unit-rate or complexity-based pricing for systems added later. This is a public procurement example, not a description of a Stingrai engagement or an active tender.
The useful lesson is a buying principle: a vendor's price unit must map to your testing decision unit. An application, target, credit, tester day and annual subscription can all be legitimate units. None proves how much authenticated business-logic testing a given product receives. Ask each vendor to state both the commercial unit and the test work delivered by that unit.
This matters to budget owners because the expensive surprises usually sit in definitions. A separate admin console might be a role in one quote and a second application in another. A mobile client might be part of an API assessment or a separately priced binary. A retest might be included once, available during a term, or charged as ad hoc work. The line that appears cheapest can simply be the line with the most work left outside it.
Build one demand schedule before asking for prices
Procurement can require the same response format, but security must supply the demand schedule. The schedule should describe what decision a test must support, not just list URLs. It can be attached to a request for quotation and updated when a product owner changes scope.
Field in the buyer's schedule | What to give bidders | What a comparable response must say |
|---|---|---|
Product and owner | A stable product name, owner, environment and business purpose | Whether it is a separate chargeable unit |
Authorized surface | Web front end, APIs, mobile binaries, cloud resources and shared services that may be tested | Exact included and excluded assets |
Identity and roles | Representative customer, staff, privileged and service-account roles, plus tenant boundaries | Which roles receive authenticated manual testing |
Test objective | Key workflows and abuse cases, with the risk the test should answer | What evidence the vendor will produce for each objective |
Depth | Expected manual work, automation and any source-assisted review | Tester effort or equivalent capacity allocated to this unit |
Timing | Release windows, blackout periods, reporting deadlines and test dependencies | Lead time, delivery window and reserved capacity |
Remediation | Who will fix findings and the expected retest window | Retest entitlement, expiry and overage rate |
Evidence | Product report, executive view, limitations and audit evidence needs | Deliverables, formats and acceptance criteria |
For application tests, the OWASP Application Security Verification Standard is a useful way to specify security requirements in a contract. OWASP explicitly describes procurement as a use for ASVS. Use requirements relevant to each application and agree on how exceptions are reported; merely putting "OWASP" in a proposal does not define test depth.
The schedule should be an input, not a finished statement of work. Bidders should challenge assumptions. A strong vendor may explain that two listed products share an authorization service but implement different object-level checks. It may recommend a separate exercise for a sensitive workflow. Capture that recommendation as an explicit variation with a price and coverage effect rather than quietly changing the base comparison.
Specify roles and complexity without guessing effort
Role depth changes the work. USAC's public solicitation distinguishes anonymous, external, internal nonprivileged and internal privileged users. Your role model may differ, but the quote should state which identities testers receive, whether cross-role and cross-tenant authorization is in scope, and what happens if an account is unavailable at kickoff.
Avoid prescribing the same number of tester days to every product before discovery. Instead, classify product complexity with evidence: distinct codebase, number of privileged workflows, sensitive data flows, external integrations, tenant boundaries and release cadence. Ask the vendor to propose effort by product and explain any sampling. If a vendor proposes a shallower pass for a low-change application, the comparison can still be fair when the tradeoff is visible.
Decide what belongs in the base schedule
Split the purchase into required baseline, priced options and explicit exclusions. Required baseline work is what must happen for the annual program to meet its purpose. Options may include a new acquisition's application, a cloud assessment, social engineering or an urgent product launch. Exclusions state what the vendor will not test or deliver. This split prevents one bidder from bundling optional work into the total while another leaves it out.
The USAC RFP and Q&A offer a public example: optional physical and social engineering work was requested as separate price lines, while the core scope and ad hoc testing were defined in the solicitation. Your organization need not copy those categories. It should copy the discipline of making optional work visible.
Translate each commercial model into the same output
Do not require every vendor to abandon its normal pricing architecture. Require each to translate that architecture into the same demand schedule and response fields. Then finance can compare what the program will cost under the same workload.
Per-engagement price. Each scoped assessment has a fee and its own deliverables. Ask what is charged when two applications share an API, when a test slips because an environment is not ready, or when a product needs a second test after a major release. A menu of per-application fees is easy to understand but can omit the coordination work required for a portfolio view.
Per-asset subscription. The vendor defines an asset or target and charges for a term. Ask whether an application with an admin domain and associated APIs is one asset, whether mobile platforms count separately, and how a newly launched product is added. Ask what the recurring charge entitles the buyer to receive in actual test effort and reports. A subscription to a platform is not itself proof that every enrolled asset is manually tested.
Credit pool. The buyer prepays capacity and draws it down against assessments. Cobalt's public pricing page gives a concrete example: it defines one credit as the equivalent of eight hours of offensive security testing and says the credits needed for an asset depend on its scope and delivery options. That definition does not tell a buyer the number of credits their portfolio will consume or the contracted price per credit. Ask for a credit forecast by named application, the debit rule when effort exceeds the forecast, how platform access and retesting are treated, and what the contract says about unused capacity. Do not infer a portfolio price by multiplying eight hours by an assumed hourly rate.
Reserved capacity or retainer. The buyer pays for access to named or pooled tester capacity over a term. Ask whether capacity is genuinely reserved, the maximum concurrent tests, how far in advance it can be scheduled, and what happens when the queue is full. A retainer can work well for unpredictable release work, but only when the service-level commitment says how quickly the team starts, what constitutes a completed test, and what rolls into a later period.
Custom enterprise program. A vendor may blend scheduled assessments, ongoing application testing, specialist exercises and a platform. Require the same line-item translation. The program description should make clear which work is human-led, which is autonomous, and which combines them. It should also explain whether a one-time or annual test is available alongside a continuous program. Stingrai's Enterprise page explicitly offers one-time or continuous custom work for more than one web application.
Figure 1: The response fields that make unlike portfolio proposals comparable. Source: Stingrai editorial worksheet informed by USAC's public PTaaS solicitation and Cobalt's published credit model.
Normalize the annual total, then stress it
Create a common cost view for each bidder. The base view uses the same portfolio inventory and delivery schedule. The expansion view asks what happens when another product or material scope change enters. The urgent view asks what is available when an incident or release creates a short deadline. A bidder may be strongest in one scenario and weaker in another; the buyer can decide which exposure matters.
For a planned year, add every required charge: assessment fees, platform or access fees, reserved capacity, onboarding, reporting and any known travel or tax treatment. Keep optional services below the base total. For a credit model, show contracted credits, estimated credits by application and the cash price of overage. For a retainer, show the capacity purchased and the rule for unused capacity. The calculation is straightforward; the hard part is obtaining the assumptions in writing.
Comparable cost line | Ask the bidder to fill in | Why it can change the decision |
|---|---|---|
Baseline testing | Fee or capacity for each named product and shared service | Establishes what is actually covered |
Platform and access | Mandatory subscription, setup, integration and support charges | Prevents an assessment price from being mistaken for the total |
Capacity guarantee | Start-time commitment, concurrency and reserved tester availability | Distinguishes available work from a future queue position |
Retesting | Included cycles, covered findings, expiry and extra rates | Exposes the cost of verifying fixes |
New assets | Incremental rate or complexity bands with a change-order rule | Prices portfolio growth before it occurs |
Urgent work | Priority scheduling and ad hoc rate | Shows whether incident-driven tests consume planned capacity |
Reports and evidence | Product reports, executive roll-up and post-remediation evidence | Avoids buying a portal view when a signed report is required |
Contract administration | Currency, taxes, travel, minimums, renewal uplift and cancellation | Converts a headline quote into a budget commitment |
The USAC Q&A is particularly useful on growth. USAC asked whether added systems could be priced with a unit rate or complexity-based model, and the answer was yes. It also said that pricing by test category size or test day would help. Your request for quotation can use the same idea: ask for a transparent expansion rule even when the base agreement is fixed price.
Avoid the false precision of a single blended rate
A blended price per application is useful for a budget summary only after the program is scoped. Before that, it can hide that a high-risk product gets the same effort as a low-risk one or that shared identity work is counted against several applications. Show a product-level allocation next to the portfolio total. Where a vendor proposes shared testing efficiency, name the reused test evidence and the product-specific checks that remain.
An hourly or credit rate also cannot stand alone. A low unit rate with a generous effort estimate can exceed a higher unit rate with disciplined scoping. Conversely, a cheap fixed fee may leave a necessary role untested. Ask bidders to show both unit economics and assurance output: tested products and roles, manual depth, report artifacts, retest commitments and exclusions. If the two cannot be reconciled, the numbers are not comparable yet.
Price the next product before signing
The expansion scenario is where a portfolio contract reveals its flexibility. State what a newly acquired or launched application looks like in your environment, then request the trigger, classification, lead time and price method for adding it. Ask who decides whether it is a new chargeable application or an extension of an existing one. Include APIs, admin surfaces, mobile clients and shared controls in that decision. A simple written mechanism is more valuable than a vague promise of a discount on future work.
The same rule applies to urgent change. If a critical release requires a focused test, does it replace a planned assessment, consume pooled credits, draw on reserved capacity, or create a new charge? How quickly can the vendor start, and will a product owner receive a report suitable for release approval? Price the path, not merely the hourly rate.
Figure 2: Three buying scenarios to price in each proposal. Source: Stingrai editorial worksheet informed by USAC's public PTaaS RFP and Q&A.
Retesting is a contract term, not a footnote
Retest promises differ in ways that a top-line quote hides. Define whether the vendor verifies every remediated finding or only findings above a severity threshold. Clarify whether a retest checks the original exploit path, related role and tenant boundaries, and potential regressions, or only confirms a ticket was closed. Set the time window in which the buyer may request it and the evidence that will be issued after verification.
The USAC public Q&A makes the commercial consequence explicit: it expected one retest per remediation, with ad hoc costs for repeated or lengthy remediation tests. Cobalt's pricing page, by contrast, describes unlimited on-demand retesting during the contract term. These are different published models, not universal category rules. A buyer should obtain the precise entitlement in the actual proposal and agreement.
Ask how a retest is counted if a remediation changes the application architecture. A fix verification is not necessarily a new penetration test of the changed workflow. If a product team rebuilds its authorization path, the agreement should say whether the new work is included, debits capacity, or requires a separate scope. This keeps the remediation promise honest and gives engineering an incentive to schedule the right review.
Retesting also affects reporting. If the program supports an audit or customer assurance request, ask whether the vendor updates the original report, issues a retest letter or delivers a new post-remediation report. NIST SP 800-115 treats verification of mitigation as part of the assessment cycle. A quote should therefore cover the evidence the buyer actually needs, not only the action of re-running a check.
Reserve capacity for the work that cannot wait
An enterprise team may have a calendar of scheduled tests and a separate stream of releases, acquisitions and incidents. A proposal should say which queue each kind of work enters. "On demand" is a product description; a contractual start-time commitment is an operating promise. Ask for the start event, business-hours convention, approved testing windows, escalation contact and remedy if the slot is missed.
If the vendor offers named testers, ask how many engagements those people can run concurrently and who may replace them. If the vendor uses a pool, ask how role-specific expertise is matched to the application and how context from earlier tests is retained. Neither delivery model is automatically better. The quote should make the capacity and continuity tradeoff legible.
Reserved capacity should not be purchased simply because a portfolio is large. If tests can be scheduled well ahead of time and release dates are predictable, a series of one-time or annual engagements may be sufficient. If the product estate changes frequently and urgent testing affects release decisions, a continuous program with a defined queue may be worth the commitment. In both cases, the buyer should ask for the same product-level evidence and retest terms.
Keep exclusions and assumptions on the pricing sheet
Most scope disputes are foreseeable. Put the answer next to the price for each of the following:
Are source code review, API testing and authenticated role testing included, optional or excluded?
Do shared components, cloud infrastructure, networks, mobile apps, AI features and third-party integrations require separate authorization or a separate fee?
What happens when test accounts, representative data or a production-like environment are unavailable?
Does a test window change, application outage or vendor pause create a rescheduling fee?
Are remediation workshops, executive presentations and compliance evidence included in the quoted deliverables?
Which expenses, taxes and currencies affect the total, and who approves change orders?
What is the treatment of unused credits or reserved capacity at renewal and termination?
Some exclusions protect the buyer and tester as much as the vendor. NIST SP 800-115 says an assessment plan should identify authorized systems, authorized assessors, logistics, handling of sensitive data and incident response. A technically ambitious quote without those boundaries is not procurement-ready. Require a signed rules-of-engagement process, and treat an unapproved third-party service as outside scope until its owner authorizes testing.
Keep private customer information out of the request circulated for pricing. A representative architecture and synthetic roles are usually enough to get a defensible proposal. The final testing plan can carry more detail under the appropriate agreement.
An RFP response table you can reuse
Send the same questions to each bidder and require a direct answer in the response table. A narrative proposal can follow, but it should not substitute for these fields.
Buyer request | Required vendor response |
|---|---|
Confirm the baseline inventory | Name each included application or service and the commercial unit assigned to it. |
Show depth by product | State roles, tenant types, APIs, manual objectives, automation and estimated effort or equivalent capacity. |
State the delivery model | Identify human-led, autonomous and hybrid work, plus who directs and reviews each engagement. |
Commit to a calendar | Give start lead time, concurrency, planned reporting dates and urgent-work handling. |
Define findings and reports | Specify in-test reporting, product reports, executive roll-up, evidence format and limitations. |
Quote retests | State which findings qualify, how many verification attempts are included, the request window and extra-work rate. |
Quote change | Give price method and approval path for a new application, expanded role scope, significant release and incident-driven test. |
Quote total | Show baseline total, mandatory platform charges, options, overage rules, currency, tax and renewal treatment. |
Name exclusions | List out-of-scope assets, techniques, environments and buyer dependencies. |
This table is deliberately demanding. It gives finance a comparable number, engineering a credible test plan, and the security leader a way to explain what was bought. If a bidder declines to state effort by product because its model is outcome-based, request a different commitment that can be inspected: named workflows, tested role boundaries, coverage evidence and a report for each product. Do not force an artificial day count, but do require an observable deliverable.
Ask a final clarification question, not a generic discount question
When proposals arrive, procurement often seeks a lower total before understanding the differences. First ask each bidder to explain the three largest assumptions that could increase the invoice or reduce coverage. Then ask whether those assumptions can be removed, capped or priced as options. This conversation tends to expose more than a broad request for a discount because it ties cost to a concrete test and business decision.
For example, if one quote omits privileged testing, the buyer can ask for its added cost and decide whether the risk is acceptable. If a second quote assumes all retests happen in the original test window, the buyer can price a later verification. If a third includes a platform fee, the buyer can compare it against the reporting and coordination work it replaces. The final scorecard should carry those differences beside the total.
Choose one-time or continuous work based on the operating need
A one-time or annual program is sensible when the estate and release schedule are relatively stable, tests can be booked in advance, and the organization mainly needs a defined body of evidence. It can still use a platform for findings, collaboration and retests. Continuous testing is sensible when material releases, new products or changing exposures create repeated decisions between planned assessment dates. The relevant question is not which label sounds modern; it is whether the cadence purchased matches the risk and release cadence.
The vendor should state what is continuous. It may mean continuous access to a portal, continuously available capacity, automated checks between human deep dives, or ongoing human testing. Those are materially different commitments. Put the cadence, staffing and deliverables in the same row of the quote. Stingrai's published Enterprise offering can be configured as one-time or continuous work, with human-led, autonomous or hybrid testing selected for the relevant scope. Its autonomous agent, Snipe, tests web applications and their APIs; specialist human-led work covers other surfaces in a custom engagement.
For a portfolio spanning cloud, mobile, network or social engineering, ask which parts are included in the base and which are a separate specialist exercise. A continuous web application testing subscription cannot silently stand in for a network or physical test. Conversely, a one-time report for a network assessment should not be judged as if it promised continual web release checks. Compare each offer against the approved demand schedule.
Where Stingrai fits
Stingrai is a Toronto-headquartered, CREST-accredited penetration testing company. Its human-led engagements use two named penetration testers from a team holding OSCE³, OSWE, OSEP and CREST CRT certifications, with findings delivered through the PTaaS platform as they are confirmed. Teams can collaborate with testers during work, receive prioritized remediation guidance, and request retesting of remediated findings. Human-led and hybrid reports include an attestation letter that can support a buyer's compliance program and audit evidence needs.
The published fixed plans cover one web application and associated APIs. A multi-application estate, other testing disciplines, and broader Enterprise delivery need a custom quote. Stingrai offers one-time or annual tests and continuous programs, so the proposal should state the selected cadence, the products and roles in scope, the human and autonomous work split, retest terms and reporting output. Bring the demand schedule above to Get a Quote; a precise inventory lets the team return a proposal that can be compared line by line.
Frequently Asked Questions
How much does enterprise PTaaS cost for a multi-application portfolio?
There is no defensible single portfolio price without an agreed inventory, role depth, cadence, capacity and retest entitlement. Ask each bidder for a planned-year total and a priced expansion scenario against the same demand schedule. Stingrai custom quotes multi-application Enterprise work; its published fixed packages cover one web application and associated APIs.
What is the best way to compare a credit quote with a fixed-price quote?
Translate both into the same named applications, test depth, reports, retests and delivery dates. For the credit offer, request the contracted credit price, forecast debit by application, overage rule and unused-capacity terms. For the fixed offer, request its change-order and urgent-work rates. Compare the totals under the same planned and expansion scenarios.
Should every application receive the same tester effort?
No. Allocate depth according to product-specific risk, role and tenant boundaries, sensitive workflows, change rate and shared controls. Ask the vendor to explain how much work each product receives and what is sampled or omitted. A uniform day count is less useful than a transparent coverage decision.
Are retests normally included in enterprise PTaaS?
Terms vary. USAC's public PTaaS Q&A expected one retest per remediation with ad hoc costs for repeated or lengthy work, while Cobalt's public pricing page describes unlimited on-demand retesting during the contract term. Require your proposal to state the qualifying findings, request window, verification depth, evidence and extra-work rate.
Is a PTaaS platform fee the price of testing?
Only if the contract expressly makes it so. A platform can coordinate scope, findings and reports, while test execution may be separately priced by assessment, asset, credit or reserved capacity. Ask for mandatory platform charges and the testing work they include before comparing totals.
How should a new application be priced after contract signature?
The agreement should define when a new product becomes a chargeable unit, how complexity is classified, what testing depth it receives, the scheduling lead time and the applicable rate. USAC's public PTaaS Q&A asked for a unit-rate or complexity-based method for incremental systems. An expansion scenario in the original quote makes that rule testable before purchase.
Do we need continuous testing or annual penetration tests?
Choose the cadence that matches release and risk decisions. Predictable scopes can use one-time or annual tests with scheduled retests; changing application portfolios may benefit from a continuous program with defined capacity and deliverables. Ask the vendor to specify whether "continuous" describes a portal, automated checks, human testing, or some combination.
What should an enterprise penetration testing RFP require from bidders?
Require a response against a common product inventory, role matrix, test objectives, delivery calendar, report specification, retest entitlement, growth pricing and exclusions. Ask for a planned-year total and a priced expansion scenario. NIST's assessment-planning guidance also calls for clear authorization, logistics, sensitive-data handling and incident procedures.
Related reading
References
Universal Service Administrative Company, RFP IT-26-027: Penetration Testing as a Service, first revision and public Q&A, 2026.
Cobalt, Pricing and credit model, checked 23 October 2026.
OWASP, Application Security Verification Standard, stable release 2025.
NIST, SP 800-115: Technical Guide to Information Security Testing and Assessment, 2008.
Stingrai, Plans and pricing, PTaaS platform and About Stingrai, checked 23 October 2026.
Talk to Stingrai
Bring your product inventory, role matrix, target cadence and retest needs to Get a Quote or book a free discovery call. Stingrai can return a scoped Enterprise proposal for one-time or continuous portfolio testing.
