01What a penetration test is – and what it is not
A penetration test is a time-boxed, commissioned security assessment in which testers manually identify, chain and exploit vulnerabilities in a controlled manner to demonstrate their real-world risk. A vulnerability scan must be clearly distinguished from this: it checks automatically and at scale against known vulnerability patterns, but does not verify findings and regularly produces false positives – it is part of ongoing vulnerability management, not a substitute for a pentest. Red teaming, in turn, pursues a different goal: it covertly simulates a realistic attack on defined crown jewels and also tests the defenders' detection and response capabilities, whereas a penetration test examines a defined scope as completely as possible for vulnerabilities.
02Test types: from web applications to Wi-Fi
Web application and API tests examine, among other things, authentication, session management, access control and injection vulnerabilities. External infrastructure tests target the attack surface reachable from the internet, while internal tests assume an attacker inside the network and investigate issues such as privilege escalation, lateral movement and Active Directory weaknesses. Cloud pentests focus on misconfigurations and on identity and permission models within the shared responsibility with the provider. Mobile app tests look at local data storage, platform protection mechanisms and the backend interfaces; Wi-Fi tests examine authentication, encryption and network segmentation on site.
03Black, grey and white box: the level of prior knowledge
This classification describes how much prior knowledge the testers receive. In a black-box test they start without any internal information – realistic from an attacker's perspective, but time-consuming and with lower coverage, because testing time is spent on reconnaissance. In a white-box test, architecture documentation, configurations or source code are available, enabling the greatest testing depth per unit of time. The grey-box approach lies in between, typically with test accounts and documentation; in practice it has established itself as the efficient standard for most test objectives. Independently of this, the perspective (external/internal) and the degree of prior announcement are defined during scoping.
04Methodologies: OWASP WSTG, PTES and the BSI guide
Recognised methodologies make penetration tests traceable and comparable. For web applications and APIs, the OWASP Web Security Testing Guide (WSTG) is the reference; the current stable version 4.2 was released in December 2020, and version 5.0 is under development. The Penetration Testing Execution Standard (PTES, version 1.0) structures the overall process into seven phases, from pre-engagement interactions through intelligence gathering, threat modeling, vulnerability analysis, exploitation and post-exploitation to reporting. For the German-speaking region, the BSI "Praxis-Leitfaden für IS-Penetrationstests" (2016 edition) describes a structured approach and provides guidance in particular on commissioning. Reputable providers disclose the methodology used in their report.
05Process and legal basis
A penetration test begins with scoping: objectives, systems, testing windows, exclusions and emergency contacts are defined in writing. This is followed by information gathering and vulnerability analysis, the controlled exploitation of relevant findings, and the report with an executive summary, technical details, risk assessment and prioritised remediation recommendations; a retest after remediation closes the cycle. Legally indispensable is prior written authorisation by the entitled party ("permission to test"): without it, testing activities can constitute criminal offences under §§ 202a ff. StGB of the German Criminal Code (data espionage and interception of data). Third-party systems – for example at hosting, cloud or SaaS providers – may only be tested with their consent or within the scope of their testing policies; confidentiality and data protection agreements belong in every contract.
06Frequency and regulatory triggers: NIS2, DORA, TISAX
There is no universal mandatory frequency; established practice is testing critical systems at least annually, plus event-driven tests after significant changes to architecture or applications. NIS2 (Directive (EU) 2022/2555) requires in Art. 21(2)(f) policies and procedures to assess the effectiveness of risk-management measures – penetration tests are an established means to this end. For the financial sector, DORA (Regulation (EU) 2022/2554, applicable since 17 January 2025) explicitly names penetration tests as part of the resilience testing programme (Art. 25); financial entities designated for this by the authorities must additionally carry out threat-led penetration testing (TLPT) under Art. 26 at least every three years. In the automotive sector, TISAX assessments based on the VDA ISA catalogue (version 6; for assessments ordered from 2027 onwards, the successor catalogue ISA 2027) expect evidence of regular technical reviews and effective vulnerability management – penetration tests are a common means of providing this evidence.
