What Is Penetration Testing? A Practical Guide

What penetration testing actually is

A penetration test is a security assessment where a qualified person — not an automated tool — attempts to compromise your application, API, network, or cloud account in ways an attacker would. The goal is not to confirm you have vulnerabilities (most environments do). The goal is to find the ones that matter, prove they are exploitable, and write up how to fix them in a way your engineers can act on.

Three things usually distinguish a real pentest from "running a scanner and emailing the report":

• A human reasoning about your business logic. Scanners can find the SQL injection in a login form. They cannot find that an account in the "viewer" role can call the export endpoint that should be admin-only.
• Chained findings. The interesting attack paths are usually two or three medium-severity issues combined into one critical-severity outcome. That chaining is what makes pentests valuable.
• A report your engineers will act on. Each finding has a working proof of concept, a clear severity, and a remediation an engineer can paste into a ticket — not a CVE description and a generic "patch this".

The main types of pentests

Engagements are usually scoped by surface. The same testing fundamentals apply, but the depth and the framework alignment shift.

Type	What it covers	Typical driver
Web application	OWASP Top 10, business logic, authorization, multi-tenant boundaries	Customer security review, SOC 2, ISO
API	OWASP API Top 10, REST/GraphQL/webhook surfaces, BOLA, BFLA, rate limits	Customer integration, partner audit
Network and cloud	External and internal network, AWS/Azure/GCP IAM, configuration drift	PCI DSS, ATO, board-level security review
Authenticated	Role-matrix coverage; what every role can do to every resource	Multi-tenant SaaS, role-rich product
Red team	Adversary simulation across initial access, lateral movement, objectives	Detection program validation
AI / LLM feature	Prompt injection, RAG leakage, tool-use safety, OWASP LLM Top 10	Customer red-team request, AI Act readiness

Most teams pick the surface that maps to the conversation that triggered the engagement — a customer asking for a pentest report, an audit on the calendar, a new feature shipping.

How an engagement actually works

Six phases, more or less universal across reputable vendors. The names vary; the work doesn't.

1. Scoping

A short call to agree what's in scope, what's explicitly out, and what would actually hurt the business if compromised. Output: a fixed scope, a price, and a date.

2. Preparation

Test accounts provisioned, environments confirmed, rules of engagement signed, communication channels opened. This is also where any safe-testing constraints get documented — production windows, rate limits, hosts to exclude.

3. Reconnaissance and surface mapping

The tester maps the application or environment as it actually exists in the wild — endpoints in production may differ from the spec or the architecture diagram. This is where most "shadow" attack surface gets surfaced.

4. Active testing

Manual exploitation across the agreed surfaces. Confirmed findings are written up immediately, with safe proofs of concept and reproduction steps. Critical findings are shared the same day, not at the end.

5. Reporting

One document, three audiences. A one-page board summary. An executive section with control mapping for SOC 2, ISO, PCI, HIPAA. A developer section where every finding has steps, evidence, severity, and a paste-ready remediation.

6. Retest of reported findings

After your engineering team fixes the items in the report, the affected findings get retested and the report gets updated. This matters because the version your auditor or customer ultimately sees should reflect post-fix state, not test-day state.

Manual versus automated

The honest answer is that both belong in a mature program — they answer different questions:

• Automated scanning finds known issues at high coverage and low cost. It catches obvious things fast and gives you continuous visibility between deeper engagements.
• Manual testing finds issues a scanner cannot reach: broken authorization, multi-tenant isolation gaps, business logic flaws, novel input combinations, and chained attack paths.

If your program runs scanners but never runs a real pentest, you have coverage of the easy class of bugs and zero coverage of the hard class — which is the class real intrusions exploit. If your program runs annual pentests but no scanning between, you are blind to drift and to the easy-and-obvious things that creep in between assessments. The right answer is usually both, scoped honestly.

How to pick a vendor

Three signals tend to predict whether the engagement will produce something useful:

• Who actually does the testing. Ask whether the person on the scoping call is the person doing the work, or whether the engagement is delegated to junior testers or subcontractors after signing.
• What the deliverable looks like. Ask to see a redacted report. If every finding is a CVE description plus a generic remediation, the report will not get fixed.
• What happens after the report. A retest after fixes should be in scope by default, not an add-on. Otherwise the report you ship to auditors and customers reflects test-day state, not reality.

When to run a pentest

Three triggers cover most real-world cases:

• Compliance cadence. SOC 2, ISO 27001, PCI DSS, HIPAA, FedRAMP — all expect periodic penetration testing. Annual is the minimum for most; PCI requires more frequent for cardholder environments.
• Material change. A new product, a major feature, a new authentication system, a new region, a new partner integration. Anything that changes the trust model is worth a fresh test.
• Business pressure. A customer asking for a current report, an investor diligence question, a board-level concern, or a regulator inquiry. These are not optional, and they rarely give you long timelines.