Penetration testing is an authorized, time-boxed simulated attack on systems, applications or networks in which skilled testers find and actively exploit vulnerabilities to demonstrate what a real attacker could achieve. Unlike an automated scan, a penetration test proves impact by chaining weaknesses together, for example from an exposed login page to a database full of customer records.
In security testing, penetration testing sits between automated techniques such as SAST, DAST and fuzzing and the broader adversary simulation of a red team. Its output is a report of verified, prioritized findings with remediation guidance, which makes it a standard requirement in security programs, customer contracts and regulations such as PCI DSS.
Phases of a penetration test
A professional penetration test follows a defined methodology so that results are repeatable and comparable. Common references include NIST SP 800-115, the Penetration Testing Execution Standard (PTES), the OWASP Web Security Testing Guide and OSSTMM, which describe broadly the same sequence of phases.
| Phase | Main activities | Output |
|---|---|---|
| Pre-engagement | Scope, rules of engagement, written authorization | Signed test plan and contacts |
| Reconnaissance | Passive and active information gathering | Map of hosts, services and technologies |
| Vulnerability analysis | Scanning and manual analysis of weaknesses | List of candidate vulnerabilities |
| Exploitation | Controlled attempts to exploit findings | Proof of access or data exposure |
| Post-exploitation | Privilege escalation and lateral movement | Demonstrated attack paths and impact |
| Reporting and retest | Findings, severity, fixes, verification | Report and retest confirmation |
Written authorization is mandatory. Without explicit permission from the system owner, the same activities constitute unauthorized access under computer misuse laws, and third-party platforms such as cloud providers or hosting companies may impose their own testing policies.
Types and knowledge levels
Penetration tests differ by target and by how much the testers know in advance. The knowledge level trades realism against coverage within a fixed budget of days.
| Approach | Information given to testers | Advantage | Drawback |
|---|---|---|---|
| Black box | Only a target name or address range | Realistic outsider view | Time spent on discovery, lower coverage |
| Gray box | User accounts and basic documentation | Good balance of realism and depth | Assumes a partially informed attacker |
| White box | Source code, architecture, credentials | Deepest coverage per day | Less representative of an external attack |
Common target types include external network, internal network, web application, API, mobile application, cloud configuration, wireless and social engineering tests. A web application test of moderate size typically takes about 5 to 15 person-days, depending on the number of roles, endpoints and business functions in scope.
Penetration testing compared with related methods
Penetration testing is one of several security testing methods, and each answers a different question. Mature programs combine them rather than choosing one.
| Method | Main question | Performed by | Typical frequency |
|---|---|---|---|
| Vulnerability scanning | Which known weaknesses are present? | Automated tools | Weekly to continuous |
| SAST | Does the source code contain insecure patterns? | Static analysis tools | Every code change |
| DAST | Does the running application respond insecurely? | Automated dynamic scanners | Every release or scheduled |
| Fuzzing | Does malformed input cause crashes or errors? | Automated fuzzers | Continuous for parsers and protocols |
| Penetration testing | What can an attacker achieve within the scope? | Human testers with tools | Annually and after major changes |
| Bug bounty | What can many independent researchers find? | External researchers paid per finding | Continuous |
| Red team | Can defenders detect and stop a realistic attacker? | Specialized adversary team | Periodic campaigns |
The key difference from a red team is the goal. A penetration test aims to find as many significant vulnerabilities as possible in a defined scope, usually with defenders informed, while a red team pursues a specific objective covertly to test detection and response.
Scoping, frequency and compliance
A test is only as useful as its scope. It should cover the assets that matter most to the business, include the authentication and authorization model of applications, and state explicitly what is excluded, such as denial-of-service attacks or production data changes.
Several frameworks set minimum expectations. PCI DSS requires internal and external penetration testing at least once every 12 months and after significant changes, plus regular testing of segmentation controls. The EU Digital Operational Resilience Act requires threat-led penetration testing at least every three years for selected financial entities, and many enterprise customers request a recent independent test report during vendor due diligence.
Findings are usually rated with CVSS scores adjusted for business context. A good report contains an executive summary, a description of each attack path, reproduction steps, evidence and specific remediation advice, followed by a retest that confirms each fix.
Limitations and common mistakes
A penetration test is a point-in-time sample, not a guarantee. A clean report means that skilled testers found no serious issues within the given scope, time and knowledge level, nothing more.
| Mistake | Consequence | Better practice |
|---|---|---|
| Scope chosen to pass | Report looks clean, real risk untested | Scope by business risk and attack surface |
| Scan sold as a pentest | No exploitation or chaining of findings | Require manual testing and proof of impact |
| No retest | Fixes remain unverified | Book a retest window in the contract |
| Annual test only | New releases go untested for months | Add continuous scanning and change-based tests |
| Testing without backups or contacts | Outage handling becomes chaotic | Agree on emergency contacts and stop conditions |
| Findings without owners | Same issues reappear next year | Track remediation in the normal work queue |
The simple explanation
Penetration testing means hiring friendly burglars. An organization invites security experts to try to break into its systems, with permission and under agreed rules, before real criminals try the same thing.
The testers do not stop at finding an unlocked window. They climb through it to show how far they can get and what they could take. Afterward, they write down every weak spot and how to fix it, so the organization learns about its problems from allies instead of attackers.
How it is used in practice
A software-as-a-service company preparing to sign its first large enterprise customers commissions a gray-box test of its web application and API, with 10 person-days and two test accounts in different customer tenants. The automated scanner used by the company had previously reported only low-severity issues.
On the third day, the testers notice that an API error message reveals internal tenant identifiers. On their own, both this leak and a missing tenant check on a reporting endpoint look minor, but chained together they let one customer download reports belonging to any other customer. The testers rate the combined attack path as critical and report it immediately rather than waiting for the final report.
Developers add tenant validation to every API endpoint and remove identifiers from error messages within a week. The retest confirms the fix, and the company closes the vulnerability before any customer data is exposed, with a clean retest report to show prospective customers.