The short version
- A pen test is an authorized attempt to exploit vulnerabilities the way an attacker would.
- It validates that controls work under pressure, not just that software is patched.
- Common types are external network, internal network, web application, API, wireless, and social engineering.
The longer explanation
What a pen test actually does
Pen testers use the same techniques real attackers use — reconnaissance, exploitation, privilege escalation, lateral movement, data exfiltration — within a carefully scoped engagement with the client's written authorization. The goal is not just to find vulnerabilities; it is to demonstrate what those vulnerabilities enable an attacker to do in the client's specific environment.
That distinction matters. A Log4j advisory says "there is a critical vulnerability in this library". A pen test says "we exploited the vulnerable library on your public-facing API, pivoted to an internal service, and extracted the following PII records". The second finding drives urgency and remediation budget in a way the first never does.
Common pen test types
External network. Tests the internet-facing perimeter — web applications, VPN endpoints, email gateways, exposed services. The most common starting point.
Internal network. Tests what an attacker with a foothold inside the network can do. Often chained with a phishing-based initial-access test or simulated from an "assumed compromise" starting point.
Web application. Tests a specific application against the OWASP categories plus business-logic flaws that automated scanners cannot find.
API. Tests REST, GraphQL, and gRPC APIs for authn/authz flaws, business-logic issues, and injection.
Wireless. Tests the Wi-Fi environment for rogue access points, weak encryption, and segmentation issues.
Social engineering. Tests the human layer — phishing, vishing, physical-access simulations. Often paired with a technical test to demonstrate the full kill chain.
Red team. A broader engagement that tests the client's detection and response capability, not just the point-in-time security of the target. Red team engagements typically combine multiple techniques and stretch over weeks.
How scoping should work
A good scope is driven by the client's highest-risk scenarios and compliance obligations, not by what the tester is fastest at. The scoping conversation covers:
- What systems or scenarios are in scope? What is explicitly out?
- What is the test window? Business hours only, after hours, or 24x7?
- What data types are in play, and what is the handling protocol?
- What are the escalation paths if a tester finds something requiring urgent attention during the test?
- What is the deliverable — a report, a debrief, a retest after remediation?
What the deliverable should look like
A pen test report is valuable for as long as the findings are actionable. A good report includes:
- Executive summary for leadership.
- Ranked findings with business-risk context, not just CVSS.
- Technical detail with reproduction steps for the client's security team.
- Narrative attack path that ties findings together.
- Remediation guidance that is specific and implementable.
- Evidence and screenshots.
How Thoughtwave approaches this
Our cybersecurity practice runs external, internal, web, and API pen tests for clients across financial services, healthcare, retail, and government. We integrate application-security testing (SAST and DAST) into CI/CD for clients where per-release testing is the right cadence, and we run targeted re-tests after remediation of critical findings.
For the broader context, see our Cybersecurity Solutions service.