Penetration Testing Buyer's Guide for 2026: How to Choose a Vendor

Who this guide is for

If you are the person on the hook for picking a penetration testing vendor — a head of security, a CTO, a head of engineering, a compliance lead, or the founder doing it because the customer just asked — this is the conversation you would have with a senior tester before signing any statement of work. We have written it the way we would brief our own buyers, not the way a pricing page is usually written.

The market in 2026 looks different from a few years ago. Continuous scanning has become table stakes, "pentest-as-a-service" platforms have proliferated, AI-augmented tools now handle a meaningful share of routine coverage work that used to fill a junior tester's week, and customer questionnaires increasingly ask for things that were rare not long ago — model red-teaming reports, EU AI Act conformity evidence, prompt-injection resistance. The buying motion has to keep up.

What you are actually buying when you buy a pentest

Being precise about the deliverable matters, because most bad engagements trace back to buyer and vendor holding different mental models of the product.

A penetration test is not a software product, an audit, or a compliance certificate. It is a time-boxed, scope-bound investigation conducted by humans; the output is a report and a remediation conversation. You are paying for three things, in this order:

• The testers' time and reasoning applied to your specific attack surface — not a generic scan, not a checklist walked once a quarter, and not the same boilerplate report with your logo on top.
• A report that survives contact with engineers and auditors. Engineers need reproduction steps, evidence, severity, and paste-ready remediation. Auditors need control mapping. The board needs one page. The same report has to serve all three.
• A working relationship through remediation. Critical findings shared the same day they are confirmed, a retest of reported findings as standard, and a vendor who answers when your engineers ask "what does this remediation actually look like in our stack."

Anything in the proposal not directly producing one of those three things is overhead. Feature checkboxes — dashboards, briefing decks, AI-flavored findings prioritization — can be useful, but none of them are the product. The testers and the report are the product.

The four vendor archetypes in 2026

The market sorts into four broad shapes. Each has a buying motion, and each is the right answer in a different situation.

Archetype	What they look like	Best for	Watch for
Senior boutique	Small, senior-heavy team, narrow service surface, principals doing the work	Deep technical engagements on a specific surface — SaaS app, API, cloud, AI feature	Bench depth for parallel engagements; PTO and sequencing
Mid-market consultancy	Larger multi-region firm with a mixed senior/junior bench and formalized methodologies	Multi-app, multi-region engagements with parallel compliance audits	Who actually does the testing after signing
Pentest-as-a-service platform	Software platform plus crowdsourced or curated tester pool, continuous engagement model	Programs that want continuous coverage with rolling reports	Tester quality variance; depth on business-logic flaws
Big-4 / national-brand	Cybersecurity practice inside a larger consultancy, brand-led, partner-led sales	Board-mandated tests where audit-firm independence or brand is the requirement	Price per finding; how much of the budget pays for the testers vs the brand

Brand recognition correlates poorly with technical depth on a specific surface. Pick the archetype that matches the engagement, and ask each candidate for a redacted sample report before you sign anything.

Twelve questions that separate sales decks from real testing

If your shortlist passes these on a thirty-minute call, you are in good shape. If they don't, the report will not surprise you.

1. Who specifically is doing the testing? Names, roles, years of experience. Senior testers should be on the engagement, not the call. "We will assign a team after signing" means you are buying a shape, not a team.
2. Can we see a redacted sample report? Not a template — a real, redacted report from a similar engagement. If they can't share one under NDA, that's a signal.
3. What is your methodology and where is it documented? Look for explicit alignment with OWASP WSTG, ASVS, API Top 10, NIST SP 800-115, PTES, and where relevant OWASP LLM Top 10. "Industry best practices" is not a methodology.
4. How much testing is manual versus tool-assisted? A good answer acknowledges both. Manual reasoning for authorization, business logic, and chained findings; tools for coverage on known issues. The honesty of the answer matters more than the ratio.
5. How do you handle critical findings during the engagement? Same-day disclosure on a shared channel is the right answer. Saving criticals for the final report is not.
6. Is retest of reported findings included in the price? Should be standard with the report reissued post-fix. Retest as an hourly add-on is a red flag.
7. How do you scope authorization and multi-tenant testing? They should ask for your role matrix, tenant model, and feature-by-role expectations. If they do not bring it up, they are not planning to test it.
8. What is your approach to safe testing in production? Throttling, exclusions, communication windows, and explicit rules on destructive techniques.
9. How do you handle findings in third-party components? A mature tester knows when a finding is upstream and how to write it up so your engineers do not chase a ghost.
10. What compliance frameworks have you mapped to before? SOC 2, ISO 27001, PCI DSS v4, HIPAA, and where relevant FedRAMP, NIS2, EU AI Act. They should have done it many times.
11. Do you support AI feature testing? Prompt injection, RAG leakage, tool-use safety. If your product has an LLM feature, this is no longer optional.
12. What does a typical week-by-week timeline look like? A vendor that cannot describe one has not done many engagements like yours.

