Back to blog Buyer Guides

Questions to Ask Before Hiring a Penetration Testing Company

20 questions, organized by category, to ask any penetration testing company before signing. Use it as a procurement checklist for technical depth, reporting quality, and post-engagement support.

Author Neil Cameron
Published May 13, 2026
Read 13 min

Why the Questions You Ask Matter

The difference between a useful penetration test and a wasted budget often comes down to the buying process. A poorly scoped engagement with the wrong company produces a generic report that collects dust. A well-matched engagement finds real weaknesses and gives your team a clear path to fix them.

Asking the right questions before signing a contract is the single most effective way to improve outcomes. This guide covers 20 questions organized into six categories. Use it as a checklist during procurement.


Category 1: Technical Capability

These questions determine whether the company has the skills to test your specific environment.

1. What certifications do your testers hold?

Individual certifications matter more than company logos on a website. Ask for a list of certifications held by the testers who will actually work on your engagement. OSCP, CREST CRT, CREST CCT, GPEN, GXPN, and OSWE are strong indicators of hands-on skill.

Be specific. “Our team is certified” is not a useful answer. You want to know which testers, which certifications, and when they were obtained or renewed.

2. How many years of experience do your testers have?

Certifications prove baseline competence. Experience determines how well a tester handles unusual environments. Ask for average years of experience across the team, and the experience level of the lead tester assigned to your project.

A company staffing your engagement with junior testers supervised by a senior reviewer is not the same as having a senior tester doing the hands-on work. Both models can work. You need to know which one you are paying for.

3. Can you assign named testers to this engagement?

Some companies assign testers after the contract is signed, and you have no say. Others let you review tester profiles in advance. Ask whether you can request specific testers or at minimum approve the assigned team.

This also protects against bait-and-switch, where senior staff handle pre-sales and junior staff do the testing.

4. Have you tested environments similar to ours?

A company with deep experience in cloud-native SaaS applications may not be the best fit for OT/SCADA testing. Ask for relevant examples. If your stack is AWS-heavy, ask how many AWS engagements they completed in the past year.

You do not need to see confidential client data. A general description of similar engagements with anonymized details is reasonable.

5. What is your approach to testing [specific technology]?

Pick one or two technologies central to your environment. Ask the company how they would approach testing them. This question reveals whether the team has genuine depth or is relying on automated scanning.

For example, if you run a Kubernetes cluster, ask about their approach to container escape testing, RBAC misconfigurations, and secrets management review. Vague answers are a red flag.


Category 2: Methodology and Scope

These questions clarify what you are buying and how the work gets done.

6. What methodology do you follow?

Most reputable companies follow an established framework. OWASP Testing Guide, PTES, OSSTMM, and NIST SP 800-115 are common references. The specific framework matters less than having a structured, repeatable approach.

Ask the company to describe their methodology in enough detail that you can evaluate it. A one-line answer like “we follow OWASP” is not sufficient. You want to understand their phases: reconnaissance, enumeration, exploitation, post-exploitation, and reporting.

7. How do you handle scope definition?

Scope creep and scope ambiguity cause most engagement failures. Ask how the company defines scope. Good companies produce a detailed scope document that lists in-scope targets, out-of-scope targets, testing windows, and constraints.

This document should be finalized and signed before any testing begins. If a company is vague about scoping, expect problems later.

8. What is the split between manual testing and automated scanning?

Automated tools are part of every engagement. The question is how much of the work is manual. A test that is 90% Nessus output reformatted into a report is not a penetration test. It is a vulnerability scan with a markup.

Ask for an approximate ratio. Ask which tools they use. Ask what their manual testing process looks like after automated scanning is complete.

9. Do you test business logic vulnerabilities?

Automated tools cannot find business logic flaws. These vulnerabilities require a tester who understands your application’s workflows. Ask whether business logic testing is included in the standard scope, or whether it requires an add-on.

This is especially important for financial applications, e-commerce platforms, and any system that handles transactions or multi-step workflows.

10. How do you define rules of engagement?

Rules of engagement (RoE) specify what testers can and cannot do. They should cover testing hours, social engineering boundaries, denial-of-service restrictions, data handling rules, and emergency contacts.

