How much does a penetration test cost?

Cost depends mainly on scope, complexity, testing approach, depth, and tester expertise. Small, simple scopes need a few tester days, while large applications, internal networks, or red team exercises need weeks. Request quotes from several providers using the same written scope.

Why do penetration testing quotes vary so much?

Providers estimate different amounts of testing time and use different balances of manual and automated work. Very low quotes often reflect mostly automated scanning, which misses business logic and access control flaws.

How long does a penetration test take?

A small scope may take a few days, a medium web application with an API one to two weeks, and large platforms or red team exercises several weeks, plus time for reporting and retesting.

How often should we do penetration testing?

At least annually for many organisations, and after significant changes such as new applications, major features, cloud migrations, or authentication changes. Compliance requirements may specify a frequency.

Is a vulnerability scan the same as a penetration test?

No. A scan automatically checks for known issues, while a penetration test uses skilled manual work to confirm, chain, and exploit weaknesses, including business logic flaws that scanners cannot detect.

Penetration Testing Cost: Pricing Factors & Test Types

Key takeaways

Penetration testing cost is driven mainly by scope, complexity, testing depth, and the experience of the testers, not by a fixed price per test.
Web applications, APIs, mobile apps, internal and external networks, cloud environments, and social engineering each require different effort.
Clear scoping, including roles, environments, and integrations, produces accurate quotes and avoids surprises.
Very cheap tests often amount to automated scans with a report; real penetration testing relies on skilled manual work.
The value of a test comes from fixing the findings, retesting, and learning from the results, not from the report alone.

Penetration testing, often called pen testing, is an authorised simulated attack on your systems by security professionals who try to find and exploit weaknesses before real attackers do. It is required or expected by many compliance frameworks, customers, and insurers, and it is one of the most effective ways to understand how exposed your applications and infrastructure really are. One of the first questions organisations ask is how much it costs. The honest answer is that it depends on what is tested and how deeply. This guide explains the factors behind pricing so you can budget accurately, compare proposals fairly, and get real value from the investment.

What penetration testing is, and what it is not

A penetration test goes beyond automated scanning. A vulnerability scanner checks systems for known issues, such as missing patches or common misconfigurations, and produces a list of potential problems. A penetration tester uses scanners as a starting point but then manually investigates, confirms which issues are real, chains weaknesses together, tests business logic, and demonstrates what an attacker could actually achieve, such as accessing another customer's data or gaining administrative control. Our comparison of vulnerability assessment vs penetration testing explains the difference in detail. Both are valuable: regular scanning provides broad, frequent coverage, while penetration testing provides depth and realistic evidence of risk.

Types of penetration tests

Test type	What is tested	Typical effort drivers
Web application	Authentication, authorisation, session management, input handling, business logic, and data exposure in web apps	Number of pages, features, user roles, and integrations
API	REST, GraphQL, or other APIs for access control, injection, data exposure, and rate limiting	Number of endpoints, authentication methods, documentation quality
Mobile application	iOS and Android apps, local data storage, communication, and backend APIs	Number of platforms, app complexity, backend scope
External network	Internet-facing systems such as firewalls, VPNs, mail servers, and exposed services	Number of IP addresses and services
Internal network	What an attacker with internal access, or a compromised device, could reach, including Active Directory	Network size, number of sites, directory complexity
Cloud	Configuration, identity and access management, storage, and workloads in AWS, Azure, or Google Cloud	Number of accounts or subscriptions, services, and environments
Wireless	Wi-Fi security, segmentation, and rogue access points	Number of locations and networks
Social engineering	Staff susceptibility to phishing, phone pretexting, or physical intrusion	Number of employees, campaigns, and locations
Red team exercise	Goal-based, multi-vector simulation of a real adversary over an extended period	Objectives, duration, and rules of engagement

What drives penetration testing cost

Scope and size. The number of applications, endpoints, IP addresses, cloud accounts, or employees in scope is the biggest driver. A small marketing website with a contact form needs far less effort than a multi-tenant SaaS platform with dozens of features.

