Pentesting Resources & Buyer Guides

Pentesting resources and buyer guides are structured evaluation tools that help organisations compare methodology, reporting quality, provider type, and commercial terms before selecting a penetration testing vendor.

This guide is for buyers who already know they need a penetration test and now need a defensible way to shortlist providers. Use it to:

• separate manual, expert-led testing from scanner output
• weight criteria to your actual driver
• run vendor conversations that expose weak scope, weak reports, and weak post-engagement support

It is not a tools list. It is a procurement framework you can take into scoping calls, RFPs, and internal sign-off.

What Separates a Real Pentest from an Automated Scan

A penetration test is a manual, expert-driven security assessment that attempts to exploit vulnerabilities to understand real-world business impact, not a report generated by automated scanning tools.

A vulnerability scan is automated, matches known weakness signatures, and produces a list. A penetration test is authorised, human-led work that chains findings, attempts exploitation, and explains what an attacker could actually do to the business.

Red teaming is a different service: an objective-led simulation of a determined adversary, not a scoped vulnerability assessment.

Do not buy a scan labelled as a pentest, and do not buy a pentest if what you actually need is a red team.

Treat scanner-only work as inventory, not assurance. Automated scans miss business-logic errors, broken authorisation, and chained paths that never appear as a single high CVSS row.

That is the commercial risk: a cheap scan sold as a pentest can still generate an audit-looking PDF while leaving the path to data or admin access untested.

The most reliable way to test whether a vendor does genuine manual testing is to request a redacted report sample. Look for:

• proof-of-concept steps
• exploitation chains
• business context

Ask whether the sample shows how two or three medium issues became a high-impact path. A CVSS list with no attack narrative is a scan dressed as a pentest.

The Core Evaluation Criteria: What to Assess Before You Shortlist Any Vendor

Assess every pentesting vendor against seven criteria before they enter a shortlist: methodology, scope, reporting, retesting, tester qualifications, timeline, and data handling.

Score vendors on evidence, not brochures. A defensible shortlist is built from written methodology, a redacted report, named testers, and clear commercial boundaries.

Prepare a draft scope before you ask for quotes. Vague requirements produce vague proposals, and vague proposals hide exclusions.

Methodology and quality

Methodology quality is proven by a written, manual-first process that includes attack path analysis, not by marketing claims about ethical hacking.

Ask for a sample methodology document. A strong document states how testers combine reconnaissance, manual exploitation, and attack-path analysis, and where automation is used only as a starting point. Ask directly how they separate manual testing from scanning, and how they report chains of issues rather than isolated CVEs.

Attack path analysis is the difference between a list of weaknesses and an explanation of how an attacker would actually move.

Low or medium findings often matter only when they combine: an information leak, a weak access-control check, and a privilege-escalation bug can become a business-critical path. Ask vendors how they identify, validate, and write up those chains. If they can only talk about individual CVSS rows, they are not testing the way attackers work.

Scope and approach

A thorough scope defines the attack surface, test types, exclusions, and boundaries before any testing window opens.

A well-defined scope names systems, applications, APIs, and networks in play, the test types (for example external, internal, web application), what is explicitly out of bounds, and how newly discovered assets are handled. It should also state authentication levels, test accounts, environments, and whether cloud, APIs, and third-party integrations are in or out.

Vague scope is the usual reason critical systems go untested while the report still looks complete.

Read the exclusions as carefully as the inclusions. If the proposal omits identity providers, admin interfaces, or the APIs that actually move data, the engagement will not answer the question you think you bought.

Reporting and remediation

A high-quality pentest report includes an executive summary, methodology, findings with CVSS scores and business context, proof-of-concept steps, remediation guidance, and a clear risk rating.

Request a redacted report sample during sales. Score it against the checklist below. If the sample cannot be used by both a CISO and an engineer, the live report will not be usable either.

CVSS is a useful severity input. It is not a substitute for exploitability, asset criticality, or business impact. A high finding that cannot be reached in your architecture is not the same as a medium finding that leads straight to customer data.

Mark each item present, partial, or absent on the sample. A vendor who cannot share a sample, or whose sample fails more than two of these points, should not reach the shortlist.

Retesting policy

A usable retesting policy states whether retesting is included in the original price, what is in scope for retest, and how quickly it can be scheduled.

