Pre-engagement questionnaires are your first step in understanding a client's unique needs, technical environment, and primary goals. By gathering this critical information early, you can accurately estimate the project scope, avoid costly misunderstandings, and ensure a smooth, legally compliant testing process.
A penetration test should never be confrontational. Frame your questionnaires as a collaborative tool to help identify business risks, rather than a checklist for "hacking" the client.
The Questionnaire Workflow
Using questionnaires effectively bridges the gap between initial contact and the formal scoping meeting.
flowchart TD
A[Initial Client Contact] --> B[Send General Questionnaire]
B --> C{Client Answers}
C -->|Review| D[Identify Scope & Gaps]
D --> E[Hold Scoping Meeting]
E --> F[Finalize Statement of Work]- 1
Send the initial questionnaire
Provide the client with a tailored set of questions based on the high-level services they requested (e.g., Web App, Network, or Physical).
- 2
Review and estimate
Use their answers to determine the Rough Order of Magnitude (ROM). Look for red flags, such as third-party hosted services that will require additional legal permissions.
- 3
Hold the scoping meeting
Bring the completed questionnaire to your scoping meeting. Use it to validate assumptions, clarify ambiguous answers, and finalize the exact IP ranges and domains in scope.
Core Questionnaire Categories
Clients often don't know exactly how to communicate what they need tested. Breaking your questions down by engagement type helps guide them through the process.
Use the categories below as a baseline for your own client questionnaires.
Network Penetration Testing
Focus on understanding the size, location, and constraints of the network infrastructure.
Why is the penetration test being performed? (e.g., specific compliance requirement, recent breach)
When should active testing (scanning, exploitation) occur? (Business hours, after hours, weekends)
How many total IP addresses are in scope? (Break down by internal vs. external)
Are there active defense devices in place? (Firewalls, IDS/IPS, WAF, load balancers)
If a system is compromised, how should the team proceed? (Stop at local access, attempt privilege escalation, or perform password attacks?)
Web Application Testing
Focus on the complexity of the applications and the level of access the testing team will have.
How many web applications and login systems are being assessed?
Approximately how many static and dynamic pages exist?
Will source code or architectural documentation be provided? (White-box vs. Black-box)
Does the assessment require static analysis, fuzzing, or credentialed role-based testing?
Wireless Network Testing
Focus on physical coverage and authentication mechanisms.
How many wireless networks are in place, and what encryption types are used?
Is there a guest network? Does it require authentication?
What is the approximate square footage of the coverage area?
Will the team need to enumerate rogue devices or assess attacks against connected clients?
Physical Penetration Testing
Focus on physical security measures, locations, and safety boundaries.
How many locations are in scope, and are they shared facilities?
Are there security guards? (Are they armed? Employed by a 3rd party? Allowed to use force?)
How many entrances exist, and what is the square footage of the facility?
Is the use of lock picks or bump keys legally allowed and approved?
Are there video cameras or armed alarm systems? (Silent alarms, motion triggers, door sensors)
Social Engineering
Focus on target identification and approved methods.
Can you provide a list of approved target email addresses or phone numbers?
Is social engineering approved for the purpose of gaining unauthorized physical access?
How many total personnel will be targeted?
Third-Party Hosting: If a client's answers reveal that their infrastructure or applications are hosted by a third party (like a Cloud provider, Web Host, or MSSP), you must obtain explicit permission from that third party before testing begins. The client cannot legally authorize attacks against infrastructure they do not own.
Role-Specific Questions
Depending on the maturity of the client's security program, you may need to interview specific stakeholders to understand the true business impact of a potential breach.
Questions for Business Unit Managers
Managers provide insight into what data matters most to the business.
What specific data would create the greatest risk to the organization if exposed, corrupted, or deleted?
Are there disaster recovery procedures in place for critical application data?
Are you aware of the testing schedule, and do you have validation procedures to ensure applications remain functional during the test?
Questions for Systems Administrators
Administrators help you navigate the technical realities and fragility of the environment.
Are there any "fragile" systems on the network? (e.g., legacy OS, unpatched servers, systems prone to crashing)
What is the mean time to repair system outages?
Are backups tested regularly, and when were they last successfully restored?
Is there any active system monitoring software in place?
Using Answers to Prevent Scope Creep
Scope creep is one of the biggest risks to a successful engagement. By thoroughly documenting the client's answers in the pre-engagement phase, you establish a clear boundary of what is included in your pricing.
If a client later requests testing for an additional web application or an extra physical location not listed in their questionnaire, you can easily reference the original answers. Document any new requests as a separate Statement of Work (SOW) with an associated hourly rate or flat fee.