Choose a penetration testing provider: comparing cyber security companies

You need a penetration test from an independent provider, and you are either about to go out for quotes, or already have a handful of responses to compare. How do you work out which one to trust with delivering your next pentest?

The proposal that arrives in your inbox is designed to win the work, so it leads with the things that are easy to put in writing: certifications, a methodology, and a price. If you have bought testing before, then you already know the difference between a quality pentest that delivered valuable information, and one that left a bad taste. Knowing what to ask, and when, can make that difference easier to see.

Work out what you need before you compare anyone

From a provider perspective, the best scoping conversations are with buyers who know exactly what they want tested, the approach they're happy with, and can state their drivers behind requiring testing.

One of the issues that buyers typically have on the back of testing is where the provider may have had a different picture of the engagement. Scope documents may be too high-level, or are vague enough that it leaves room for interpretation for what is in scope. These should be crystal clear, as the person delivering the pentest may often not be the one that's sat on the scoping call with you, and any information could be lost along the way.

The first thing to pin down is the type of assessment you actually need, because this colours the questions that a provider will ask for scoping. If you're looking for web application pentesting, they'll raise questions about user roles, development frameworks, tenant boundaries, and how authentication works. For network pentesting, the provider will enquire about the number of IPs/servers, domain structure, and other relevant details. Having this information ready before approaching a provider saves a round of emails, and it means the quotes you get back are actually comparable.

Some organisations may have specific goals in mind, or may prefer stating what they're most concerned about (customer PII, database backups, payment card data, etc.). These goals, along with any compliance requirements, can change the perspective of an engagement for the penetration tester, so they are worth raising in the initial scoping conversation.

For example, PCI DSS requirement 11.4 mandates testing of the cardholder data environment at least annually, and knowing that a test is being driven by PCI compliance adds the goal of compromising the CDE.

It is worth figuring out timing for the pentest engagement at this point too. Two to three weeks between signing a contract and the start of testing is common, and can be even longer if you need a particular testing window, an on-site visit, or are looking for a longer-term cyber security partner.

If a certification or a customer security review deadline is driving the need for testing, then count backwards from this and leave room for the report, remediation, and any retesting, and not just the days for the actual pentest.

What accreditations actually prove

Certification logos do useful work, but they answer narrower questions than most buyers assume, and company-level badges answer a different question to individual ones.

CREST accreditation is assessed at company level. It examines a provider's processes, methodologies, data handling, and its quality assurance. It is a benchmark that most UK buyers will recognise.

Cyber Scheme accredited companies are also independently reviewed, including the organisational security of the provider, whether it has qualifying personnel, and that they adhere to the Cyber Scheme Code of Conduct.

CHECK scheme organisations are certified companies that are authorised to perform penetration testing on public sector or critical national infrastructure within the UK.

Cyber Essentials tells you whether the provider has baseline controls in place in their own environment. Treat it as due diligence on them as a supplier rather than as a measure of technical capability. The same goes for ISO 27001 certification.

Whilst a company accreditation is proof that their methodology, approach, data handling, and policies have been independently verified, providers without accreditation can be just as capable; they may just not be at a scale where they are ready to become accredited.

Individual certifications are where you learn about the person doing the work. There are countless certifications available to security professionals in 2026, and buyers may see differences between UK providers and US providers. Some of the most common and trusted certifications include:

• OSCP requires candidates to compromise live machines in a proctored practical exam and write it up, so it demonstrates hands-on exploitation rather than recall.
• OSCE/OSCE3 sits above the OSCP and covers exploit development and chaining techniques together.
• CPSA, CRT, CCT INF, CCT APP are CREST certifications for individuals who have sat the relevant examinations.
• Cyber Scheme provide an equivalent certification pathway with their CSTM, CSTL Infrastructure, and CSTL Application accreditations.
• CHECK Team Leader and CHECK Team Member are statuses applied to individuals that have a relevant CREST or Cyber Scheme certification, and are a UKCSC Principal or Practitioner (respectively).
• GIAC certifications such as GPEN and GWAPT are common among US providers.

None of this tells you who has been assigned to your engagement, and it's the individual performing the testing who is pivotal to the quality of service delivery. Ask which certifications the named consultant on your job holds, and ask what comparable environments they have tested. A good provider will answer without hesitating.

Find out who is actually performing the testing

Subcontracting is common in the cyber security industry, and it is not disclosed as often as it should be. Providers may be in a growth stage and need to subcontract to meet their planned engagement schedules, or may not even have their own security testing delivery team.

As a buyer you wouldn't know that the person delivering your pentest wasn't affiliated with the vendor you procured from. So ask whether any part of the delivery is outsourced or subcontracted, get the answer in writing, and ask for the assigned consultant's name and qualifications before you sign.

A question you should be asking is how much of the testing a human does at all. "Penetration testing" now covers everything from fully automated platform assessments through to entirely manual, consultant-led work. We have written about this in a bit more detail in our manual vs automated penetration testing article.

