How to choose a penetration testing firm

Why do credentials tell you less than you hope?

Because accreditation attaches to an organisation or to an individual, and your engagement is a specific person for a specific week. An accredited firm has demonstrated that it has documented processes and qualified staff somewhere on the payroll. It has not promised that those staff are on your job. The single most useful contractual term available to you is the right to know, in writing, who is assigned and to see their specific experience.

Certifications also measure different things and are not interchangeable. Some are multiple choice examinations of knowledge, some are timed hands-on exercises requiring actual exploitation, and some are organisational audits of process rather than skill assessments at all. A firm listing a wall of acronyms is not necessarily stronger than one listing two hands-on qualifications held by the people who will do the work.

The practical filter: ask for the assigned tester's name, the qualifications that person holds, and two anonymised examples of findings they personally discovered in systems similar to yours. Firms that cannot or will not answer are telling you their staffing model, and you should price the engagement accordingly.

Which credentials actually mean something?

Each of the common ones answers a narrow question. Read them for what their assessment involves rather than as a general quality ranking, and note that some are requirements for particular kinds of work rather than marks of skill.

What questions expose real depth?

Ask what they would test first in your system and why. A firm that has read your brief will name a specific target and a specific hypothesis, such as the multi-tenant boundary or the password reset flow. A firm that has not will describe their methodology. Both answers are polite; only one indicates thought.

Ask about a test where they found nothing significant, and what they concluded. Every experienced tester has had engagements that produced little, and the interesting part is whether they interpreted it as a strong system, a bad scope, or lost time on access. A supplier who claims they always find critical findings is either exaggerating or working exclusively with very weak clients.

Then ask a technical question with a specific answer. How they would approach testing authorisation in a system where every request carries a signed token, or how they would establish whether a Kubernetes service account is over-permissioned, or what they check when a web application firewall sits in front of the target. The quality of the answer separates the people who test from the people who sell testing, and you can hear the difference without being a specialist yourself.

How should you evaluate a sample report?

Ask for a redacted real report rather than a template, and read it for three things. First, is there any finding that required more than one step, described as a chain. Second, are remediation recommendations specific to the client's code and configuration or generic advice that could be pasted anywhere. Third, does the coverage section say honestly what was not tested and why.

Then check the balance. A report where the majority of findings are headers, cookie flags, TLS configuration and information disclosure is scan output with a cover page, regardless of how well designed the cover page is. A report with six findings, two of which are genuinely interesting chains, represents more work than a report with sixty.

Give the sample to one of your own engineers to read. They will tell you within twenty minutes whether the remediation advice is actionable, and that judgement is the most reliable procurement signal available to you. Buyers who skip this step consistently overweight presentation quality, which is the one dimension of a report that has nothing to do with the testing.

What about liability, vetting and data handling?

Your test produces the most damaging document about your organisation that will exist, and where it lives afterwards matters. Establish how the report is delivered and stored, how long the firm retains evidence and raw tool output, whether that includes any data extracted during testing, and how it is destroyed. A firm without clear answers is a firm holding your exploitation instructions on an unknown laptop.

Confirm whether testers are employees or subcontractors, and whether the firm may subcontract without telling you. Subcontracting is not automatically a problem, but you should know who is touching your systems and be able to refuse. Ask what personnel vetting is applied, and where you have a regulatory or public sector requirement, confirm the specific level of screening or clearance held rather than accepting a general assurance.

On insurance, check that professional indemnity and any cyber liability cover exists at a level proportionate to the engagement, and read the limitation of liability clause. Many testing contracts cap liability at the fee, which is a small number relative to the cost of an outage caused during testing. Whether that is acceptable is a commercial decision, and it should be a decision rather than a discovery.

What are the red flags?

Pricing by asset count with no discussion of objectives, which means the proposal is a spreadsheet rather than a plan. Guaranteed timescales measured in hours for anything but a small scope. A refusal to name the assigned tester. A sample report that is clearly a scanner export. Findings volume used as a selling point, since it indicates no filtering. And any variant of a guarantee that the test will make you secure, which is not a claim testing can support.

Also treat scope inflexibility as a warning. A firm that will not reallocate days from a low-value target to a high-value one after the first day of testing is running a process rather than an investigation. The best engagements change direction mid-week because the tester found something, and a contract that prevents that is buying you the wrong thing.

One last check you can run cheaply: ask what they will not do. A credible firm has boundaries, such as declining to test systems where authorisation is unclear, refusing to guarantee no impact on production, or declining work where the scope makes a meaningful result impossible. A supplier who agrees to everything has not read the brief closely enough to disagree with any of it.