On this page
What information do you need for a penetration testing quote?
A penetration testing quote needs four things: which tests you want, how big each scope is, why you need the test and when it has to happen. Rough numbers are enough to start. We confirm exact counts during scoping, before the price is fixed.
This is what the form asks for, and why each answer changes your pen testing quote. For an external penetration testing quote, for example, the number of live public IP addresses is the main input.
| Test type | What we ask | Why it changes the quote |
|---|---|---|
| Web application | Number of applications, user roles, approximate size | Access control is tested separately for each role, and bigger applications have more functions and workflows to exercise |
| API | Endpoints, API style, whether documentation exists | Each endpoint and method is tested for authorisation and input handling; an OpenAPI file or Postman collection saves paid discovery time |
| External infrastructure | Live public IP addresses and exposed services | Every live host needs discovery and manual testing of what it exposes |
| Internal infrastructure | Hosts, sites, Active Directory, remote or on-site access | Larger networks and Active Directory attack-path analysis take longer, and on-site work adds travel |
| Cloud and Microsoft 365 | Providers and the number of accounts, subscriptions or tenants | Each account has its own identities, policies and services to review |
| Mobile app | Number of apps, iOS or Android, backend API | Each platform is tested separately, and a backend API adds its own scope |
| PCI segmentation | Segmentation boundaries around the cardholder data environment (CDE) | PCI DSS Requirement 11.4.5 needs each segmentation control shown to be effective |
How is a pen test quote calculated?
Almost every pen test quote is an estimate of tester-days multiplied by a day rate, including fixed-price packages. Your scope sets the number of days; the day rate reflects the seniority and specialism of the tester.
That is why the tool above shows effort, not a price. Two organisations asking for "a web application test" can need very different numbers of days, depending on roles, workflows and how much documentation they can share. Published UK day rates and price ranges by test type are in our penetration testing cost guide, and our guide to affordable penetration testing for small businesses explains how to right-size a scope on a tight budget.
Beyond asset counts, these choices move the number of days:
- Authenticated testing. Testing as logged-in users adds time, but it is where access-control and business-logic flaws show up.
- Documentation. Sharing architecture diagrams and API specifications means paid days go on testing rather than discovery.
- Testing windows. Out-of-hours or weekend-only testing, and fragile production systems, slow the work down.
- Location. Remote access through a VPN or a test device avoids on-site days for internal work.
- Compliance evidence. Mapping findings to PCI DSS, ISO 27001 or a customer's requirements adds reporting time.
How does the effort band work?
The tool adds up a simple planning rule for each test you choose, adds time for reporting and quality assurance, and places the total in one of four bands. The rules are deliberately rough. They show the size of engagement you are describing; they are not a quote and they do not set a price.
| Test | Rough rule used by the tool (tester-days) |
|---|---|
| Web application | 2, 4 or 6 days per application (small, medium or large), plus 0.5 days for each user role after the first |
| API | 1 day, plus 1 day per 25 endpoints, plus 0.5 days if there is no OpenAPI or Postman documentation |
| External infrastructure | 1 day, plus 1 day per 20 live public IP addresses |
| Internal infrastructure | 2 days, plus 1 day per 150 hosts (capped at 6 days), plus 0.5 days per extra site, plus 1.5 days if Active Directory is in scope |
| Cloud and Microsoft 365 | 2 days for the first account, subscription or tenant, plus 1 day for each extra one, plus 0.5 days for each extra provider |
| Mobile app | 2 days per platform per app, plus 1 day per app if its backend API is tested with it |
| Wireless | 1 day for the first site, plus 0.5 days per extra site |
| Social engineering | 1.5 days per channel (email, phone or physical) |
| PCI segmentation testing | 1 day, plus 0.5 days per segmentation boundary |
| Reporting and quality assurance | 1 day, plus 0.5 days per extra test type, plus 0.5 days for PCI DSS evidence mapping |
Each line is rounded to the nearest half day, and blank fields use a typical default. The range shown runs from about 20% below to 25% above the total. Up to 5 tester-days is a small engagement, up to 15 is medium, up to 30 is large, and anything bigger is a multi-phase programme.
Real scopes vary: a well-documented API may need less time than the rule suggests, and a complex multi-tenant platform more. Your proposal replaces this estimate with a scoped figure.
What happens after you request a quote?
We aim to reply within one working day, and we send a fixed-price proposal once the scope is confirmed. The steps are:
- We review your answers and reply, either with a few questions or to book a short scoping call.
- We confirm the scope: the exact targets, user roles, accounts and environments, and any standard the report must support.
- You receive a fixed-price proposal setting out the tests, tester-days, methodology, proposed dates, reporting and how retesting works.
- You authorise the test in writing, and we agree the rules of engagement, contacts, testing windows and any cloud provider requirements.
- We test and report, with an executive summary and a technical report your team and auditors can use.
Our checklist on how to prepare for a penetration test covers credentials, allow-listing and contacts, so no paid days are lost on the first morning.
How do you compare penetration testing quotes?
Compare quotes on the days allowed and what happens in them, not on the headline price. A very cheap quote can turn out to be an automated scan with a report template. The NCSC's penetration testing guidance is a good reference for what a real test should involve.
| Ask each provider | Why it matters |
|---|---|
| How many tester-days does the price allow? | This one number explains most of the gap between quotes |
| How much is manual testing rather than scanning? | Scanners miss access-control and business-logic flaws |
| Which methodology will you follow? | For web applications, look for the OWASP Web Security Testing Guide; PCI DSS Requirement 11.4.1 requires a defined methodology |
| Is authenticated testing included, and for which roles? | Many serious flaws only appear after login |
| Is a retest included, and within what window? | You need proof that fixes work, and PCI DSS Requirement 11.4.4 requires corrected exploitable findings to be retested |
| What does the report contain? | Look for an attack narrative, evidence and remediation advice, not a list of scanner output |
| Is the tester independent of what is being tested? | PCI DSS requires the tester to be organisationally independent of the systems under test |
Our guide to choosing a penetration testing company goes further, and how to read a penetration test report explains what good reporting looks like.
Can you quote PCI DSS, ISO 27001 and Cyber Essentials Plus work together?
Yes, but they are different things, so the form handles them differently.
- PCI DSS v4.0.1. Requirement 11.4 calls for internal (11.4.2) and external (11.4.3) penetration tests at least every 12 months and after significant change, retesting of corrected exploitable findings (11.4.4), and, where segmentation is used to reduce scope, segmentation testing every 12 months and after changes to segmentation controls (11.4.5), or every six months for service providers (11.4.6). We scope these together; see PCI DSS penetration testing. The standard is free from the PCI SSC document library.
- ISO/IEC 27001:2022. Annex A 8.8 (management of technical vulnerabilities) and 8.29 (security testing in development and acceptance) do not make penetration testing mandatory, but a regular test is a common way to evidence them. Our ISO 27001 consultancy can help you decide what to test.
- Cyber Essentials Plus. This is a certification audit by the certification body, not a penetration test. Tick it under "Also quote for", or go straight to our Cyber Essentials scoping questionnaire.
- PCI ASV scans. Quarterly external scans under Requirement 11.3.2 must be run by a PCI SSC Approved Scanning Vendor. We deliver them through an ASV partner; see ASV scanning.
Why Sovereign Secure?
Sovereign Secure Ltd (company no. 08334453, est. 2012, Accrington, Lancashire, UK) is a PCI SSC-approved Qualified Security Assessor (QSA), Qualified PIN Assessor (QPA), Card Production Security Assessor (CPSA), P2PE Assessor (Europe and USA) and 3DS Assessor company, a member of the PCI SSC Global Executive Assessor Roundtable 2026 to 2028, an IASME-licensed certification body for Cyber Essentials, IASME Cyber Assurance and Defence Cyber Certification Levels 0 and 1, and an ISO 27001-certified firm, with offices in Los Angeles, Singapore, Dubai and Dhaka.
As a QSA company we know what evidence an assessor expects from Requirement 11.4 testing. Our penetration testing services run from web applications, APIs and networks to hardware and IoT (including POS and PIN devices), AI and LLM applications and red team. Our clients include Accor, Fiserv, Ticketmaster and Cashplus.
Last reviewed October 2026 by the Sovereign Secure assessment team.
