A penetration testing engagement only runs as smoothly as the preparation behind it. The kickoff call is where scope gets confirmed, expectations get aligned, and the actual work gets authorized to begin. Show up without the right documentation, and you risk delays, scope gaps, or worse, a test that misses critical systems entirely. Gathering these nine documents before that first call puts you in control of the process from day one.
What happens when you show up unprepared
Pentest kickoff calls that stall usually stall for the same reasons: missing authorization documents, unclear asset boundaries, or no agreed process for handling emergencies during testing. These gaps do not just slow things down. They create real risk. A tester who cannot confirm authorization may pause the engagement entirely. A missing contact list means no one knows who to call when a critical system goes offline mid-test.
Preparation is not just about efficiency. It demonstrates to your testing team that your organization takes security seriously, which sets the tone for a more productive and thorough engagement. The nine documents below cover everything a testing team needs to start work with confidence.
1: Network diagrams and topology maps
Network diagrams give testers a structural understanding of your environment before they run a single scan. A clear topology map shows how systems connect, where segmentation exists, and which paths an attacker might realistically take through your network.
Without this, testers rely entirely on discovery scanning, which takes longer and may miss isolated segments or legacy systems that are not broadcasting their presence. Even a rough, hand-drawn diagram is more useful than nothing at all.
Best suited for organizations with complex or segmented environments, but valuable for any engagement. Include both on-premises and cloud infrastructure where relevant.
2: Asset inventory and IP address ranges
Scope definition depends entirely on knowing what you own. An asset inventory paired with confirmed IP address ranges tells the testing team exactly which systems are in play and prevents accidental testing of out-of-scope infrastructure, including third-party systems that share your address space.
Include servers, workstations, network devices, cloud instances, and any internet-facing assets. Flag anything that is shared with another organization or hosted by a third party, as these require separate authorization before they can be tested.
Incomplete inventories are one of the most common causes of scope disputes after a test concludes. Getting this right upfront protects both sides.
3: Rules of engagement and authorization letters
Authorization documentation is non-negotiable. Rules of engagement define what testers are permitted to do, which systems they can target, what techniques are off limits, and what happens if critical infrastructure is affected. The authorization letter confirms that the organization has formally approved the test.
Without signed authorization, a penetration test is legally indistinguishable from an unauthorized intrusion. No professional testing team will proceed without it, and they should not. Ensure the document is signed by someone with the organizational authority to approve it.
If your organization operates in a regulated industry, your authorization documentation may also need to satisfy specific compliance requirements around third-party security assessments.
4: Previous pentest or audit reports
Prior reports give testers immediate context about your security posture and history. They show which vulnerabilities were previously identified, which were remediated, and which may have been accepted as risks. This prevents duplication of effort and lets the team focus on new attack surfaces and unresolved findings.
Previous reports also reveal patterns. If the same vulnerability class keeps appearing across multiple audits, that tells the testing team where to look harder. Share reports from the last two to three years where available, including any internal audits or compliance assessments.
5: System owner and emergency contact list
Testing can trigger unexpected behavior in production systems. When that happens, the team needs to reach the right person immediately. A system owner and emergency contact list maps each critical asset to a named individual who can make decisions about that system in real time.
This list should include primary and backup contacts for each major system, along with phone numbers that will actually be answered during testing hours. Email alone is not sufficient when a database goes offline during a live engagement.
Establish a clear escalation path before testing begins, not during an incident. This single document can prevent a minor disruption from becoming a major outage.
6: Active monitoring and security tool inventory
Your security team needs to know that a penetration test is happening. Your monitoring tools need to know too, or at least your team needs to decide how to handle alerts generated by test activity. A full inventory of active monitoring, endpoint detection, SIEM platforms, and intrusion detection systems allows the testing team to coordinate its approach.
In some engagements, alerts are suppressed to test whether testers can operate undetected. In others, detection capability itself is part of what is being evaluated. Either way, this decision needs to be made before the test starts, not discovered mid-engagement when your SOC team starts blocking test traffic.
7: Application credentials and test accounts
For any application-layer testing, the team needs working credentials with appropriate permission levels. Test accounts should mirror real user roles, including standard users, administrators, and any privileged roles specific to your application.
Do not hand over production admin credentials. Instead, create dedicated test accounts that can be disabled immediately after the engagement. Confirm that these accounts have full access to the features being tested and that multi-factor authentication can be bypassed or configured for the testing environment without affecting real users.
Credential issues are among the most common causes of mid-engagement delays. Preparing accounts in advance keeps the test moving.
8: Compliance and regulatory requirements
If your organization operates under specific regulatory frameworks such as ISO 27001, NIS2, or sector-specific standards, the testing scope may need to align with those requirements. Some frameworks specify what must be tested, how frequently, and what the reporting format should look like.
Sharing your compliance context upfront allows the testing team to structure their methodology and final report to support your audit or certification process. This is far more efficient than requesting a reformatted report after delivery.
For organizations in the Netherlands and across the EU, 2026 brings continued regulatory pressure around demonstrable security practices. Aligning your pentest with compliance requirements turns one engagement into evidence for multiple purposes.
9: Change freeze and maintenance window schedule
Penetration testing should not happen during major system changes or immediately before critical business periods. A change freeze and maintenance window schedule tells the testing team when systems are stable, when patches are being applied, and when testing activity might conflict with other planned work.
Testing a system the day before a major patch deployment produces results that are immediately outdated. Testing during a maintenance window risks being mistaken for legitimate administrative activity, which complicates the findings. Coordinating schedules prevents both problems.
Share at least four to six weeks of upcoming planned changes so the testing team can identify the most stable and representative window for their work.
Walk into your kickoff call ready to start
These nine documents transform a kickoff call from a planning session into a launch meeting. When authorization is confirmed, scope is defined, contacts are in place, and credentials are ready, the testing team can focus entirely on finding vulnerabilities rather than resolving administrative gaps. The organizations that get the most value from penetration testing are the ones that treat preparation as part of the engagement, not a prerequisite they rush through.
We work with organizations at every stage of security maturity, including those running their first pentest and those looking to build a recurring testing program. If you want to make sure your next engagement starts on solid ground, get in touch with us and we will help you prepare everything you need before that first call.
Frequently Asked Questions
Wat gebeurt er als ik niet alle negen documenten kan aanleveren vóór de kickoff call?
Als niet alle documenten beschikbaar zijn, is het belangrijk om dit vooraf te communiceren met het testteam, zodat zij de aanpak kunnen aanpassen. Ontbrekende documenten zoals een incomplete asset-inventaris of verouderde netwerkdiagrammen kunnen leiden tot scopeproblemen of vertragingen tijdens de test, wat de effectiviteit en waarde van de pentest aanzienlijk vermindert.
Hoe zorg ik ervoor dat mijn autorisatiedocumentatie juridisch geldig is voor een penetratietest?
Zorg dat de autorisatiebrief wordt ondertekend door iemand met de bevoegdheid om namens de organisatie toestemming te verlenen, zoals een directeur of IT-manager. Leg hierin duidelijk vast welke systemen getest mogen worden, welke technieken zijn toegestaan en wat de duur van de test is, zodat het document juridisch onderscheidend is van ongeautoriseerde toegang.
Wanneer is het beste moment om een penetratietest in te plannen in relatie tot patchcycli en systeemwijzigingen?
Plan een penetratietest bij voorkeur in een stabiele periode, minimaal één tot twee weken na een grote patchronde of systeemwijziging, zodat de testresultaten representatief zijn voor de werkelijke beveiligingsstatus. Deel het wijzigingsschema van vier tot zes weken van tevoren met het testteam, zodat zij samen met u het meest geschikte testvenster kunnen bepalen.
Hoe kan ik de resultaten van een penetratietest koppelen aan mijn compliance-verplichtingen zoals ISO 27001 of NIS2?
Informeer het testteam vooraf over de specifieke compliance-kaders waaraan uw organisatie moet voldoen, zodat zij de methodologie en rapportage hierop kunnen afstemmen. Dit voorkomt dat u achteraf een aangepast rapport moet aanvragen en zorgt ervoor dat de pentest direct bruikbaar is als bewijs voor audits of certificeringstrajecten.