Penetration testing cost is the first question most security leaders ask and the hardest one to get a straight answer to. Ask three firms to test the same environment and you can get three proposals that differ by a factor of four, all of them technically honest. The spread is not usually a sign that someone is overcharging. It is a sign that the three firms scoped three different pieces of work and called them the same thing.
This guide explains what actually sits behind a penetration testing quote: the variables that move the number, the pricing models you will encounter, the compliance drivers that change the required depth of testing, and the costs that tend to surface after the engagement letter is signed. The goal is that you can read two proposals side by side and understand precisely why they differ, rather than defaulting to the cheaper one and discovering the gap during your audit.
We are not going to publish a price list here, and you should be skeptical of any firm that publishes one without seeing your environment. A penetration test is a labor engagement. The cost is a function of how many hours a qualified tester spends and what they are asked to do with those hours. Any number quoted before scoping is a guess dressed as a price.
What Actually Drives Penetration Testing Cost
Every credible penetration testing quote resolves to the same underlying calculation: estimated tester-days multiplied by the day rate for the skill level the work requires, plus reporting time, plus any retest included in the scope. Everything else in the proposal is a detail that feeds one of those three terms.
Tester-days are driven by the size and complexity of the attack surface. Twelve external IP addresses running a handful of standard services is a fundamentally different job from twelve IP addresses fronting custom web applications with authenticated user roles, payment flows, and an API layer. The IP count is identical. The effort is not remotely comparable.
Day rate is driven by who does the work. A tester capable of chaining logic flaws in a custom application, writing a working exploit, and explaining the business impact to your board is a materially different resource from a technician running an automated scanner and exporting the output. Both can be called penetration testing in a proposal. Only one of them will find the finding that matters.
Reporting time is routinely underestimated by buyers and is often a third of the total engagement. A report that an auditor will accept, that your engineers can act on, and that ranks findings by real exploitability rather than raw scanner severity takes real hours to produce. Firms that quote suspiciously low are frequently economizing here, and you discover it when the deliverable arrives as a lightly edited tool export.
The Pricing Models You Will See in Proposals
Four pricing structures dominate the market, and each one distributes risk differently between you and the testing firm.
Fixed fee for a defined scope. The firm scopes the environment, commits to a price, and absorbs the risk of the work taking longer than estimated. This is the most common structure for compliance-driven testing and the easiest to budget against. The tradeoff is that the scope boundary becomes contractually rigid: anything discovered mid-engagement that sits outside the defined targets becomes a change order rather than part of the work.
Per-target pricing. The firm quotes per external IP address, per web application, per API, or per wireless network. This is transparent and easy to compare across vendors, but it rewards firms that define a target narrowly. One organization's single web application is another's three applications plus an API, and the per-unit price is meaningless until both parties agree on what a unit is.
Day rate or time and materials. You buy a block of tester-days and direct how they are spent. This suits mature security programs that know exactly what they want tested and want the flexibility to redirect effort mid-engagement. It is a poor fit for a first test or a compliance deadline, because there is no contractual commitment that the work will reach a defined finish line.
Retainer or continuous testing. Testing is spread across the year rather than delivered as a single annual event. This costs more in aggregate than one annual test and is substantially more useful for environments that ship code frequently, because an annual point-in-time test on a codebase that changes weekly is stale within a month of delivery.
Scope Variables That Move the Number Most
When you are trying to understand why one quote is double another, these are the variables to interrogate first.
External versus internal versus both. An external test looks at what an unauthenticated attacker on the internet can reach. An internal test simulates an attacker who already has a foothold, whether through a phished credential, a malicious insider, or a compromised vendor connection. They answer different questions and the second one is where most organizations find their genuinely alarming results. Scoping only the external perimeter is cheaper and tells you considerably less. Our network penetration testing work commonly surfaces lateral movement paths that no external-only engagement would have touched.
Authenticated versus unauthenticated application testing. Testing a web application without credentials examines the login page and whatever sits in front of it. Testing with credentials for each user role examines the actual application: privilege boundaries, horizontal and vertical access control, business logic, and the flows where real money or real data moves. Authenticated testing costs more because it is more work, and it is where the serious findings live. If a quote is unusually cheap, check whether it includes authenticated testing at all.
Number of distinct user roles. An application with an anonymous user, a standard user, a manager, and an administrator requires the tester to work through the access control matrix between every pair of roles. Each additional role expands that matrix substantially. This is one of the single largest cost drivers in application testing and one of the most frequently omitted details in a scoping conversation.
Manual depth versus automated coverage. Automated scanning is fast, cheap, and finds known vulnerabilities in known software. It does not find broken access control, business logic flaws, chained exploits, or anything requiring an understanding of what your application is for. Ask any firm directly what percentage of the engagement is manual testing. The answer tells you what you are buying.
Social engineering and physical testing. Phishing simulation, pretext calling, and physical site access are separate disciplines with separate costs. They are frequently assumed to be included and frequently are not.
Retesting. After you remediate, someone has to verify the fixes actually work. Some firms include one retest window in the base price. Others bill it separately. This is a common source of budget surprise and an easy thing to confirm in writing before signing.
The Compliance Framework Changes What You Have to Buy
A large share of penetration testing spend is driven by a framework requirement rather than by an internal security decision. What that framework actually requires has a direct effect on the cost, and buying the wrong depth of test is an expensive way to fail an assessment.
PCI DSS. Requirement 11.4 of PCI DSS v4.0 mandates internal and external penetration testing at least annually and after any significant infrastructure or application change, with testing that covers the entire cardholder data environment perimeter and any segmentation controls. Segmentation testing is a specific, separately scoped activity: if you rely on network segmentation to reduce your PCI scope, the effectiveness of that segmentation has to be validated by testing. Organizations regularly budget for the perimeter test and forget the segmentation validation.
NIST SP 800-171 and CMMC. Organizations handling Controlled Unclassified Information work against the assessment and system integrity requirements in NIST SP 800-171. Security assessment obligations mean testing has to produce evidence an assessor will accept, and the report becomes an artifact in your assessment package rather than an internal document. That raises the bar on documentation quality and on the tester's ability to map findings to specific control requirements. Our broader compliance services work exists largely because this mapping step is where technically sound tests fail to satisfy assessors.
HIPAA. The Security Rule requires a risk analysis and does not explicitly mandate penetration testing by name. In practice, testing is one of the most defensible ways to evidence that technical vulnerabilities have been identified and evaluated, and it is routinely expected by cyber insurers and business partners regardless of the letter of the rule.
SOC 2 and ISO 27001. Neither prescribes penetration testing in explicit mandatory terms, but auditors overwhelmingly expect it as evidence for vulnerability management and change management controls. The practical requirement is annual testing with documented remediation.
Methodology standards. NIST SP 800-115 remains the reference technical guide for information security testing and assessment, and a proposal that references a recognized methodology is generally a better sign than one that describes no methodology at all.
Costs That Surface After the Quote
The quoted figure is rarely the total spend. These are the line items that appear later.
Remediation effort. The test finds problems. Fixing them consumes engineering time, and on a first test the remediation effort frequently exceeds the cost of the test itself. This is the correct outcome and should be planned for rather than treated as a surprise.
Retest fees. Covered above, and worth confirming in the contract rather than assuming.
Scope expansion mid-engagement. Testers routinely discover assets the organization did not know it had. Whether those get tested under the current agreement or become a change order depends entirely on how the scope was written.
Attestation letters. Many organizations need a summary letter for customers, insurers, or partners. Some firms include it and some bill for it.
Repeat testing after significant change. Frameworks that require testing after significant infrastructure changes mean a major migration can trigger an unbudgeted second test in the same year.
How to Compare Two Penetration Testing Cost Quotes
When two proposals differ significantly, the difference is almost always in one of these places. Work through them in order.
- Does the scope include internal testing, or only the external perimeter?
- Is application testing authenticated, and for how many distinct user roles?
- What proportion of the engagement is manual testing versus automated scanning?
- What are the qualifications and experience of the people actually assigned, not the firm's aggregate credentials?
- Is a retest included, and how long is the remediation window before it expires?
- Will you receive a sample report before signing?
- Are findings mapped to the specific framework controls your assessor or auditor will ask about?
- Who writes the report, and is it reviewed by someone senior before delivery?
- Is segmentation testing included where your compliance scope depends on it?
- What happens contractually if the testers find something outside the agreed scope?
The single most informative request you can make is for a redacted sample report. Proposals are marketing documents and tend to look alike. Reports are the actual deliverable, and the difference between a thoughtful one and a scanner export is obvious within thirty seconds to a non-specialist.
Why the Cheapest Quote Is Frequently the Most Expensive
A low quote is not automatically bad. It may reflect a genuinely small scope, an efficient firm, or a straightforward environment. But when a quote is dramatically below the others for what appears to be identical work, one of a few things is usually true: the scope silently excludes internal or authenticated testing, the engagement is predominantly automated scanning, the report is a lightly formatted tool export, or the work is being performed by junior staff without meaningful senior review.
The failure mode is not that you wasted the fee. It is that you now hold a document asserting your environment was tested, you have a false sense of the risk, and the vulnerability that actually gets exploited was never in scope. For organizations testing to satisfy a framework, there is a second failure mode: the assessor rejects the evidence, and you pay for a second test under deadline pressure at whatever price is available.
Frequently Asked Questions
How much does a penetration test cost?
There is no honest single answer, because the cost is a direct function of scope. The meaningful question is what a test costs for your specific environment, which requires a scoping conversation covering your external footprint, internal network size, number and complexity of applications, user roles, and the compliance framework driving the requirement. Any firm quoting a firm price before that conversation is quoting a number, not a scope.
How long does a penetration test take?
Field work commonly runs one to three weeks depending on scope, with reporting adding time after testing concludes. Remediation and retest extend the overall timeline further. If you are testing against an audit deadline, plan the engagement backward from the deadline with remediation time built in, not forward from when you happen to sign.
How often should we test?
Annually is the baseline that most frameworks require. After any significant change to infrastructure or applications is the second trigger, and it is the one organizations most often miss. Environments that deploy code frequently get materially more value from continuous or periodic testing than from a single annual event.
Is a vulnerability scan the same as a penetration test?
No, and conflating them is the most common and most expensive misunderstanding in this area. A vulnerability scan is automated, identifies known issues in known software, and can be run continuously at low cost. A penetration test uses a skilled human to attempt actual exploitation, chain multiple weaknesses together, and evaluate business impact. Scanning tells you what is potentially wrong. Testing tells you what an attacker can actually do. Most frameworks require both, and a scan submitted as a penetration test will generally be rejected by an assessor.
Will a penetration test disrupt production systems?
A competently run test is scoped with agreed rules of engagement covering testing windows, out-of-bounds systems, escalation contacts, and which classes of testing are permitted. Denial-of-service testing is normally excluded by default. Discuss and document this before work begins rather than assuming.
Do we need internal testing if our external perimeter is clean?
Almost certainly yes. A clean external perimeter demonstrates that the front door is locked. It says nothing about what an attacker can reach after a single phished credential, and that is the scenario most real incidents follow. Internal testing is where organizations with strong perimeters typically find their most serious results.
What should we do first if we have never tested?
Establish what you are actually required to demonstrate and to whom. The framework driving the requirement determines the necessary depth, the evidence format, and the timeline. Scoping backward from that requirement avoids the common and costly pattern of buying a test that is technically fine but does not satisfy the assessor who asked for it.
Getting a Scoped Penetration Testing Quote
Petronella Technology Group, Inc. has been performing security testing for regulated organizations since 2002, with engagements scoped around the framework actually driving your requirement rather than a generic package. Craig Petronella is a CMMC Registered Practitioner and the author of multiple books on cybersecurity, and our testing work is deliberately structured so the resulting report functions as assessment evidence rather than as an internal document that has to be re-explained to an auditor.
If you want a number for your environment, the fastest path is a short scoping conversation covering your external footprint, internal network size, applications and user roles, and the framework you are testing against. That conversation produces a defined scope and a fixed price, and it takes considerably less time than comparing proposals that are not describing the same work.
You can review our full penetration testing services for methodology and engagement types, and contact our team to schedule a scoping call.
Free, practical, and specific to regulated environments. We will email it to you.
No spam. Unsubscribe anytime.