How to read a sample report

The sample report is the most predictive artifact you will see during evaluation. Read it the way you would read code.

• Open a high-severity finding end to end. Working proof of concept? Reproduction steps clear enough to replay? A remediation in the language of your stack, or a generic "validate input on the server side" line? Generic remediation is the most reliable signal that the test was shallow.
• Open a medium-severity finding. Mediums separate good vendors from great ones. Great vendors write them up with the same care as criticals — chained mediums are how real intrusions happen.
• Open the executive summary. Does it tell the story of the engagement, or is it a colorful chart with a vendor logo? The narrative is the value.
• Open the compliance mapping. Are findings tied to specific control IDs you can paste into your audit response? "Supports SOC 2 readiness" does not help an auditor.
• Look for what is missing. A web app report with no authorization, IDOR/BOLA, or multi-tenant findings is almost certainly an incomplete engagement.

What drives pentest pricing in 2026

Pentest pricing is scope-based and varies widely by region, bench seniority, and engagement depth. Rather than publish a number that will be wrong for your scope, here is what drives cost up or down and how to compare quotes apples-to-apples.

Engagement	Typical duration	What scales cost
Single web application	2–3 weeks of testing + reporting	Endpoint count, role count, integrations, tenancy model
API (REST or GraphQL)	2–3 weeks of testing + reporting	Endpoint inventory, auth model, business-logic depth
Multi-app SaaS engagement	3–5 weeks of testing + reporting	App count, role matrix, shared services, SSO
External + internal network	3–5 weeks of testing + reporting	IP scope, segmentation, AD/IdP, jump hosts
Cloud (AWS/Azure/GCP)	2–4 weeks of testing + reporting	Account count, IAM depth, workload type
Red team engagement	4–6 weeks of operations	Objectives, detection program, physical scope
AI / LLM feature test	2–4 weeks of testing + reporting	Model surface, RAG/tool-use depth, OWASP LLM coverage
Retest of reported findings	Days, after fixes	Should be included with the base engagement

To compare quotes fairly, make sure each vendor is bidding on the same surface inventory and role matrix, and that retest, reporting, and remediation support are all in the base price. The cheapest quote on a shortlist is rarely the right answer; the second-cheapest, on a like-for-like scope, often is. Brand premium is real and sometimes worth it — just make sure the testers behind the name are still doing the work.

Compliance alignment that matters in 2026

If a pentest is feeding an audit, framework alignment is not optional — and the relevant set has grown since 2024. Your vendor should be fluent in the frameworks you actually operate under, and at least conversant in the rest so they can scope around them when they appear.

• SOC 2 (AICPA TSC, 2017 with 2022 points of focus): Annual external penetration testing aligned with CC7.1 monitoring expectations is the de facto standard. Findings should be mapped to specific points of focus.
• ISO 27001:2022: Annex A 8.8 (vulnerability management), 8.29 (security testing in development and acceptance), 8.34 (protection during audit testing). The 2022 revision raised the bar on documented testing programs.
• PCI DSS v4.0.1: Requirement 11.4 requires both internal and external penetration testing with explicit segmentation testing, plus tests after any significant change. The deadline for v4 requirements is March 31, 2025 — by 2026 your assessor will expect full compliance.
• HIPAA Security Rule: The HHS Notice of Proposed Rulemaking issued in late 2024 / early 2025 proposes tighter technical testing expectations including periodic penetration testing and documented results. Whether and when the final rule lands is uncertain at the time of writing; track the rulemaking and scope conservatively against the proposed text.
• FedRAMP Rev. 5: Penetration testing aligned with the FedRAMP Penetration Test Guidance and performed under a 3PAO methodology, against the Rev. 5 baseline derived from NIST SP 800-53.
• EU NIS2 directive: Transposition deadline was 17 October 2024; member state adoption is still uneven. Essential and important entities are expected to perform regular technical security testing — pentests are the de facto evidence.
• EU AI Act: Entered into force August 2024 with phased application through 2026 and beyond. High-risk AI systems require conformity assessments; adversarial testing of those systems is increasingly part of the evidence base.
• DORA (financial services): Applicable to in-scope EU financial entities from 17 January 2025. Threat-led penetration testing (TLPT) under DORA references the TIBER-EU methodology.