Get this in writing before award. Confirm whether retest covers only the listed findings, related controls, or a full re-run, and whether a revised report is included. An extra charge or an undefined wait after remediation is a common budget surprise and delays closure of audit findings.

Tester qualifications

Tester quality is assessed by the named people assigned to your engagement, their certifications, and their years of hands-on testing, not by a generic team of experts line.

Ask who will actually test. Look for OSCP, OSWE, CREST, or equivalent credentials, plus evidence of relevant stack and industry experience. Ask whether those named people can be substituted without your agreement.

You are hiring the testers. The company brand does not sit at the keyboard.

Timeline and process

A realistic timeline is set by scope and attack surface and should cover a scoping call, a defined testing window, reporting, and retesting.

Small, well-bounded web application tests can complete in days of testing plus reporting time. Multi-system internal and external work often needs several weeks from kick-off to debrief.

Ask for the full sequence, including how findings are communicated during the window if a critical issue appears, and ask about lead time to start. Strong testers book ahead, and a short remaining compliance deadline is not a reason to accept the first available scanner-led slot.

Data handling and confidentiality

Data handling must be explicit: storage location, access controls, NDA terms, retention, and UK GDPR obligations.

Pentesting exposes credentials, architecture, and sometimes production data. Ask where evidence is stored, who can access it, how long it is kept, and how it is destroyed. Ask whether screenshots, logs, and payloads leave your environment, and whether subprocessors or platforms will hold copies.

For UK and EU buyers, GDPR processing terms, lawful basis, and data-processing agreements are procurement items, not footnotes. If you need UK or EU residency for evidence, say so before scoping, not after the first screenshot is taken.

Choose Your Evaluation Priority: Match Your Criteria to Your Context

Match your pentesting evaluation criteria to one primary driver: compliance, risk reduction, security maturity, or incident response.

A compliance-driven pentest and a risk-reduction pentest are not the same engagement. A test can satisfy an auditor’s evidence request and still miss the attack path that matters to the business.

Decide which driver you are optimising for before you compare vendors. UK and EU programmes often have a compliance clock (GDPR evidence, DORA, PCI DSS, ISO 27001) running at the same time as a real risk need. Name which one governs scope if they conflict.

If two drivers apply, name a primary and a secondary. Do not let a compliance deadline silently strip manual testing out of the scope.

An audit-shaped report that never attempted exploitation can still leave you exposed, and it can still fail you later when a real incident shows the path the test never walked.

Consultancy vs. PtaaS vs. Crowdsourced Testing: Which Provider Type Fits Your Needs?

Choose consultancy, PtaaS, or crowdsourced testing by matching testing depth, reporting, engagement model, and data-handling needs to your organisation, not by which model is currently fashionable.

You can use more than one model across a year. Each individual engagement still needs one accountable owner, one scope, and one report standard. Do not mix community testers, a portal, and a consultancy brand in the same contract unless you know who signs the findings and who holds your data.

Evaluating AI and LLM Pentesting Capabilities

AI and LLM pentesting is specialised testing of model-backed applications for prompt injection, data leakage, model manipulation, training-data poisoning, and insecure output handling, not a relabelled web application test.

Traditional web application testing still matters for the surrounding app, APIs, and access control. It does not automatically cover model behaviour, prompt-injection paths, or data flow through retrieval and tool-calling pipelines.

Testers need to understand how prompts, context windows, retrieved documents, plugins, and downstream actions combine. Treat AI testing claims as unproven until the vendor shows a dedicated method and AI-specific findings.

Ask these questions and keep the answers on file:

• Do you have a dedicated AI/LLM testing methodology, written down?
• Which frameworks do you use, for example the OWASP Top 10 for LLM Applications?
• Can you provide redacted examples of AI-specific findings from past engagements?
• How are testers trained on AI security, and who would be assigned?
• How do you test data leakage, insecure output handling, and tool or plugin abuse in the actual pipeline?
• Will the test cover the model integration, the retrieval layer, and the application that acts on model output, or only the chat UI?

Pentesting Pricing Models: How to Compare Costs Without Getting Burned

Pentesting is typically sold as fixed-scope, hourly, or subscription/retainer pricing, and each model changes depth, flexibility, and cost risk.

Do not treat price as a quality proxy. Expensive vendors can still deliver scanner-like reports. Lower-cost vendors can still deliver excellent manual work.