Complexity. Multiple user roles, complex workflows, payment flows, file uploads, integrations with third-party services, and custom authentication all add testing time, because each must be examined for authorisation and logic flaws.

Testing approach. In black box testing, testers have no prior knowledge, simulating an outside attacker but spending time on discovery. In grey box testing, they receive credentials and some documentation, which is usually the most efficient approach for applications. In white box testing, they also review source code or architecture, providing the deepest coverage at higher effort.

Depth and duration. A short test may cover only the most common vulnerability classes, while a thorough test examines every role and feature. Most providers estimate effort in tester days, and the total price follows from that estimate.

Tester expertise. Experienced testers with relevant certifications and specialist skills, for example in cloud, mobile, or industrial systems, command higher rates but often find more serious issues in less time.

Compliance and reporting requirements. Tests that must satisfy specific standards, such as PCI DSS, or produce reports for auditors and customers, may require particular methodologies, documentation, and attestation letters.

Retesting. Verifying that fixes are effective takes additional time. Some providers include one retest; others charge separately.

Logistics. On-site testing, testing outside business hours to avoid disrupting operations, and urgent timelines can increase cost.

Common pricing models

Fixed price per engagement. The provider scopes the work, estimates the effort, and quotes a fixed price. This is the most common model and gives budget certainty, provided the scope is clear.

Day rate. The client buys a number of tester days. This is flexible but requires trust that the days are used effectively.

Subscription or retainer. Organisations that release frequently may buy an annual programme with several tests, continuous scanning, and on-demand retests, often at a lower effective cost per test.

Penetration testing as a service (PTaaS). Platforms combine manual testing with a portal for real-time findings, collaboration with testers, and retesting. They suit teams that want ongoing visibility rather than a single annual report.

Bug bounty programmes complement, rather than replace, penetration testing. They pay independent researchers per valid finding and provide continuous coverage, but they offer less predictable scope and coverage than a structured test.

Relative cost by scope

Exact prices vary widely by region, provider, and market conditions, so it is more useful to understand relative effort. The table below shows how scope typically affects the number of tester days required.

Scope	Relative effort	Notes
Small brochure website or single simple app	Low (a few tester days)	Limited functionality and one or two roles
Small external network	Low	Handful of internet-facing IP addresses
Medium web application with API	Moderate (one to two weeks)	Several roles, integrations, and business workflows
Mobile app with backend API	Moderate	Each platform adds effort
Cloud environment review and testing	Moderate to high	Depends on accounts, services, and identity complexity
Large SaaS platform or multiple applications	High (several weeks)	Multi-tenancy, many features, complex permissions
Internal network and Active Directory	Moderate to high	Grows with network size and number of sites
Red team exercise	Very high	Extended, objective-based, multiple attack vectors

Request quotes from several providers using the same written scope; this is the most reliable way to understand current market pricing for your specific needs.

How to scope a test accurately

A clear scope gives you accurate quotes and focuses testing where risk is greatest. Prepare the following information before contacting providers:

The applications, APIs, domains, IP ranges, cloud accounts, or locations to be tested, and anything explicitly out of scope.
For applications, the main features, number of user roles, authentication method, and integrations such as payment providers.
The environment to be tested: production, staging, or a dedicated test environment with representative data.
The testing approach you prefer, such as grey box with test accounts for each role.
Compliance or customer requirements the test must satisfy.
Preferred timing, testing windows, and any systems that are sensitive to disruption.
Contacts for technical questions and for emergencies during testing.

Testing in a staging environment that closely mirrors production is often safer and allows more aggressive testing, but differences between environments must be understood, and some checks, such as external network exposure, are best performed against production with appropriate care.

What a good proposal and report include

