Penetration Testing Cost: What Drives the Quote, and How to Budget for One

In summary

• Penetration testing cost is a day rate times scoped tester-days. There is no list price because there is no product — you are buying a named human being’s time, and the quote moves with IP count, application complexity and whether a remediation retest is bundled.
• Ask for the scope in tester-days before you ask for a figure. A quote you cannot decompose into days is a quote you cannot compare, and procurement will bounce it.
• The cheapest quotes are almost always an automated vulnerability scan reformatted as a “pen test”. Four questions expose it: tester credentials, methodology (OWASP WSTG or PTES), a redacted sample report, and whether the retest is included.
• Continuous scanning is a genuinely useful and far cheaper product — but it does not satisfy a manual-test requirement in a funder’s data security plan, a NHS DSPT return or a CMMC assessment. Do not substitute one for the other.
• Bitdefender GravityZone has no public list price and is quoted at checkout by endpoint count — verified 18 August 2026. We publish only prices read off a vendor’s own page, so we will not invent a figure for it or for any testing firm.

What each scope actually buys, and what moves the quote

Penetration testing pricing is expressed in tester-days. Use this to challenge a scope before you compare figures — a firm quoting three days for a 400-host internal network is not doing the same work as one quoting ten.

Dimension	Typical scoping unit	What pushes the quote up	Retest normally included?
External network	Live IP addresses and exposed services; usually the shortest engagement of the five	IP count, number of distinct hosting providers, VPN and remote-access endpoints, forgotten legacy subdomains from old project sites	Often, because the fix is usually a configuration change — confirm in writing
Internal network	Host count and number of VLANs or campus sites the tester must reach	Site visits versus a shipped testing appliance, Active Directory complexity, research VLANs and unmanaged lab instrumentation, segregated clinical networks	Less often — travel and rebuild time make it a separate line
Web application	Authenticated user roles and distinct functional areas, not page count	Number of roles to test as, file upload and payment flows, APIs behind the interface, participant or patient data in scope, whether a staging environment exists	Usually chargeable unless negotiated up front — this is the one to push on
Cloud configuration review	Subscriptions, tenancies or accounts reviewed	Number of accounts, IAM sprawl, storage buckets holding research data, multi-cloud estates, whether infrastructure-as-code is available to read	Commonly bundled, because re-reading a configuration is cheap
Social engineering	Target population size and number of pretexts run	Phishing only versus voice or physical access attempts, bespoke pretext research, ethics and HR sign-off time, whether results feed a training programme	Rarely — the honest follow-up is a training cycle, not a retest

Day counts are deliberately absent. Scoping conventions vary too much between firms and regions for a published range to be honest, and CASRAI prints only prices and figures it has read off a vendor’s own page. Ask three firms for the same scope in tester-days and you will have a real band for your institution within a week.

Why no vendor will publish a penetration testing price

It is tempting to read “contact us for pricing” as a sales tactic. Mostly it is not. A penetration test is a professional services engagement, and the only two variables that matter — the seniority of the tester and the number of days they spend — are both set after someone has looked at your estate. Publishing a figure would mean publishing a figure that is wrong for almost every buyer who reads it.

That has a practical consequence for you. The quote you eventually receive is not a price for “a pen test”. It is a day rate multiplied by scoped days, with a handful of modifiers bolted on: out-of-hours testing, travel to a second campus, a retest, an executive summary written for a board or a funder. If you can decompose a quote into those parts, you can compare three firms honestly. If you cannot, you are comparing a large number to a slightly smaller number and your procurement office will, quite correctly, ask you why.

So the first email you send is not “how much does a pen test cost”. It is a scoping request: here are our assets, here is what is in scope, please respond with the number of tester-days you propose, the seniority mix, and whether a remediation retest is included. Every serious firm will answer that. The ones that will not are telling you something.

What you are actually procuring

