Penetration testing cost starts with the scope you can defend
Penetration testing cost follows the written scope, the depth of manual testing and the deliverables you need, not a fixed price list. If a framework, a customer security review, a launch or an insurer requires a penetration test, the budget question cannot be answered until the targets, the environments, the testing approach and the report requirements are defined in writing. DeployOpen does not publish prices. We quote from a written scope, so the most useful thing you can bring to a budget conversation is a clear statement of what must be tested and why.
Organizations commission penetration tests for specific reasons. PCI DSS requires internal and external penetration tests, CIS Controls Safeguard 18.2 asks for periodic external tests, and customers increasingly ask for evidence before they sign. The underlying risk is also concrete. The PCI SSC guidance draws a clear line between vulnerability scans, which identify and rank weaknesses mostly through automated tools, and penetration tests, a mainly manual process that exploits vulnerabilities to defeat security features. A scan tells you what might be wrong. A penetration test tells you what an attacker could actually reach, and that manual depth is a major reason the work takes the time it does.
Before you ask for a quote, confirm three things: which systems and accounts are in the boundary, which framework or customer requirement defines the deliverable, and whether you need a retest included. Ask the provider to show how the price maps to targets, testing hours, reporting and retesting, and whether the figure covers one test or an ongoing arrangement. Those answers determine what you are actually buying.
Which scope decisions move the price
Price follows effort, and effort follows what is in scope. NIST SP 800-115 places rules of engagement and goals in the planning phase, before any testing occurs, so most of the cost logic is settled when the scope is written. The cards below cover the decisions that change the amount of tester time, the number of environments and the amount of coordination a client should expect to pay for.
Number and type of targets
Each target type brings its own test method. An external network range, an internal segment, a web application, an API set, a cloud account, an Active Directory forest and an AI application each need different tooling and manual work. Ask the provider to list every target with its type, count and owner, and to state which targets are priced individually and which are grouped. Adding a target after signature usually changes the quote.
Production versus staging environments
Testing a production system needs tighter testing windows, extra care to avoid disruption and sometimes a rollback plan, which adds planning time. Testing a staging copy is usually cheaper but may miss configuration differences that matter. Ask whether the quote assumes production, staging or both, and whether the staging build matches production in configuration, data and integrations.
User accounts and roles
Each role an application or directory exposes, such as anonymous, standard user, administrator or service account, adds authorization checks the tester must work through. A grey-box test with two roles costs less than a test that must cover every role and tenant boundary. Ask the client to list roles up front and the provider to state how many accounts it will use and who creates them.
Exclusions and third-party systems
Systems the client does not own or control, such as a hosted SaaS tenant, a payment processor or a shared cloud service, may need separate permission or be excluded entirely. Each exclusion narrows the work, but a gap left by an exclusion can also limit the value of the report. Confirm in writing who authorizes testing of third-party components and what the report will say about them.
Testing windows and rules of engagement
Business hours, change freezes, maintenance windows and notification rules affect how many hours a tester can work and how the team plans. The rules of engagement document, which NIST SP 800-115 provides as a template in Appendix B, records these limits, emergency contacts and stop conditions. Ask for the rules of engagement to be agreed before work starts, and ask how out-of-window work is priced.
How a priced penetration test moves from quote to retest
The sequence shows how a quote becomes a bounded engagement, how each phase produces a checkable output, and how fixes are verified without paying for work that was never scoped.
Agree the written scope and rules of engagement
The client and DeployOpen agree targets, environments, test accounts, exclusions, testing windows and the knowledge level (black, grey or white box) in writing. NIST SP 800-115 places this in its planning phase, where rules are identified, management approval is finalized and documented, and testing goals are set, with no testing occurring yet. The quote is tied to this document, so the signed scope and rules of engagement are the output that closes this step.
Confirm access and information handover
The client provides the information the agreed knowledge level requires, such as architecture notes, credentials for test accounts or source access, and named contacts for emergencies. DeployOpen checks that every in-scope system can be reached as described and records any gaps. Costs here are mostly internal time on the client side, and they grow when access arrives late or in pieces. The step closes when both parties confirm, in writing, that the environment matches the scope.
Run discovery and enumeration
Testers map the in-scope assets, services, roles and trust relationships, and compare what they find against the agreed scope. NIST SP 800-115 describes discovery as the phase where testers gather information about the target and identify potential weaknesses. If discovery shows that the real estate is larger than the scope assumed, the change is raised with the client before any further testing, and it is priced as a change request. The step closes with an agreed list of testable targets.
Perform manual attack testing
Testers attempt to exploit the weaknesses found in discovery to test whether security features can be defeated, following the agreed methodology and testing windows. PCI SSC's guidance describes penetration testing as a mainly manual process that exploits vulnerabilities to defeat security features, and notes that it may last days or weeks depending on scope. Most of the labor cost sits in this step, so the depth of manual work is the main driver of the quote. The step closes when every in-scope target has been tested or a documented limitation explains why it was not.
Document findings and limitations in a draft report
Testers record each finding with evidence, affected assets, severity reasoning and remediation advice, and state the methodology, tools and limitations. PCI SSC's suggested outline includes an executive summary, statement of scope, statement of methodology, statement of limitations and findings with references such as CVE and CWE. The client reviews the draft for factual accuracy, and DeployOpen corrects it without changing the findings. The closed output is a final report that matches the scope document.
Walk through findings and agree remediation priorities
The client's engineering and security leads review the findings with the testers, ask questions about reproduction and business impact, and set remediation priorities according to their own risk ranking. This is also where the client decides whether a finding is accepted, mitigated or fixed. The step closes with a remediation plan that names owners and the retest scope. Where the client asks for work beyond the original findings, that work is quoted separately.
Retest after remediation
Once fixes are in place, testers repeat the relevant tests to confirm that the new controls address the original risk. PCI SSC's guidance says the tester should retest after remediation is complete, and PCI DSS requirement 11.4.4 requires exploitable vulnerabilities to be corrected and penetration testing repeated to verify the corrections. A retest is usually priced on the number of findings and the systems affected, so it is quoted separately from the original test. The step closes with a retest report that marks each finding as closed, open or partly mitigated.
Decide whether a new engagement is needed
If remediation runs long after the original test, or the environment changes significantly, the earlier results may no longer describe the system. PCI SSC's guidance says remediation extending long after the original test may require a new engagement. The client and DeployOpen review the timeline and the changes, then agree whether to retest, extend or start a new scope. The step closes with a written decision that the client can file with its auditor or customer.
How black, grey and white box testing change the bill
The knowledge level you give a tester is one of the largest levers on both cost and output, and it should be chosen for a reason rather than to lower a quote. PCI SSC's *Penetration Testing Guidance* defines black-box testing as work done with no information provided, white-box testing as work done with full details of the network and applications, and grey-box testing as work done with partial details. The same guidance states that a black-box assessment may require more time, money and resources for its deliverables to meet PCI DSS requirements, and that PCI DSS tests are typically white-box or grey-box because they produce more accurate and comprehensive results. The cost difference comes mostly from the time a tester spends on discovery before any exploitation work starts, so a black-box quote that looks cheaper may simply cover less ground.
The trade-off is realism against coverage. Black-box work shows what an outsider could reach with no help, which can be useful for a question such as how exposed the external perimeter is, but a tester who spends hours finding hosts and guessing account names will test fewer application paths in the same window. Grey-box work, where the tester receives a standard user account, architecture notes or API documentation, usually reaches authenticated functions, role boundaries and business logic that an outsider would never see first. White-box work gives the most coverage per day, which suits a deep review before launch, though it tests less of what an attacker would actually encounter. Ask the provider to state which knowledge level its quote assumes, how many accounts and roles are included, and what changes in price if you move one level.
Before you accept a quote, confirm three things: the knowledge level in the written scope, the information you will supply and who prepares it, and whether any credentials or documents are counted in the effort. Your auditor or customer may also specify the level, so check the framework or contract first. For example, an illustrative external-facing payment API might need a grey-box test with two customer roles and an administrator role, which is a different effort profile from a black-box test of the same domain. Record the chosen level and the reason in the scope document so the report's limitations section can state it plainly.
What drives penetration testing cost and duration
This table lists the main factors that change the tester's time and the cost of tools and reporting, and explains why each one moves the quote. Use it to see which parts of your request add effort and which ones you can narrow before asking for a price. Quotes follow from a written scope, so the clearer your targets and goals, the easier it is to compare proposals on equal terms.
| Cost driver | Why it changes effort | How to scope efficiently |
|---|---|---|
| Number and complexity of targets | Each host, application, API or cloud account adds discovery, manual testing and write-up time, and complex authentication or workflows take longer to exercise properly. | Inventory targets by business function, separate in-scope from out-of-scope assets, and ask the provider to price each target group separately. |
| Test type and depth of manual work | A mainly automated scan takes minutes per host, while a manual penetration test exploits weaknesses to defeat controls and may last days or weeks depending on scope, according to PCI SSC guidance. | Ask which parts are manual, which are automated, and what the tester does by hand. Do not pay for a scan under a penetration test label. |
| Knowledge level (black, grey or white box) | Black-box work requires the tester to discover more before testing, which PCI SSC notes may require more time and resources to meet PCI DSS deliverables. Grey and white box tests start with more information. | Share architecture diagrams, role lists and API documentation where the goal allows, and state clearly why you chose the knowledge level. |
| Number of roles and accounts | Each privilege level, tenant or user role needs its own authorization and access checks, so the same application can take several passes. | List every role to test, including administrative, partner and customer roles, and confirm which test accounts the client will provide. |
| Environments and staging | Testing a production-like copy needs setup, data refresh and sometimes a separate environment review, while production testing needs tighter timing and safety controls. | Decide whether testing happens in staging, production or both, and confirm the environment matches production configuration. |
| Testing windows and change freezes | Work outside normal hours, around freezes or across time zones adds coordination and can split the work into more sessions. | Agree windows in the rules of engagement early and confirm whether a change freeze limits when testing can run. |
| Retesting | A retest checks that fixes address the original risk, so it is a separate phase with its own effort. Remediation that takes long after the original test may require a new engagement, per PCI SSC guidance. | Ask whether one retest round is included, how long the window stays open and what counts as a retest versus a new test. |
| Reporting needs | An auditor-ready report with methodology, limitations, severity reasoning and evidence takes more writing and review than a short findings list. | State the audience (executives, engineers, auditors or customers) and request a sample report before agreeing on the deliverable. |
| Remediation support | Help with fix design, a walkthrough with engineers or a debrief adds meeting and review time beyond the test itself. | Decide whether a debrief or remediation advice is needed, and ask whether it is a fixed session or billed as time. |
One-time tests versus recurring testing costs
A point-in-time penetration test is a single engagement with a defined scope, a fixed testing window and a written report. Its cost is paid to the tester for planning, manual testing, analysis and reporting, and it is the line most buyers first compare when requesting quotes. NIST SP 800-115 describes the work as four phases: planning, discovery, attack and reporting. Planning produces the rules of engagement and goals, and testing does not start until management approval is documented.
- Planning and rules of engagement: Time spent agreeing targets, exclusions, testing windows and contacts is billed as part of the engagement, even though no testing has yet occurred.
- Manual testing depth: The largest cost driver is the hours of hands-on work by testers, which grows with the number and complexity of targets and roles.
- Knowledge level: Black-box work may need more time and resources to meet reporting requirements, so the knowledge level changes the quote.
- Reporting needs: Mapped findings, retest-ready evidence and audit-facing summaries add analysis time.
- Tooling and access setup: Test accounts, environments and VPN or jump host access may be arranged by the client or the tester, which changes who pays for setup.
Ask the provider to itemize these phases, state the number of testers and days allocated and name any work excluded from the price.
A retest checks whether fixes for findings from the original test actually remove the risk. It is usually priced separately from the original engagement because it covers only the findings in scope for verification, not a new discovery phase. PCI SSC's guidance says the tester should retest once remediation is complete to validate that new controls mitigate the original risk. Under PCI DSS requirement 11.4.4, exploitable vulnerabilities must be corrected and the penetration test repeated to verify the corrections.
- Number of findings: More open findings mean more verification hours, so a clean remediation cycle costs less to close.
- Time between tests: PCI SSC notes that remediation long after the original test may require a new engagement rather than a retest.
- Environment changes: If the target has changed significantly since the first test, the tester may need to rescope the work.
- Retest report: Confirm whether the provider documents each closed finding with evidence and states which findings remain open.
- Terms of retest: Ask whether a retest is included in the original quote, whether it has a time limit and how many rounds are covered.
Request a written retest price alongside the original quote so the full remediation cycle is visible before work begins.
Recurring obligations come from standards rather than from a single project. PCI DSS requires internal and external penetration tests at least every 12 months and after significant changes (requirements 11.4.2 and 11.4.3). CIS Controls v8.1 Safeguards 18.2 and 18.5 ask for external and internal penetration tests at least annually. PCI DSS also requires internal and external vulnerability scans at least once every three months (requirements 11.3.1 and 11.3.2). Each recurring line should be budgeted and quoted on its own.
- Annual penetration test: A yearly manual engagement, usually priced like a point-in-time test, with scope adjusted for changes.
- Change-triggered tests: Tests after significant change are unpredictable in number, so agree on how a change is defined and how extra tests are quoted.
- Quarterly scans: Scanning is largely automated and costs less per run than manual testing, though a scan is not a penetration test.
- Scan tooling and review: Scan licenses, false-positive review and reporting are recurring costs even when no tester is on site.
- Retainers: Some providers offer a fixed annual retainer covering recurring tests, which should be compared against separate quotes.
Check whether a quoted "continuous" or subscription model includes real manual testing by named testers, or only automated scanning with periodic reports.
Continuous testing offerings combine automated scanning with periodic manual testing, often on a subscription basis. The cost structure differs from a yearly project: the fee may cover platform access, scan frequency and a set number of manual testing days. PCI SSC distinguishes vulnerability scans, which are mainly automated and take seconds to minutes per host, from penetration tests, which are mainly manual and may last days or weeks depending on scope. A low subscription price can therefore hide very little manual effort.
- Manual days included: Ask how many days of named tester time are in the fee and what triggers them.
- Scan versus test reporting: Confirm which reports are scan outputs and which are penetration test reports with methodology and limitations.
- Change handling: Check whether a significant change triggers manual work or only a rescan.
- Rollover and unused days: Clarify whether unused manual time expires or carries over.
- Tester qualifications: Ask who performs the manual work and how they are qualified, using the indicators PCI SSC lists while noting that certifications alone do not establish experience.
If the manual hours are not stated in the quote, the recurring cost cannot be compared with the one-time price.
What buyers ask before they request a penetration testing quote
How much does a penetration test cost?
DeployOpen does not publish a price list, and no supplied source gives a general price for a penetration test, so a figure here would be guesswork. A quote follows from a written scope. The main cost drivers are the number and type of targets, the depth of manual work, the knowledge level the tester starts with, whether retesting and a formal report are included, and how quickly the work must happen. Ask each provider to itemize testing days, reporting, retest rounds and any project management, and to state which items are one-time and which recur if the test is repeated.
How long does a penetration test take?
Duration depends on scope, environment complexity and how quickly the client can respond. PCI SSC's guidance describes a penetration test as a mainly manual process that may last days or weeks depending on scope, which contrasts with automated scans that finish in seconds to minutes per host. Time is also spent on planning, access setup, testing windows and the report. Ask the provider for a timeline that separates these phases, and confirm how much of the schedule depends on your change freezes and availability of contacts.
Can our own team run the penetration test internally?
Internal teams can test their own systems, but a result is only as credible as the tester's independence and skill, and auditors and customers often ask for an external provider. PCI SSC lists OSCP, GIAC certifications such as GPEN and GWAPT, CREST certifications and CHECK as indications of tester skill, while stating that it does not validate or endorse them and that certifications alone do not establish experience. Ask any provider, internal or external, for named testers, relevant project history and a sample report, and confirm with your assessor which qualifications they will accept.
What does the client need to provide for a penetration test?
The client typically provides written authorization, scope details, target lists, test accounts with defined roles, named technical and emergency contacts, testing windows and any change freezes. Where a test covers production or regulated data, you also need to agree on data handling and how sensitive evidence is stored and deleted. NIST SP 800-115 treats rules of engagement and management approval as planning items that must be finalized before any testing starts, so budget internal time for this work even though it is not billed as testing.
Is retesting included in the penetration test price?
Retesting is often quoted separately, so check the written scope before signing. PCI SSC's guidance says the tester should retest once remediation is complete to confirm that new controls address the original risk, and that remediation completed long after the original test may require a new engagement. PCI DSS requirement 11.4.4 requires exploitable vulnerabilities to be corrected and the testing repeated to verify the fixes. Ask whether the quote includes one or more retest rounds, how retest scope is defined, and what the time limit for retests is.
Will a cheaper vulnerability scan satisfy our requirement?
Not always. PCI SSC distinguishes vulnerability scans, which identify, rank and report vulnerabilities using mostly automated tools, from penetration tests, which are mainly manual and attempt to exploit vulnerabilities to defeat security features. PCI DSS requires internal and external vulnerability scans at least once every three months and penetration tests at least every 12 months and after significant changes, so the two serve different requirements. Check your framework's wording with your assessor before choosing the cheaper option, and ask any provider whether their offer includes manual testing or only scanning.
Does a black box test cost less than a grey or white box test?
Not necessarily. PCI SSC notes that black box assessments may require more time, money and resources to produce the deliverables a PCI DSS test needs, and that PCI DSS tests are typically white box or grey box because they give more accurate and comprehensive results. Lower access can mean more reconnaissance time, while more access can mean more scope to cover. Ask each provider how they priced the knowledge level you choose and what access they expect you to provide.
Which frameworks set the testing your budget must cover
This table compares three frameworks that set penetration testing frequency and triggers, and what each one means for the budget. Read each row for what the framework asks for, what an assessor will expect to see as evidence, and where the spend usually grows. The main takeaway is that recurring tests, retests after fixes and extra tests after significant change are the costs most often missed in first-year planning.
| Framework or program | What it expects | What to budget for |
|---|---|---|
| PCI DSS requirements 11.4.2 and 11.4.3 | Internal and external penetration tests at least every 12 months and after significant changes to the cardholder data environment or infrastructure. | A recurring annual test plus an unplanned test after each significant change. Ask the provider how change-triggered tests are priced and whether they are included in a retainer. |
| PCI DSS requirement 11.4.4 | Exploitable vulnerabilities found in testing are corrected by risk ranking, and the penetration test is repeated to verify the corrections. | A retest after remediation, usually scoped as a smaller effort than the original test. Confirm whether retests are included in the original quote and how long the retest window stays open. |
| CIS Controls Safeguards 18.2 and 18.5 | External penetration tests under Safeguard 18.2 and internal tests under Safeguard 18.5, each at least annually. The CIS assessment fails Safeguard 18.2 if more than twelve months pass since the last external test. | A recurring annual external test and annual internal test, planned so that the external test never lapses past twelve months. Budget both as separate scopes unless the quote bundles them. |
| DORA threat-led penetration testing (TLPT) | Threat-led testing for in-scope financial entities, based on threat intelligence and run by qualified testers. The European Commission's 2020 impact assessment (SWD(2020) 199) cites an ESA estimate that such testing costs between 0.1% and 0.3% of the total ICT budget of the firms concerned. | A large, multi-week program with threat intelligence, red team work and a regulator-facing report. Use the ESA estimate as a planning context only, and confirm the scope and frequency with your competent authority. |
What the price should include in the deliverables
A penetration test price is only comparable when the deliverables are defined. The cards below list the outputs a buyer should expect in the quote, what each one is for, and what to confirm before signing. Items marked optional in the quote often change the total more than the testing hours do.
Report structure and scope statement
The PCI SSC report outline covers an executive summary, a statement of scope, a statement of methodology, a statement of limitations, a testing narrative and environment clean-up. The scope and limitations sections show what was and was not tested, so confirm they are included in the quote rather than added later as an extra. Ask for a sample report from the provider before you commission the work.
Findings with CVE and CWE references
Each finding should name the weakness category and, where one exists, the matching CVE and CWE identifiers. References let your engineers and auditors trace a finding to a public definition. Confirm whether the quote includes evidence, affected components and reproduction detail for every finding, or only for the highest-rated ones.
Severity reasoning based on CVSS
Severity should be traceable. The report should explain how each rating was derived, typically from CVSS, and show any adjustment made for your environment, such as compensating controls or exposure. Ask whether the scoring method is written into the report and whether you can challenge an adjusted rating before the report is final.
Tools and testing method disclosure
The report should list the tools used and the testing methods applied, including which parts were manual. OWASP ASVS guidance notes that running an automated tool without thorough testing is not sufficient, so a short list of tools with no manual testing narrative is a warning sign. Confirm that tool output is reviewed and validated by a tester before it reaches a finding.
Retest results and closed findings
A retest should be priced as a defined deliverable, not an open-ended favor. The retest report should record each original finding as closed, partly closed or still open, with the evidence used to decide. Confirm how many retest rounds are included, the window in which they can be requested, and whether the retest is billed separately.
Summary letter for auditors and customers
Some buyers need a short letter or summary for a customer, a regulator or an auditor, not the full technical report. Ask whether this is included, who signs it, and what it states. A provider can describe the test, but it cannot replace an assessor's attestation, so confirm the letter does not claim compliance on your behalf.
How to compare two penetration testing quotes fairly
Two penetration testing quotes are comparable only when they describe the same test. Before comparing prices, confirm that both quotes name the same targets, the same knowledge level (black, grey or white box), the same test type and the same deliverables, including retest terms. A quote that covers an external network while the other covers external and internal networks, cloud accounts and a mobile app is not a price comparison at all. PCI SSC's guidance notes that black-box work may need more time and resources to meet PCI DSS deliverables, so a cheaper black-box quote may simply be a narrower one. Ask each provider to restate its scope in writing, then check that the two restatements match line by line.
Ask each provider to state in writing which test methods it uses and how much of the work is manual. The key question is whether a named tester exploits and chains weaknesses by hand, or whether the quote is essentially a scanner run with a report attached. PCI SSC describes penetration testing as a mainly manual process, in contrast to automated scans that take seconds to minutes per host. Also request the tester qualifications the provider relies on, the sample report format, the hours or days allocated to testing and reporting, the retest terms and the number of retest rounds included, and how findings are rated. Confirm the data handling terms for evidence and credentials, and the professional liability and cyber insurance cover the provider carries. Ask for each item as a line in the quote, not as a general claim.
A lower quote with no manual work or no retest may not satisfy a framework. PCI DSS requirement 11.4.4 requires exploitable findings to be corrected and the test repeated to verify the fix, so a quote without retest terms leaves that obligation open and may need a second purchase. Similarly, CIS Controls Safeguard 18.2 expects periodic external tests, and a scan-only deliverable may not be accepted as a penetration test by an assessor or customer. Before you accept a quote, ask your auditor, regulator or customer which methodology, report content and retest terms they will accept, and write that requirement into the request. Any quote that cannot meet those points is cheaper only on paper.
How cost changes across external, internal, cloud and AI targets
External testing covers the addresses and services that the internet can reach, such as public IP ranges, DNS names, VPN gateways, mail relays and remote access portals. Effort follows how much of the estate is exposed and how much each exposed service needs to be understood before it can be judged.
- Number of live hosts. Each reachable address needs discovery, service identification and validation. A short list of addresses with few services takes less manual work than a wide range where ownership is unclear.
- Number of exposed services. A single host running several listeners, admin panels or legacy protocols adds checks beyond the host itself.
- Asset discovery work. If the client cannot supply an authoritative inventory, the tester spends time confirming which addresses belong to the organization and fall inside the agreed scope.
- Third-party and hosted assets. Addresses held by cloud or SaaS providers may need confirmation of ownership and of whether the provider's testing rules allow the test.
Ask whether the quote states the address list, how assets discovered during testing are handled, and whether web applications on those hosts are priced separately, as covered in the web applications and APIs pillar.
Internal testing starts from a foothold inside the network, often a standard user account or a connected device, and examines how far access can travel. Active Directory usually drives the effort because identity controls connect most systems. Scope is shaped by network segments, user roles and the number of locations the test covers.
- Network segments and sites. Each segment, VLAN or branch office adds routing, access and monitoring questions to resolve during the test.
- Number of starting roles. Testing from a standard user, a helpdesk account and a privileged account is separate work, and each starting role adds analysis time.
- Active Directory size and trusts. Multiple domains, forests and trust relationships add paths to analyze and configuration to review.
- Hybrid identity and remote access. Synchronization to cloud identity, VPN concentrators and wireless networks each add components to test.
Ask which starting access levels the quote assumes, which segments are in scope, and whether Active Directory configuration review is included or priced as a separate task as detailed in the infrastructure and Active Directory pillar.
Cloud testing combines configuration review with attack-path analysis inside accounts, subscriptions or projects. The shared responsibility model determines what the client's team can change and what the provider controls, so the tester needs account access and a clear list of which services the client manages.
- Number of accounts, subscriptions and projects. Each boundary usually needs its own identity, policy and network review.
- Services and workload types. Managed databases, serverless functions, storage, container registries and identity services each have settings to examine.
- Kubernetes clusters and namespaces. Cluster count, tenant separation, admission controls and the number of workloads all affect how much review is needed.
- Access model and review depth. A read-only configuration review is different work from a test that includes authenticated attack-path analysis using supplied roles.
Confirm which providers the test is permitted against under their published testing rules, whether the review is repeated after infrastructure changes, and who supplies the cloud access, as detailed in the cloud pillar.
Application testing effort is driven by how many functions a user can reach, how many roles the application has and how many integrations sit behind it. An API with a documented schema and few endpoints is a different job from a portal with many workflows, even when both run on the same number of hosts.
- User roles and tenants. Each role, permission level and tenant boundary needs authenticated testing, which often multiplies effort more than page count does.
- Authentication and payment flows. Login, multi-factor steps, session handling and payment steps receive detailed attention, especially where compliance frameworks single them out.
- Endpoints and documentation. Available API specifications, collections or source access can reduce discovery work, while undocumented APIs take longer to map.
- Mobile clients and integrations. Companion apps and connected services share back-end APIs and may need extra scope.
Ask how many roles, endpoints and workflows the quote assumes, and whether the price covers authenticated testing for every role or only one, as detailed in the web applications and APIs pillar.
AI testing is newer than the other categories, and effort depends on the number of model integrations, the tools an agent can call and the data sources the system retrieves from. Methods for these systems are still maturing, so the quote should name the testing approach and the categories covered before work starts.
- Model integrations and endpoints. Each model, whether hosted or self-hosted, and each entry point into the application adds configuration and behavior to examine.
- Tools and permissions for agents. Every tool an agent can call, and each permission it holds, expands the paths that need analysis.
- Retrieval pipelines and data sources. Retrieval-augmented generation adds document stores, ingestion steps and access controls to assess.
- MCP servers and model supply chain. Connected servers and model dependencies add components, and their versions and provenance need review.
Ask whether the quote is based on a defined list of agents, tools and data sources, and how testing will be repeated when models, prompts or tools change, as detailed in the AI systems and agents pillar.
What you prepare to keep the engagement on budget
This sequence lays out what the client gathers and confirms before testing begins, so the tester spends paid hours on testing rather than on questions, access problems or rescheduled windows. Each step closes with a written artifact that both sides can check against the agreed scope.
Confirm the written scope and owners
The client confirms in writing which targets, environments and business functions are in scope, which are excluded, and the purpose of the test (for example, a PCI DSS requirement, a customer security review or a release gate). The client names one accountable owner for the scope and for sign-off on changes. The tester drafts the scope and the client returns it marked up. Work is done when both parties have signed the scope statement and the rules of engagement, which NIST SP 800-115 treats as part of planning before any testing occurs. Ambiguous scope is the most common source of change requests, because each unclear boundary becomes a question mid-test that someone must price and approve.
Provide accounts and roles
The client supplies the test accounts the scope requires, such as standard users, administrators or service roles, along with the authentication details the tester needs, and states which roles and privileges each account has. Where the test is grey box, the client also decides what prior knowledge the tester receives. The tester checks that each account works before the testing window opens and reports any lockout, missing role or MFA barrier the same day. This step is done when a short access register lists every account, its role, its owner and a confirmed login. Missing or misconfigured accounts often consume paid hours on access troubleshooting, which is one of the most avoidable cost drivers.
Share architecture and asset lists
The client shares network diagrams, application architecture, an asset or host inventory, cloud account identifiers and known third-party dependencies, marking which items are owned by the client and which are hosted by a provider whose testing rules apply. The tester reviews the material for gaps, such as systems that appear in a diagram but not in the scope, and raises them in writing. Done when the asset list is reconciled against the scope and every in-scope host, application and account has a named owner. Accurate inventories reduce discovery time, since testers otherwise spend paid hours finding what the client already knows, and they reduce the risk of testing a system the client did not intend to include.
Schedule testing windows and change freezes
The client agrees the dates and hours when testing may run, and the change freeze that protects those windows from unrelated deployments. The tester confirms whether testing will be overt, meaning the IT staff know about it, or covert; NIST SP 800-115 notes that overt testing is less expensive, carries less risk and is more frequently used. The client then records the freeze in its change calendar and tells the operations team which activity to expect. This step is complete when a written calendar with approved windows and freeze dates is on file. Testing that is interrupted by a deployment, or paused while a window is renegotiated, adds idle time and often a second round of scoping.
Name escalation contacts
The client names technical and business contacts who can respond quickly during the test, including a person who can stop testing, approve a change to scope and receive notice of a critical finding. The tester names its own lead and the person who makes decisions on its side. The contacts agree how urgent findings are reported and the channel used, and they confirm the after-hours route if the test runs outside business hours. Done when the escalation list is attached to the rules of engagement and each contact has confirmed availability. A tester who cannot reach a decision maker either waits, which is billed time, or proceeds on an assumption, which is a scope risk.
Agree the retest window before testing starts
Before testing begins, the client and tester agree how retesting will work, including which findings are eligible, how long the client has to remediate and how the retest is scoped. PCI SSC's guidance says the tester should retest once remediation is complete, and that remediation extending long after the original test may require a new engagement. PCI DSS requirement 11.4.4 also requires the corrections to be verified by repeating the test. Agreeing these terms up front determines whether a retest is included in the original quote or priced later as a separate engagement. The output is a written retest clause that states the window, the eligible findings and the approach to a separate quote if the window is exceeded. Retesting costs are otherwise often discovered after the report is delivered, when budget has already been spent.
Confirm the quote matches the written scope
Before signing, the client checks that the quote lists the in-scope targets, the test type, the knowledge level, the report deliverables and whether a retest and a debrief are included. The client asks the tester to state which costs are one-time and which recur if the test is repeated, and what would trigger a change order. The client should ask for the tester's assumptions in writing, such as the number of applications or hosts, the expected number of roles and the number of retest rounds. This step is done when the quote and the scope statement reference the same targets and the client holds a list of the assumptions that drive the price. Quotes that do not tie back to the scope usually lead to change requests once work starts.
Questions to ask a provider before you sign
A penetration test quote is only as useful as the work it describes. The cards below cover the provider checks that tell you what you are paying for, from how manual testing is done to how fixes are retested and who carries the risk if something goes wrong. Each answer should appear in the written scope and quote before you commit budget.
Methodology and manual testing
Ask which methodology the provider follows, how it is documented, and what share of the effort is manual exploration versus automated scanning. NIST SP 800-115 does not endorse one methodology, so the provider should name its own and explain how it fits your target. A quote that lists hours but not the manual phases behind them is hard to compare. Ask for the phases in writing, with the time each one receives.
Sample reports
Request a redacted sample report before signing. Check whether it has the sections a reader needs: scope, methodology, limitations, findings with evidence, and severity reasoning. A thin sample usually means a thin deliverable, and the price should reflect the depth of the report you will receive. Confirm whether the report format can be reused for your auditor or customer.
Tester experience and certifications
Ask who will do the work, how long they have tested similar targets, and which certifications they hold. PCI SSC lists OSCP, GPEN, GWAPT, CREST and CHECK as indications of skill, but notes they do not establish experience on their own. Price tends to follow senior tester time, so ask how much of the engagement is led by the people you meet.
CREST accreditation
Ask whether the provider holds CREST accreditation for the disciplines you need. CREST is a not-for-profit that accredits member companies and certifies individuals. Accreditation is a provider-level check that complements tester-level credentials. Confirm the current status directly with CREST rather than relying on a logo in a proposal.
Independence and data handling
Confirm that the tester is independent of the team that builds or operates the system, and that no conflict exists with a remediation contract. Ask how captured data, credentials and evidence are stored, who can access them, how long they are kept and how they are destroyed. These terms affect the security of the test itself and should be written into the agreement before testing starts.
Retest terms and insurance
Ask whether retesting is included, how many rounds are covered, and how long after the original report it is available. PCI SSC notes that remediation far beyond the original test may require a new engagement, so the window matters. Confirm the provider's professional indemnity and liability insurance, and how testing disruption is covered. Retest terms that are missing from the quote often appear later as extra cost.
How DeployOpen scopes, prices and retests penetration tests
DeployOpen, a Chainscore Labs company, runs security testing alongside implementation work on self-hosted open-source platforms inside the client's own infrastructure. Cost follows from a written scope, so the work is defined before anyone quotes a price or starts testing.
How we scope
- Engagements are fixed-scope, with targets, test type and deliverables agreed in writing before work starts.
- The written scope states which systems, accounts and environments are covered, and which are excluded.
- Ongoing support and retesting can be added as a retainer, priced separately from the initial test.
How we build the test
- Testing combines automated scanning with manual work, so the effort reflects the depth agreed in scope.
- Knowledge level, whether black, grey or white box, is set in the scope because it changes the hours required.
- Testers confirm rules of engagement, testing windows and contacts with the client before any active testing begins.
How we hand over
- The report covers scope, methodology, limitations, findings, severity reasoning and remediation advice.
- Each finding includes evidence and a clear explanation, so your internal team and your auditor can follow it.
- Retesting of corrected findings is quoted as its own item, so the report sets out what is verified and what remains open.
How we support
- Retainers can cover recurring testing after significant changes, scoped to each release or platform update.
- Platform upgrades and hardening work can be planned alongside the test, so findings feed directly into fixes.
- Confirm with us in the quote which deliverables, retest rounds and support hours are included before you sign.