If a provider uses AI tooling in delivery, our article on AI penetration testing risks sets out the questions to put to them about where your data goes.

Read the proposal as a commitment, not a brochure

A provider who is confident about their services will put detail in the proposal. Larger providers, who turn over hundreds of penetration tests a year, often use pre-canned templates for scoping purposes. There's nothing wrong with standardising this information, but it is vital to ensure that the scope you're procuring is tailored to your organisation.

Look for these things:

• A detailed methodology explaining which parts apply to your systems, and why, is the part that tells you they have tailored the engagement to you specifically. Our own penetration testing methodology page is written for exactly this purpose.
• An explicit scope, including any notable exclusions. Assets, URLs, IP ranges, user roles, environments. Exclusions are as important as inclusions, as you should know up-front if anything is not going to be covered.
• Rules of engagement. Testing windows, permitted techniques, denial of service handling, escalation contacts, and what happens if something breaks.
• What you need to provide, and when. Credentials, VPN access, whitelisting, test accounts for each role. Delays with pre-requisites are one of the most common causes of an engagement slipping.
• Deliverables listed individually. An executive summary, a technical report, a debrief, and any retesting should each be named rather than bundled under "reporting".

A vague scope document is where fixed-scope engagements can go wrong for the buyer. If the document does not define what "covered" means, you have no way to hold anyone to it when the report quality and depth aren't what you expected.

Understand how the price is structured

How a provider prices the work tells you what they are actually committing to, and there are three common pricing models.

A day rate. You buy a number of consultant days at a set rate. Effort is transparent, but the scoping risk sits with you. If the scope was underestimated, then testing stops when the number of days runs out, whether or not everything has been assessed.

A fixed price, with a set number of days. The proposal shows a single total rather than a rate, but that engagement still runs under a day count. This is probably the most common pentest pricing model.

A fixed price for a fixed scope. The commitment is the scope document rather than the calendar. The provider carries the risk of the work taking longer than they estimated, but testing covers the agreed scope.

The trade-off with either fixed price model is that it gives the provider an incentive to finish quickly, which is why the scope document has to be detailed with coverage and depth.

Many providers offer free spot-rechecking of critical vulnerabilities on external penetration tests or application pentests. At Exploitr, focused retesting of remediated vulnerabilities is included on web application, API, and external network engagements, and you can request it directly from our platform.

Be suspicious of any outliers at the bottom end of the price point. Manual testing is priced on skilled consultant time, and a quote that sits well below the market rate could either mean you are buying an automated test wrapped in a pentest report, or they're possibly a smaller security provider that's new to the market and undercutting competitor pricing.

Whichever model you are quoted, get answers to these before you sign rather than after:

• Is the price fixed against a number of days, or against the agreed scope?
• What happens if the agreed scope cannot be fully tested within the allocated time?
• What is the proposed testing period, how much testing time is allocated, and is there a cap on it?
• What does the quoted price or rate include?
• If additional testing time is required, how is that handled and charged, and would it need your approval first?
• If a vulnerability needs further investigation, is that investigation included within the agreed scope?
• Is remediation testing or retesting included? If so, how much, and within what timeframe?
• What deliverables are included, such as the technical report, executive summary, presentation, attestation, and retest report?

Our penetration testing pricing page sets out what drives cost and typical ranges by service type, and the pentest cost calculator gives you an indicative figure for your own scope so you have a reference point when proposals come in.

Comparing proposals like for like

Two quotes for "a web application penetration test" can differ by several thousand pounds, and both be fair prices, because they are describing different pieces of work. Before comparing the cost side by side, check that the proposals align on what is actually being purchased.

• Asset counts. Check whether a network quote is priced against the address ranges you supplied, or the hosts that are actually live. The same applies to applications: one application, and that application plus its staging environment, are two different scopes.
• Network depth. How many Active Directory domains are covered, the type of approach to depth and lateral movement, and whether an internal test runs from a single network point or several. Each of those changes the amount of work involved.
• User roles. An application tested as an anonymous visitor takes a fraction of the time compared to one that's tested across four privilege levels, along with the authorisation controls between them.
• Authenticated or unauthenticated testing. Whether authenticated testing is in scope at all changes the depth of the assessment considerably.
• Testing days. Where a day count is given, compare it. Two providers quoting the same total cost, one for five days and one for three, are not offering you the same thing.
• Deliverables. Executive report, technical report, debrief, attestation letter, and retesting are sometimes bundled into the price and sometimes charged separately.
• Retest terms. Whether retesting is included, how long you have to use it, and whether it covers every finding or only the critical ones.

Once these line up, a price difference leaves the comparison down to your view of the provider itself.

Ask to see a sample report

Any established provider will have a sanitised sample ready to hand. Ask for a sample report, and when you have it, review the example content rather than the formatting.

Specifically:

