How to Choose a Penetration Testing Provider: 15 Questions to Ask

The team

1. Who will do the testing?

Ask for the profiles of the testers assigned to your project, whether they are employees or subcontractors, and who reviews their work before it reaches you. Ask, too, whether the same people will run the retest: a team that already knows your system needs less ramp-up.

2. Which certifications do they hold?

Practical exams, where candidates must compromise systems against the clock and then write a report, carry the most weight. Examples include OffSec's OSCP and the time-limited OSCP+ designation (added in November 2024 and valid for three years), OSEP and OSWE, and CREST's practical tester exams. GIAC's GPEN and GWAPT add proctored exams with hands-on lab questions. A certificate shows a baseline. Recent findings, published research and conference talks show current skill.

3. Have you tested systems like ours?

A team that knows payment flows or health data tests the risky parts first. Ask for anonymized examples of findings in your industry and on your technology stack.

Methodology

4. Which methodology do you follow?

Expect named standards: the OWASP Web Security Testing Guide for web applications, OWASP MASVS for mobile, the OWASP API Security Top 10 as the checklist for APIs, and PTES or NIST SP 800-115 for infrastructure. For financial institutions in the EU, red team work follows the TIBER-EU framework. A named methodology gives you coverage you can check against the report.

5. How much of the work is manual?

Scanners find known issues quickly. Access control, business logic and attack chains need people. Ask how the testing days are split between automated and manual work, and what the testers do once the scan has finished.

6. How do you test business logic?

Ask for a concrete example: a refund issued twice, a role that approves its own request, a discount applied after payment. Concrete answers like these show that the team studies how your product works.

The report and what follows it

7. Can we see a sample report?

A good report has an executive summary in plain language, a severity rating with a stated method (CVSS or a documented risk model), reproduction steps with the actual requests and screenshots, business impact, and a fix written for your stack. CVSS measures technical severity, so a good report adds the business context that decides what to fix first.

8. Is a retest included?

A finding is closed when someone confirms the fix works. Agree on retest timing and scope in the contract.

9. Will the testers help us fix what they find?

Developers often need a call with the tester to reproduce a finding or check a proposed fix. Ask whether that time is included and who answers questions after the report is delivered.

10. How often should we test?

A good answer depends on your release cadence and risk. PCI DSS sets a baseline of at least once a year and after significant changes. Products that ship often benefit from short tests of new features before each major release.

Safety and data handling

11. How will you protect our data during the test?

Ask where evidence is stored, how it is encrypted, who can access it, how long it is kept and how it is destroyed. Testers often see production data, so the provider should handle it under a written policy and a signed NDA.

12. What happens when you find something critical?

Critical findings should reach your named contact quickly, with enough detail to act on, without waiting for the final report. Ask for the time commitment in writing, for example the same working day. Agree on the channel and the escalation path in the rules of engagement.

13. How do you keep production running?

Ask about testing windows, request rate limits, how potentially disruptive tests are handled, and how fast testers stop when a service slows down. Name an emergency contact on each side.

Scope and contract

14. What exactly is in scope?

The contract should list hosts, applications, APIs, roles and environments, plus everything excluded and the reason. A precise scope shows whether the system that matters most is included.

15. Can we speak to a previous client?

A reference call answers questions a proposal cannot: whether the findings were real, whether the team helped with fixes, how the retest went, and whether the client would hire them again. Security clients often keep vendor relationships confidential, so ask whether a reference call can be arranged under NDA.

When a proposal deserves a closer look

• It lists tools in detail and says little about the testers or the methodology.
• The sample report reads like a scanner export.
• Every client gets the same scope and the same number of testing days.
• Retest terms and support after the report are left open.
• There is no written process for critical findings.

Send these questions with your request to info@jetlink-s.com, and we will answer them in writing for your project. Our penetration testing guide explains what each type of test covers.