Compare what is included: scoping calls, report revisions, retesting, and post-engagement access to testers. Ask for the extras tariff in writing: out-of-scope assets, extra days, rush reporting, and retest rounds.

The cheapest fixed-scope quote is often the most dangerous, because it usually implies a tightly constrained surface. Ask what is excluded from the fixed scope, not only what is listed. Ask how the vendor behaves if the surface is larger than the questionnaire suggested. If a critical path sits outside the price, you have bought a certificate, not a test.

Questions to Ask Every Pentesting Vendor Before You Sign

Ask every pentesting vendor the questions below and judge the answers against the quality signals, not against confidence in the sales call.

If a vendor hesitates to provide a redacted report sample, treat that as a red flag and stop the process until a sample appears.

Take notes against each answer. A fluent sales narrative that cannot be matched to a document is not evidence.

How to Prepare for Your Pentest: A Pre-Engagement Checklist

Prepare for a pentest by lining up stakeholders, documentation, attack-surface boundaries, environments, communications, and rules of engagement before the testing window starts.

Start vendor evaluation early. Capable testers book ahead, and a proper scoping call takes calendar time. Internal delay is as common as vendor delay. Do not wait until the audit date is immovable and then accept whatever slot is left.

• Identify key stakeholders. Include security, IT, application owners, compliance, and legal. Name a single internal owner for vendor questions during the test.
• Gather documentation. Prepare network diagrams, application architecture, API documentation, user roles and privileges, and previous test reports where they exist.
• Define the attack surface. List systems, applications, APIs, and networks in scope, and write explicit out-of-scope items. Ambiguity here becomes missed coverage later.
• Prepare test environments. Confirm whether staging is representative, whether production will be tested, and whether there are availability or change-freeze constraints. Unrepresentative staging produces findings you cannot trust.
• Provision access. Ready test accounts, MFA exceptions if agreed, VPN or jump-host access, and a named contact who can unblock testers the same day.
• Set expectations with the team. Decide who is told about the test, how findings will be escalated, and how blue-team or SOC alerts will be handled so testers are not treated as live attackers by accident.
• Clarify rules of engagement. State what is permitted around social engineering, denial-of-service testing, data access, and out-of-hours work.
• Schedule the scoping call. Take the documentation, in-scope list, constraints, and compliance driver into that call so the proposal matches the real surface.

What Happens After the Report? Post-Engagement Support and Retesting

Post-engagement support is the work after delivery: remediation guidance, tester access for questions, retesting of fixes, and a revised report where agreed.

The report is the start of remediation, not the end of the engagement. A vendor’s willingness to explain findings and retest fixes is a quality signal that sales decks do not show.

Engineers will have questions about exploit conditions, false-positive risk, and fix order. If the testers disappear after PDF delivery, you will spend longer arguing about the findings than fixing them.

A pentest is a point-in-time assessment. It identifies weaknesses at a specific moment. It does not guarantee that the estate stays secure, and it does not replace patching, design review, or ongoing testing.

Clarify retesting terms before you sign. Some vendors include a retest in the original price. Others charge extra and queue it behind new projects. Confirm whether the retest validates the specific fix or only re-runs a scan against the same host.

Ask before award:

• Does the report include actionable remediation steps, and is there a debrief call?
• Is retesting included, how is it scoped, and how quickly can it be scheduled?
• What is the process for confirming that a fix actually closed the issue?
• Can engineers contact the testers through a defined channel?
• Will you issue a revised report after retesting?

Frequently Asked Questions

Next Steps: Turn Your Evaluation into a Vendor Shortlist

Turn this evaluation into a shortlist by locking scope, provider type, methodology evidence, and pricing model before you request quotes.

• Define the attack surface, test types, exclusions, and primary driver (compliance, risk reduction, maturity, or incident response).
• Select the provider type that fits that driver: consultancy, PtaaS, or crowdsourced.
• Assess methodology and reporting using a written method document and the Report Quality Scorecard on a redacted sample.
• Compare pricing models on inclusions and exclusions, especially retesting, not on headline fee alone.
• Request quotes from the shortlist and compare proposals against the same questions in this guide.

A thorough evaluation is the practical way to avoid paying for a scan labelled as a pentest. When the research is done, compare live service options and ask for a proposal that you can score against the criteria above.