By the time you're comparing vendors, the proposals in front of you look nearly identical: overlapping certifications, similar pitch decks. And whatever you choose, you'll have to defend the spend to the people who sign off on it. The firms that do the work and the firms that resell scanner output diverge on three things, all auditable before you sign anything.

Here's how to test for each before you commit.

How Can You Tell Manual Testing From an Automated Scan?

A real penetration test is manual, scenario-based exploitation, and it looks different from an automated scan once you know what to check for. That difference is what separates a report that passes an audit from one that actually reduces risk — the compliance-fatigue gap every infrastructure lead knows.

An automated scanner reliably flags an outdated Apache banner. What it won't find is a business logic flaw — the kind where an authenticated user changes /api/v1/user/101 to /api/v1/user/102 and pulls another customer's records. That's a BOLA (broken object level authorization) vulnerability, and it's invisible to a scanner because nothing is technically broken, since the server still returns a valid response. A scanner matches known vulnerability signatures; it has no concept of who should see which record. A human tester who understands the application's intended logic, and asks whether this specific user should have access to this specific record, is the one who catches it. CrowdStrike's 2026 Global Threat Report found that 82 percent of 2025 detections were malware-free, with adversaries moving through valid credentials, not the known-bad signatures a scanner is built to catch.

The clearest marker of a real engagement is the exploit chain: combining low-severity findings into a high-impact compromise. If a vendor can't walk you through one from a past engagement, that's a sign the testing was automated, not manual. NIST SP 800-115, the federal government's technical guide to security testing, draws this same distinction: scripted enumeration is not adversarial simulation.

How Do You Audit a Vendor's Scoping Math?

Cross-reference the timeline a vendor quotes against endpoints, APIs, and user roles, and the math will expose an automated-only scan every time. A proposal that doesn't survive arithmetic doesn't survive the engagement.

Say a vendor quotes three days to test a 100-endpoint application with five user roles. That timeline doesn't cover reconnaissance, let alone manual testing. It only works if a tool is doing the work. A seasoned firm builds scope from the asset inventory up, and comparing the quoted timeline against the asset count is what makes bids comparable: a shorter quote usually means less real testing, not better value.

Scope also defines what the test can find: black-box engagements simulate an attacker with no prior knowledge, while grey-box engagements use credentialed access to spend hours exploiting instead of days reconnoitering. A vendor who can't explain which model fits your environment is running the same playbook for every client.

How Do You Stop a Vendor From Subcontracting the Work?

Write it into the Master Services Agreement — verbal assurance that "our team" runs the engagement means nothing without a clause behind it. Cascading subcontracting is the red flag competitors name but never teach you to prevent: a primary contractor wins the engagement, then hands execution to unvetted freelancers without disclosure. In practice, that means the team whose resumes and references you reviewed is not the team touching your network — and you have no way to know until something goes wrong.

Three clauses close the loophole: named, in-house testers identified in the contract, not "qualified personnel"; active payroll verification so those testers are demonstrably employees; and a financial penalty for undisclosed subcontracting. Work these through legal and procurement; they're a compliance safeguard, not just a quality one. PCI DSS v4.0.1 requires organizational independence between the testing team and the people who built or administer the environment, and Requirement 11.4.1 mandates testing at least annually and after any significant infrastructure change. You can't demonstrate independence for testers you can't name.

How Do You Read a Sample Report Like a Practitioner?

Judge the proof, not the polish. Every vendor hands you a sanitized sample; most infrastructure leads skim it for formatting. Read it for the proof-of-concept instead.

A finding worth paying for includes the raw request/response, the exploit script, and reproduction steps, not a scanner screenshot with a logo on it. Strong reports also include remediation verification: proof the vendor retested and confirmed the fix closed the gap. Ask whether that's in the fee or billed as an upsell; the answer tells you whether the firm stands behind its findings. See The Anatomy of a Penetration Testing Report.

Which Certifications Actually Matter — and Why They're Only the Floor

OSCP, OSWE, and CREST are meaningful, but they're the floor, not the ceiling — a firm that leads with a credential list and nothing else is telling you something.

The vendors worth hiring treat credentials as table stakes and compete on methodology, mapping findings to MITRE ATT&CK® so you can see which techniques your environment withstood. Ask what a firm does beyond the certs. See our 5 interview questions to ask penetration testing companies.

Common Questions About Vetting a Pentest Vendor

How do you evaluate a penetration testing company?

Evaluate three things: whether the testing is genuinely manual, whether the scoping math holds up, and whether the named testers are contractually locked in. A vendor that fails any is a risk regardless of price.

How can you tell if a vendor is running automated scans instead of a manual pentest?

Run the scoping math and read a sample report: if the quoted timeline can't cover manual testing, or findings are backed by scanner screenshots rather than raw request/response payloads, the testing was likely automated, not manual.

Does a penetration test report satisfy PCI DSS, SOC 2, and HIPAA?

A properly scoped penetration test produces the documented findings these frameworks expect, and PCI DSS's organizational-independence requirement is one more reason to contractually name your testers. A report that satisfies the audit but doesn't harden your cyber security posture has only solved half the problem.

Choose a Partner That Passes Its Own Test

When social engineering is within scope, The Global Ghost Team™ has maintained a 100 percent success rate in penetrating the security of every system it has been engaged to test. Hold any cybersecurity partner to the same standard: ask us to walk you through the scoping math, name the testers, and show you the proof behind a finding you can put in front of leadership.

Not sure which type of test your program actually needs first? Take the Pentesting Readiness Quiz to find out where you stand before a scoping conversation.