Pricing
Penetration testing pricing
Packages scoped to your systems. Penetration testing cost depends on what is being tested and how deep the engagement goes. We quote each engagement after a short scoping conversation so the price reflects the actual work. All testing performed within the United States by experienced professionals.
Focused test
A single application or a small, well-defined network scope. A good fit for a first engagement or a targeted retest.
- One web app, one mobile app, or a defined network scope
- Manual testing supported by tooling
- Full report with findings, impact, and severity
- Post-delivery readout to walk through findings
Standard engagement
A typical application plus the APIs behind it, or combined external and internal network testing.
- Application and its supporting APIs, or external plus internal network
- Multiple user roles and access levels
- Full report with remediation guidance
- Post-delivery readout. Retest terms set in the statement of work.
Program
Recurring testing across multiple applications or environments on a schedule that fits your release cadence.
- Multiple applications, mobile clients, or network environments
- Scheduled testing aligned to your releases
- Consistent reporting across engagements
- Ongoing readouts and retests defined per statement of work
Short answer
How quotes work, without a published price list.
How we quote
After a short scoping conversation we send a written proposal and statement of work. It lists what is in scope, the test windows, the deliverables, and the retest terms, so there are no surprises.
If your needs change, we adjust the scope and the quote together before any additional work begins.
How to compare two proposals on coverage
When you have more than one written proposal, line up what each one would deliberately cover before you decide. This checklist clarifies coverage. It is not a score of vendor quality, and it does not use prices.
Give every firm the same brief: the systems you want tested, the environments, the roles you can supply, and anything that must stay out. Then read each proposal against the same five coverage questions. An item that is not named is unresolved, not included. Authorized testing only happens inside the written scope you agree.
| Coverage axis | What to line up |
|---|---|
| Scope | Named hosts, apps, APIs, environments, and explicit exclusions. An unmentioned item is unresolved, not included. |
| Methodology | How testing is done: tooling-supported manual checks, authenticated paths, and any named limits such as no denial-of-service testing. |
| Accounts and roles | Which signed-in roles, tenants, or logged-out perspectives are in scope, and what your team must supply for those accounts. |
| Deliverables | What the written report includes (steps to reproduce, evidence, business impact, remediation), and whether a readout is part of the engagement. |
| Retest terms | Whether a return to original confirmed findings is described, and what that return covers. Retest terms set in the statement of work. |
Illustrative example: Example Corp lines up two proposals
Illustrative only, not a client or past engagement. Example Corp, app.example.com, api.example.com, and staff.example.com are placeholders. Proposal A and Proposal B are labeled made-up proposals, not real vendors or past quotes.
Say Example Corp wants an authorized test of its customer app at app.example.com, and is deciding whether the staff console and the API behind the app should be in the same window. It receives two written proposals against the same brief. Before anyone talks about budget, the team would line up coverage like this.
| Coverage axis | Proposal A (illustrative) | Proposal B (illustrative) |
|---|---|---|
| Scope | app.example.com in staging only. API hosts and staff.example.com are not named. | app.example.com and api.example.com in staging, plus staff.example.com for the staff console. |
| Methodology | Tooling-supported manual checks on the public surface. Signed-in workflows are not described. | Tooling-supported manual checks, including signed-in paths and object-level authorization between roles where accounts are supplied. |
| Accounts and roles | Logged-out checks only. No Member or Staff test accounts are listed. | Two Member accounts and one Staff account, so role and object checks can be compared. |
| Deliverables | A written report with confirmed findings. A readout call is not named. | A written report with steps to reproduce, evidence, business impact, and remediation, plus a readout with the people who will fix the issues. |
| Retest terms | Retest terms are not described in the proposal text. | A return to the original confirmed findings is described. Retest terms set in the statement of work. |
In this example, Proposal A would deliberately cover the public surface of app.example.com while logged out. Proposal B would deliberately cover the app, the API, and the staff console with agreed roles. Neither row above is a judgment of which firm is better. The rows show what each written scope would and would not cover. Example Corp would still need written authorization from whoever controls each host before any testing starts.
Retest terms set in the statement of work. A penetration test is not a compliance certification. Choosing a proposal does not make Example Corp compliant on its own. When you are ready for a scoped quote from us, tell us what you want tested.
Frequently asked questions
Short answers about how quotes work, without listing prices.
Why don't you list prices on this page?
Because scope drives the quote. Every engagement is quoted after a short scoping conversation so the written proposal reflects what is tested and how deep, not a menu price list.
What drives the quote?
The assets in scope, testing depth, user roles, environments, and testing windows. We agree these during a short scoping conversation, then send a written proposal and statement of work. Authorized testing only happens inside that written scope.
What's the difference between Focused, Standard, and Program?
Focused is a single application or a small, well-defined network scope, a good fit for a first engagement or a targeted retest. Standard is a typical application plus the APIs behind it, or combined external and internal network testing. Program is recurring testing across multiple applications or environments on a schedule that fits your release cadence. We still quote each after scoping, because the actual assets and depth vary.
Are retests included?
Retest terms set in the statement of work.
Is a penetration test a compliance certification?
No. A penetration test is not a compliance certification. It can support a broader compliance program by providing independent evidence of testing. It is one input among many. It does not by itself make an organization compliant or certified.
How do I compare two penetration testing proposals?
Line up coverage before anything else: named scope, methodology, accounts and roles, deliverables, and retest terms. Treat an unmentioned item as unresolved, not included. That checklist clarifies what each proposal would deliberately cover. It is not a score of vendor quality. Authorized testing only happens inside the written scope you agree. Retest terms set in the statement of work. A penetration test is not a compliance certification.
Tell us what you need tested
Share a few details about your systems and we will follow up with a quote.