ESSENTIAL GUIDANCE · BUYER GUIDE · 9 min read
Part of Validate insights →How to choose a penetration-testing provider
Compare penetration-testing providers on competence, accreditation, scope quality, safe delivery, reporting, data handling and remediation support.
Choose a penetration-testing provider by matching its relevant competence and delivery controls to your systems, risks and assurance need. Evaluate scope quality, tester experience, safe working, evidence handling, reporting and remediation support—not price or an accreditation badge alone.
Need an acronym translated?Open the cyber glossary →Start with the outcome you need
Define why you are buying the test before comparing suppliers. Record the business service and risks involved, the technology and environments in scope, the deadline, the audience for the report, any mandated scheme and the support needed after delivery. A clear outcome lets providers explain what they would test, what they would not test and why.
Check relevant company assurance
CREST accreditation is an organisational accreditation for specified service disciplines; individual CREST certifications are separate. Check the current CREST directory to confirm both the provider and the service accreditation relevant to the work you are buying. Accreditation is a confidence signal, not proof that every engagement or individual will be equally suitable. Confirm the proposed delivery team, method and engagement terms for your environment. For eligible UK government, public-sector and critical national infrastructure work, NCSC CHECK may be required or appropriate; it is not a universal requirement for every organisation.
Independent guidance:Search the current CREST directory →Read NCSC guidance for CHECK buyers →
Evaluate the proposed people and experience
Ask who will perform and review the work, what relevant experience they have with your technology and threat model, how specialist questions are escalated and whether any delivery will be subcontracted. Evidence of relevant delivery, sound methodology and effective review is more useful than counting unrelated qualifications.
Judge the quality of scoping
A strong provider should ask about the business service, assets, identities, APIs, trust boundaries, test accounts, constraints and reporting needs. It should state assumptions and exclusions clearly. Be cautious if a proposal gives a confident fixed price from a host count alone when the real scope includes complex applications, multiple roles or business-logic testing.
Review safety, escalation and data handling
Confirm how written authority and scope versions are controlled, which techniques are restricted in production, who can pause testing and how critical findings are escalated. Ask where evidence will be processed and stored, who can access it, how it is encrypted, how long it is retained and whether subprocessors or overseas locations are involved. Regulated organisations should map the answers to their own legal, contractual and risk requirements.
Inspect a representative report
A redacted sample should show executive context, scope, reproducible evidence, affected assets, business and technical impact, severity rationale, practical remediation, limitations and retest status. A polished severity chart is not enough: engineering teams need enough detail to reproduce and fix issues, while risk owners need a clear basis for decisions.
Compare remediation and retest support
Clarify whether engineers can discuss findings with the tester, which fixes are eligible for retest, how many rounds are included and how partial fixes or remaining limitations are recorded. A report identifies work; retesting checks whether the agreed fixes address the previously demonstrated finding within the agreed retest scope and records any remaining limitations.
Compare proposals consistently
Apply the same scorecard to each supplier: relevant service accreditation, delivery-team experience, scope and assumptions, safety controls, data handling, report quality, aftercare and total commercial terms. Weight the criteria to the risk. For a sensitive API handling customer data, relevant expertise and data controls may matter more than the lowest price.
Recognise warning signs
Investigate further if a provider promises to find every vulnerability, presents automated scanning as a complete penetration test, cannot explain scope assumptions, avoids evidence-handling questions, provides vague escalation or retest terms, or pressures you to test assets without confirmed authority. Good selection reduces avoidable risk but cannot make a time-bounded test exhaustive.
This guide covers the essentials. Continue into our technical analysis for a firmer position, practical implications and recommended action.
Read “Modern penetration testing should create decisions, not just findings” →



