Pentest preparation: the complete pre-engagement checklist
A penetration test (pentest) is not an automated scan that you simply 'turn on'. It is a controlled, hostile test in which a professional ethical hacker actively attempts to compromise your systems, just as a real attacker would. This has an impact: on your systems, your team, and your availability. Poor preparation leads to an unclear scope, missed findings, legal risks, and reports that you cannot use as audit evidence.
This article provides you with a concrete pre-engagement checklist, including everything you need to arrange in advance to ensure the test runs smoothly and to make the results immediately usable for compliance purposes such as SOC 2, ISO 27001, NIS2, or DORA.
First, determine the goal of the pentest
Before you write down a single IP address or URL, you must know what the test needs to demonstrate. Is it about detecting technical vulnerabilities in a new application? Do you want to demonstrate exploitability to your board? Or do you need a pentest as evidence for an audit? That question determines everything: the scope, the methodology (black/grey/white box), the reporting format, and the depth. Different reporting requirements apply to SOC 2 compliance than to NIS2 demonstrability. Align your choice with this so that you won't have to test again later.
Standards relevant for this evidence are:
• SOC 2 (technical controls, availability, confidentiality)
• ISO 27001 certification (A.12.6 / Annex A vulnerability management)
• NIS2 (Article 21: risk management measures including security testing)
• DORA (threat-led penetration testing / TLPT for financial institutions)
Step 1: Carefully define your pentest scope
An unclear scope is the most common reason why pentests turn out disappointingly. Ensure you have a scope document (a document that refers to the extent, range or boundaries of the pentest) of no more than one page that Security, IT, and Legal understand.
In-scope: IP ranges, domains/URLs, API endpoints, cloud components (e.g., AWS/Azure/GCP resources), user roles and test accounts, environment (production or staging).
Explicitly out-of-scope: third-party systems for which you do not have permission, vendor SaaS tools, production components with high availability requirements that you cannot afford to miss.
The difference between a pentest and vulnerability scanning is precisely here: a pentest traces the attack path, while a scan only flags it. Both have their place, but the scope logic differs.
Step 2: Establish the Rules of Engagement (RoE)
The RoE is the document that prevents your team from getting stuck during the test.
Ensure at a minimum:
• Test window (date/time, including time zone)
• Constraints: no DoS attacks, no automated exploitation on production databases
• Communication frequency: daily status update or only for critical findings?
• Escalation protocol: who do you call if there is a critical finding that requires immediate action?
Methodologies such as PTES (Penetration Testing Execution Standard) and CVSS (Common Vulnerability Scoring System) provide a standardized basis for prioritizing findings in the report. Agree on this in advance with your pentest provider.
Step 3: Getting legal and organizational matters in order
A pentest without written permission is legally considered a breach of computer trespass. That sounds serious, but it is the reality. Ensure:
• NDA/non-disclosure agreement: covers confidential information and discovered vulnerabilities, including disclosure rules (when can what be shared?).
• Authorization letter: a written mandate granting the pentest provider permission to test. State exactly which systems, environments, and techniques are permitted.
• Responsibilities: establish who within Security, IT, and Legal makes the go/no-go decision.
Create a short Legal/Procurement checklist so that your internal approval process does not take weeks.
Step 4: Operational agreements and the kill switch
Even when a pentest is simulated, something can go wrong. Discuss downtime risks in advance. This includes which systems are vulnerable to availability issues and how do you limit that? A well-organised kill switch procedure protects your business continuity without unnecessarily disrupting the test.
Step 5: Preparing the technical environment
Before the pentest starts, your technical environment must be ready. This means:
• IP allowlist for the tester (if the environment is blocked or for the WAF)
• Creating test accounts with the correct roles (user, admin, API key)
During the pentest: what your team does and does not do
Ensure there is a single point of contact on your end (a primary contact person). This is the person who answers questions and makes decisions. What you do not do: grant ad-hoc permission for systems outside the scope, implement changes within the test window, or ignore critical findings with 'I am waiting for the final report'. If a tester reports a critical vulnerability, take immediate action.
After the penetration test: remediation, retest, and audit evidence
A penetration test without follow-up is wasted effort and resources. Link findings to a CVSS score and translate that into business risk. Create a remediation board with, for each finding: owner, action (patch/workaround/accept risk with substantiation), and deadline. Plan a retest after the primary remediation. For compliance claims (e.g., for your NIS2 obligation or a DORA audit), a documented retest is proof that you have resolved the vulnerabilities. Without a retest, you have a finding in a report, but no demonstrable fix.
And finally: Frequently Asked Questions
1. How long does a penetration test take? Depending on the scope and approach: a web application typically takes 3 to 5 days, while a broader infrastructure test can run up to 10+ days. Discuss this during the intake.
2. Pentest in production or simulation? Simulation is preferred, but if production deviates in terms of configuration, it may be useful to test (parts of) production. In that case, be sure to establish additional backup and kill switch agreements.
3. What is the difference compared to a vulnerability scan? A scan automatically identifies known weaknesses. A pentest goes a step further: the tester manually exploits vulnerabilities and demonstrates the actual impact.
4. How often should you perform pentests? Risk-based. A test is appropriate after major releases, architecture changes, or when a new compliance obligation arises. Annual pentesting is a common baseline but always combine it with continuous proactive cybersecurity monitoring.
5. Do we need an NDA? Yes. Always. A pentest report contains detailed vulnerability information that must not circulate unprotected.
6. How Securance combines your preparation and compliance Securance works with a Single Audit, Multiple Standards approach: one streamlined route that combines governance, assurance, and cybersecurity for SOC 1, SOC 2, ISAE 3402, ISO 27001, NIS2, and DORA. You do not need to set up a separate process for each standard. In addition to pentesting, Securance performs monthly scans to detect risks early, so you do not wait until the next annual test to discover vulnerabilities. That combination is exactly why more than 800 professional firms and SaaS companies choose Securance, with demonstrable results: 96% customer satisfaction and over €6 billion in protected revenue.
Would you like to discuss scope and RoE (Rules of Engagement) in a single session and know immediately what you need for your next audit?
Contact Securance for an introduction.