How to vet a penetration testing provider: a 46-question questionnaire

To vet a penetration testing provider, send them a written questionnaire and score the answers on one scale: who exactly will test, which methodology they follow, what happens to your data, what report you get and who is liable if something breaks. Below are 46 such questions in ten sections; each comes with a “Good answer” line, so even a reader without a technical background can judge the replies.

The questionnaire is neutral: you can use it on any provider, including us. It complements the article on how to choose a penetration testing company: that one explains what to look at and why, while this is a ready working document you can paste into an email or a tender form. How to prepare your own side is covered in the pentest preparation checklist, and other free lists are collected on the free cybersecurity checklist page.

In short

• Send the same questions and the same description of your systems to two or three providers and ask for written answers.
• Score each answer 0, 1 or 2 points. Seven questions are marked as stop questions: a zero on any of them means you do not go further with that provider.
• Three things tell you the most: named testers, a sanitised sample report and written rules for handling your data, including AI tools.
• Methodologies should be named precisely. As of October 2026 these are PTES ^[1], OWASP WSTG 4.2 ^[2], OWASP MASVS 2.1.0 and MASTG 2.0.0 ^[3], NIST SP 800-115 (2008) ^[4] and OSSTMM 3 ^[5]; severity is usually rated with CVSS 4.0 or 3.1. ^[6]

How to use the questionnaire

1. Copy the questions into a document, add a short description of the systems the pentest should cover (what is tested, where, how many user roles) and give providers 5-7 working days to reply.
2. Ask for written answers and evidence: a sample report, a contract template, a list of certifications with numbers. A spoken “yes, of course” does not count as a full answer.
3. Score each answer:
   • 2 points: a specific written answer with evidence, or a willingness to put it in the contract;
   • 1 point: a general answer, “usually yes”, with no detail or document;
   • 0 points: no answer, an evasive answer or an answer from the red flags list.
4. Check the stop questions (marked [stop]): a zero on even one of them means no, whatever the total.
5. Work out the percentage of the maximum (92 points). As a guide: from 75% you can move to a contract, 50-75% needs a follow-up call, below 50% it is worth looking for another provider.

For a small company not every question matters equally. If one does not apply to you (for example, you have no mobile apps), simply remove it from the maximum for all providers.

The questionnaire: 46 questions

1. Company and legal entity

1. Which legal entity signs the contract: full name, country of registration, registration number?
   Good answer: the entity can be found in the official company register, and it is the same entity that signs the NDA and the contract and issues the invoice.
2. Where are the company’s owners registered and where do the testers physically work?
   Good answer: countries and cities are named; no owners or staff in sanctioned or hostile jurisdictions; work on your data happens only from agreed countries.
3. What services do you offer besides pentesting? Do you sell security products or implement systems you would then test?
   Good answer: any conflict of interest is stated openly, and the recommendations in the report are not tied to products the provider sells.
4. Have there been incidents involving client data, lawsuits or complaints about your work in the last three years?
   Good answer: an honest “no”, or a short account of what happened and what changed in their processes afterwards.
5. What certifications or accreditations does the company itself hold (for example ISO/IEC 27001, CREST) and what is their scope?
   Good answer: a copy of the certificate whose scope covers testing services. For a small company the lack of a certificate is not a failure if the processes in sections 5 and 6 are described in writing.

2. The team and who actually tests

6. [stop] Who exactly will test our project? Give names, roles and experience for each person.
   Good answer: names in the proposal or contract; a person can be replaced only with your written consent.
7. Which certifications do these specific people hold and how can we verify them?
   Good answer: the certificate name (OSCP, GPEN, GWAPT, OSWE, CREST and so on) with a number or a link to the issuer’s public register, such as the GIAC directory of certified professionals. ^[7] Certificates held by a manager who will not test do not count.
8. [stop] Do you use subcontractors or freelancers?
   Good answer: a written “no”, or a list of specific people or companies who sign the same NDA and are brought in only with your consent.
9. What experience does the team have with our type of systems (web application, API, mobile apps, cloud, Active Directory, industrial systems)?
   Good answer: sanitised examples of similar projects and a list of checks specific to your stack. The NCSC advises flagging unusual systems up front so the provider can confirm it has the right skills. ^[8]
10. Who runs the project and who reviews the report before it is sent?
    Good answer: a named project lead and a second person who reviews the findings and recommendations (peer review).
11. Do testers sign personal confidentiality undertakings, and does the company screen them when hiring?
    Good answer: yes, individual NDAs; only project members have access to your data.

3. Methodology and standards

