Penetration testing exists because automated vulnerability scanning cannot find the vulnerabilities that matter most. A scanner can identify that a software version has a known CVE, or that a configuration deviates from a baseline, but it cannot determine whether an authentication flaw can be chained with an access-control weakness to take over an administrator account. That chaining — the manual work of thinking like an attacker, exploring the application's logic, and combining findings to demonstrate real impact — is what a penetration test provides. A pentest answers the question an executive actually cares about: could someone really break in, and what would happen if they did.
The discipline spans several domains, each with its own methodology. Web application testing targets the OWASP Web Security Testing Guide and focuses on injection, broken access control, authentication flaws, SSRF, and business-logic vulnerabilities. API testing applies the OWASP API Top 10, including broken object-level authorisation. Mobile testing follows the OWASP MASTG for Android and iOS. Network testing, internal and external, follows PTES and NIST SP 800-115 to test services, credentials, lateral movement, and domain escalation. Cloud, Wi-Fi, and social engineering each have their own approaches. A comprehensive offensive-security programme draws on all of these.
A penetration test is structured around phases. Scoping defines what is in scope, the testing window, the rules of engagement, and the objectives. Reconnaissance and mapping gathers information about the target. Vulnerability discovery combines automated scanning with manual analysis. Exploitation attempts to validate and chain findings, demonstrating real impact rather than theoretical risk. Reporting documents each finding with evidence, impact, and remediation guidance, and prioritises by severity. A retest confirms the remediation. The quality of the report and the clarity of the remediation guidance — not the number of findings — is what makes a pentest useful to a development team.
Penetration testing is also a compliance requirement for most security frameworks. PCI DSS explicitly requires annual penetration testing and after any significant change. ISO 27001, SOC 2, NIS2, and DORA all require some form of security testing, and DORA's Threat-Led Penetration Testing is a specific, regulated testing regime for financial entities selected by competent authorities. For regulated organisations, the penetration test is both a security improvement activity and a compliance obligation, and the report is an audit artifact.
Passeca delivers penetration testing across web, API, mobile, cloud, network, and Wi-Fi, following OWASP, PTES, and NIST methodologies through a defined five-phase process. Engagements are scoped to the customer's objectives and risk, deliver an evidence-based report with prioritised remediation, and include a retest to confirm fixes. A gated sample report is available for organisations evaluating the quality and depth of the output. For regulated financial entities, Passeca delivers TLPT under the DORA testing framework.