How to choose a penetration testing company

The report is what you are buying, so ask every provider for a redacted sample before anything else. Within ten minutes it tells you more than any sales call. NCSC guidance says a report should cover the issues found, the tester's risk assessment of each and a method to resolve them. Look for:

• Evidence for each finding: screenshots, request and response pairs, or a clear description of what was accessed. Not just a vulnerability name and a score.
• Attack narratives showing how issues were chained, not only an isolated list.
• Business impact in plain language, next to technical severity such as a CVSS score.
• Specific remediation, tied to the actual flaw rather than generic best practice.
• Clear scope, dates and method, so a customer or auditor knows what was covered.

If the sample reads like a scanner export with a logo on it, you have your answer. How to read a penetration test report explains what good looks like.

The NCSC states that the quality of a penetration test is closely linked to the abilities of the testers. The company name on the contract matters less than the people doing the work, so ask who they are, what they have tested before and whether the work is subcontracted.

Certifications and schemes can help as a baseline. For UK government work, the NCSC recommends companies in its CHECK scheme. Outside regulated contexts, treat certifications as one input: ask for evidence of relevant experience, such as similar engagements or published, coordinated vulnerability research through official bug bounty or disclosure programs.

Unauthorized access to computer systems is illegal in most jurisdictions, so a reputable provider will insist on written authorization before testing. Expect:

• A contract or statement of work, including liability and confidentiality terms.
• A written scope listing exactly which systems, domains, IP ranges and accounts are in bounds.
• Rules of engagement: testing windows, prohibited techniques (for example denial of service), how production data is handled, and emergency stop procedures.
• Confirmation that you are entitled to authorize testing of every in-scope system, including third-party hosting or SaaS where their policies apply.

See rules of engagement for what a good document covers. A provider that is relaxed about paperwork is a provider that is relaxed about risk to your systems.

During a test, a provider may see customer records, credentials and source code. Ask where testing evidence is stored, who can access it, how reports are delivered (a secure portal or encrypted channel rather than plain email) and when data is deleted after the engagement.

Agree on communication up front: a named contact on each side, a kickoff call, a channel for questions, a status update cadence, and an immediate escalation path for critical findings. You do not want to learn about exposed customer data in a PDF three weeks later.

• Rebranded scanner output. Findings that match scanner plugin names, hundreds of low-severity items, no evidence of exploitation.
• A quote with no scoping questions. Effort depends on scope; a provider that does not ask is selling a fixed product.
• Guaranteed outcomes. Nobody can promise a system is secure, or guarantee a compliance pass.
• No retest. You get a problem list but no proof of fixes.
• Testing before paperwork is signed.
• Reluctance to name testers or explain subcontracting.
• Fear-based selling instead of clear explanations of method and scope.

1. Write one scope document and send it to every shortlisted provider.
2. Compare tester days, manual work, retest terms and report samples side by side, not just total price. Penetration testing cost explains what drives the differences.
3. Hold a short technical call with the people who will actually test.
4. Check authorization, data handling and communication terms before signing.
5. If your systems change frequently, ask how they would cover changes between tests, for example through continuous penetration testing.