What a penetration test delivers, and what it does not
A penetration test gives a reliable answer to whether an attacker can reach a particular objective with realistic effort. It shows chains no scanner finds: a misconfiguration that looks harmless until, together with an outdated service and overly broad permissions, it opens a path to production data.
What it does not deliver is proof of security. The result is a sample at a point in time, in a defined area, with the knowledge and time budget of the team engaged. A report with no findings means that nothing was found within those limits, not that nothing is there. Use the test as a substitute for ongoing vulnerability management and you are confusing a snapshot with a process.
Variants
| Distinction | Forms | What it means for the result |
|---|---|---|
| Level of information | black box, grey box, white box | The more information the testing team receives, the more depth per unit of time; black box measures visibility from outside |
| Starting point | external (from the internet), internal (from inside the network) | Internal tests show the paths of lateral movement after a successful first foothold |
| Subject | network and infrastructure, web application, API, mobile application, client, physical access, social engineering | Each subject needs its own methodology and its own approvals |
| Objective | finding-oriented test, threat-led red teaming | A pentest looks for as many vulnerabilities as possible; a red teaming exercise tests one attack objective and the organisation's own ability to detect it |
Before you commission: the scope
The quality of a test is decided before the first day of testing. What has to be set down in writing is at least: the exact targets by address, application or account; explicit exclusions; the test window; permitted and prohibited techniques, in particular around denial of service and social engineering; how real data encountered is handled; an emergency contact on both sides; and what happens if signs of an existing compromise surface during the test.
Two points are regularly overlooked. First, the system owner's approval is needed, and for environments run by others, that of the operator or cloud provider as well. Second, the written engagement is not a formality: testing activity against systems belonging to others can be criminally relevant without the consent of the party entitled to give it.
The report is the product
A usable report contains a summary for management without jargon, a comprehensible description of the path for each finding with evidence, an assessment of the impact in the specific environment, and a concrete recommendation. What it should not contain is unfiltered output from a tool.
What happens afterwards matters just as much: findings belong in the same treatment logic as every other vulnerability, with an owner, a deadline and a re-check. An agreed retest after remediation is the only reliable evidence that the findings were actually closed.
The regulatory context
ISO/IEC 27001 requires the effectiveness of controls to be evaluated, but prescribes neither a penetration test nor an interval for one. § 30(2) sentence 2 BSIG (the German BSI Act) sets a binding minimum and requires, in no. 6, "concepts and procedures for assessing the effectiveness of risk-management measures in the field of security in information technology", a procedure, not a prescribed method. A penetration test is one possible form that can take; the statute does not name it.
DORA (Regulation (EU) 2022/2554) goes furthest: Chapter IV, Articles 24 to 27 governs the testing of digital operational resilience, and Article 24(6) requires systems supporting critical or important functions to be tested appropriately at least yearly. Financial entities identified by their supervisor additionally carry out threat-led penetration testing (the Regulation's own defined term, at Article 3(17)) under Article 26(1) at least every three years, with the competent authority able to raise or lower that frequency. Which critical or important functions such a test has to cover is assessed by the entity itself; the authority validates the scope that follows from that assessment. Article 26(11) expressly points to the TIBER-EU framework for how the testing itself is carried out.
Frequency
Outside sector-specific requirements there is no binding interval. Organisations usually derive the frequency from the protection requirement of the system, its reachability from outside, its rate of change and contractual commitments to customers. Tests before new externally reachable applications go live, and after material architecture changes, are widespread. An annual test that always examines the same area while the rest of the estate goes unexamined produces mainly routine.
The scoping problem before the test
The most common shortcoming of a penetration test happens before the test: what gets examined is what the statement of work names, and what the statement of work names is what somebody remembered. Systems nobody mentioned stay untouched, and the report therefore looks better than the situation.
In Rizzqo the scope is derivable from the inventory rather than from recollection. Objects exist classified and with their links, and the inherited protection need shows which of them carry the critical processes. After the test a finding can be attached to the requirement it concerns on the object where it was found, valued as a risk assessment in likelihood and impact in euros, and worked off through a task.