Penetration Testing Cost: What Drives the Price and How to Scope It

Penetration testing cost comes down to scope, depth, and deliverables, not a flat rate. Two quotes for the "same" test can describe very different work, and that gap is where most budget surprises start. This guide explains what moves the price, how to write a scope that gets comparable quotes, and which red flags to watch for.

What Is Included in Penetration Testing Cost?

A penetration test is a time-boxed engagement where a qualified person tries to break into your systems, the way an attacker would, and then reports what they found. You are paying for tester hours, tester skill, and the report. Everything else follows from those three things.

Most of the penetration testing cost sits in a few places:

• Planning and scoping: confirming targets, access, and rules of engagement.
• Testing time: the manual work of probing, exploiting, and verifying findings.
• Reporting: writing findings so engineers can fix them and auditors can read them.
• Retest: checking that fixes actually worked.
• Project management: scheduling, communication, and live updates on critical issues.

Ask every provider how many tester days their quote assumes. That one question exposes the real difference between quotes faster than any price comparison. A short test by a junior tester and a long test by a senior one are different products, even if the proposals look alike.

For the basics of how a penetration test differs from a broader assessment, see VAPT vs penetration test.

Test Type: The First Driver of Penetration Testing Cost

Each type of test targets a different part of your environment, and each takes different skills and time. Most compliance-driven teams need more than one.

Network Penetration Testing

Network penetration testing looks at your infrastructure: servers, firewalls, VPNs, and exposed services.

• External network testing attacks what the internet can see. It is usually the quickest to scope because it depends mostly on how many public IP addresses and services you have.
• Internal network testing assumes an attacker already has a foothold, such as a stolen laptop or a phished employee. It takes longer because there is more to explore once inside.

Web Application and API Testing

This is the test most SaaS companies care about, and it is what buyers usually mean by web security testing. A tester logs in to your product and tries to break authorization, abuse business logic, and reach other customers' data. Cost rises with the number of distinct features, user roles, and API endpoints. An application with three roles and a large API takes much longer than a simple one with a single role.

Mobile and Cloud Configuration Review

Mobile testing covers the app itself plus how it talks to your back end. Cloud configuration review checks settings in AWS, Azure, or Google Cloud for risky permissions and exposed storage. Both add work, and both are often bundled into a single engagement to save setup time.

Scope Size and Complexity

Scope is the biggest single lever on penetration testing cost. Tester time grows with every item you add.

Here is what usually counts toward scope:

• Applications and APIs: each one is its own body of work.
• User roles: an admin, a standard user, and a read-only user each need testing.
• IP addresses and hosts: more targets mean more time, especially internally.
• Integrations: payment flows, single sign-on, and third-party connections.
• Environments: testing staging as well as production, or several regions.

Write the scope down before you ask for quotes. List each application, how many roles it has, the number of public IPs, and any systems that are off limits. A vague request ("test our platform") is the main reason quotes come back far apart.

Scope also connects to compliance. If you handle payment card data, your scope must cover the whole cardholder data environment. For a PCI DSS test, that includes the connected and security-impacting systems, and you should confirm the boundary with your assessor first. See our PCI DSS compliance guide for how to define that boundary.

Scanner vs Manual Pen Test: Where the Money Goes

This is the most important section for understanding penetration testing cost. Many low quotes are really vulnerability scans with a new label.

What Pen Test Software and Scanners Do

Pen test software and VAPT tools run automated checks against known weaknesses. They are fast, repeatable, and good for broad coverage. Some are free to download, and some come as subscription platforms. They are a sensible part of ongoing security hygiene.

What Scanners Cannot Do

A scanner cannot reason about your business. It will not notice that a user can change an invoice ID and read another customer's invoice. It cannot chain two small issues into a serious breach. It also produces false positives that someone must sort out.

