What is Penetration Testing?
An authorized, simulated attack on your own systems by skilled testers to find and prove exploitable weaknesses before real attackers do.
Definition
A penetration test (pentest) is a time-boxed, authorized engagement in which testers attack an application, network, cloud account, or device the way a real adversary would, then report what they could compromise and how to fix it. The key difference from automated vulnerability scanning is human judgment and chaining: a scanner lists an outdated library and a verbose error page, while a tester combines a leaked internal hostname, an SSRF bug, and an over-permissive cloud role into full data access. Engagements start with scoping and written rules of engagement that define targets, dates, allowed techniques, and emergency contacts. Testing proceeds through reconnaissance, discovery, exploitation, and post-exploitation, then a report ranks findings by risk with reproduction steps and remediation advice. Tests are black-box (no prior knowledge), gray-box (user credentials or partial docs), or white-box (source code and architecture). Common methodologies include the OWASP Web Security Testing Guide, PTES, and NIST SP 800-115; typical tools include Burp Suite, nmap, Metasploit, and cloud-specific tools. Red-team exercises are broader, goal-driven campaigns that also test detection and response. Compliance often drives pentests. PCI DSS v4.0.1 requirement 11.4 calls for internal and external testing at least every 12 months and after significant changes, with segmentation testing every six months for service providers. SOC 2 does not explicitly mandate a pentest, but auditors commonly expect one as evidence of control monitoring.
When to Use Penetration Testing
Commission a pentest before a major launch, after significant architectural changes, annually for compliance, or when a large customer's security review asks for a recent report. Fix findings from automated scanning and code review first; paying testers to rediscover missing headers wastes the budget. Gray-box testing usually gives the best coverage per day because testers skip guesswork. Scope matters: include authentication flows, multi-tenant boundaries, APIs, and cloud configuration, not just the marketing site. A pentest is a point-in-time snapshot, not continuous assurance; pair it with SAST, dependency scanning, and a bug bounty or vulnerability disclosure program. Never test systems you do not own or lack written permission to test.
Penetration Testing in Practice
- A gray-box SaaS test: testers receive two accounts in different tenants and find that changing an orgId in an API request returns the other tenant's invoices, a critical broken-access-control finding.
- Initial network discovery of an in-scope host, listing open ports and service versions: nmap -sV -p- --open -oA scan-results 203.0.113.10
- A cloud review finds an EC2 instance role with s3:* on all buckets; combined with an SSRF in an image-fetch feature, testers read instance credentials from the metadata service and download backups.
- A retest after remediation confirms the tenant-isolation fix holds and the report is updated, satisfying PCI DSS 11.4.4's requirement to verify corrections.
Common Mistakes
- Treating an automated scan report as a pentest. Scanners miss business-logic and chained flaws; ask for evidence of manual exploitation.
- Scoping only production web pages and excluding APIs, mobile backends, or cloud accounts. Scope by data flows and trust boundaries, not by URL list.
- Testing without written authorization from the system owner, including third-party hosts. Get signed rules of engagement and check cloud provider policies.
- Filing the report and never retesting. Track findings to closure and schedule a retest to confirm fixes.
- Running the test against a staging environment that differs from production configuration, so results do not reflect real exposure.