Most of what gets sold as "penetration testing services" isn't a penetration test. It's a nuclei scan with a company logo on the cover, a CVSS number copied straight out of the NVD, and a finding that reads possibly vulnerable. You pay four figures, wait two or three weeks, and receive a PDF you could have generated yourself over a lunch break. Avoiding that outcome is the entire point of this guide.
I buy and review pentests for a living — for our own audits and for teams getting ready for SOC 2, ISO 27001, and PCI DSS assessments. The thing that separates a good provider from an expensive one is almost never price. It's whether anyone actually proved the findings, or just flagged them. Below is how to read the market, evaluate a penetration testing company, and know exactly what you're signing before the invoice shows up.
Last updated: 2026.
What you're actually paying for
A penetration testing service is a person or system that tries to break into your target the way a real attacker would — chaining weaknesses together, bypassing authentication, reaching data or admin — and then documents how they did it, with proof. A vulnerability scan, by contrast, enumerates known CVEs and misconfigurations and hands you a list. Both are useful. They are not the same product, and plenty of "pen testing services" quietly sell you the second one at the price of the first.
If that distinction matters for how you spend your budget, we've written it up separately in vulnerability assessment vs penetration testing. For now, hold onto one line: a scan tells you what might be wrong; a pentest tells you what an attacker can actually do.
Penetration testing services come in three delivery shapes, and the shape you pick matters as much as the vendor:
- Project-based engagement — a point-in-time test with a fixed scope and a report. Good for an annual requirement, a new product launch, or a specific audit deadline.
- Consulting / retainer — human specialists on call for deeper red-team work, threat modeling, or complex environments. Expensive, slow, and worth it for the hardest targets.
- Penetration testing as a service (PTaaS) — continuous, platform-delivered testing rather than a once-a-year event. If your code ships weekly, an annual test leaves you blind for eleven months; PTaaS closes that gap.
Most buyers over-index on the annual project and under-invest in continuous coverage. A single test in March says nothing about the auth bug you shipped in July.
Types of penetration testing services
Providers slice their offerings by scope. You should know which of these you're buying, because "we do penetration testing" can mean wildly different things.
External and network penetration testing
The classic. Everything reachable from the public internet — your perimeter, exposed services, VPN gateways, mail, DNS. External and network penetration testing services look for exposed admin panels, weak or default credentials, unpatched services, and SSRF or misconfiguration that lets an outsider pivot inward. This is the baseline most compliance frameworks expect, and it's where an attacker starts.
Internal penetration testing
Assumes the attacker is already inside — a phished employee, a rogue contractor, a compromised laptop. Testers work from a foothold on the internal network and try to escalate: lateral movement, privilege escalation, Active Directory abuse, reaching the data that matters. It answers "how bad is one compromised machine?"
Web application penetration testing
The largest category by demand, and rightly so — most breaches ride in through the app. Web application penetration testing services work the OWASP Top 10 and beyond: IDOR, broken access control, injection, authentication bypass, insecure deserialization, business-logic flaws a scanner will never find because they require understanding what your app is for.
API penetration testing
APIs are their own beast and deserve their own scope. The OWASP API Security Top 10 — broken object-level authorization (BOLA), broken function-level authorization, mass assignment, excessive data exposure — describes failures that automated scanners routinely miss because they don't understand your object model. If your product is API-first, don't let this get folded into a generic "web app" line item.
Mobile penetration testing
iOS and Android apps, plus the backends they talk to: insecure local storage, weak certificate pinning, hardcoded secrets, and the API layer behind the app (which is usually where the real damage is).
Cloud penetration testing
AWS, Azure, and GCP configurations — over-permissioned IAM roles, public storage buckets, exposed metadata endpoints, and the identity misconfigurations that turn one leaked key into full account takeover. Cloud testing overlaps with configuration review; ask a provider how much is real exploitation versus a settings audit.
Social engineering
Phishing, pretexting, sometimes physical access. Useful, but scope it deliberately and get written authorization — this is the service most likely to cause internal drama if it's not agreed on in advance.
What a real engagement includes (versus scan-and-PDF)
Here's the honest test. A real penetration testing service does the work a tool can't: it validates. Anyone can run a scanner. The value is in a human or a capable system taking each candidate finding and answering — can I actually exploit this, in this environment, against these defenses?
If a finding ships without a reproduction path, it's a hypothesis, not a vulnerability. Treat "possibly vulnerable" as unfinished work.
A genuine engagement produces:
- Proven exploitation, not speculation. The report shows the request that worked, the response that proved it, the data that came back. A working proof-of-concept, not a CVSS score borrowed from a database.
- Chained findings. Attackers don't stop at one bug. Real testing shows how a low-severity info leak plus a weak reset flow adds up to account takeover — a chain no scanner scores because it grades each item in isolation.
- Business-logic coverage. Coupon abuse, negative-quantity carts, tenant isolation failures, workflow bypasses. These are invisible to automation and are frequently the worst bugs you have.
- False-positive filtering. A good provider does not dump 400 raw scanner rows on you. They've already thrown out what doesn't reproduce, so your engineers aren't triaging noise.
- Actionable remediation. Step-by-step fixes tied to each finding, not "implement input validation."
If a service can't show you a redacted sample of this before you buy, that tells you what you'd be getting. Ask for one — here's what a real one looks like.
How to choose a penetration testing company
Provider evaluation is where buyers get burned, because the sales conversation sounds identical across vendors. These are the axes that actually differentiate them.
Scope coverage
Make them define scope in writing — assets, IP ranges, domains, apps, APIs, credentialed vs uncredentialed, in-scope and explicitly out-of-scope. Vague scope is how you end up with a "pentest" that touched your marketing site and nothing that holds real data. Match the scope to where your risk lives, not where testing is convenient.
Evidence quality
This is the single most important criterion. Demand proven PoC. When a report says "vulnerable," the correct follow-up is "show me." Providers who exploit and demonstrate are selling a different product than providers who scan and flag, even when the price is the same.
CVSS done properly
CVSSv3 is fine as a shared language, but a base score without environmental context is close to meaningless. A critical CVSS on an internal, unreachable service may matter less than a medium on your login flow. Good providers explain their reasoning and reflect your environment; weak ones paste the NVD number and move on.
Retest policy
You'll fix things. Does the retest to confirm your fixes come included, or is it a separate invoice? A provider who validates remediation is invested in you actually being secure, not just in delivering a document. Get the retest window and cost in writing before you sign.
Data handling, NDA, and DPA
You're inviting someone to attack systems that hold your data. Ask where findings and any captured data are stored, how long they're retained, and who has access. Get an NDA. If you're in the EU or handle EU data, get a DPA and confirm GDPR-appropriate handling. "Zero data retention" is a meaningful answer here; "we keep everything on a shared drive" is a reason to walk.
Methodology
Credible providers work to a recognized standard — PTES, NIST SP 800-115, OWASP for apps and APIs. Methodology matters because it defines coverage: it's the difference between "we poked around" and "we systematically worked every category." If you want to see how the phases fit together, we break it down in our penetration testing methodology guide.
Reporting layers
A usable report speaks to two audiences. An executive summary your CISO or auditor can read in five minutes — risk posture, headline findings, business impact. And an engineering layer with the technical detail your developers need to reproduce and fix. One-layer reports fail one of those readers every time.
Compliance mapping
If the test exists to satisfy an audit, the report should map findings to the framework you care about — SOC 2, ISO 27001, NIST CSF, GDPR Art. 32, PCI DSS v4.0 (note Requirement 11.4's specific pentest expectations). Be clear-eyed about what mapping is, though: a pentest report supports an audit. It is not itself a certification, and no testing vendor issues one.
Red flags
Walk away, or at least ask hard questions, if you see any of these:
- A flat quote with no scoping call. Real scope requires a conversation. A price before any questions means a canned scan.
- "Possibly vulnerable" findings with no PoC. Unvalidated output dressed up as a pentest.
- Refusal to share a redacted sample report. They either don't have a good one or don't want you to see it.
- Retest quoted as a surprise add-on. Fine to charge for, not fine to hide.
- No named methodology. "Our proprietary process" with nothing behind it.
- Vague credentials. Ask who is doing the testing and what they've done.
- A report that's mostly a scanner export. 300 rows of raw tool output, un-triaged, is not a deliverable.
- No NDA or DPA on offer. For anyone touching your systems, this is non-negotiable.
Questions to ask on the sales call
Bring these. The answers separate the real services from the resellers in about ten minutes:
- What exactly is in scope, and what's explicitly excluded?
- Do you manually validate findings, or is this primarily automated? Can I see a redacted sample?
- How do you handle CVSS scoring — do you adjust for our environment?
- Is a retest of our fixes included? What's the window and cost?
- Where is our data stored, how long is it retained, and who can access it?
- What methodology do you follow (PTES, OWASP, NIST SP 800-115)?
- Will the report have both an executive summary and an engineering layer?
- Can you map findings to [name your framework]?
- What's the turnaround from kickoff to final report?
- Who is actually doing the testing?
The penetration testing services buyer's checklist
Run any provider through this before you commit. If a column-two answer is missing, that's your negotiation — or your exit.
| What to check | A good answer looks like | Walk away if |
|---|---|---|
| Scope | Written, specific, matched to your real risk | "We'll figure it out as we go" |
| Evidence | Working PoC per finding — request, response, impact | "Possibly vulnerable," no reproduction |
| CVSS | CVSSv3 adjusted for your environment | NVD score pasted with no context |
| False positives | Pre-triaged; noise removed | Raw scanner export, hundreds of rows |
| Retest | Included, with a stated window | Undisclosed add-on, or none |
| Data handling | Defined retention, NDA + DPA available | Unclear storage, no NDA |
| Methodology | PTES / OWASP / NIST SP 800-115 | "Proprietary," unspecified |
| Reporting | Executive + engineering layers | One-size PDF for everyone |
| Compliance | Findings mapped to your framework | No mapping, or claims to "certify" you |
| Turnaround | Committed dates | Open-ended, weeks of drift |
What penetration testing services cost
Prices range from a few thousand euros for a tightly scoped web app to well into five figures for multi-week red-team consulting. The spread is driven by scope, depth, and how much of the work is human. Cheap-and-automated and expensive-and-manual are both legitimate — they solve different problems. What you want to avoid is paying manual-engagement prices for scan-and-PDF output. We break the numbers down in detail in how much a penetration test costs; read it before you accept any quote, so you know what a fair one looks like.
How BackDoor delivers penetration testing services
Full disclosure on where this is written from. BackDoor is an autonomous AI black-box penetration test: a swarm of AI agents attacks your target from the outside — no source code, no backend access — the way a real external attacker would. A complete pentest plus report lands in about 5 hours instead of the usual 4–6 weeks, starting at €5,100.
The part that matters for this guide is the deliverable. Every finding comes with a proven, working proof-of-concept, CVSSv3 scoring, and step-by-step remediation. Findings map to SOC 2, ISO 27001, NIST CSF, GDPR Art. 32, and PCI DSS v4.0 for audit readiness. Data handling is zero-retention, with NDA and DPA available — which, if you re-read the evaluation checklist above, is most of the "good answer" column.
Where does this fit, and where doesn't it? An evidence-first autonomous service is strong for continuous testing, fast pre-audit readiness, and covering your external attack surface on every release instead of once a year. For site and API scopes specifically, that runs as a dedicated website penetration testing engagement. It is not a full replacement for human red-teaming on the hardest, most bespoke engagements, and it is not a regulatory attestation like DORA TLPT. Compliance mapping is exactly that — mapping — not a certificate we or anyone else can issue by running a test. Any provider that tells you otherwise is failing your checklist.
What to actually do next
Buying penetration testing services well comes down to one discipline: refuse to pay for hypotheses. Make every provider prove their findings, define their scope in writing, and show you a redacted report before you sign. Run the ten questions on the sales call and the checklist over the proposal. That process alone filters out most of the scan-and-PDF market.
If you want to see what evidence-first output looks like before you talk to anyone, pull the sample report or scan your target — a full pentest with a proven-PoC report in about five hours, from €5,100. Whatever you choose, choose the service that shows its work.
Frequently asked questions
How much do penetration testing services cost?
Prices run from a few thousand euros for a tightly scoped web app up into five figures for multi-week red-team consulting, driven by scope, depth, and how much work is done by humans. Cheap-and-automated and expensive-and-manual are both legitimate for different problems; the mistake is paying manual-engagement prices for scan-and-PDF output. BackDoor's autonomous test starts at €5,100 with a full proven-PoC report in about five hours.
What should a penetration testing service include?
A real engagement validates findings rather than just flagging them, so it should include working proof-of-concept exploits (not just possibly vulnerable), environment-adjusted CVSSv3 scoring, chained and business-logic findings, and step-by-step remediation. The report needs two layers — an executive summary and an engineering layer — plus compliance mapping and a defined retest of your fixes. Data handling with an NDA, and a DPA for EU data, should be part of the deal.
How do I choose a penetration testing company?
Judge providers on what the sales pitch hides: written scope matched to your real risk, evidence quality (demand a redacted sample report with proven PoC), a clear retest policy, a named methodology (PTES, OWASP, NIST SP 800-115), and proper data handling with NDA/DPA. Ask who is actually doing the testing and whether they map findings to your framework without claiming to certify you. Walk away from flat quotes with no scoping call or surprise retest fees.
How often should we get a pentest?
Most frameworks expect at least an annual test plus a retest after any significant change, but an annual point-in-time test leaves you blind for the other eleven months if you ship code frequently. Teams releasing weekly should move to continuous testing (PTaaS) so every meaningful change to the attack surface gets checked. At minimum: annually, after major changes, and before an audit.
See it on your own site
Full report with proof, exploits, and fixes — in ~5 hours, from € 5,100.
Written by

Application Security Engineer
Ilya works on application and API security at BackDoor — turning scan findings into prioritized, developer-ready fixes and compliance-mapped evidence for SOC 2, ISO 27001, and PCI DSS.