The PCI Security Standards Council's penetration testing guidance is direct on this point. It says that simply running an automated tool does not satisfy the penetration testing requirement, because the tester must interpret the results and decide what further testing is needed. It describes a penetration test as a manual process that may use scanning and other automated tools, ending in a comprehensive report.

How This Affects Price

A scan costs little because it takes little human time. A manual test costs more because experienced people spend days thinking like an attacker. Neither is wrong. The mistake is paying for one and expecting the other, or handing an auditor a scan report when they asked for a penetration test.

A Note on a Free Pen Test

Searching for a free pen test or a free download will turn up scanners and open-source tools. These are useful for learning and for your own routine checks. They do not give you an independent report that an auditor will accept, and they do not replace a tester's judgment.

Black Box, Grey Box, and White Box Testing

How much information you give the tester changes how efficiently they use their time.

• Black box: the tester starts with almost nothing, like an outside attacker. It is realistic but spends a lot of time on discovery.
• Grey box: the tester gets test accounts and basic documentation. This is the most common choice for SaaS because it focuses effort on the product itself.
• White box: the tester gets source code and architecture details. It finds deeper issues but takes more skilled review time.

For most compliance tests, grey box gives the best return. You pay for testing, not for the tester guessing at your login flow. If a provider recommends black box only, ask why.

Manual Depth and Tester Experience

Depth is what separates a checkbox test from a useful one. Ask how the hours are split between automated tooling and hands-on work.

A strong provider can explain:

• Who does the testing, and what their experience and credentials are.
• How much of the engagement is manual exploitation versus tooling.
• What methodology they follow (for example, OWASP guidance for web applications).

Tester credentials also matter to your assessor. The PCI Council's guidance says the tester should be qualified, and it lists certifications and relevant experience as ways to judge that. Senior testers cost more per day, but they find more and write clearer reports. You are paying for judgment, which is the part a tool cannot supply.

Report Quality and the Attestation Letter

The report is the deliverable your customers and auditors actually see. It is a major part of the value, and quality varies widely.

A compliance-ready deliverable usually includes:

• An executive summary a non-technical reader can follow.
• A clear scope and methodology section, so an auditor can see what was and was not tested.
• Findings with severity ratings, evidence, and fix guidance.
• A dated record showing when testing took place.
• A letter of attestation you can share with customers who ask for proof.

Many SaaS buyers send security questionnaires and ask for the summary or letter. If your provider only hands over a raw findings export, you may end up rewriting it yourself. Ask to see a sample report, with client details removed, before you sign.

Retesting and Remediation Verification

Finding issues is only half of the job. You also need to show they were fixed.

PCI DSS v4.0.1 Requirement 11.4.4 says exploitable vulnerabilities and security weaknesses found during penetration testing are corrected, and that penetration testing is repeated to verify the corrections. For SOC 2, auditors want to see that you acted on findings, so a clean retest is strong evidence.

This is why retest terms affect penetration testing cost. Some quotes include one retest within a set window. Others charge extra for every retest, or exclude it entirely. Ask:

• Is a retest included, and for how long after the report?
• Does it cover all findings or only high and critical ones?
• Do I get an updated report that shows the fixes?

A quote that leaves out the retest can look cheaper on paper and then cost more once your team has fixes ready to verify.

Timing, Urgency, and Scheduling

Calendar pressure shapes price. Good testers book out in advance, especially around audit season. If your SOC 2 observation window or PCI assessment is close, a rushed engagement can mean limited availability and fewer choices.

Plan the test early enough to leave time for fixes and a retest before your auditor needs evidence. For a Type II SOC 2 report, the test should fall inside the observation window. Book the test, wait for the report, fix findings, retest, and only then hand the evidence over. That sequence takes weeks, not days.

How Often Do You Need a Penetration Test?

For the compliance frameworks most SaaS teams face, the answer is at least yearly, plus after major changes.

