A well prepared project starts testing on day one. A poorly prepared one starts with a week of reconnaissance that still lands on the client's invoice.
Some arrangements are common to every type of test, others depend on what exactly is being examined. Both are covered below.
Common ground rules
Scope and Rules of Engagement
Scope says what is in the test. The ROE say how it may be worked. Three questions need settling before work begins.
The target. What is included: production systems only or test environments as well, the application with its backend or the application alone, one site or all of them.
Exclusions. Real customer data, third party supplier infrastructure, DoS attacks and systems owned by someone else all require an explicit position.
Handling a critical finding. Agreeing who takes the call if unauthenticated RCE surfaces on day two takes a few minutes and often decides how the project goes.
Formalities
- Authorisation to test, issued by the system owner, with scope and dates. Cloud assets sometimes also require notifying the provider.
- An NDA, if the documentation contains sensitive information.
- Clarity on whether the report will reach an end customer, an auditor or a notified body. This changes how it is written.
Contact
A technical contact with a declared response time. The point is easy to underestimate, yet a single unanswered question can block a day of work.
Web application or API
- Test environment addresses, separated from production
- Accounts for every role in the system, two per role
- API documentation: OpenAPI, Postman or at minimum a list of endpoints
- Information about blocking mechanisms: WAF, rate limiting, account lockout
- Test data allowing a full business flow to be completed
Two accounts per role matter. Without them there is no way to check whether one user can reach another user's data, and that is one of the most common and most damaging classes of defect.
If the WAF is to stay enabled, consider allowlisting the tester's address. Otherwise a large share of the budget goes into bypassing your own control instead of testing the application.
Mobile application
- Installable builds for both platforms, close to the production version
- Test accounts and access to the application backend
- Information about hardening: certificate pinning, root detection
- A test device, if the app requires specific hardware
Internal network and infrastructure
- Address ranges in scope together with a list of exclusions
- Network access: VPN or a workstation on site
- A standard domain user account, if the test assumes an employee perspective
- Information about critical systems that must not be disrupted
- Administrator contact for the duration of the test
Time windows matter here in particular. Scanning older equipment during working hours can disturb its operation, and it is better to agree this in advance than to explain it afterwards.
IoT or embedded device
- Two units, with power supplies and cables
- Block diagram and component list: main SoC, radio modules, memories
- Description of UART, JTAG, SPI and USB interfaces, including those declared disabled
- Documentation of the protocol used with the cloud component
- Description of the update process, including signing and verification
- Test accounts in the mobile app and management panel
Two units is not excessive. The first serves non-invasive testing, the second the work after which the device may not come back: desoldering memory, flashing modified firmware or forcing service mode. With a single unit the scope has to be planned more cautiously, which usually raises the effort.
OT and ICS systems
- Inventory: controllers, panels, software versions
- Network diagram with IT and OT interface points marked
- Maintenance windows or a twin rig for active testing
- List of systems where only passive listening is acceptable
- An automation engineer who knows the installation
The last point matters more in OT than the entire documentation set. Somebody who knows what a given cabinet actually controls turns a risky test into a safe one.
What not to do
Do not prepare the system for the test. Disabling diagnostic interfaces for the duration, cleaning up service accounts, swapping configuration for a reference one or flashing fresh firmware all distort the picture of the real state.
A test should reflect the situation in which the system genuinely operates. A report describing an environment staged for the occasion has no practical value and will not hold up in front of an auditor.
The effect
Completing the right checklist typically shortens a project by several days, which translates directly into cost. Pricing is covered in how much a penetration test costs.
Planning a test? Get in touch and I will send back a checklist tailored to the specific target. The scope of work is described under services.