12. Which methodologies do you follow and how do you adapt them to our project?
    Good answer: specific documents are named: PTES (seven phases from pre-engagement to reporting) ^[1], OWASP WSTG for web applications (stable version 4.2, version 5.0 in development) ^[2], OWASP MASVS and MASTG for mobile apps ^[3], NIST SP 800-115 ^[4], OSSTMM 3 ^[5]. A “proprietary secret methodology” with no description of its phases is a weak answer.
13. How many hours or days of manual work by a person, and how much automated scanning? Which tools do you use?
    Good answer: manual hours are listed separately; scanners only help, and a person verifies every result.
14. How do you test business logic and access rights: can one user see another user’s data?
    Good answer: testing with at least two accounts per role, with typical scenarios for bypassing roles, tampering with requests and skipping payment described.
15. How do you weed out false positives?
    Good answer: only findings reproduced by hand go into the report; assumptions are marked separately.
16. Which type of testing do you propose (black box, grey box, white box) and why?
    Good answer: the choice is explained by your goal: for example, grey box with test accounts gives more coverage for the same number of days.
17. How do you account for requirements we have to meet (a regulator, PCI DSS, ISO/IEC 27001, our customers’ requirements)?
    Good answer: the provider asks who needs the report and proposes a format that this particular auditor or customer accepts.

4. Scope and rules of engagement

18. How do you define the scope and what will be out of scope?
    Good answer: a written list of systems, addresses, roles and exclusions. If an important out-of-scope system turns up during the test, the client decides: extend the scope or record it as a testing limitation. ^[8]
19. What is your estimate of effort and timing based on?
    Good answer: a calculation from the number of systems, roles, API endpoints or addresses, not a fixed “package” offered without a single question about your systems.
20. Which actions are forbidden by default?
    Good answer: the rules of engagement state them explicitly: denial-of-service attacks, deleting or changing real data, emails to real customers, social engineering without separate consent.
21. From which IP addresses and at what hours do you test?
    Good answer: fixed addresses shared in advance, agreed hours, work outside them only with your permission.
22. [stop] What do you do if, mid-test, you find a critical vulnerability or signs of a real breach?
    Good answer: they report immediately through the agreed channel without waiting for the report; the notification deadline is written into the rules of engagement.
23. How do we stop the test, and who on your side is reachable?
    Good answer: a named person with a phone number for the whole test window and a simple stop procedure.
24. How do you make sure we have the right to authorise testing of cloud, hosting or third-party services?
    Good answer: the provider asks who owns each system and follows the cloud provider’s rules; it does not test other parties’ services without their owner’s permission.

5. Your data, NDA and AI tools

25. [stop] Do we sign an NDA before any data, access or system description is shared?
    Good answer: yes, a mutual NDA before any technical details.
26. Where and how do you store evidence: screenshots, data extracts, credentials?
    Good answer: encrypted storage, the hosting country is named, access only for project members, no unencrypted personal laptops.
27. What do you do with personal data you gain access to during the test?
    Good answer: they take the minimum needed as proof, mask the data in the report and do not extract it in bulk.
28. [stop] How long do you keep project data and how do you delete it?
    Good answer: the retention period is in the contract, followed by deletion with written confirmation.
29. [stop] Do you use AI tools (chatbots, coding assistants, AI scanners) with our data?
    Good answer: a list of tools; client data never goes into public services that train on prompts; use with your data only with your written consent.
30. How do you hand over the report, passwords and access?
    Good answer: an encrypted channel or archive with the password sent separately; never a plain email attachment.
31. What happens to test accounts, uploaded files and other traces of the test once it is over?
    Good answer: a list of everything created or changed, a clean-up after the test and confirmation in the report.

6. The report

32. [stop] Can we see a sanitised sample of a real report?
    Good answer: yes, a real report with names removed, not a marketing brochure.
33. Which severity scale do you use, and which version?
    Good answer: the CVSS version is stated (4.0 is current, 3.1 is also common) with a vector for each finding, plus a risk rating for your business specifically. ^[6] Any departure from the standard rating is explained by the tester. ^[8]
34. Is there a short executive summary on business impact?
    Good answer: one or two pages in plain language: what was found, what the risk is, what to fix first.
35. Does every finding include reproduction steps and evidence?
    Good answer: yes, your developer can reproduce every finding on their own.
36. How specific are the recommendations?
    Good answer: what exactly to change in the code or settings, not “improve the security level”, with links to documentation.
37. What language will the report be in?
    Good answer: the language you need (English, Ukrainian or both), with the same content; the second language is included in the price or priced as a separate line.
38. When will we receive the report, and can we discuss it with the tester?
    Good answer: the deadline after the end of testing is in the contract, and a walkthrough meeting is included in the price.

