How Much Does a Penetration Test Cost?
Penetration testing can cost anywhere from a couple thousand US dollars for a small, tightly scoped engagement to tens of thousands for larger or more complex environments. Treat that as a budgeting starting point: the scope, testing depth, and deliverables determine what a quote actually buys.
Two proposals with very different prices may cover different systems, allow different amounts of investigation, or deliver different kinds of testing. Before comparing the totals, find out what a tester will actually do.
You’re paying for human time and judgment
In a manual penetration test, much of the fee pays for a skilled person’s time: learning how your system works, investigating potential weaknesses, validating findings, and explaining their impact. Automated tools help with discovery and repeatable checks, while the tester decides what to investigate and follows the evidence.
For a customer portal, that could mean examining whether users can access another organization’s records or bypass an approval step. Those questions require an understanding of the application’s permissions and workflows.
Ask how much hands-on testing is planned, who will perform it, and how that time is allocated. A two-week delivery window does not necessarily mean two weeks of active testing. More hours also do not guarantee better work; experience, coverage, and the quality of the investigation all count.
What changes a penetration testing quote?
A useful quote starts with your objective: the application you are launching, the customer requirement you need to meet, or the access controls you want examined. Your provider then estimates the effort needed to test the agreed systems under the agreed conditions.
Our guide to defining your penetration testing scope walks through the systems, roles, environments, and exclusions to agree on before requesting a quote.
| Pricing factor | Work it can add | What to share |
|---|---|---|
| Systems and test types | Different applications, APIs, and network environments need distinct testing activities. | Systems to include, their purpose, and boundaries. |
| Functional complexity | Features and integrations introduce workflows and data paths to investigate. | Sensitive actions, integrations, and a walkthrough. |
| User roles and tenants | More roles and customer organizations create permission boundaries to examine. | Role descriptions and available test accounts. |
| Testing depth | Broader objectives and deeper investigation require time within the agreed scope. | Priority questions, concerns, and required coverage. |
| Access and environments | Setup, restrictions, and production or staging differences affect what can be tested. | Access requirements, environment differences, and permitted activities. |
| Deliverables and follow-up | Reporting, stakeholder discussions, and retesting require work beyond initial testing. | Required documents, audiences, and follow-up needs. |
| Scheduling constraints | An accelerated deadline can affect staffing and availability. | Testing and report deadlines; ask whether timing changes the price. |
For example, adding a billing administrator role creates another set of permission boundaries to examine. Testers may need to check whether an ordinary customer can perform billing actions, whether administrators can reach other customers’ records, and whether the API enforces the same restrictions as the interface.
An endpoint count alone cannot describe that work. A simple read-only endpoint and a workflow that approves payments may require different investigation. For web application penetration testing costs, a short demonstration of the application can make the estimate more useful than a list of URLs.
Why can two quotes for “one application” differ?
Suppose you request quotes for a customer portal with document uploads, billing, a support console, and an API. Customers belong to separate organizations, and users have different permissions. Two providers could both describe their offer as an application penetration test while proposing the following coverage:
| Coverage | Proposal A: limited scope | Proposal B: broader scope |
|---|---|---|
| Public functionality | Included | Included |
| Authenticated roles | One standard customer role | Customer, billing administrator, and support roles |
| Administration | Excluded | Agreed administrative workflows included |
| Supporting API | Only functions used by the included customer workflow | Agreed supporting API scope across included roles |
| Tenant isolation | Not included | Access between separate customer organizations assessed |
| Open questions | Testing effort, reporting, and follow-up still need confirmation | Testing effort, reporting, and follow-up still need confirmation |
Proposal A could fit a deliberately limited assessment of public and standard-user functionality. Proposal B would better fit an objective that includes administrative access and separation between customer organizations. If your customer requires those boundaries to be assessed, Proposal A would leave part of that requirement unanswered.
Neither scope description establishes the quality of execution. Ask each provider how it will investigate the agreed areas, who will perform the work, and how findings will be documented. Compare fees after you understand both the coverage differences and the proposed testing effort.
Is the “pentest” actually a vulnerability scan?
Some services sold as penetration tests amount to an automated vulnerability scan and a report, with little manual investigation. Scanning is useful for finding known vulnerabilities and common misconfigurations, but a scan report alone does not show that someone investigated your business logic, tested permission boundaries, or explored how weaknesses could be combined.
Ask what work happens beyond scanning. Will a tester examine authenticated workflows, investigate access between users, and provide evidence of what they could do? Request a sample report and look for application-specific analysis and reproducible findings rather than a list of scanner alerts.
A low price alone does not tell you which service you’re getting, and a high price does not prove thorough testing. Get the testing approach and coverage in writing.
For a fuller evaluation of the people, methods, and follow-up behind an offer, use our 12 questions to ask a penetration testing company.
What should you check is included?
Use the worksheet below to record each provider’s offer in the same format. Copy it into your evaluation notes and add rows as needed; no form submission is required. Use “not specified” when a proposal is silent, then resolve those gaps before signing.
Penetration testing quote comparison worksheet
| Provider | Included coverage | Exclusions | Follow-up | Total proposed fee |
|---|---|---|---|---|
| Proposal 1 | ||||
| Proposal 2 | ||||
| Proposal 3 |
For each proposal, check these details before reducing the offer to a single total:
- Scope: Name the applications, APIs, network ranges, roles, tenants, and environments. Record exclusions and restrictions alongside included coverage.
- Testing effort and methodology: Ask how much active testing is planned and how manual investigation and automated tools contribute. Separate testing time from setup, reporting, and the overall delivery window.
- Reporting: Confirm the technical report, evidence supporting findings, remediation guidance, and any executive summary or customer-facing documentation you need. Request a sample to assess whether it will serve your audience.
- Communication: Establish how urgent findings will reach you, who can answer technical questions, and whether a discussion of findings and remediation is included.
- Retesting: Record the number of rounds, eligible findings, submission deadline, expected turnaround, and whether an updated report is included. Ask how additional rounds are priced.
- Fees and changes: Identify optional charges and assumptions behind the total. Agree who approves added scope and how changes affect price, coverage, or delivery.
At Halo Security, a penetration test for a simple application or small network generally starts at $3,950 USD, with a fixed-price quote after scoping. Halo’s services include a technical report, an attestation letter, and one retest round after your team addresses the findings, followed by an updated report.
Also distinguish a test completion date from the date you need usable documentation. A customer may need a report showing verified fixes, which requires time for reporting, remediation, and retesting after the initial investigation.
How can you make better use of your budget?
Prepare the access and context testers need before the engagement starts. Time spent resolving broken credentials or waiting for sample data leaves less opportunity to investigate the workflows you intended to assess.
- Provide working accounts for the agreed roles and tenants. Check sign-in, multifactor authentication, and access from the testing connection in advance.
- Demonstrate sensitive workflows, such as inviting users, approving transactions, changing permissions, and exporting records. Explain what each role should be allowed to do.
- Gather existing documentation, including API specifications, architecture diagrams, and setup instructions. Flag differences between staging and production.
- Share known issues and previous findings. Tell the testers which fixes are complete, which remain open, and where your team has unanswered questions.
This preparation helps preserve testing time for investigation. It does not guarantee a discount or a particular saving. Halo’s penetration test planning guide offers additional preparation advice.
If the proposed scope exceeds your budget, ask the provider to explain what it would prioritize and why. Systems handling sensitive data, permission changes, and exposed services may warrant different levels of attention. Required customer or audit coverage must remain part of that discussion.
Phasing can be useful when the work can be divided without missing a requirement or deadline. For example, you might assess a customer portal before launch and schedule a separate internal application later. Document which systems and behaviors remain untested, when you plan to assess them, and whether the first report is sufficient for its intended use. Do not let required coverage disappear inside a cheaper quote.
What other costs should you plan for?
The provider’s fee is only one part of the project budget. Your team will need time to coordinate access, prepare accounts and data, demonstrate the application, and answer questions during testing. Assign an available contact so routine questions do not stall the engagement.
Afterward, engineers need to evaluate findings, implement fixes, and support retesting. Some fixes may also require deployment planning or changes to third-party services.
Plan internal capacity alongside the external quote. A test scheduled just before a customer deadline may leave too little time to resolve findings and obtain updated documentation, even when the initial report arrives on schedule.
What do you need to get an accurate quote?
You can begin a scoping conversation with a short description of your environment. Bring the following information when it is available:
- Testing objective: What prompted the test, and what question or requirement does it need to address?
- Systems involved: Which applications, APIs, network environments, and production or staging systems are candidates for testing?
- Roles and features: Approximately how many user types or tenants exist, and which workflows handle sensitive data or permissions?
- Timing: When can testing begin, and when do you need the initial report or documentation of verified fixes?
- Deliverables: What do your engineers, leadership, customers, or auditors need to receive?
You do not need every detail ready before contacting a penetration testing company like Halo Security. Share what you know, your budget constraints, and any uncertainties about coverage. The scoping conversation should resolve those questions and produce a fixed-price proposal with clear boundaries and deliverables.