Preparing for Your Test
Providing the right information and access helps us test effectively and focus on the areas that matter most.
Web applications
Required
Target URL or URLs
Provide the target URL(s).
Credentials for each user role
For authenticated applications, provide suitable test accounts for each user level or role being assessed.
If users can self-register, we will create suitable test accounts ourselves.
Recommended
Two accounts for each relevant user role
Where users of the same role can access different data, providing two accounts allows us to test horizontal access controls as well as access between different privilege levels.
Test or staging environment
Where possible, we recommend a representative test or staging environment. This allows more extensive testing while reducing the risk of disruption to production services.
Representative test data
Populate the test environment with realistic dummy data. An empty application can limit the areas and workflows that can be meaningfully assessed.
Permissions or roles matrix
If available, provide documentation showing what each user role should and should not be able to access.
WAF or application security controls
Tell us if a WAF, reverse proxy or similar security control is in place.
For application testing, we will usually recommend allowlisting our testing IP addresses where appropriate. This helps us focus the assessment on the application itself rather than the protective control in front of it.
For production systems, security controls should normally remain in place where changing or bypassing them could increase the risk of business disruption. However, we do not intentionally perform denial-of-service testing unless it has been explicitly agreed as in scope.
We can provide the required testing IP addresses.
APIs
Required
API definition or collection
Where available, provide a Postman collection, Swagger/OpenAPI specification or equivalent documentation covering the APIs in scope.
Credentials for each relevant user role
Where the API is authenticated, provide suitable credentials or tokens for each relevant user level.
Recommended
Known-good request values
Providing valid example values for parameters helps us exercise functionality efficiently rather than having to determine valid inputs during the assessment.
Workflow documentation
Provide details of important workflows, particularly authentication, authorisation and multi-stage flows.
Two accounts for each relevant user role
Where users of the same role can access different data, providing two accounts allows us to test horizontal access controls as well as access between different privilege levels.
Test or staging environment
A representative non-production environment is preferred where available, particularly where testing could affect live data or business processes.
Representative test data
Populate the test environment with realistic dummy data. An empty application can limit the areas and workflows that can be meaningfully assessed.
Permissions or roles matrix
If available, provide documentation showing the intended permissions for different users, roles or API clients.
Rate limiting or API protection
Tell us about any rate limiting, API gateways, WAFs or other controls that may affect testing. Where appropriate, we may recommend allowlisting our testing IP addresses.
External infrastructure
Required
Public IP addresses in scope
Provide the public IP addresses to be tested, plus any FQDNs you would like included.
You must have the legal authority to authorise testing of all systems in scope. Where systems are owned, hosted or operated by a third party, you are responsible for obtaining any required permission before testing begins.
Optional, but useful
Test credentials for public login services
Where appropriate, test accounts can help us assess authenticated services without risking lockout or disruption to live user accounts.
Details of security controls
Let us know about relevant firewalls, intrusion prevention systems, rate limiting or other security controls that may affect testing.
For external infrastructure testing, we would normally recommend leaving these controls enabled so the assessment reflects the externally exposed environment.