Penetration testing: finding weaknesses before someone else does

2026-08-07 · by SECURITYSQUAD

Most security gaps are not spectacular. A forgotten test account, an outdated plugin, a permission set too generously – harmless individually, often the route to full access in combination. A penetration test makes that chain visible by reproducing, under control, what a real attacker would try.

A pentest is not a vulnerability scan

The distinction gets blurred constantly, usually by providers who sell one and promise the other.

| | Vulnerability scan | Penetration test | |---|---|---| | Approach | Automated against a signature list | Manual, combining, creative | | Result | List of known gaps | Demonstrated attack paths | | False positives | Many, must be weeded out | Verified, because exploited | | Finds chains? | No | Yes – that is the whole point | | Effort | Minutes to hours | Days to weeks |

A scanner reports ten medium findings. A tester shows that three of them together yield domain administrator. That is the difference, and it is why neither replaces the other: the scan belongs in continuous operation, the pentest in the calendar.

How the BSI classifies pentests

Germany's BSI published an execution concept for penetration testing that helps in shaping an engagement. Tests are described there along several criteria – among them the information basis and the aggressiveness.

Two of its recommendations surprise many people:

The BSI generally advises white-box testing. The reflex usually goes to black box, because it feels "more realistic" – the tester knows nothing, like a real attacker. The problem: a tester has days, an attacker has months. What the tester does not find in that limited time, the attacker still finds later. With prior knowledge the same effort covers considerably more ground.

Moderate aggressiveness rather than maximum. A test should demonstrate weaknesses but only actively exploit them where unavoidable, and then with sufficiently proven means. An aggressive test is also noticed quickly and sits badly with a covert approach.

For your engagement that means: settle these points up front and put them in the contract instead of leaving them to the tester.

The legal side – not a formality

A penetration test interacts with systems directly. Without effective authorisation this touches sections 202a ff. of the German Criminal Code – unlawful access to and interception of data. A checkbox on a website does not suffice.

What you need is a written engagement, often called a letter of permission to attack, covering at least:

named targets – IP ranges, domains, applications; and expressly what is out of scope
testing window – period and times of day
contacts on both sides, reachable at night as well
abort criteria – when testing stops and who may stop it
handling of data encountered – personal data in particular

A special case many overlook: if the target sits with a hoster or in a cloud, that provider's consent is needed too. You can only authorise what is yours to authorise.

How a test runs

Alignment – objective, scope, information basis, testing window, contacts.
Reconnaissance – what is actually there? Often the most revealing part, because systems surface that nobody remembered.
Examination – methodically, along a recognised approach rather than by instinct.
Exploitation – controlled, within the agreed frame, proving rather than damaging.
Report – prioritised by risk, with concrete recommendations and a summary management can follow.
Retest – after remediation. Without this step you do not know whether it is really closed.

The retest is the most commonly cut item and the second most important after the test itself.

How to recognise a good proposal

The scope is concrete. "Pentest of your infrastructure" is not a scope. Systems, counts and depth belong in the proposal.
It states effort, not just a price. Person-days say more about depth than any list of certifications.
The report is part of the deliverable, including a management summary and a retest option.
The manual share is named. Anyone who just runs a scanner and sells the output as a pentest turns vague at this point.
There is a clear line on handling personal data.

When the effort pays off

Before going live with new applications, after major infrastructure changes, as part of certification – and on a regular cycle, because a test is a snapshot.

A sensible order: deal with the passively visible points first, then harden, then test. A pentest that confirms what a free vulnerability check would also have found is expensively purchased common knowledge. The test earns its keep where you want to know whether the remaining attack surface can genuinely be exploited.

The real value comes afterwards

The report is not the goal but the starting point. The benefit arises when findings are fixed and the underlying causes addressed – usually organisational matters such as patch management or permission assignment. A pentest whose findings are still open a year later was an expensive confirmation.

As at August 2026. Classification per the BSI execution concept for penetration testing.