1. Define the objective and the important systems
Explain why testing is needed now: a new service, a system change, a customer requirement or a specific risk you want to assess. Include a list of the important systems and a short explanation of what they do.
Clarify whether the scope covers a public website, an authenticated application, an API or infrastructure. Where different user roles need testing, include them in the scope. The number of URLs alone does not describe the complexity of the work.
2. Agree the depth of testing
Automated scanning helps identify potential known vulnerabilities. Manual testing can additionally validate findings, assess access boundaries and examine the behaviour of specific functions. Penetration-testing scenarios assess how weaknesses could be exploited within the agreed scope.
Ask the provider to specify the methodology, planned scenarios and exclusions. OWASP WSTG can inform discussions about web application testing coverage; the checks selected will depend on the application.
3. Prepare authorisation and working arrangements
- System owners, exact addresses, environments and explicitly excluded systems.
- Written authorisation, agreed testing windows and any required third-party permissions.
- Test accounts for relevant roles and a secure way to share necessary information.
- Emergency contacts, stop conditions and the process for reporting a critical finding.
- Arrangements for storing, transferring and deleting test evidence and data.
4. Define what the report should contain
Ask for an anonymised example of the report structure. The IT team needs clear findings, supporting evidence and remediation recommendations. Management needs an explanation of impact, priorities and the decisions required.
The report should identify the coverage achieved and its limitations. Discuss severity in the context of the system’s purpose, data and business dependencies. Testing cannot guarantee that every possible vulnerability has been identified.
5. Plan what happens after the test
Assign an owner and a remediation date to each significant finding. If a weakness cannot be fixed immediately, record the interim measure and the decision on residual risk.
Check whether retesting is included in the proposal, which findings it covers and the period in which it can be requested. Agree how resolved and outstanding weaknesses will be reported.
What should you send for an initial discussion?
Start with a short business overview, the testing objective, system types, intended timing and any customer requirements. Do not send passwords, access keys or sensitive technical details through the public contact form. We will agree a suitable transfer method separately.
Official sources
Glesum