Ask to see a sample RoE document. Verify that it requires written approval before any destructive or high-risk testing activities.


Category 3: Reporting

The report is the primary deliverable. Its quality determines the value of the entire engagement.

11. Can I see a sample report?

This is the most important question in the entire list. A sample report tells you more about a company’s quality than any sales presentation. Review it for:

  • Executive summary - Clear, concise, written for non-technical stakeholders
  • Technical detail - Step-by-step reproduction of each finding with evidence
  • Risk ratings - Consistent, justified, tied to a recognized framework like CVSS
  • Remediation guidance - Specific, actionable, not just “apply patches”
  • Methodology section - Transparent description of what was tested and how

If a company will not share a sample report, treat that as a disqualifying signal.

12. How do you classify and rate vulnerabilities?

Ask whether findings are rated using CVSS, a proprietary scale, or something else. If they use CVSS, ask whether they apply environmental and temporal scores or only base scores.

Also ask how they handle findings that are low severity individually but high severity when chained together. The ability to demonstrate attack chains separates competent testers from checkbox operators.

13. What format is the report delivered in?

Most companies deliver a PDF. Some also provide raw data exports, CSV files of findings, or access to an online portal. Ask what formats are available.

If you need to import findings into a vulnerability management tool, ask whether the company provides data in a compatible format. JIRA integration or API access to findings can save your team significant time.

14. What is the typical turnaround time for the final report?

Ask for the number of business days between the end of testing and report delivery. Five to ten business days is standard for most engagements. Anything over 15 business days is slow.

Also ask whether you will receive a draft report with an opportunity to ask questions before the final version is issued.


Category 4: Communication and Logistics

Good communication prevents disruption and builds trust during the engagement.

15. How do you handle critical findings during testing?

If a tester finds an actively exploitable critical vulnerability on day two of a ten-day engagement, you need to know immediately. Not on day fifteen when the report arrives.

Ask about the company’s process for real-time notification of critical findings. Most good companies will call or message you within hours of confirming a critical issue. Get this commitment in writing.

16. Who is my point of contact during the engagement?

Ask whether you will have a dedicated project manager or account lead. Determine who to contact if you need to pause testing, adjust scope, or escalate an issue.

Also confirm how communication will happen. Encrypted email, Slack, a shared portal, or phone calls. Agree on this before testing starts.

17. What happens if testing causes an outage or disruption?

Penetration testing carries inherent risk. A mishandled exploit can crash a service. Ask the company what their incident response process looks like if they cause unplanned downtime.

Good answers include: immediate notification, cessation of testing, root cause analysis, and documented reporting of the incident. Poor answers include vague assurances that it will not happen.


These questions protect your organization from liability.

18. Do you carry professional indemnity insurance?

A penetration testing company should carry professional indemnity (errors and omissions) insurance. This protects both parties if the engagement causes damage or if the company misses a critical vulnerability that later gets exploited.

Ask for the coverage amount. Ask for a certificate of insurance. Companies that refuse to provide this information are not worth the risk.

19. How do you handle our data during and after the engagement?

Testers may access sensitive data during testing. Ask how data is stored, encrypted, transmitted, and destroyed. Ask how long the company retains engagement data and what their data destruction process looks like.

If your organization is subject to GDPR, HIPAA, or other data protection regulations, confirm the company can meet those requirements. A data processing agreement may be necessary.


Category 6: Post-Engagement Support

The engagement does not end when the report is delivered.

20. Do you offer retesting after remediation?

Retesting confirms that your team fixed the identified vulnerabilities correctly. Ask whether retesting is included in the original scope and price, or whether it costs extra.

Also ask about the retesting window. Some companies include retesting if remediation is completed within 30 days. Others extend the window to 90 days. Get the terms in writing.

21. How long are your testers available for questions after delivery?

Your development or infrastructure team will have questions about the findings. Ask how long the testing team remains available to answer those questions.

Two weeks of post-delivery support is common. Some companies offer 30 days. If there is no post-engagement support, factor that into your evaluation.

22. Do you provide strategic recommendations beyond individual findings?

The best reports go beyond a list of vulnerabilities. They identify patterns, systemic weaknesses, and strategic recommendations for improving your security posture over time.

Ask whether the company provides this kind of analysis. Ask whether a debrief call with your security and development teams is included.


