How to Choose the Right Penetration Testing Company: 10 Questions to Ask

Hiring a penetration testing company is not a checkbox exercise. It is a decision that directly affects whether your security controls will hold up against a real adversary, or collapse the moment someone runs a targeted phishing campaign or chains together a pair of unpatched CVEs. With dozens of vendors competing for your budget, the differentiators between a firm that delivers genuine risk reduction and one that runs automated scans and calls it a pentest are rarely obvious from a proposal document alone.

This guide gives you ten sharp, technically grounded questions to ask any penetration testing company before you sign the statement of work. The answers will reveal whether you are hiring a team of skilled adversary simulators or a compliance-report factory. If you are already evaluating vendors, reviewing a firm's actual service offerings alongside this checklist is a practical first step.

1. What Methodologies and Frameworks Do You Follow?

A credible penetration testing company will name specific, recognized frameworks and explain how it adapts them to your environment. The answer you want to hear includes some combination of PTES (Penetration Testing Execution Standard), OWASP Testing Guide, OSSTMM, and MITRE ATT&CK. For red team engagements, you should also hear about Cyber Kill Chain alignment and threat-informed adversary emulation.

What you do not want to hear is a vague reference to "industry best practices" with no specifics. That phrasing signals a methodology that exists in a marketing deck but not in a repeatable testing process.

Why This Matters for Your Organization

Frameworks dictate scope. A team using ATT&CK maps its findings to real-world threat actor TTPs, which means your remediation work is prioritized by actual risk rather than CVSS scores in isolation. Ask the vendor to show you a sample finding that references a specific ATT&CK technique ID, such as T1059.001 for PowerShell execution or T1003.001 for LSASS memory credential dumping. If they can produce that immediately, the methodology is real.

2. Can You Walk Me Through Your Reconnaissance Process?

Reconnaissance quality separates professional penetration testers from script runners. A skilled team will describe passive and active recon phases, including OSINT collection, certificate transparency log analysis, subdomain enumeration, and ASN mapping, before a single exploit payload is launched.

Ask specifically: "What tools do you use during recon, and can you show me a sample output?"

A competent team might reference a workflow like the following for subdomain enumeration and certificate transparency:

# Passive subdomain enumeration using Amass
amass enum -passive -d targetcorp.com -o passive_subs.txt

# Certificate transparency log query via crt.sh
curl -s "https://crt.sh/?q=%25.targetcorp.com&output=json" \
 | jq -r '.[].name_value' | sort -u | tee ct_subs.txt

# Merge and deduplicate
cat passive_subs.txt ct_subs.txt | sort -u > all_subs.txt

# Probe for live hosts
httpx -l all_subs.txt -silent -status-code -title -o live_hosts.txt


[cta]

This kind of toolchain reflects a disciplined, low-noise approach. A vendor who cannot describe their recon process in technical terms is unlikely to find the attack surface that a real threat actor would.

3. What Is Your Approach to Privilege Escalation and Lateral Movement?

This question cuts directly to the heart of what separates a vulnerability scan from a penetration test. Any automated scanner can flag an unpatched kernel or a misconfigured sudo rule. What you are paying for in a pentest is the human judgment to chain those findings into an actual attack path.

Ask the vendor: "After you gain initial access, how do you simulate lateral movement? What techniques do you use to escalate privileges in a Windows Active Directory environment?"

A strong answer covers Kerberoasting, Pass-the-Hash, token impersonation, ACL abuse, and GPO tampering. A sample of the kind of technical depth you should expect:

# Identify Kerberoastable accounts using PowerView
Import-Module .\PowerView.ps1
Get-DomainUser -SPN | Select-Object samaccountname, serviceprincipalname

# Request service tickets for offline cracking
.\Rubeus.exe kerberoast /outfile:hashes.txt /format:hashcat

# Crack offline with Hashcat (mode 13100 = Kerberos 5 TGS-REP)
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt \
 --rules-file /usr/share/hashcat/rules/best64.rule


[cta]

If the vendor stares blankly at a question about ACL-based privilege escalation paths in Active Directory, that is a disqualifying signal. Firms like Redfox Cybersecurity treat Active Directory attack path analysis as a core deliverable, not an optional add-on.