Research institutions typically buy one of three shapes. A compliance-driven test, where a funder, sponsor, insurer or framework such as CMMC or Cyber Essentials Plus requires an independent assessment on a defined cycle — scope is dictated by the requirement, and the cheapest compliant scope is the right one. An assurance test before a system goes live, usually a web application holding participant or patient data, where scope should follow the data rather than the codebase. And a red-team exercise, a considerably larger purchase most institutions should not attempt until they have run the first two for a couple of cycles. Getting that classification right before you request quotes is the single largest saving available to you.

A worked example for a grant budget justification or IT capital request

Finance and grants offices do not need a vendor name. They need a line item with a unit, a quantity and a justification that survives a reviewer. Because we will not invent a day rate, the worked example below is written as arithmetic you complete with the first quote you receive — which is exactly how a defensible budget justification should read anyway.

Take a mid-sized research group standing up a web application that collects participant data, hosted in a single cloud tenancy, with an internal network of a few hundred hosts across one campus. A realistic first-cycle programme is: a web application test scoped by user role, an external network test, and a cloud configuration review. Internal network testing and social engineering come in year two, once the obvious findings are closed.

The budget line

Write it as (quoted day rate × proposed tester-days) + retest + reporting, and then justify each multiplier:

• Day rate. Take the median of three quotes for identical scope. Note in the justification that rates vary by tester seniority and that you have specified a named senior tester rather than accepting a rate for unspecified staff.
• Tester-days. Quote the firm’s own scoping figure and the basis for it — number of authenticated roles for the application, live IP count for the external test, accounts reviewed for the cloud element. Reviewers accept scope expressed in countable units; they query scope expressed as “a pen test”.
• Retest. Budget for it explicitly even where a firm bundles it. A test that produces findings you cannot afford to have verified as fixed has bought you a document, not assurance. This is the line most often cut and most often regretted.
• Contingency for scope discovery. Institutional estates always contain more than the asset register says — a decade-old project site, a departmental server nobody claims. A stated contingency percentage is easy to justify and saves an embarrassing variation request mid-test.

Two further notes reviewers respond well to. State the cycle: an annual or biennial test with a retest is a programme, and programmes are fundable in a way that one-off purchases are not. And state what the test does not cover, and what covers it instead — continuous scanning, endpoint prevention, patch management. If patching is your weakest point, our patch management comparison is the cheaper half of that argument.

If the requirement driving all of this is a formal framework rather than a funder condition, cost the assessment alongside the test. Our breakdowns of SOC 2 compliance cost and CMMC compliance for research institutions set out how the testing line sits inside the larger programme, because in both cases the test is a small fraction of the total and budgeting it alone will leave you short.

The cheapest quote is usually a scan in a report cover

When three quotes come back and one is dramatically lower, the temptation is to treat it as a bargain and the professional instinct is to treat it as a red flag. The professional instinct is right more often than not, and the reason is specific: it is trivially easy to run an automated vulnerability scanner, export the findings, reformat them into a document with a logo on the front and sell it as a penetration test. The tooling costs the seller almost nothing and the output looks superficially similar to the real thing.

It is not the same thing, and the difference shows up precisely where it hurts. Automated scanners find known vulnerabilities in known software. They do not find business logic flaws — the ordering of steps that lets a participant view another participant’s record, the role that can escalate itself, the export endpoint that ignores the permission check applied to the interface. Those are the findings that matter in research systems, because they are the ones that turn into a data breach involving identifiable participant data, and they are found by a human being who understood what your application was for.

Four questions that separate the two

1. Who is testing, and what are their credentials? Ask for the named individuals and their certifications — CREST registrations, OSCP, CHECK team member or leader status where UK public sector work is in scope. “Our team is fully certified” is not an answer. A firm that will not name the tester before you sign is a firm that has not decided who is doing it.
2. What methodology? You want an explicit answer: the OWASP Web Security Testing Guide for applications, PTES or a comparable structured methodology for network work. A firm that cannot name its methodology in one sentence is running a tool and writing up whatever it prints.
3. Can we see a redacted sample report? This is the single most revealing request. A real report contains a narrative of the tester’s reasoning, evidence of exploitation, and remediation advice specific to your stack. A scan repackaged as a test contains a table of CVEs sorted by severity and generic vendor advice. You will know within thirty seconds which one you are holding.
4. Is a remediation retest included, and for how long after delivery? Retests are where cheap quotes recover their margin. Get the window in writing — a retest available for thirty days is worth much less than one available for ninety, because institutional change control does not move at thirty-day speed.

