A penetration test begins long before the first request is sent. Results depend on a clear objective, scope and rules. Leaving these open delays testing, consumes time in clarification and makes results harder to compare with expectations.
This overview draws on our experience and public frameworks. NIST SP 800-115, for example, devotes a chapter to planning and includes sample Rules of Engagement. This is not an exhaustive list: every environment has its specifics.
Start with objectives and scope
Clarify why you are testing. A new application before launch, an external infrastructure assessment and a customer or auditor request call for different approaches. The objective determines what to test, how deeply and how to present results.
Useful scoping questions include:
- Which systems, applications, APIs or address ranges are included?
- What is explicitly excluded, such as third-party systems or shared hosting?
- Are we testing production or a staging environment that accurately reflects it?
- Which user roles exist and which should be tested?
- Is the perspective external, internal or both?
Services you do not own require care. Cloud platforms, SaaS applications and hosting providers have their own testing rules. Verify what is permitted and obtain provider consent where needed.
Authorisation and Rules of Engagement
Testing must not start without written authorisation from someone entitled to authorise work on the systems. Supplier-operated systems may require the supplier's involvement.
Rules of Engagement define how testing proceeds and what is allowed. They typically cover:
- Time windows and restrictions, such as avoiding financial closing.
- Allowed and prohibited techniques, including load testing or social engineering.
- Tester source IP addresses so your team can recognise activity in logs.
- Critical vulnerability escalation and reporting times.
- Conditions requiring immediate suspension.
- Handling of data accessed during testing.
Decide whether operations and security teams will know about the test. Announced tests reduce false alarms; unannounced ones can assess team response. Both approaches are useful when agreed beforehand.
Test accounts, data and contacts
Missing access commonly delays application and API tests. Prepare accounts for every role. Authorisation testing needs at least two accounts with the same role, ideally in different organisations or tenants, to verify data separation.
Use realistic synthetic data in staging. For production, agree which records testers may use. Transfer credentials securely, never in an ordinary email alongside the system address.
Check the technical details:
- Confirm staging works and runs the current version.
- Agree whether tester addresses should be allowed through WAF or other controls, according to test objectives.
- Supply mobile installation packages and test backend access where relevant.
- Provide API documentation, such as OpenAPI, or sample requests.
- Back up important data in the test environment.
Contacts and communication
Appoint contacts on both sides. Your contact should understand the systems and be able to decide quickly. Agree a backup contact and communication channel.
Set expectations for progress updates. Short tests may need only opening and closing meetings; longer tests benefit from brief interim reports. Agree critical finding escalation without waiting for the final report.
What a test cannot deliver
Testing is limited by time and scope. It reduces uncertainty but cannot prove the absence of all vulnerabilities. It does not replace updates, monitoring or secure development. Its output is documented evidence of what was tested under agreed conditions and what was found.
Testing itself does not remediate issues. The report explains findings, impact and recommendations; your team or supplier implements fixes. Retesting is generally a separately agreed part of the proposal.
Preparation checklist
- Objectives and expected deliverables are documented.
- Scope lists targets and explicit exclusions.
- Authorisation is signed by an entitled system owner and, where necessary, the service provider.
- Rules cover time windows, prohibited techniques and stop procedures.
- Accounts cover all roles, including two accounts with the same role.
- The environment works and data is prepared.
- Primary and backup contacts and communication channels are agreed.
- It is clear whether operations teams know about the test.
If you are unsure about scope or rules, we can work through them together. See Penetration testing or arrange a consultation to discuss your environment.