How to Use These Questions

Do not treat this as a rigid script. Adapt the questions to your context. If you are buying an internal network test, business logic questions are less relevant. If you need PCI DSS compliance testing, add questions about ASV qualifications and the company’s experience with PCI scoping.

Here is a practical approach:

  1. Shortlist companies. Use a directory like pentest.fyi to find companies that match your requirements by service type, location, and certifications.
  2. Send a structured RFP. Include these questions in your request for proposal. Give companies a consistent format to respond in.
  3. Score responses. Create a weighted scorecard. Weight technical capability and reporting quality higher than price.
  4. Request sample reports. This step alone eliminates most weak candidates.
  5. Conduct a technical call. Before signing, get on a call with the actual testers. Ask them to walk through their approach to your specific environment.

Evaluation Scorecard Template

Use this template to compare companies side by side.

CategoryWeightCompany ACompany BCompany C
Technical capability25%
Methodology and scope20%
Reporting quality25%
Communication and logistics10%
Insurance and legal10%
Post-engagement support10%
Total100%

Score each category from 1 to 5 based on the company’s responses. Multiply by the weight. Sum the weighted scores. The company with the highest total is not automatically the right choice, but this framework makes the comparison structured and defensible.


Red Flags to Watch For

Some responses are red flags that should eliminate a company from consideration immediately.

  • No sample report available. Every established company has a sanitized sample report.
  • Cannot name testers or certifications. This suggests a brokerage model where work is subcontracted to unknown parties.
  • No professional indemnity insurance. This is a non-negotiable for any professional services engagement.
  • Pricing far below market rate. Extremely low pricing usually means automated scanning repackaged as a penetration test.
  • Vague methodology descriptions. If a company cannot clearly explain how they test, they likely do not have a structured process.
  • No rules of engagement document. This indicates immaturity and creates legal risk.
  • Guaranteed zero disruption. No honest company can guarantee this. The right answer is a clear incident response process.

Finding Companies to Evaluate

Building a shortlist is the first step. pentest.fyi is a free directory of penetration testing companies worldwide. You can search by service type, geographic location, certifications held, and industries served. Each listing includes the information you need to start your evaluation.

Using a directory saves time compared to cold searching. You start with companies that have already been categorized by the criteria that matter for your selection process.


Final Thought

Hiring a penetration testing company is a trust decision. You are granting an external team permission to attack your systems. The questions you ask before signing determine whether that trust is well placed.

Take the time to ask these questions. Compare the answers. Choose the company that gives clear, specific, evidence-backed responses. That company will almost always deliver the best results.

Key Takeaways

  • Ask about specific tester certifications, years of experience, and whether named testers will be assigned to your engagement.
  • Require sample reports before signing a contract so you can evaluate depth, clarity, and actionability of findings.
  • Confirm the company carries professional indemnity insurance and has a clear incident response plan if something breaks during testing.
  • Define scope, rules of engagement, and communication protocols in writing before any testing begins.
  • Ask about post-engagement support including retesting, remediation guidance, and how long the team remains available after delivery.

Frequently Asked Questions (FAQ)

How many questions should I ask a penetration testing company before hiring them?

There is no fixed number, but covering at least five categories is practical: technical capability, methodology, reporting, logistics and communication, and post-engagement support. The 20 questions in this guide give thorough coverage.

What certifications should a penetration testing company have?

Look for individual tester certifications like OSCP, CREST CRT/CCT, or GPEN. Company-level accreditations such as CREST membership or CHECK status add assurance. The right certifications depend on your industry and compliance requirements.

Should I ask to see a sample penetration test report before hiring?

Yes. A sample report is the best indicator of the quality you will receive. Evaluate it for technical depth, clear risk ratings, evidence of findings, and actionable remediation guidance.

How do I compare penetration testing companies effectively?

Use a structured evaluation framework. Score each company against the same set of questions. Directories like pentest.fyi let you filter and compare companies by service type, location, and certifications.

What is a reasonable timeline to expect for a penetration test engagement?

A typical web application test takes 5 to 15 days of active testing depending on complexity. Add time for scoping, reporting, and retesting. Ask the company for a detailed timeline broken down by phase.

Related posts