What Is Penetration Testing? A Founder's 2026 Buyer Guide

A penetration test is a time-boxed, authorized, human-driven attempt to compromise the security of your systems by chaining vulnerabilities together the way a real attacker would, and then writing down exactly what worked so you can fix it. That is the whole job.

What a pentest is not: it is not a vulnerability scan, which is an automated tool that produces a list of known weaknesses without verifying impact. It is not a compliance checkbox you can fake. It is not a one-and-done event that proves your environment is permanently secure. And it is not a magic spell that prevents breaches — it is a snapshot of your security posture on the days the test ran, against the threat model the engagement scoped for.

The reason the distinction matters is that the cybersecurity industry has done a poor job protecting the word. Every vendor selling vulnerability scanners or asset management platforms now calls their output a "pentest" in marketing copy, which means non-security buyers cannot tell what they are actually getting. If the deliverable does not include a human chaining findings into a narrative attack path, you bought a scan, not a pentest, and the two are priced differently for a reason.

Most shops bucket their offerings into five engagement types. You usually need one or two of these, not all five, and the right scoping conversation starts with which types apply to your threat model.

Web application pentesting. Targets your customer-facing or internal web applications and APIs. This is what most SaaS companies need first because it is where customer data lives. A web pentest will look at authentication, authorization, input validation, session management, business logic flaws, and the API surface — including endpoints that exist but are not linked from the UI. Web app pentest scoping usually starts with an inventory of the app, its third-party integrations, and its authentication flow.

Network pentesting. Targets your network perimeter (external) or your internal corporate network (internal). External network tests look for exposed services, weak authentication, and misconfigurations on internet-facing infrastructure. Internal network tests assume an attacker has already gotten a foothold — usually through a phishing email or a stolen laptop — and tries to see how far that foothold can spread. Network pentests usually run alongside Active Directory testing for any company with more than 20 employees.

Active Directory pentesting. A subset of internal network testing focused on Windows AD environments specifically. Almost every breach of a company that uses AD goes through AD at some point, which is why AD-focused pentests have become a category of their own. The deliverable should include the specific Kerberos and ACL findings that lead to domain compromise, not a generic list of patch levels.

Wireless pentesting. Targets your Wi-Fi infrastructure on-site. Includes rogue access point detection, WPA2/WPA3 attack paths, captive portal bypass, and lateral movement from guest Wi-Fi into corporate. Often bundled with a physical engagement.

Social engineering. Targets your people. Includes phishing campaigns (email, SMS, voice), pretext-based information gathering, and sometimes on-site physical engagements. Social is almost always the highest ROI per dollar but requires clear rules-of-engagement to keep the team safe and the test legal.

The "box color" refers to how much information you give the pentest team before testing starts. Most buyers assume black box (zero information) is the most realistic and therefore the best. That is wrong about 80% of the time.

Black box means the testers start with nothing — just a company name or a domain. They have to find the assets, profile them, and attack them like a real external adversary. The argument for black box is realism. The argument against is that pentests are time-boxed: a real attacker has years; your pentest team has two weeks. Most of that time gets burned on reconnaissance instead of finding real bugs.

Grey box means the team starts with limited information — usually a low-privilege user account, a network diagram, or both. This is the right default for most engagements because it skips the part of a real attack that does not produce learnings (reconnaissance) and gets straight to the part that does (chaining vulnerabilities into impact). For web app testing especially, grey box is almost always the right call.

White box means the team gets full access — source code, admin accounts, network diagrams, documentation. White box engagements find more bugs per dollar than any other variant, especially when the testers can read the code. They are the right call when you are pre-launch, when you need maximum coverage, or when you are compliance-driven and need the deepest possible result.

Every legitimate pentest follows roughly the same six phases, in this order. If the shop you are talking to skips one, ask why.

Phase 1 — Scoping. The shop talks to you about your assets, your threat model, your compliance drivers, your testing windows, and your rules of engagement. A good scoping call lasts an hour and produces a written statement of work with specific in-scope and out-of-scope assets, testing dates, escalation paths, and report-delivery commitments. If you are scoped in 15 minutes from a templated quote, you are buying a templated test.

Phase 2 — Reconnaissance. The team gathers information about your environment — passive (OSINT, DNS, certificate transparency) and active (port scanning, banner grabbing). The output is an asset inventory that becomes the attack surface.

Phase 3 — Vulnerability identification. Manual and automated discovery of weaknesses against the asset inventory. Good shops manually validate every finding before it goes in the report, which is how you avoid false-positive reports from the cheaper vendors.

Phase 4 — Exploitation. The testers actually exploit the validated vulnerabilities to demonstrate impact. This is the difference between "you have a SQL injection" and "we used the SQL injection to pull every customer record in the database — here is the proof."