Add a fifth if participant, patient or otherwise regulated data is in scope: ask how test data is handled, where evidence is stored, and whether the firm will sign your data processing terms. In a clinical or human-subjects context that is not paperwork, it is a condition of the test being permissible at all.

Continuous scanning is cheaper, useful, and not a substitute

Here is the uncomfortable part, and the part vendors on both sides are motivated to blur. Continuous vulnerability scanning — an automated service that watches your external estate and tells you when something new appears or something known becomes exploitable — is genuinely valuable, materially cheaper than an annual manual engagement, and catches a class of problem a point-in-time test never will, because it is looking on the three hundred and sixty-four days the tester is not.

It also does not satisfy a manual-test requirement. If your funder’s data security plan, your framework assessment, your cyber insurance renewal or your institutional policy specifies an independent penetration test, a scanning subscription will not close that requirement, and presenting one as though it does creates a compliance problem worse than the one you were solving. Read the requirement literally. Where it says “penetration test” performed by an independent qualified tester, buy that. Where it says “vulnerability management” or “regular scanning”, the cheaper product is the correct product and you should not be paying day rates.

Do not buy a penetration test if…

Do not buy a penetration test if you already know what it will find and cannot yet fix it. If your estate has unpatched internet-facing servers, no endpoint protection on lab machines, and shared administrator credentials, a tester will spend your budget writing those up at length. You will receive an expensive document confirming what you already knew, and no capacity left to act on it. Spend the first year’s money on the fixes, then test to prove they worked. That sequencing is easy to defend to a funder and impossible to argue with technically.

Similarly, do not buy an internal network test the month before a major infrastructure migration, and do not buy an application test against an environment that will be substantially rewritten in the next quarter. A point-in-time assessment of a system that will not exist in that form is a point-in-time assessment of nothing.

What belongs in the budget instead, in that first year, is the unglamorous control layer: managed endpoint prevention, patching with an actual cadence, and staff who do not click the thing. Our guides to endpoint security for smaller institutional estates and security awareness training for staff cover the two that most reliably reduce the finding count on the test you eventually commission.

Where the quote is actually negotiable

Day rates move very little. Firms with real testers and real accreditation are competing for those testers against every other firm, and pushing hard on rate tends to buy you a more junior tester at the same price — the worst available outcome. Scope, sequencing and packaging move a great deal:

• Narrow the scope to the requirement. The most expensive quotes are scoped to an entire institutional estate when the driver covered one funded project.
• Split across financial years. External and application testing in year one, internal and social engineering in year two. Two smaller engagements are easier to fund than one large one, and year-one findings improve the year-two scope.
• Remote over on-site. Internal testing via a shipped appliance removes travel entirely, and for a single-campus estate the assurance difference is small.
• Commit to a cycle. A multi-year commitment is worth more to a firm than a discount request, and it removes an annual procurement exercise from your calendar.
• Prepare properly. An accurate asset register, working test accounts for every role on day one, and a named contact who answers the phone reduce the days a firm has to scope. Testers waiting for credentials are testers you are paying to wait.

You will look at Rapid7, Kroll, Cobalt and the regional CREST-accredited firms your peers use, and you should — sector familiarity is worth real money when the tester already understands research data flows, ethics approvals and why the instrumentation VLAN is like that. We publish no figures for any of them, because none publishes a rate card and we print only prices read off a vendor’s own page. Ask all of them for the same scope in tester-days; the comparison is meaningless until the unit is the same.

Cut the findings list before you pay someone to write it

Unmanaged endpoints and missing patches are the cheapest findings a penetration tester will ever bill you for — and you pay for them twice, once in the report and again in remediation. Bitdefender GravityZone is quoted at checkout by endpoint count, so you can get a real figure for your estate today rather than waiting on a scoping call, and it is a consistent top performer in independent AV-Comparatives and AV-TEST business endpoint testing. Verified 18 August 2026: no public list price is published, and we will not invent one.

