How to choose a penetration testing company: questions to ask

Start with names. Ask which person will run your test, what certifications or track record that person holds, and whether the work is done in house or passed to a subcontractor. Sales calls are often led by someone who never touches your system.

Ask for a sample of the tester’s earlier reports with client details removed. A tester who writes clearly in a report usually thinks clearly in the test. Vague sample pages tell you plenty.

Also ask how many testers will be on your job and for how many days. A small web portal and a platform with three mobile apps and an API need different effort.

A serious provider will not start before a written scope exists. It lists hostnames, IP ranges, app builds, user roles and anything left out, such as a payment gateway you do not own. Third party systems need their own permission.

Ask about the rules of engagement. Which hours are allowed? Is production touched? What happens if the tester finds a way into a customer database? Good firms stop, note it and call a named contact. They do not copy data to see how far it goes.

Look for a signed authorisation letter and a confidentiality clause. Without them, a test can look exactly like an attack to your hosting provider.

Scanners are useful. They find missing patches, weak TLS settings and exposed ports quickly. But a scanner cannot tell that a customer can change an order number in the address bar and read someone else’s invoice.

Ask the provider to describe what is done by hand. Expect answers about logging in as two users and trying to cross over, or tampering with requests in a proxy such as Burp Suite. Small weaknesses get chained into one real path. If the answer is only a tool name, be wary.

Ask whether findings are checked before they reach you. A report with two hundred unverified items, many of them false alarms, wastes your developers’ week.

The report should open with a summary a non technical director can read in five minutes. After that come findings, each with a title, where it was found, steps to reproduce, the evidence, a severity and a plain fix.

Ask whether severity is explained or only coloured red and amber. A medium finding on a public login page may matter more than a high one on an internal test server. The provider should say why.

Check that the report also lists what was tested and found clean. That tells you the coverage, and it helps the next tester avoid repeating the same ground.

Ask whether a retest is included, how long after fixes it can happen, and whether it needs a new contract. Fixing is half the job. Proving the fix holds is the other half, and the retest letter is what a customer’s security questionnaire will ask for.

Ask for a walkthrough call with your developers. Reading a finding is easy; understanding why a filter bypass worked is harder. A tester who will sit with your team for an hour is worth more than a thicker report.

Before you sign, send your shortlist the same one page brief and compare answers side by side.