• PCI DSS v4.0.1: Requirements 11.4.2 (internal) and 11.4.3 (external) require penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change. The tester must be a qualified internal resource or a qualified external third party with organizational independence. The tester does not have to be a QSA (Qualified Security Assessor) or ASV (Approved Scanning Vendor).
• SOC 2: The AICPA Trust Services Criteria do not name penetration testing, but auditors commonly expect an annual test as evidence for vulnerability management and monitoring. Our guide to SOC 2 penetration testing covers what auditors look for and how to time the test.

If you ship large changes often, budget for a test after major releases, not just one per year. Ask your auditor or assessor what "significant change" means for your product.

How to Get an Accurate Quote

You can get comparable quotes if you give every provider the same information. Use this short checklist.

1. Write a scope document. List applications, APIs, roles, public IPs, and cloud accounts.
2. State your driver. Say whether the test is for SOC 2, PCI DSS, a customer request, or internal assurance.
3. Choose the test approach. Grey box is usually the right default for SaaS.
4. Define the deliverables. Ask for the full report, an executive summary, and an attestation letter.
5. Set retest expectations. Say you want fixes verified.
6. Share your deadline. Give the audit date so the provider can plan.

Then ask each provider the same follow-up questions about tester experience, manual versus automated effort, and sample reports. When the inputs match, differences in the quotes tell you something real. Expect a good provider to ask you questions first, because they cannot price work they do not understand.

Red Flags in a Cheap Quote

A low number is not always a bargain. Watch for these signs that the penetration testing cost is low because the work is thin.

• A price with no scoping call. Real scoping takes questions.
• No tester days stated. If they cannot say how long the test takes, they may not know.
• Scanner output sold as a pen test. Ask whether findings are manually verified.
• No retest. Or a retest that costs extra and is not mentioned up front.
• No sample report. You cannot judge quality without seeing one.
• Vague credentials. They will not say who will test or what their experience is.
• Guaranteed "pass" language. An honest tester reports what they find. A guarantee suggests the findings will be softened.
• No independence. For PCI DSS, the tester needs organizational independence from the systems being tested.

If a quote makes you ask "how can they do that for this price?", ask them exactly that. A good answer explains the scope. A poor answer reveals the shortcut.

Where VAPT Fits

VAPT stands for vulnerability assessment and penetration testing. It pairs regular scanning for breadth with an annual manual test for depth, which is the pattern auditors expect. Our VAPT service is scoped by framework, so your report maps to what your auditor needs.

For the service overview, see our VAPT service page. To understand what auditors expect, read SOC 2 penetration testing and VAPT vs penetration test. For framework context, see our SOC 2 and PCI DSS pages.

Frequently Asked Questions

How much does a penetration test cost? It depends on scope, test type, manual depth, retest terms, and report quality. A single external test of one application is a smaller job than a multi-application test with several roles and cloud review. Send every provider the same written scope and compare what each one includes. A provider who gives a number without asking about scope has not scoped the work.

Why do penetration test quotes vary so much? Because they often describe different work. One quote may be an automated scan with a short summary, while another is a manual test by a senior tester with a full report and a retest. Line quotes up against the same scope and ask what is manual and what is automated.

Does a penetration test have to be done every year? For most compliance programs, yes, plus after major changes. PCI DSS v4.0.1 Requirements 11.4.2 and 11.4.3 call for testing at least once every 12 months and after any significant change. SOC 2 does not name penetration testing, but auditors commonly expect an annual test. Confirm timing with your auditor or assessor.

Can a vulnerability scanner replace a penetration test? No. A scanner finds known weaknesses automatically but cannot judge how they chain together. The PCI Council's guidance says running an automated tool alone does not satisfy the penetration testing requirement. Use scanners for ongoing coverage and a qualified tester for the annual test.

Ready to Scope Your Penetration Test?

ShieldKey Solutions scopes penetration tests around your compliance framework, with a clear statement of what is tested, what is manual, and what the report will contain. Bring your SOC 2 or PCI DSS deadline and we will help you define the scope before you commit to a quote.

Schedule a scoping call →