7. Retest

39. Is a retest included in the price, how many times and within what period?
    Good answer: yes, the number of retests and the retest window are in the contract.
40. What do we get after the retest?
    Good answer: an updated report or an annex with the status of each finding: fixed, partly fixed, open.
41. Can you provide a letter confirming the testing for our customers or auditor?
    Good answer: yes, with facts (what was tested, when and within which scope) and no promises that “the system is fully secure”.

8. Insurance and liability

42. Does the company carry professional indemnity or cyber insurance? What is the cover?
    Good answer: the insurer and the limit are named, or it is explained how liability is covered by the contract.
43. Who is liable if the test causes an outage or data loss, and where is that written down?
    Good answer: a separate contract clause with a liability cap and a procedure, not “nothing will happen”.
44. Who owns the report and the results, and may you name us as a client?
    Good answer: the report belongs to you; you are named only with written consent.

9. Price and contract

45. What is included in the price, what is billed separately, and what happens if the scope changes?
    Good answer: separate lines for days of work, the report, languages, retest and travel; scope changes only by written agreement before the extra work starts.

10. References and reputation

46. Can you give us a client contact for a short call, or show your experience publicly?
    Good answer: a client contact with their consent or a sanitised project description; public research, talks or disclosed vulnerabilities that can be checked are a plus. Declining to name clients because of NDAs is normal.

Red flags

Anything on this list scores 0 for the relevant question, even if the rest of the answer is good:

• “We’ll test everything” with no list of systems or exclusions.
• A price straight away, without a single question about your systems.
• Tester names “after payment”, or the team changes without notice.
• A report within a day of the start, or a sample report that looks like a scanner export.
• “We guarantee no vulnerabilities will remain.”
• No answer on what happens to your data after the project, or your data going into public AI services without your consent.
• Pressure: “discount today only”, “let’s start without a contract and do the paperwork later”.
• Active testing before an NDA and written authorisation are signed.

One-page short version

If there is no time for the full questionnaire, start with these 12 questions. The text after “Good” says what a good answer looks like. Tick an item only if the provider answered that way in writing. Items marked [stop] are mandatory.

• [stop] Team. Who exactly will test? Good: names and certificates with numbers.
• [stop] Subcontractors. Anyone else involved? Good: “no”, or only with our consent.
• Method. Which methodology? Good: PTES, OWASP or NIST, manual days listed separately.
• Scope. What will you test? Good: a written list of systems, roles and exclusions.
• Rules. How will you avoid breaking production? Good: bans, IP addresses, hours, who stops it.
• [stop] Critical. When will you tell us? Good: immediately, without waiting for the report.
• [stop] Data. What about evidence? Good: NDA first, encryption, deletion with confirmation.
• [stop] AI. Does our data go into AI services? Good: only with our written consent.
• [stop] Report. Is there a sample? Good: sanitised report, CVSS version, executive summary.
• Retest. Is it in the price? Good: number of retests and deadlines in the contract.
• Liability. Who is liable for an outage? Good: a contract clause, a cap, insurance.
• Price. What is included? Good: separate lines, scope changes only in writing.

Download the preparation checklist (PDF)PDF · A4

FAQ

How many providers should we send it to?

Two or three is enough. What matters is sending everyone the same questions and the same system description, otherwise the answers cannot be compared fairly.

Can we shorten the questionnaire?

Yes. For a small project keep the one-page short version and all the stop questions. Remove questions that do not apply to you from the maximum for every provider in the same way.

What if a provider will not answer in writing?

That is an answer in itself. It is reasonable to share some details only after an NDA, but a good provider puts tester names, a sample report and data handling rules in writing.

Does a provider have to hold ISO/IEC 27001 or CREST?

No. It is a plus, especially for large clients and regulated industries, but for a small company named testers, a sample report and written data handling rules matter more.

Can we use this questionnaire in a tender?

Yes. The questions are neutral and fit a tender form. Add your system description and report format requirements so every bidder prices the same scope.

References

1. The Penetration Testing Execution Standard (PTES) pentest-standard.org
2. OWASP Web Security Testing Guide (WSTG) owasp.org
3. OWASP Mobile Application Security: MASVS and MASTG mas.owasp.org
4. NIST SP 800-115: Technical Guide to Information Security Testing and Assessment csrc.nist.gov
5. ISECOM: OSSTMM 3, Open Source Security Testing Methodology Manual isecom.org
6. FIRST: Common Vulnerability Scoring System v4.0 first.org
7. GIAC: Certified Professionals directory giac.org
8. NCSC: Penetration testing ncsc.gov.uk