Penetration test: process, scope, cost factors and retest
By Nico Freitag, Geschäftsführer, Cybersecurity und Governance
A reliable penetration test begins with a written goal, a defined test area, permitted methods, contact persons and termination criteria. The effort depends primarily on the attack surface, roles, interfaces, test depth and required evidence. The conclusion includes prioritized findings, reproducible evidence, measures and a follow-up test.
What is determined before the test?
Clients and testers define systems, accounts, roles, interfaces, time windows and explicitly excluded actions. This includes accessible emergency contacts, permitted test dates and termination criteria. The BSI requires a concept with framework conditions, methods and success criteria for penetration tests. This framework protects operations and prevents a technically good test from working on the wrong target.
How is the scope of the test determined?
A web application does not only consist of visible pages. Registration, roles, APIs, file uploads, administration paths and connected services are part of the attack surface. The OWASP Web Security Testing Guide structures testing from information gathering to specific application controls. The OWASP ASVS can also serve as a contractually specified requirements basis. The scope and depth of testing must therefore be clearly described before the offer is made.
What factors determine the costs?
The decisive factors are the number and type of systems, user roles, interfaces, technical diversity, desired test depth, existing documentation and the scope of the report. A test with source code access can test more deeply in the same time than a pure black box test, but is a different testing model. A reliable calculation states assumptions and limits instead of promising a blanket number for every application.
What should be included in the report and post-test?
Every relevant finding needs an understandable impact, reproducible evidence, affected components and an actionable recommendation. The priority is based not only on an automatic score, but also on real exploitability and business impact. After the fix, the post-test checks whether the specific attack opportunity has been closed and whether the fix has created new problems.
From the answer to implementation
Related service
View the scope, delivery model and responsible contacts.
Open →Related product
See a practical product path connected to this topic.
Open →Working checklist
Prepare the next decision with a structured checklist.
Open →All specialist articles
Continue with reviewed answers from the same practice areas.
Open →Sources and basis
The central statements in this article were reviewed against the following primary sources.
Frequently asked questions
- How long does a penetration test take?
- This depends on the attack surface, roles and test depth. Small, clearly defined applications can be tested in just a few days of testing, while complex platforms require significantly more time and preparation.
- Black box, gray box or white box?
- Black Box starts with little prior knowledge, Gray Box with agreed access and White Box with deep technical insight. For many business applications, Gray Box delivers a good balance of realistic perspective and technical depth.
- Can a test disrupt operations?
- Yes, active audits can create risks. Therefore, time windows, permitted methods, contact persons and termination criteria are agreed in advance.
- Is an automated scan a penetration test?
- No. Scanners support testing, but do not replace manual assessment of roles, business logic, attack chains and actual impact.
- Is a retest necessary?
- It is very useful because it checks whether the specific vulnerability has been effectively remedied. The scope and time period should be clarified in the original order.