Phase 5 — Post-exploitation. The testers see how far the initial compromise can spread. Can they pivot to other systems? Can they escalate privileges? Can they exfiltrate sensitive data? This is where MITRE ATT&CK mapping earns its keep — every technique chained into the attack path gets tagged with the corresponding TTP ID.

Phase 6 — Reporting. The written deliverable, which we'll cover in detail in the next section.

The report is the deliverable. Everything else is process. A non-technical reader (your CEO, your auditor, your insurance broker) should be able to read the executive summary and understand both the severity of the risk and the path to fixing it. A technical reader (your engineering team) should be able to reproduce every finding and validate the fix.

A good report includes: an executive summary with risk rating; a scope and methodology section; a full attack narrative showing how findings chain together; per-finding entries with severity, evidence (screenshots), reproduction steps, MITRE ATT&CK and OWASP mapping, business impact, and remediation guidance; a risk-prioritized remediation roadmap; and a commitment to retest after fixes land. Reports that just list CVEs with CVSS scores are not pentest reports — they are scan output with a logo.

Red flags in a sample report: no attack narrative, every finding rated critical (severity inflation), CVSS scores treated as the only severity input, no reproduction steps, no remediation specifics, no mapping to ATT&CK or OWASP, and no retest clause. Ask for an anonymized sample before you sign. Any shop that will not show you one is hiding the quality of the deliverable.

Most companies do not buy their first pentest because they decided they wanted one — they buy it because a compliance framework or an insurance application forced them. Knowing which framework is driving the requirement matters because the scope and depth differ.

SOC 2. The standard says you need a "regular" pentest. In practice, annual is the expectation, with re-tests after major changes. Auditors want to see scope, methodology, executive summary, and evidence of remediation.

HIPAA. The technical safeguards section requires a regular evaluation but does not specify pentest. In practice, healthcare auditors look for an annual pentest plus continuous vulnerability management. Web app scope is usually mandatory; internal network scope is wise.

PCI DSS. The strictest requirements. PCI requires both internal and external pentests annually, plus after "significant changes," plus segmentation testing if you use it to reduce scope. PCI also has specific methodology requirements that your shop should be able to recite without hesitation.

Cyber insurance. The fastest-growing pentest trigger. Insurers increasingly want evidence of a recent pentest before they renew, especially for policies above $1M. The pentest does not have to be heavy — but it has to be real and recent. If you are seeing your premium quote double on renewal, a pentest plus visible remediation is usually the cheapest fix.

The three offerings sound similar and are very different. The short version: a vulnerability scan is automated and broad, a pentest is human-driven and time-boxed against specific assets, and a red team engagement is objective-driven and stealth-aware.

A vulnerability scan is your gym checkup — it tells you whether you have the basics covered. A pentest is your annual physical — a doctor poking around to see what hurts. A red team engagement is a stress test in a hospital — a multi-week, no-holds-barred attempt to see if a determined adversary could reach a specific objective like "exfiltrate the customer database" or "reach domain admin" without being caught by your defenders.

Most companies need a pentest before they need a red team engagement. Red teams assume you already have detection and response capability worth testing. If your incident response plan is a Slack channel and a wish, start with a pentest.

Honest ranges, in 2026 dollars, from a US-based shop with a real methodology. Anything materially below these numbers is either an automated scan dressed up as a pentest or a foreign shop with quality risk worth pricing in. Anything materially above is either a Big-Four name premium or a much larger scope than you actually need.

External network pentest. $8,000 to $18,000 for a small environment (under 50 external assets). Larger environments scale roughly linearly.

Internal network and Active Directory pentest. $15,000 to $35,000 depending on the size of the environment, the number of subnets, and AD complexity.

Web application pentest. $10,000 to $25,000 for a single application of moderate complexity. Multi-tenant SaaS, complex auth, or admin/customer portal splits push the price up.

Wireless pentest. $6,000 to $15,000 depending on the number of sites and APs.

Bundled engagements. Most shops will package external + internal + AD + web for somewhere in the $35,000 to $80,000 range, which is the most common scope for a SOC 2 or HIPAA-driven first pentest. We've published a separate guide on pentest cost ranges in 2026 with more granular numbers per scope variant.

For founders in the Southeast specifically, we've covered how to evaluate Georgia-based pentest shops with a focus on what local methodology and engagement experience actually buy you over an East-Coast remote vendor.

If you are early in the process and trying to figure out which type of pentest your situation calls for, the most useful next read is our explainer on MITRE ATT&CK, because methodology is the single biggest quality differentiator between shops. If you are further along and have a scope in mind, our pentest service page covers the specifics of how we run engagements. If you are local to Atlanta, Macon, or anywhere in the Southeast and want to talk about on-site engagements, our Atlanta software and security page covers the local angle.