Per-device annual licensing — see current offer

Get an endpoint-count quote Opens on the vendor’s site · CASRAI referral link

Frequently asked questions

How much does a pen test cost for a research institution?

There is no honest single figure, and any page that gives you one has invented it. Penetration testing cost is a day rate multiplied by scoped tester-days, and both halves depend on your estate: live IP count for an external test, authenticated user roles for an application test, host and site count for an internal test. The reliable way to get your number is to write one scoping document, send it to three accredited firms, and require each to respond with proposed tester-days, seniority mix and whether a remediation retest is included. You will have a defensible band within a week, and — more usefully — you will have three independent opinions on what your scope actually is, which is often where the real disagreement lies.

Why does every penetration testing pricing page say “contact us”?

Because there is no product to price. The firm is selling a specific person’s time, and the number of days that person needs cannot be known before someone has looked at your systems. It is the same reason a structural engineer will not publish a price for “a survey”. This is not, on its own, a warning sign. The warning sign is a firm that will not decompose its quote into days and rates after scoping — that usually means the figure was not built from days in the first place.

Is a cheap pen test quote ever legitimate?

Sometimes. A genuinely narrow scope or a smaller regional firm with lower overheads can produce a lower figure for real work. What is almost never legitimate is a low figure for a broad scope, because the arithmetic does not permit it — the days simply are not there. Apply the four questions: named testers with verifiable credentials, a stated methodology such as the OWASP Web Security Testing Guide or PTES, a redacted sample report, and a written retest window. A cheap quote that answers all four convincingly is a bargain; one that deflects on any of them is an automated scan with a cover page.

Does continuous vulnerability scanning satisfy a penetration testing requirement?

No, and this is the most common and most expensive misunderstanding in this purchase. Continuous scanning is a different product: automated, far cheaper, and valuable precisely because it runs on the days a tester does not. But where a funder’s data security plan, a framework assessment or an insurance renewal specifies an independent penetration test performed by a qualified tester, a scanning subscription does not close that requirement. Read the wording literally. Where it says scanning or vulnerability management, buy the cheaper product and stop. Where it says penetration test, buy the test — and run scanning alongside it, because they answer different questions.

What should we spend the money on if we cannot afford a full test this year?

The controls that determine what the test would have found. In descending order of value for most institutional estates: managed endpoint prevention across staff laptops, lab workstations and servers; a patching cadence that actually happens; multi-factor authentication everywhere it will fit; and staff training aimed at the phishing pretexts your sector actually receives. Bitdefender GravityZone is where we would start on the endpoint side — it is quoted at checkout by endpoint count rather than published as a list price, so you can size it against your own estate in minutes, and it is a consistent top performer in independent AV-Comparatives and AV-TEST business endpoint testing. Verified 18 August 2026. Do that for a year, then commission the test to prove it worked; the report will be shorter and the retest cheaper.

Should the remediation retest be included in the quote?

Push for it, and budget for it either way. A test that produces twenty findings and no mechanism to verify the fixes has bought you a document rather than assurance, and auditors increasingly ask for evidence of closure rather than evidence of testing. The window matters more than the inclusion: a retest available for thirty days after delivery is worth much less than one available for ninety, because institutional change control does not move at thirty-day speed. Cloud configuration reviews are commonly bundled with a retest; application retests are most often charged separately and are the ones most worth negotiating up front.

How often do we need to repeat it?

Follow the requirement first — many frameworks and funder conditions specify annually, or after any significant change, and that wording is the whole answer where it exists. Where nothing specifies a cycle, the useful trigger is change rather than the calendar: a new system holding participant or patient data, a significant architectural change, a migration between cloud providers, or a merger that brings an unfamiliar estate into scope. An annual external test with application testing triggered by releases is a defensible default for most research institutions, and it costs less over three years than the reactive testing that follows an incident.

Related on CASRAI

• SOC 2 compliance cost, broken down
• CMMC compliance for research institutions
• Best endpoint security for smaller institutional estates
• Security awareness training for staff
• EDR vs antivirus: what the difference actually buys
• All software reviewed by CASRAI