How to Choose a Penetration Testing Firm: 7 Questions Every Security-Conscious Business Should Ask

Can you walk me through your testing methodology?

A capable firm should be able to describe their approach to your engagement in plain language — not just hand you a list of tool names or certification logos. Ask them to explain their attack phases: how they approach reconnaissance and enumeration, how they move from external access to internal compromise, how they handle post-exploitation, and how they document their work as they go.

Reputable firms align their methodology with recognized frameworks. NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, provides the federal baseline for penetration testing methodology. The Penetration Testing Execution Standard (PTES) and OWASP Testing Guide are also commonly referenced. You don't need to be fluent in these frameworks — just ask whether the firm uses one, and whether they can point to where their methodology aligns with it.

Who specifically will be conducting our test, and what are their credentials?

This is the question that separates legitimate firms from marketing fronts. Many firms advertise team credentials at the company level — "our team holds OSCP, CREST, and GPEN" — without committing to which individuals will be on your engagement. That's a problem, because certifications don't transfer between people.

Ask for the names of the specific testers assigned to your engagement and the certifications they personally hold. OSCP (Offensive Security Certified Professional) is the practical baseline — it requires passing a 24-hour live exploitation exam with no internet access. OSEP and OSWE indicate advanced capability in evasion and web exploitation. GPEN (GIAC Penetration Tester) is well-regarded in enterprise and compliance contexts. For highly regulated industries, ask about CREST or CHECK accreditation.

Be cautious of firms whose only listed credentials are CompTIA Security+ or CEH (Certified Ethical Hacker). Both are legitimate knowledge-based certifications, but neither requires passing a practical exploitation exercise. They tell you someone studied security; they don't tell you someone can break into your network.

How do you approach the scoping process?

Pay close attention to what happens before a firm sends you a proposal. A skilled firm will ask a lot of questions first: What's your environment — on-premises, cloud, hybrid? Do you have an IT team that will be notified during testing, or do you want a completely blind test? What compliance frameworks apply to you? Have you had a previous penetration test, and what did it find? Are there systems that are explicitly off-limits — production databases, SCADA equipment, third-party-managed infrastructure?

A firm that sends a quote within 24 hours of your first inquiry, with no scoping call, is pricing from a template. That template might cover your environment adequately — or it might miss your most critical assets entirely. Rushed scoping is one of the most common reasons penetration test results fail to reflect actual organizational risk.

We've seen engagements where the client assumed their cloud infrastructure was included in scope; the tester assumed it wasn't. The on-premises network got tested thoroughly. The AWS environment — where 90% of the sensitive data lived — was never touched. Both parties signed off on the final report, and the client left believing they had a clean bill of health.

Can I see a sample report from a previous engagement?

Every reputable firm should be willing to share a redacted sample report from a similar engagement. This is your most reliable preview of what you're actually buying. Read it carefully — not just for completeness, but for quality.

A strong report includes an executive summary written for non-technical leadership (not a CVSS score table), an attack narrative that describes what the tester did and how far they got, per-finding details with proof of exploitation (screenshots or command output), business impact described in plain language, and specific remediation steps — not "apply vendor patches," but the actual configuration change, policy path, or code fix.

A weak report reads like a Nessus export with a cover page. If the sample shows 47 CVEs with severity ratings and generic remediation categories, that's a vulnerability scan result delivered with penetration testing pricing. Real pentest reports describe the attack path: "we gained initial access via a default credential on the management interface, used that foothold to enumerate the internal network, discovered an unpatched SMB service on the finance server, and achieved domain administrator access within six hours." That narrative tells you something actionable about your actual risk.

What remediation support do you provide after the report is delivered?

A penetration test that delivers a report and disappears is only half an engagement. The report is a list of problems; fixing those problems is where the security value is actually realized. Ask specifically what happens after delivery.

The most important element is a re-test — a targeted follow-up to confirm that critical and high findings were actually fixed, not just marked resolved in a spreadsheet. PCI DSS v4.0 requires annual penetration testing and targeted re-testing of all failed controls. Even if you're not subject to PCI DSS, the re-test standard makes sense for any organization: the original test finds the problem; the re-test confirms the fix. Without it, you're trusting your IT team's self-assessment of whether their own remediation worked.

Beyond re-testing, ask whether the team is available to answer technical questions from your IT staff during the remediation window. In practice, many findings require back-and-forth between the tester and the team fixing the issue — particularly for complex configuration problems or findings that touch third-party systems. Firms that close the ticket on report delivery are optimizing for throughput, not outcomes.

Have you tested environments in our industry?

Penetration testing is not a purely generic discipline. Healthcare networks have specific risks — HL7 interfaces, medical device management systems, HIPAA-governed data stores — that a tester without healthcare experience may simply overlook. Law firms have document management systems and client portal architectures with business logic vulnerabilities that don't appear in generic methodology checklists. Manufacturing environments may include OT networks where standard exploitation techniques would cause operational disruption that needs to be avoided.

Ask the firm to describe a previous engagement in your industry or a similar one. What did they find? What did the environment look like? What were the most common weaknesses? You don't need a case study naming a specific client — you need evidence that the tester has a mental model of your environment before they start. A tester who has never worked in a professional services environment and doesn't understand how legal document management systems are typically architected is going to test what they recognize, not what's actually most at risk in your organization.

We've found that in many SMB engagements, the highest-risk findings are not glamorous exploits — they're default credentials on network switches, flat network architectures that allow any workstation to reach any server, unmonitored management interfaces accessible from employee desktops, and IT vendors with persistent remote access tools that haven't been audited in years. These findings require industry context to prioritize correctly.

What insurance and liability coverage do you carry?

Penetration testing involves authorized access to sensitive systems. If a tester causes service disruption, triggers a security alert that results in incident response costs, or inadvertently corrupts data during exploitation, you need to know who is responsible and whether there is coverage to make it right.

Ask specifically for professional liability (errors and omissions) insurance and cyber liability coverage. A reputable firm will disclose coverage limits without hesitation. For engagements that touch production systems or involve significant scope, ask to be named as an additional insured on the policy during the engagement window — this is standard practice in formal procurement and not an unusual request.

Also ask whether the firm has ever experienced a security incident involving client data, and how they handled it. Evasive answers here are meaningful. A firm that handles privileged access to dozens of client networks is itself a high-value target. You want to know they take their own security posture seriously.