• Is the scope and methodology present in the report, and does it match what was agreed for the engagement?
• Is the executive summary targeted to the correct audience, and does it explain what the business risk is without being overly technical?
• Do the findings describe the issue in detail, or could the same generic text be pasted into any report for any other client?
• Is the risk/severity rating justified, with reference to exploitability and impact, or is it simply asserted with a CVSS score?
• Are there reproduction steps provided that a developer or IT admin could follow, with sufficient evidence attached?
• Can the remediation advice be applied contextually to your business, or is it a generic paragraph about input validation?

A report assembled from a tool output reads very differently to one that's written by someone who understood the target environment, and has deep knowledge of the respective technology or process.

One of the most important aspects we consider with report writing, at Exploitr, is providing an appropriate narrative with the executive summary and finding details. Our guide to writing a pentest report covers what good looks like in more detail.

Ask what happens after the report lands

Your team then has to understand the findings, prioritise them, fix them, and then often demonstrate that remediation has happened for compliance purposes. The pentest report supports this, but it is one of the output deliverables and not the end goal.

One of the key things a reputable provider will do is to alert you to any impactful or critical issues they identified during the test, and not later in the report document. A serious issue that's found on day two should reach you on day two, especially if it is something that could be exploited by an attacker and cause a data breach.

Ask whether a debrief call is included and what the standard agenda is. A walkthrough with the consultant who was leading the pentest is worth considerably more than a follow-up call with an account manager.

Remediation activities often lead to follow-up questions. Whether a provider will answer them, without a new purchase order, demonstrates whether you are buying a one-off engagement or a commercial partnership.

The commercial and data-handling checks

Your procurement or legal team might be responsible for some of these topics, but there's no harm in raising them during provider evaluation:

• Professional indemnity and cyber liability insurance, with the cover levels confirmed in writing.
• Mutual NDA in place before scoping details are exchanged. Ask your potential provider for one, but be prepared to offer some high-level details to start the conversation.
• Where testing data and evidence are stored, for how long, and how they are securely destroyed afterwards.
• Data residency, and whether testing is delivered from the UK, US, or elsewhere.
• Which sub-processors are involved in delivery, including cloud tooling and AI services.
• For an RFP you may want to see references from clients, or a case study if client names cannot be shared.

Vulnerability data is among the most sensitive material a third-party will process for your organisation. It deserves the same scrutiny you would apply to any other supplier holding sensitive business data.

Warning signs to look out for when choosing a provider

The need for cyber security testing has grown massively over the last 10 years, and so has the number of providers to meet this demand. Here are some indicators to consider when procuring a provider:

• They will not name a consultant that would be assigned to your engagement or their qualifications. Many providers will provide consultant "CVs" as part of their proposal, so you know who could be leading your pentest.
• They quote a flat "5 days" for an internal network or web application pentest. Pentest engagements don't sit neatly into "days" of effort, but it is what providers will use to estimate the time allocation for consultants. A provider stating a flat figure, regardless of size and scale of your environment, may be padding the cost to fit into their calendar.
• They cannot provide a sanitised sample report. Experienced providers will have sample pentest reports ready to send out to prospective clients. This allows them to demonstrate their capabilities and instil confidence in you as a buyer.
• The scope is vaguely defined, or there are no explicit rules of engagement. A properly delivered security testing proposal will have a well written scope of work, methodology, and rules of engagement based on your specific requirements. This should be able to be handed to any experienced consultant, who would be able to deliver the test as you've intended.
• An automated or AI-delivered assessment is presented as being equivalent to manual, consultant-led testing. The advances of AI have shown that they can find vulnerabilities in source code, but AI cannot replace an experienced penetration tester's intuition and skillset.
• The report turns out to be an export of a scanner output with a branded cover page. Vulnerability scans are not pentests, and inexperienced penetration testers may often pad out a report with vulnerability scan results.
• There is pressure to sign an agreement before scoping has been fleshed out. This could show you that they're more focused on winning sales than delivering service quality.

The questions to ask providers

There are a few questions to raise with potential providers that can highlight how they work and what value you'll get from the engagement.

1. Who is assigned to this engagement, what certifications do they hold, and have they tested a comparable environment?
2. Is any part of the delivery outsourced or subcontracted?
3. Is the testing manual, AI-assisted, or automated, and what is the human doing?
4. Which methodology do you follow, and which parts of it apply to my systems?
5. What are the deliverables you offer as standard?
6. What happens if the scope is not fully covered in the time allocated?
7. Is retesting included, and for how long?
8. Can I see a sample report?
9. How is a critical finding handled if you find one mid-test?
10. Who can my developers ask questions of after the debrief?

Every Exploitr engagement is manual and consultant-led, delivered by an OSCP and OSCE-certified consultant who scopes the work, performs the testing, writes the report, and runs the debrief. Testing delivery is never outsourced or subcontracted. We price against a fixed scope rather than a set number of days, so if the work takes longer than we estimated, that is our problem rather than yours.

You can read more about how we work, or book a free scoping call and we'll happily answer any questions you have.

Adam Govier Founder & Lead Consultant

OSCP OSCE

Adam is the founder and lead consultant at Exploitr. He holds OSCP and OSCE certifications and leads all client engagements, from scoping through to delivery and debrief.