Penetration testing pricing: the five things that move the number

Three quotes for the same penetration test can differ by a factor of five, and the cheapest one is frequently not a penetration test at all. The problem is that the word covers two entirely different kinds of work.

One is a consultant spending two weeks trying to break into your systems. The other is an automated scan with a report template on top. Both get sold as a penetration test, and nothing in the price tells you which you are buying. This article sets out the five things that genuinely move a penetration testing cost, and how to compare quotes so that the comparison means something.

What you are really buying

Almost every penetration testing cost resolves to one calculation: how many days of a qualified person, at what seniority, plus the time to write it up.

That is why asking for a price without defining scope produces a meaningless number. Two proposals at very different prices are usually quoting different amounts of time, not different margins. Ask for the day count first. The rest of the conversation gets easier immediately.

The five things that move a penetration testing cost

1. 1 Scope complexity, not scope size. A flat list of IP addresses tells you very little. What costs time is distinct functionality: user roles, workflows, integrations, APIs, file uploads, payment flows. Two hundred web servers running the same image are close to the cost of one. A single application with four roles and a document pipeline is not.
2. 2 Depth. A vulnerability assessment identifies and reports. A penetration test exploits and chains. A red team exercise simulates a real adversary against your detection capability, over weeks, with objectives rather than a target list. These are not three price points of the same service.
3. 3 How much you tell the tester. Black box means they start with nothing, and you pay for reconnaissance that an attacker would also do. Grey box gives them credentials and documentation, so more of the budget goes into testing and less into discovery. White box adds source code. Counterintuitively, giving more information usually buys more findings per day.
4. 4 What the report has to satisfy. A report for internal use is one thing. A report that an assessor will read as evidence against PCI DSS Requirement 11.4 has to state scope, methodology, dates, tester qualifications and organizational independence. That is real additional work and it belongs in the quote.
5. 5 The retest. Findings get fixed, and somebody has to verify the fix. For PCI this is not optional under 11.4.4. A proposal that excludes the retest is not cheaper, it is incomplete.

The things that quietly add days

None of these appear in a scoping form, and all of them show up in the invoice or in the calendar.

• Testing against production. Rate limits, change windows, out-of-hours work and a much more careful approach. All of it is slower.
• Environments that do not match. Testing a staging system that differs from production means findings that do not apply and gaps that are never found.
• Waiting. Credentials that arrive on day three of a five-day engagement are three days of a booked consultant.
• Mobile and thick clients. They need different tooling and a different skill set from web testing.
• Urgency. A test booked for next week costs more than the same test booked for next quarter, in every firm that is any good.

How to compare three proposals

Put the prices to one side and line up these five answers instead. The comparison usually resolves itself.

1. 1 How many tester days, and at what seniority? If the proposal does not say, ask. If it still does not say, you have your answer.
2. 2 What methodology, named? An industry-accepted approach, stated explicitly, not “our proven process”.
3. 3 Is manual testing included, and what proportion? Tools find known issues. People find business logic flaws, and those are the ones that matter.
4. 4 Is the retest included, and for how long after?
5. 5 Can I see a redacted sample report? Two pages tell you more than the whole proposal.

Why the compliance version carries a higher penetration testing cost

A test done for your own assurance can stop when the team has learned enough. A test done as evidence has to cover the full perimeter of the cardholder data environment and critical systems. It also has to include application-layer and network-layer work, and produce artifacts an assessor will accept.

It also has to be repeated after any significant change, which means the annual booking is a floor rather than a ceiling. And if you use segmentation to reduce scope, the segmentation test is additional work, every 12 months for merchants and every six for service providers. The full shape of Requirement 11.4 is worth reading before you ask for a quote, because it changes what you are asking for.

Where we fit

We scope this by days and complexity rather than by host count, and we say which part is manual. The testing work sits with adversary simulation and red teaming, and the fix-and-verify cycle afterwards with vulnerability and exposure management.

If the driver is PCI rather than assurance, the quarterly external scan is a separate obligation that only a listed Approved Scanning Vendor can attest. Nordstern holds that listing with global scope, certificate 50955001-01, and the scan has pass criteria of its own. For the wider budget conversation, what a PCI program costs is driven by scope above everything else. Talk to the team.

---

Sources

• PCI Security Standards Council, document library: PCI DSS v4.0.1, Requirement 11.4, and the Penetration Testing Guidance information supplement.
• NIST, SP 800-115, Technical Guide to Information Security Testing and Assessment: one of the industry-accepted approaches a methodology can be based on.