Technical review by Volodymyr Garbar, CISO & Tech Lead
Updated: 6 October 2026
A penetration testing vendor should be evaluated on the proposed scope, tester expertise, methodology, reporting and retesting, and price relative to the work included. A good proposal should make all of these reasonably clear before testing begins.
The cheapest quote is not necessarily a bargain. Neither is a 25-page methodology document proof that the actual test will be good.
What matters is whether the provider understands your environment, can explain what its testers will actually do, and gives your team useful evidence when vulnerabilities are found.
Free playbook
Evaluating a vendor for PCI DSS penetration testing?
Q-Sec's PCI DSS Penetration Testing Playbook includes a pre-engagement readiness checklist, scoping guidance, and a practical engagement timeline you can use.
Get the PCI DSS Penetration Testing PlaybookStart by comparing eight areas: scope, testing approach, tester expertise, methodology, reporting, retesting, compliance requirements, and price. Compare these side by side rather than looking at the final quote first.
| Evaluation area | What to check |
|---|---|
| Scope | Are all relevant networks, applications, APIs, cloud systems, and other assets included? What is explicitly excluded? |
| Testing approach | How much of the assessment is manual? Are findings validated before they reach the report? |
| Tester expertise | Has the assigned team worked with similar technologies and environments? |
| Methodology | Which testing standards or methodologies will guide the engagement? |
| Reporting | Will you receive technical evidence, risk context, remediation guidance, and an executive-level view? |
| Retesting | Is remediation validation included, limited to certain findings, or charged separately? |
| Compliance | Can the engagement provide the documentation required for your applicable framework or customer requirements? |
| Price | What exactly is included in the quote, and which activities will cost extra? |
The first thing to evaluate is not the vendor. It is the scope the vendor has proposed.
Suppose you ask three penetration testing service providers to assess your external attack surface. One quotes for 20 public IP addresses. Another includes the IPs, customer portal, and APIs. The third adds cloud configuration testing.
Those are three different tests.
A useful scope should identify the assets being tested, the type of assessment, access provided to testers, important exclusions, testing constraints, and the objective of the engagement.
It should also make sense for the reason you are commissioning the test.
A company preparing for PCI DSS assessment may have specific systems and segmentation controls that need to be included. A SaaS company responding to an enterprise customer's security requirements may care more about its production application, APIs, and cloud environment. A business that has just changed its network architecture has another problem again.
NIST SP 800-115 treats planning as part of the security assessment itself, with assessment planning followed by execution and post-testing activities. OWASP likewise describes pre-engagement work as part of established penetration testing methodologies rather than paperwork sitting outside the technical assessment.
If you specifically need an external assessment, our guide to External Penetration Testing Companies explains how provider models differ and what belongs in an external testing scope.
Certifications are useful. A row of logos on a proposal is not enough.
Ask who is likely to perform the engagement and whether the team has experience with the technology you are asking them to test.
This gets important quickly.
A tester who spends most of their time on web applications may not be the person you want leading a complicated Active Directory assessment. Cloud penetration testing brings its own identity, permissions, configuration, and architecture questions. APIs can require a lot more than running the same tests used against a website.
You do not necessarily need named consultants before procurement is finished. But the vendor should be able to explain what skills it assigns to your type of engagement and how senior review works.
For regulated testing, check qualification and independence requirements separately. Do not assume that a technically capable tester automatically satisfies every audit requirement.
Most serious penetration testing vendors use both tools and manual work.
That is normal. The useful question is where each is used.
Automated tools can help with reconnaissance, enumeration, vulnerability discovery, and other repetitive work. Human testing becomes particularly important when a potential weakness needs validation, several issues need to be connected into an attack path, or the tester has to understand application logic and unusual behavior.
Ask the vendor what happens after its tools identify a potential vulnerability.
Does a tester validate it? Will controlled exploitation be attempted when permitted? Are false positives removed? Can testers investigate privilege escalation or chained vulnerabilities when those scenarios are relevant to the scope?
Methodology gives you another useful checkpoint. OWASP’s current penetration testing methodology reference includes established approaches such as PTES and NIST SP 800-115, while the OWASP Web Security Testing Guide provides detailed testing guidance for web applications and services.
The methodology should fit the target. Simply seeing “OWASP” somewhere in a proposal does not tell you much about how an internal network or Active Directory environment will be tested.
Ask for a sanitized sample report.
Seriously. It can save a lot of disappointment later.
A penetration test can be technically competent and still leave the client with a report that is painful to use. Developers need enough evidence to understand and fix the vulnerability. Security teams need risk and attack-path context. Management needs to know what matters without reading exploit logs.
At minimum, look for:
OWASP describes web security testing as identifying security issues and presenting them to the system owner together with their impact and proposed mitigation or technical solution.
Then ask yourself a less formal question: could your engineers actually work from this report on Monday morning?
If not, the logo on the front page will not rescue it.
A final report should not be the first time you hear about a critical vulnerability.
Ask how the vendor handles serious findings discovered during active testing. There should be an agreed communication route for issues that cannot sensibly wait until the final report.
Then look at remediation support.
Some vendors deliver the report and close the engagement. Others provide technical walkthroughs, remediation discussions, or retesting. None of these models is automatically wrong, but you need to know which one you are buying.
Retesting deserves a specific line in the proposal. Check how many findings can be retested, whether there is a time limit, what happens if the first fix fails, and whether you receive updated evidence afterward.
Q-Sec’s current penetration testing model, for example, includes manually validated findings, technical and executive reporting, remediation guidance, and optional retesting after remediation. Its typical targeted engagement is scoped over roughly 2–4 weeks depending on the environment.
In the UK and Europe, a standard penetration test often costs roughly £2,000–£8,000 (€2,300–€9,000), while larger or more specialized engagements can run into tens of thousands. UK market data for 2026 puts typical tester day rates around £700–£1,200, with small external or web application tests commonly falling around £2,000–£5,000. Published UK supplier rates and broader European pricing show substantial variation by scope and provider.
That is a budgeting range, not a price list.
Applications with several user roles, APIs, SSO, cloud environments, larger networks, compliance requirements, and deeper manual testing all add work. A short external infrastructure test is also a very different engagement from a multi-week Active Directory assessment or red-team exercise.
This is why penetration testing services pricing should be evaluated against scope and effort rather than the final number alone.
If Vendor A quotes €4,000 and Vendor B quotes €7,000, find out how many testing days each has allowed for, what assets are covered, whether findings are manually validated, what reporting is included, and whether you get a retest.
Sometimes the €7,000 proposal is expensive. Sometimes the €4,000 proposal simply contains less testing.
Compare penetration testing proposals against the same scope, testing depth, deliverables, timeline, and retesting terms before comparing price.
I would put the proposals next to each other and build a simple table. It does not need to become a procurement project of its own.
| Question | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
| Are the same assets in scope? | |||
| What is explicitly excluded? | |||
| How many testing days are included? | |||
| What level of access will testers receive? | |||
| How is manual testing used? | |||
| Are findings manually validated? | |||
| Who performs the test? | |||
| Which methodology is used? | |||
| Are critical findings reported immediately? | |||
| Is a technical debrief included? | |||
| Is remediation support included? | |||
| Is retesting included? | |||
| What is the delivery timeline? | |||
| Total price |
Do this before negotiating the price.
It is surprisingly easy to spend half an hour discussing a €1,000 difference and miss the fact that one penetration testing vendor has excluded two APIs and the other has included them.
NIST’s security testing guidance also puts planning, execution, analysis, and mitigation into the same assessment process. In other words, what happens before and after active testing is part of the engagement too.
Common warning signs include unclear scope, scanner-heavy testing sold as a full pentest, vague answers about who performs the work, no sample report, and unclear retesting terms.
None of these automatically proves that the provider is bad. They are reasons to ask another question before signing.
A generic methodology followed by a price is not much of a scope.
The proposal should reflect something about your actual environment: the assets being tested, access model, objectives, exclusions, constraints, and expected deliverables.
Tools are normal. Avoiding the question is not.
The vendor should be able to explain where automation is used and where testers manually investigate and validate potential vulnerabilities.
There can be legitimate confidentiality restrictions around previous client work, but a penetration testing company should normally be able to provide a sanitized or representative report.
You are buying the report as well as the test.
Company-level credentials can matter, particularly when procurement or regulation requires them. They still do not tell you whether the people assigned to your cloud assessment have meaningful cloud security experience.
Ask both questions.
“Retesting available” can mean free verification of all remediated findings. It can also mean another paid engagement.
Get the terms in writing.
Be careful with guarantees about results.
A penetration test can establish what testers found within a defined scope and period. It cannot prove that no other exploitable weakness exists anywhere in the environment.
Before signing with a penetration testing vendor, ask about the exact scope, tester experience, methodology, manual testing, vulnerability validation, reporting, remediation support, and retesting. These questions help establish what you are actually buying and make it easier to compare proposals that may look similar on paper.
You can learn quite a lot from ten questions:
There may be another ten questions for a complicated environment. Fine. But if a provider cannot give clear answers to these, I would not rush into contract details yet.
A specialist can make sense when the target requires expertise that your usual security provider does not have.
That might be a complex AWS or Azure environment, Active Directory, mobile application, API-heavy platform, industrial system, or a specific red-team scenario.
A broader security provider can be useful when penetration testing is part of a larger program. For example, you may need the technical assessment to support PCI DSS, NIS2, DORA, ISO 27001, customer assurance, or ongoing remediation work.
Neither model is inherently better.
The more useful question is whether the team doing the assessment has the right expertise and whether the engagement produces what you need afterward.
For UK organizations, accreditation can also affect vendor selection. Certain public-sector testing has specific assurance requirements, so procurement criteria should be checked against the system and contract being assessed rather than copied from a generic vendor checklist.
Vendor selection should end with an agreed scope, rules of engagement, testing schedule, communication process, and named contacts before active testing starts.
This is the point where the assumptions made during procurement become operational.
Confirm the assets and exclusions one last time. Agree testing windows and prohibited techniques. Decide who should receive critical findings. Make sure credentials and other sensitive testing information have a secure exchange process.
And decide what happens if the tester reaches somewhere nobody expected.
That conversation is much easier before the test than during it.
Q-Sec’s current process starts with scoping, an NDA, and rules of engagement before reconnaissance and active testing. Critical findings are reported to the designated contact during the engagement rather than being held until the final report. A standard targeted engagement currently runs around three to four weeks from pre-engagement through reporting, with remediation support and optional retesting afterward.
Q-Sec provides penetration testing for external and internal networks, web applications and APIs, cloud environments, Microsoft 365, Active Directory, and adversary scenarios.
The engagement includes manual validation of findings, technical and executive reporting, remediation guidance, and a developer walkthrough. Retesting can be added after remediation.
For organizations operating in Europe, testing can also be scoped around requirements connected with NIS2, DORA, PCI DSS, ISO 27001, and other security or compliance programs.
Need a penetration testing proposal you can actually compare?
Q-Sec provides penetration testing for external and internal networks, web applications and APIs, cloud environments, Microsoft 365, Active Directory, and adversary scenarios.
Start with the scope: are they actually testing what you need tested? Then look at the people doing the work, how much testing is manual, what the report looks like, and whether remediation support and retesting are included. Compare prices only after you know the proposals cover roughly the same work.
In the UK and Europe, a standard engagement often falls somewhere around £2,000–£8,000 (€2,300–€9,000). Larger or more specialized tests can cost considerably more. The biggest factors are scope, complexity, testing time, and how much manual work is involved.
Three qualified vendors is usually a sensible starting point. It gives you enough to compare scope, approach, and price without turning a fairly straightforward purchase into a month-long research project. Formal tenders and regulated procurement may have their own requirements.
Yes. Ask for a sanitized or representative report before you sign. You will quickly see whether developers get enough detail to fix the findings and whether the executive section says something useful to people who were not involved in the test.
Ideally, yes, or at least the terms should be clear before testing starts. Check what can be retested, how long you have to request it, whether a second failed fix is covered, and whether retesting costs extra.
A vulnerability scanning provider mainly uses automated tools to identify potential weaknesses. A penetration testing vendor goes further by investigating findings, attempting controlled exploitation, and working out what an attacker could actually do with a weakness.
For a straightforward test with a clear scope, vendor selection can be fairly quick. It takes longer when several teams need to approve the purchase, the environment is complicated, or procurement involves NDAs, security reviews, compliance requirements, or a formal tender.