4. How Do You Scope an Engagement, and What Is Explicitly Out of Scope?

Scope definition is where many engagements fail before they begin. An experienced penetration testing company will walk you through a structured scoping call that covers IP ranges, domain names, cloud environments, third-party integrations, and social engineering boundaries. They will also be explicit about what is excluded and why.

Vague scoping is a liability. If the rules of engagement do not clearly define whether AWS metadata service endpoints, CI/CD pipelines, or payment processors are in scope, you will receive a report that reflects the vendor's assumptions rather than your actual risk surface.

Key Scoping Questions to Ask

• Are cloud-hosted assets such as S3 buckets, Azure AD tenants, and GCP service accounts included?
• Is the CI/CD pipeline in scope for supply chain attack simulation?
• Are physical security and social engineering tests available, and if so, what authorization documents are provided to testers in the field?
• How do you handle systems that are shared with third-party tenants or hosted on multi-tenant infrastructure?

The right vendor will produce a formal Rules of Engagement document before work begins, with explicit carve-outs and a defined communication protocol for critical findings discovered mid-engagement.

5. What Certifications Do Your Testers Hold, and Can I Meet the Team?

Certifications are a floor, not a ceiling, but they do signal baseline competency and commitment to the craft. Look for testers who hold OSCP (Offensive Security Certified Professional), OSED, OSEP, CRTO (Certified Red Team Operator), GXPN, or GPEN. For web application work, BSCP (Burp Suite Certified Practitioner) and GWAPT are relevant benchmarks.

What matters more than the certifications on paper is whether you can meet the actual team that will run your engagement. Some vendors sell on the reputation of senior researchers and then deliver junior testers with no oversight. Ask directly: "Who specifically will be on my engagement, and what is their experience with environments similar to mine?"

A reputable penetration testing company will not hesitate to introduce you to the testers before the contract is signed.

6. How Do You Handle Critical Findings During an Engagement?

This question reveals operational maturity. If a tester discovers a critical vulnerability, such as unauthenticated remote code execution on an internet-facing system or an exposed cloud storage bucket containing PII, what happens in the next 60 minutes?

A professional firm will have a defined out-of-band communication protocol for critical findings. That means a direct phone call or encrypted message to a named contact on your side, not a note buried in a final report delivered three weeks later.

Ask the vendor to describe their last critical finding notification. If they cannot give you a specific example or a defined escalation SLA, their incident communication process is improvised.

What a Good Critical Findings Protocol Looks Like

The vendor should be able to describe a written notification procedure that includes the finding title and severity, the affected asset and evidence, immediate recommended mitigation, and a named contact on both sides for the follow-up call. Some teams deliver a "flash report" as a structured document within hours of discovery, separate from the final engagement report.

7. What Does Your Final Report Contain, and Can I See a Sample?

The deliverable you are ultimately paying for is a report that drives remediation. A penetration test report that consists of automated scanner output with CVSS scores and generic recommendations is not a professional deliverable.

Ask for a sanitized sample report. Evaluate it on these criteria:

• Are findings mapped to ATT&CK techniques and real-world threat scenarios?
• Is there a narrative attack path section that shows how findings chain together?
• Are remediation recommendations specific, actionable, and prioritized by exploitability and business impact rather than CVSS alone?
• Is there an executive summary that a CISO can present to a board without technical translation?
• Are code-level or configuration-level fix recommendations included for technical teams?

For web application testing, you should also see evidence of manual testing beyond automated scanner output. A finding for SQL injection should include the exact parameter, the payload used, and proof-of-concept output:

GET /api/v1/products?id=1'%20AND%20SLEEP(5)--%20- HTTP/1.1
Host: app.targetcorp.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...

# Response confirms time-based blind SQLi via delayed response
# Confirmed with sqlmap for depth, then manually verified
sqlmap -u "https://app.targetcorp.com/api/v1/products?id=1" \
 --headers="Authorization: Bearer <token>" \
 --technique=T --dbms=mysql --level=3 --risk=2 --batch


[cta]

