Preparing for a Pentest: What You Should Know
Key Takeaways
- A penetration test without a clearly defined scope produces imprecise results — which systems, networks, and scenarios are in scope must be specified precisely before the engagement begins
- A grey-box test is the best starting point for most mid-sized organisations: more realistic than black box, more efficient than white box
- Critical findings must be communicated immediately during the test, not held until the final report
- The final report is not a document to be filed — it requires qualified assessment and a prioritised remediation plan with owners and deadlines
- A single penetration test is a point-in-time snapshot; annual tests with rotating focus areas provide substantially greater assurance
A penetration test is one of the most effective tools for assessing an organisation’s actual security posture. However, the value depends substantially on how well the test is prepared. We regularly encounter organisations that commission a pentest without having clarified basic questions — and are then disappointed by the outcome.
Before the test: Define scope and objectives
The most important question before a penetration test is: What exactly should be tested and why?
A pentest without a clear scope produces imprecise results. The definition should cover: which systems, networks, or applications are in scope, which are explicitly excluded, whether internal or external attack vectors should be examined, and which scenarios are particularly relevant for your organisation.
A company that primarily uses cloud services has different priorities than one with extensive on-premises infrastructure. A financial services firm has different regulatory requirements than a manufacturing company.
Understanding the variants
Not every pentest is the same. The main variants differ in the information made available to the tester:
Black box: The tester receives no internal information and simulates an external attacker. Realistic but time-intensive and not always efficient.
Grey box: The tester receives limited access, such as user credentials or network diagrams. A good compromise between realism and efficiency.
White box: The tester receives full access to documentation, source code, and architecture. Enables the most thorough examination but requires more preparation effort.
For most mid-sized organisations, we recommend a grey-box approach as a starting point.
During the test: Ensure communication
A common mistake: the pentest is commissioned and then left to run. Ongoing communication between tester and organisation matters. Critical vulnerabilities should be reported immediately, not only in the final report. Unexpected conditions in the environment need to be clarified quickly.
Ensure that a technical contact is reachable during the test. Define in advance how critical findings will be handled.
After the test: Contextualise the results properly
The final report of a penetration test is not a document to be read once and filed away. It requires qualified assessment: Which findings are genuinely critical for our organisation? Which can be remediated quickly? Which require structural changes?
Based on the report, create a prioritised action plan with clear responsibilities and timeframes. Schedule a re-test for the most critical findings.
Regularity beats one-off testing
A single penetration test provides a snapshot. IT environments change continuously: new systems, new integrations, new staff. An annual pentest — ideally with rotating focus areas — provides substantially more security than a one-time examination.
If you are planning a penetration test or would like to improve your existing testing practice, we are happy to advise.
Frequently Asked Questions
What should a penetration test report include at minimum?
A good pentest report contains an executive summary accessible to decision-makers, a technical description of each finding with severity rating (CVSS or equivalent), reproduction steps, remediation recommendations, and a prioritised action plan. It must be readable both by technical staff and by senior leadership — findings that cannot be explained to management will not get resourced.
How does a black-box test differ from a grey-box penetration test?
In a black-box test the tester receives no internal information and simulates an external attacker with no prior knowledge. In a grey-box test the tester receives limited information — user credentials, network diagrams, or architecture documentation. Grey-box is typically more efficient because less time is spent on reconnaissance, allowing deeper testing within the same budget.
How often should penetration testing take place?
At minimum annually for core infrastructure. Additionally, significant changes to the IT environment — cloud migrations, new applications, changed network architecture — should trigger targeted tests. Regulatory requirements such as DORA or NIS2 may mandate more frequent testing. The key principle: the value of a pentest decays as the environment changes.
What is a re-test and when is it necessary?
A re-test is a targeted verification that the most critical findings have been correctly remediated — conducted by the original tester, focused only on the remediated issues. It is not a full new engagement. Without a re-test, it remains unclear whether the remediation was effective. For critical findings especially, this step should be built into the remediation timeline from the start.