Order a penetration test correctly: scope, access and rules of engagement
By Nico Freitag, Geschäftsführer, Cybersecurity und Governance
A penetration test becomes reliable when the goal, systems, roles, permitted methods, test times, protective measures and immediate reporting channels are clarified in writing before the first attack. The scope is not just a URL list. It describes the actual attack surface and determines how testers, clients and operations act in the event of critical findings or faults.
What goal should the test answer?
A test can test a new web application, an API, an external access, an internal network or a complete attack path. First, formulate the business question: Should a go-live be secured, should a customer requirement be proven, or should the effect of several security measures be checked? This follows the depth, test type and report. Without a goal, a broad tool test can easily arise that identifies many anomalies but does not answer the client's crucial uncertainty.
What belongs in a complete scope?
Covers domains, IP ranges, APIs, mobile applications, identity services, roles, tenants and relevant third parties. Explicitly names excluded systems and technically connected neighbors. Clarifies test data, user accounts with different rights and available documentation. The OWASP Web Security Testing Guide structures testing of information collection across identity, authorization, session, input, and business logic. This structure helps to scope the functions rather than just addresses.
Which rules of engagement are necessary?
Specifies test windows, source addresses, allowed load, handling of personal data, social engineering, DoS-related methods and possible persistence. Designates a 24/7 contact and secure channel for critical finds. Defines stop criteria, preservation of evidence and the decision as to whether a path found can be further exploited. The rules do not protect against every risk, but they do create a common basis for action before time pressure arises.
Black box, gray box or white box?
Black Box shows little prior knowledge, but consumes a lot of time for clarification. Gray Box provides typical accounts and basic information and often allows for more review of business logic. White Box complements architecture or source code and is suitable if you want to achieve as much security as possible per test day. Choice is not a quality level. It follows the question, the threat model and the available budget. A combination often makes sense for critical applications.
What does a usable result look like?
Every discovery needs reproducible evidence, affected components, prerequisites, effects and a realistic solution. Prioritization is based on actual exploitability and business impact, not just tool value. Critical points are reported immediately. The conclusion includes a technical version, an understandable management classification, a joint discussion and a post-test. In addition, it should be visible which areas have been checked and which remaining uncertainty remains outside the scope.
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
- Can production be checked during the test?
- This can make sense, but it must be decided consciously based on risk, alternative options and rules. Particularly stressful or destructive methods need clear boundaries.
- How many test accounts are needed?
- At least the relevant roles and clients must be mapped. Otherwise, authorization errors easily remain invisible.
- Is a vulnerability scan part of the pentest?
- Tools can support. The main difference lies in manual testing, attack chains, business logic, traceable impact and technical prioritization.