Align penetration-testing scope before comparing price
A proposal total is not comparable until every supplier is pricing the same assets, identities, environments, deliverables, retest commitment, expenses, and tax basis. One proposal may cover the customer application and every API role, while another covers only a representative path. A lower number can therefore represent a smaller engagement rather than a better price.
This calculator turns web, API, mobile, and infrastructure scope into person-days, separates shared role and environment effort, and adds evidence, reporting, briefing, travel, and remediation verification. It then separates supplier cash from customer-side coordination, remediation, and uncertainty reserves so procurement teams can plan the complete budget and identify omissions in proposals A and B.
What the result includes
Asset effort
Quantity and editable base effort produce adjusted person-days and an external-fee reference for each of the four asset types.
Shared scope effort
Roles and tenants beyond the first, plus setup for each external or internal environment, remain visible outside asset effort.
Retest reserve
A contract-specific percentage of initial technical effort is reserved for as many as two remediation-verification rounds.
Complete customer budget
External cash, internal coordination, remediation funding, and scope contingency remain separate and then roll into one total.
Conservative working days
Parallel tester capacity is applied to technical and retest effort, while deliverables are kept visible as a sequential planning allowance.
Proposal coverage
Aligned proposals A and B show their amount, gap, and coverage percentage against calculated external cash.
Define one consistent asset unit
Count targets by independent deployment, authorization, and data boundary rather than by URL alone. A customer portal and an administration portal may be separate assets when their identities, releases, or sensitive data differ. Conversely, several hostnames backed by the same code and authorization model may belong to one agreed unit. Record that decision in the request for proposal and use it across every supplier response.
- Web applications: Count web experiences with separate deployment, authorization, or important data boundaries.
- APIs: Select an endpoint, resource bundle, or service as the contract unit and keep that unit consistent.
- Mobile apps: Separate Android, iOS, build, or distribution-channel targets when they require distinct testing.
- Infrastructure and cloud: Count hosts, VMs, accounts, subscriptions, or explicitly agreed asset bundles.
Base effort is not a public standard
NIST and OWASP describe testing objectives, scope, techniques, and reporting, but they do not prescribe universal person-days per web app, endpoint, mobile build, or host. The examples in the calculator are fictional formula demonstrations. Replace them with a written supplier effort breakdown or a measured delivery record before using the budget in a decision.
Black, gray, and white box are not automatic price tiers
The method describes how much information the tester receives. More information can reduce discovery effort, yet source review, architecture review, and deeper evidence may add work. The calculator therefore records the selected method without changing price. Enter a separate adjustment only when a proposal or delivery record supports the effort difference.
Knowledge-level methods and proposal questions for penetration testing| Method | Typical information condition | Proposal question |
|---|
| Black box | Public information and limited credentials | Discovery boundaries, permitted automation, provided accounts, and prohibited actions |
| Gray box | Selected roles plus some architecture or design context | Role count, tenant count, test data, and trust boundaries |
| White box | Broad source, design, and configuration information | Source-review depth, target branch or build, and required evidence quality |
How effort is calculated
1. Adjust asset effort
For each asset type, base effort equals quantity multiplied by base person-days per unit. The scope multiplier is (1 + complexity adjustment) × (1 + method adjustment). The two percentages are multiplied rather than added, so +20% and −10% produce a multiplier of 1.08.
2. Add roles, tenants, and environments
The first authenticated role and first tenant are treated as part of base scope. Additional effort applies only to each role or tenant beyond the first. Every external or internal environment receives the entered setup allowance for access, allow-listing, accounts, tooling, and validation.
3. Add deliverables and retest
Evidence QA, technical and executive reporting, briefing, and travel remain separate from initial technical effort. Retest effort per round equals initial technical person-days multiplied by the entered contract percentage. New features or substantial architecture changes may be new scope instead of remediation verification and should be quoted separately.
4. Build the complete budget
Initial and retest person-days multiplied by the external day rate create professional fees. Direct expenses and user-confirmed cash-basis tax create external cash. Internal hours multiplied by loaded cost and the remediation reserve are then added, followed by scope contingency. The calculator does not decide whether tax is recoverable or deductible; enter only the cash treatment relevant to the comparison.
Step-by-step workflow
- Freeze the asset register. Confirm ownership, third-party restrictions, testing eligibility, and one consistent aggregation unit.
- Replace fictional effort. Use a supplier effort table or measured history from a genuinely comparable engagement.
- Record knowledge and access. Confirm the box method, roles, tenants, environments, accounts, architecture, source, and test data.
- Separate deliverables and retest. Align report types, evidence depth, readout, deadline, round limit, eligible findings, and new-function exclusions.
- Use one currency and tax basis. Avoid overlap between the day rate, direct expenses, internal labor, remediation, and contingency.
- Compare proposals A and B. A proposal below calculated external cash may omit scope rather than represent a saving.
- Approve Rules of Engagement. Testing should begin only after assets, permitted actions, windows, contacts, stop conditions, evidence handling, and recovery procedures are authorized in writing.
Worked example with exact formulas
Assume two web applications at 3 person-days each, ten API units at 0.2 day each, one mobile target at 4 days, and four infrastructure units at 0.5 day each. Base asset effort is 14 person-days. Complexity of +20% and a supplied-material adjustment of −10% create a 1.08 multiplier and 15.12 adjusted asset days.
Three roles at 0.5 day for each role beyond the first add 1 day. Two tenants at 0.75 day beyond the first add 0.75 day. Two environments at 0.5 day each add 1 day. Initial technical effort is therefore 17.87 days. Evidence of 1 day, reporting of 2 days, a 0.5-day briefing, and 0.5 day of travel produce 21.87 initial billable days. One retest round at 25% adds 4.4675 days, making total billable effort 26.3375 days.
Initial technical effort
17.87 person-days
Initial billable effort
21.87 person-days
One retest at 25%
4.4675 person-days
Total billable effort
26.3375 person-days
External cash
KRW 30,071,250
Complete budget
KRW 38,524,062.5
The cash figures use a fictional KRW 1,000,000 day rate, KRW 1,000,000 in direct expenses, 10% cash-basis tax, 20 internal hours at KRW 50,000, a 15% remediation reserve, and 10% contingency. They verify the formula; they are not market prices. With two testers, the conservative sequential schedule is 9 initial technical days, 4 deliverable and travel days, and 3 retest days, or 16 working days before any remediation waiting period.
Keep four budget layers distinct
External cash
Professional fees, retest fees, direct expenses, and user-entered cash-basis tax. This is the proposal comparison boundary, not total customer cost.
Internal coordination
Asset preparation, accounts, questions, monitoring, incident coordination, remediation discussion, and retest scheduling valued at loaded internal cost.
Remediation reserve
Customer-side development, configuration, architecture, and specialist support. If measured remediation data exists, replace a simple percentage with a separate detailed budget.
Scope contingency
Allowance for unresolved asset changes, additional environments, account delays, or report refinement. It should not conceal scope that can be defined before contracting.
Read proposal coverage carefully
Proposal coverage divides a supplier proposal by calculated external cash. A percentage below 100% is a prompt to inspect missing assets, roles, environments, deliverables, retest, expenses, or tax. A percentage above 100% is not automatically excessive: the supplier may include deeper testing, specialist review, more evidence, insurance, travel, or a different risk allocation. Use the gap to ask scope questions rather than to rank quality.
Example external-cash proposal coverage comparison| Comparison | Amount | Gap | Coverage |
|---|
| Calculated external cash | KRW 30,071,250 | KRW 0 | 100.0% |
| Proposal A | KRW 28,000,000 | −KRW 2,071,250 | 93.1% |
| Proposal B | KRW 35,000,000 | KRW 4,928,750 | 116.4% |
Practical use cases
- Pre-release product assessment: Put customer web, administration web, APIs, Android and iOS builds, and multiple roles on one scope sheet.
- Annual security budget: Reserve initial testing, as many as two retest rounds, internal coordination, and remediation instead of funding only the supplier contract.
- Supplier selection: Use a low proposal coverage ratio to ask whether reporting, internal networks, travel, tax, or verification has been excluded.
- Retest negotiation: State eligible findings, deadline, round count, report update, and the boundary between remediation verification and new scope.
- Separate certification preparation: Keep technical penetration-testing scope distinct from a broader ISMS, compliance, control, or audit-preparation program.
Authorization, safety, and result limits
Penetration testing can include active actions that affect systems. Written authorization must precede budget execution. Consistent with the Rules of Engagement concept in NIST SP 800-115, the parties should approve targets and exclusions, permitted and prohibited actions, test windows, emergency contacts, immediate stop conditions, evidence handling, and recovery procedures. Customer approval may not be sufficient for cloud, SaaS, partner, or other third-party assets; verify ownership and provider policy separately.
A clean result does not prove that a system has no vulnerabilities or is secure. The assessment covers only the authorized time, scope, and methods. The calculator does not guarantee vulnerability count, completeness, certification, compliance, acceptance, incident prevention, or supplier quality. Denial of service, social engineering, physical security, and production-data modification should remain out of scope unless they are explicitly authorized and safely controlled in the Rules of Engagement.
Frequently asked questions
What should I enter when base effort is unknown?
Use the fictional example only to understand the formula. Send the same asset and deliverable schedule to suppliers and request an effort breakdown. A measured record from a truly comparable engagement can be a second reference, but it is not a universal market average.
Does API quantity mean endpoint count?
It means the endpoint, resource bundle, or service unit defined in the contract. Keep that unit consistent so one proposal does not count individual endpoints while another counts bundles of ten.
Does white-box selection automatically reduce cost?
No. Supplied information may reduce discovery time while source or architecture review adds effort. The method is descriptive; enter only an evidence-based method adjustment.
Is 25% a standard retest percentage?
No. The 25% worked-example value exists only to verify the formula. Use the number of fixed findings, regression scope, new build, report update, deadline, and supplier contract to enter actual effort.
Is a proposal below the calculated amount a saving?
Not necessarily. First compare assets, roles, tenants, internal networks, reporting, briefing, verification, tools, travel, and tax on the same basis.
Will doubling testers halve the calendar?
Not always. The result provides a conservative workday reference, but accounts, environments, sequential validation, coordination, and report QA may prevent complete parallel delivery.
Does the result authorize testing?
No. It is a budget model only. Confirm asset ownership, third-party policy, written authorization, and approved Rules of Engagement before any testing.
Primary sources and update boundary
The following official sources were checked August 14, 2026. They support scope, testing, reporting, and authorization boundaries; they are not sources for universal prices, person-days, or retest percentages.
Future maintainers should recheck the versioned and stable WSTG material, MASTG scope, any NIST successor guidance, and actual supplier contract structures. Every engagement still requires current asset units, effort assumptions, rates, tax treatment, retest language, evidence retention and deletion, ownership, test windows, emergency contacts, stop conditions, and third-party approval.
Build one scope-aligned budget
Freeze the asset register and Rules of Engagement, then replace every fictional effort and price with written evidence. Separating external cash, internal coordination, remediation, and contingency makes proposal omissions and complete customer funding easier to explain than a single headline quote.