What are you testing
Name the systems in scope: application URLs, API endpoints, network ranges, cloud accounts, mobile binaries. Distinguish production from staging. List the user roles or privilege boundaries to be assessed. If a system is out of scope but adjacent (a third-party SSO, a shared cloud tenant), name it explicitly.
Why now
Audit deadline, compliance window, post-incident review, pre-launch security signal, M&A diligence, customer requirement, annual cadence. The driver shapes the report format and the timeline. “Because we should” is also a valid answer.
Depth and methodology
Black-box, grey-box, or white-box (or “whatever makes sense, you tell us”). Methodology requirement if any (PTES, ASVS L2, NIST 800-115, OSSTMM). If there's no methodology requirement, default is grey-box aligned with PTES.
Timeline
Hard deadline (audit date, launch date, diligence date) vs. preferred timeline. Earliest acceptable kickoff date. Any blackout windows during testing (peak traffic, maintenance, holidays). Time zones for daily check-ins.
Reporting and audience
Who reads the report: engineering, security leadership, board, auditor, customer's security team. Required deliverable formats (PDF, Markdown, Jira CSV import). Anything beyond the default bundle (board-deck summary, regulator submission, supplier-attestation letter, redacted public version).
Constraints and stop conditions
What we cannot test (third-party systems we don't have authorization for, regulated data, production systems with no rollback). What triggers an immediate halt (downtime, customer impact, alert thresholds). Escalation contacts on your side, on-call hours, after-hours protocol.