A good proposal states the scope, methodology, testing approach, estimated effort, timeline, deliverables, retest terms, and rules of engagement, including how testers will avoid disruption and how critical findings will be communicated immediately. Methodologies often reference recognised standards such as the OWASP Web Security Testing Guide, the OWASP Mobile Application Security Testing Guide, PTES, or NIST SP 800-115.

A good report contains an executive summary for leadership in plain language, a description of scope and methodology, and detailed findings. Each finding should include a severity rating, often based on CVSS adjusted for business context, a clear description, evidence such as screenshots or requests, the affected components, the potential business impact, and specific remediation guidance. Reports should also mention positive observations and areas that were tested without finding issues, so you understand the coverage. Be wary of reports that are mainly exported scanner output with little explanation or confirmation.

Comparing penetration testing providers

Manual testing depth: ask how much of the engagement is manual testing versus automated scanning.
Tester experience: ask who will perform the test, their experience with similar systems, and relevant certifications such as OSCP, OSWE, CREST, or equivalent.
Sample report: request a redacted example to judge clarity and quality.
Retesting: confirm whether retests are included and within what timeframe.
Communication: confirm how critical findings are escalated during testing and whether testers are available to discuss remediation.
Insurance and legal terms: confirm professional liability insurance, confidentiality, data handling, and written authorisation.

The cheapest quote is rarely the best value. A low price often reflects less testing time or a mostly automated approach, which can miss the business logic and access control flaws that cause real breaches.

How often should you test?

Many organisations run a penetration test at least annually and after significant changes, such as launching a new application, adding major features, migrating to the cloud, or changing authentication. Compliance frameworks and customer contracts may set specific frequencies. Teams that release frequently benefit from integrating security into development, with secure coding practices, automated security testing in pipelines, and targeted tests of major releases, rather than relying only on an annual test. Our guide to application security and the secure SDLC explains how to build that capability.

Getting the most value from a penetration test

Prepare the environment. Provide working test accounts for each role, documentation, and a stable environment, so testers spend time testing rather than troubleshooting access.

Fix before you test. Run vulnerability scans and fix known issues first, so the test focuses on deeper problems.

Prioritise remediation. Fix critical and high findings promptly, assign owners and deadlines for every finding, and track them to closure.

Address root causes. If testers find several access control issues, review how authorisation is implemented across the application rather than patching only the reported endpoints.

Retest and document. Confirm fixes with a retest and keep records for auditors and customers.

Share learning. Walk developers through the findings, because understanding how an attack works prevents similar issues in future code.

Penetration testing and compliance

Penetration testing supports many compliance and assurance requirements. PCI DSS requires regular penetration testing for environments that handle card data. SOC 2 and ISO 27001 audits commonly expect evidence of security testing as part of risk management. Many enterprise customers ask suppliers for recent test reports or attestation letters during procurement, and cyber insurers increasingly ask about testing practices. Check the specific requirements that apply to you, such as frequency, scope, and tester independence, so the test satisfies them first time. Our cybersecurity services guide covers how testing fits into a broader security programme.

Example: A growing SaaS company needed a penetration test for an enterprise customer's security review. Its first quote was very low, but the sample report showed mostly automated scanner output. A second provider proposed a grey box test of the web application and API with test accounts for each of four roles, plus a cloud configuration review. The test found a serious authorisation flaw that let users of one tenant view another tenant's invoices by changing an identifier, an issue no scanner had detected. The company fixed it across all endpoints, passed the retest, and shared the attestation letter with the customer, closing the deal.

Test your security with Vertex Cyber Tech

We provide manual, expert-led penetration testing for web applications, APIs, mobile apps, networks, and cloud environments, with clear reports, remediation support, and retesting. Explore our cybersecurity services and cloud services, or book a consultation to scope your test. For blockchain systems, see our smart contract audit guide, and for network architecture, our zero trust security guide.

Related guides: for practical next steps, read our website penetration testing guide, our API security testing guide and our cybersecurity and website security audit guide.

Penetration Testing Cost: Pricing Factors, Test Types, and How to Get Real Value