Ask any candidate vendor how recently they have delivered a report mapped to the frameworks you actually need. "We can do that" is a different answer from "here is the mapping section from our last engagement under that framework."

Scoping the engagement so it doesn't cost too much or miss too much

Most cost overruns and missed findings trace back to a poor scoping call. Bring three artifacts to the call:

• A surface inventory. Apps with rough endpoint counts, APIs with endpoint counts, networks with CIDR ranges, cloud accounts with workload type. Half a page is enough; precision matters more than length.
• A role and tenant matrix. Roles, tenants, and what each role is expected to be able to do across critical resources. For a SaaS product this is the single highest-leverage document you can bring.
• A business outcome. Why you are running this engagement. A customer asking for a current report, a SOC 2 audit on the calendar, a board-level concern, a new feature shipping, a regulator inquiry. The reason shapes the scope.

A real scoping call ends with a fixed scope, a fixed price, a fixed date range, and a one-page statement of work. A scoping call that ends with "we will send a proposal next week" usually means the vendor is figuring out their pricing — that is not a deal-breaker, but it is a tempo signal.

Red flags in proposals

The proposal document tells you more than the sales call. Read for the following:

• Findings count promises. "We typically find 20+ vulnerabilities per engagement." A real pentest finds what is there; promising a count means inflating or padding.
• No named testers, no resumes. If the proposal does not say who is doing the work, the answer is "whoever is on the bench."
• Retest as a separate line item. A small line for retest is fine; an hourly retest with no included scope means the report you ship will reflect test-day state.
• "Daily executive briefings" as a headline feature. Briefings are fine; if they are the headline of the proposal, they are dressing up a thin engagement.
• Compliance language that does not mention specific controls. "Supports your SOC 2 program" with no Trust Services Criteria, no points of focus, no CC mapping is marketing copy.
• One-week engagement on a multi-app SaaS. The math rarely works. Two senior testers for a working week is ten tester-days, and a meaningful share of that goes to reconnaissance, role-matrix setup, and reporting. On a multi-tenant product you are buying coverage, not depth.

Contract clauses that matter

Most pentest contracts are unremarkable, but a few clauses are worth your legal team's attention:

• Data handling and retention. What does the vendor do with screenshots, exfiltrated test data, and report drafts at the end of the engagement? Default: deletion within 30–90 days, with written confirmation.
• Subcontractors. Are subcontractors used, who are they, where are they located, and do they sign NDAs with your terms.
• Right to share the report. You should have unlimited right to share the final report with customers, auditors, regulators, and prospects under NDA. Avoid clauses that gate report distribution on vendor approval.
• Liability cap. Standard is one to three times the engagement fee. Pushback above that is usually pointless.
• Insurance. Professional liability (errors and omissions) and cyber liability with a meaningful limit. Ask for certificates of insurance.
• Right to rerun and right to walk. If the engagement materially underdelivers, an articulated process for re-engagement at no extra cost is a sign the vendor stands behind the work.

What happens after the report

The engagement is not the report — the engagement is the report plus what happens next. A mature vendor builds the following into the price by default:

• A remediation walkthrough. A working session with your engineering team where the tester walks through findings, answers stack-specific questions, and pairs on the harder remediations.
• A retest of all reported findings. Once your team has fixed the items, the affected findings are retested and the report is reissued. The report your customers and auditors see should reflect post-fix state.
• An executive readout. One conversation with your security leadership or board liaison, framed around risk posture and remediation progress, not finding counts.
• An open Slack or email channel for follow-ups for a defined window after report delivery — usually 30 to 90 days.

Whether a pentest produces value comes down to whether the report gets fixed. Vendors that build remediation support into the engagement price get more reports fixed than vendors that bill it hourly.

The buyer's checklist

A one-page version you can paste into your evaluation tracker:

• Redacted sample report received and reviewed by a senior engineer.
• Named testers with resumes attached to the proposal.
• Methodology documented and aligned with OWASP WSTG, OWASP ASVS, OWASP API Top 10, NIST SP 800-115, and where relevant OWASP LLM Top 10.
• Role-matrix and multi-tenant testing explicitly scoped if applicable.
• Retest of reported findings included in the base engagement price.
• Same-day disclosure of critical findings agreed in writing.
• Compliance mapping to your specific frameworks (SOC 2, ISO 27001, PCI DSS v4, HIPAA, FedRAMP, NIS2, AI Act) included in the report deliverable.
• Fixed scope, fixed price, fixed date in the statement of work.
• Right to share report with customers, auditors, and regulators under NDA.
• Insurance certificates received.
• Data handling, retention, and subcontractor terms reviewed by legal.
• Remediation walkthrough and 30- to 90-day follow-up window included.

How CyberGuards answers this checklist

Treating the checklist above as a worked example, here is how we would answer each item. Use it as a comparison anchor — if a candidate cannot answer as concretely on each line, that is a useful signal.

Checklist item	How we answer it
Who specifically does the testing	Named senior tester on the proposal, on the scoping call, and on the engagement. No subcontractors, no junior handoff after signing. The certifications behind the bench include OSCP, OSWE, GPEN, GXPN, CRTO, CCSP, CISSP, and CREST CRT.
Redacted sample report	Shared under NDA before signing. Every finding has a working proof of concept, reproduction steps, severity, CVSS, and a paste-ready remediation written in the language of your stack.
Methodology	OWASP Top 10, OWASP API Top 10, MITRE ATT&CK, NIST SP 800-115, and PTES — the frameworks we test against, referenced in every report. OWASP LLM Top 10 applies on AI-feature engagements.
Critical findings during the engagement	Same-day disclosure through a shared channel with your security and engineering leads. Criticals do not wait for the final report.
Retest of reported findings	Included in scope at no extra cost. After fixes, affected findings are retested and the report is reissued so the version your auditors and customers see reflects post-fix state.
Authorization and multi-tenant testing	Role-matrix and tenant-matrix coverage is part of the scoping conversation. Bring or build a role × resource matrix; we test against it as part of authenticated testing.
Compliance mapping	Findings mapped to SOC 2 trust criteria, ISO 27001:2022 Annex A, PCI DSS v4, HIPAA safeguards, and NIST CSF / 800-53 in our compliance pentest. Other frameworks (FedRAMP, NIS2, EU AI Act, DORA) can be scoped on the call where they apply to your operating context.
AI feature testing	A dedicated AI security testing service covering prompt injection, RAG leakage, tool-use safety, and OWASP LLM Top 10 — for teams shipping LLM features into production.
Pricing structure	Scope-based, fixed price, fixed delivery date. No hourly billing, no scope creep, retest in the base price.
After the report	Remediation walkthrough with your engineering team, retest and reissue, executive readout, and a direct line to the senior tester through and beyond the engagement.

If you are evaluating two or three vendors and want a clean comparison, ask each candidate to answer the same twelve checklist lines in writing. The contrast is usually clarifying. We are happy to do this on a thirty-minute scoping call — no slides, no pitch — and you leave with a fixed scope, a fixed price, and a fixed date whether or not you choose us.

A simple decision framework

If you are between two candidates and the proposals look close, decide on the basis of three weighted criteria, in this order:

1. The report. The redacted sample is the single most predictive artifact. Pick the report you would rather your engineers receive.
2. The testers. Named, senior, available for the engagement window, and ideally on the scoping call. If both reports are close, pick the team you would rather have on the worst day of an incident.
3. The relationship. Communication tempo on the sales call is the communication tempo you will get during the engagement. Pick the vendor whose tempo matches yours.

Price is not on this list because, within a sensible band, it is rarely the deciding factor. The cost of a bad engagement is a missed finding that ships into production, a customer that does not renew, or an audit finding that comes back next year. Those costs dwarf the delta between the cheapest and second-cheapest quote.

If an engagement still underdelivers, you have done your job — pentests are a probabilistic product. Run a retest with a different vendor and tighten the scoping conversation next time.

Why teams pick CyberGuards

We built CyberGuards for the buyer this guide is written for. Three things tend to make customers stay across multiple engagements:

• Senior testers, every engagement. The person on the scoping call is the person doing the work. No subcontractors, no junior handoffs.
• Reports engineers actually fix. Working proofs of concept, paste-ready remediations in the language of your stack, and a control mapping auditors accept on first read.
• Retest in scope by default. The report your customers and auditors see reflects post-fix state, not test-day state.

The long version is a thirty-minute scoping call where we look at what you have, tell you what we would test first, and quote a fixed scope, price, and date — whether or not you choose us. Most calls happen the same week.