If the sample report you receive looks like it was generated by clicking "Export" in a scanning tool, move on to the next vendor.

8. Do You Offer Post-Engagement Support and Remediation Validation?

A single report delivery and a handshake is not a complete engagement. Vulnerabilities require remediation, and remediation requires validation. Ask the vendor whether a retest is included in the engagement fee or priced separately, and what the turnaround time is.

Reputable firms will offer a defined retest window, typically 30 to 90 days after report delivery, where confirmed findings can be retested at reduced or no additional cost. This is not a courtesy, it is a professional standard.

You should also ask whether the team is available for remediation guidance calls. Your developers will have questions about fix implementation, particularly for complex findings like deserialization vulnerabilities, SSRF chains, or OAuth token leakage. A vendor who delivers the report and disappears is not a security partner.

Redfox Cybersecurity structures engagements to include a post-report debrief call and defined retest availability as standard components. If you want to understand how structured remediation support fits into a testing engagement, that detail is worth discussing during your initial scoping conversation.

9. How Do You Ensure Confidentiality and Data Handling During the Engagement?

Penetration testers will have access to sensitive systems, credentials, and potentially PII during the course of an engagement. Your contract should define exactly how that data is handled, stored, transmitted, and destroyed.

Ask these specific questions:

• Are testers using encrypted communication channels for all findings and credential captures during the engagement?
• Where is engagement data stored, and who has access to it?
• What is your data retention policy for client data post-engagement?
• Do you carry professional liability and cyber liability insurance, and can you provide certificates?
• Will you sign a mutual NDA before scoping calls begin?

A vendor who hesitates on any of these questions, particularly around insurance or NDA execution, is a vendor who has not thought carefully about their professional obligations. Engagement data should be encrypted in transit and at rest, stored in isolated environments, and destroyed according to a defined schedule after report acceptance.

10. What Is Your Experience With Environments Like Mine?

This is the question that filters generalists from specialists. A firm that has spent years testing SaaS platforms built on Kubernetes is not automatically the right choice for a healthcare organization running legacy EHR systems, and vice versa. Ask for specific examples of prior engagements in your industry vertical or with your technology stack.

For cloud environments, ask whether testers have experience with IAM privilege escalation in AWS, service principal abuse in Azure AD, and workload identity misconfiguration in GCP. A technically grounded answer might reference techniques like the following:

# AWS IAM privilege escalation: enumerate attached policies
aws iam list-attached-user-policies --user-name low-priv-user
aws iam get-policy-version \
 --policy-arn arn:aws:iam::123456789012:policy/DevPolicy \
 --version-id v1

# Check for PassRole abuse potential
aws iam simulate-principal-policy \
 --policy-source-arn arn:aws:iam::123456789012:user/low-priv-user \
 --action-names iam:PassRole \
 --resource-arns "*"

# Enumerate EC2 instance profiles for credential harvesting paths
aws ec2 describe-instances \
 --query "Reservations[].Instances[].IamInstanceProfile"


[cta]

For OT and ICS environments, ask whether testers hold ICS/SCADA-specific training and whether they have experience with passive-only assessment approaches that avoid disrupting industrial processes.

Matching vendor experience to your environment is not a vanity requirement. It directly determines whether the findings in your report reflect your actual risk profile.

Final Thoughts

Choosing the right penetration testing company requires moving past marketing language and asking questions that expose technical depth, operational discipline, and professional accountability. The ten questions above are designed to do exactly that.

A vendor who can answer each of these with specificity, backed by real examples and sample deliverables, is a vendor who has built their practice around producing genuine security outcomes rather than generating compliance artifacts. A vendor who deflects, generalizes, or cannot produce a sanitized sample report on request is telling you something important before the contract is signed.

If you are currently evaluating penetration testing providers, Redfox Cybersecurity's service portfolio covers the full range of offensive security assessments including network penetration testing, web application testing, red team operations, cloud security assessments, and social engineering campaigns. Every engagement is staffed by certified practitioners who operate against real-world threat actor TTPs and deliver findings that your technical and executive teams can actually act on.

The quality of your next penetration test depends almost entirely on who runs it and how. Ask hard questions before you sign anything.