A good penetration test begins before the first request. Unclear objectives, missing roles and late access consume assessment time without improving security. Structured preparation lets the tester focus on relevant attack paths and gives the development team useful results.
Name the business objective
“We need a pentest” does not describe the priority. The trigger might be a launch, customer requirement, architectural change or a specific risk question. Each needs a different assessment.
Useful objectives include:
- verify tenant isolation and roles before launch,
- assess an external API including partner access,
- examine paths from the internet to critical data,
- verify remediation from an earlier audit,
- review a mobile app, backend and local storage.
A clear objective concentrates time on the most expensive risks.
Define scope technically
Scope contains more than a primary domain. Explicitly include or exclude subdomains, APIs, mobile builds, IP ranges, cloud resources and source code. Third-party systems require suitable authorisation.
| Detail | Example |
|---|---|
| systems | web app, API, administration, mobile app |
| environment | dedicated staging or controlled production |
| roles | guest, customer, manager, administrator |
| methods | manual, automated and source-code review |
| exclusions | load testing, social engineering, real payments |
| windows | normal tests and particularly risky actions |
Verify DNS names and IPs before starting. Historic systems may be relevant, but cannot be tested actively without authorisation.
Provide representative accounts and data
Authorisation testing needs at least two accounts with the same role and accounts with different roles. This distinguishes horizontal access between users from vertical access to privileged functions. Multi-tenant platforms should provide accounts in at least two organisations.
Test data should be realistic without using unnecessary personal information. The tester needs meaningful objects, state changes and relationships. An empty staging environment prevents many relevant checks.
Select documentation deliberately
Useful material includes architecture overview, role matrix, API specification, data flow, known constraints and changes since the last test. White-box information does not make a test less realistic. It allows more time for deep paths instead of avoidable orientation.
Source-code review also needs build instructions, relevant repositories, the tested revision and secret-handling rules. Credentials are shared through an agreed secure channel and rotated or disabled after completion.
Establish communication during testing
Product and technical contacts are named before work begins. Critical findings are not held until the final report. The escalation path includes availability, expected response and the person authorised to stop testing if operations are affected.
Rules of engagement cover:
- allowed and forbidden methods,
- handling of discovered data,
- evidence and minimal exploitation,
- rate limits and operating boundaries,
- immediate reporting of critical results,
- deletion or return of project data.
Agree on a useful report
A finding needs title, severity, affected component, prerequisites, reproduction, evidence, impact and concrete remediation. A scanner list does not satisfy this need. The management section explains major risks without distorting technical details.
CVSS helps compare technical severity. Priority additionally depends on reachability, data value, existing controls and business importance. Developers should be able to discuss findings directly with the tester.
Plan retesting from the start
A retest verifies the exact fix and reasonable variants of the root cause. Version, environment and expected behaviour must be documented. The team should add an automated regression test so the same weakness cannot return silently.
Not every finding is fixed immediately. Accepted risk needs an owner, rationale, compensating controls and a date for renewed review.
Handover package before testing starts
This table can be used directly as a joint kickoff checklist:
| Package | Must contain | Owner |
|---|---|---|
| Authorisation | commissioning party, approved targets, period and permitted methods | project lead |
| Scope | domains, APIs, IPs, builds, repositories and explicit exclusions | engineering and tester |
| Identities | at least two accounts at each relevant level and two tenants where applicable | product team |
| Test data | realistic objects and states without unnecessary live data | domain team |
| Operations | monitoring notice, stop contact, rate limits and maintenance windows | operations |
| Evidence | secure transfer, retention and deletion date | security |
| Acceptance | report recipients, severity model, retest and expected timing | project lead |
Before the first active test, targets are resolved technically and compared with the scope. A misconfigured subdomain or third-party cloud IP is then found before it becomes a legal or operational problem.
When AI assists the assessment, A realistic view of AI-assisted pentesting explains the boundaries. For the subsequent engineering work, use Prioritising security findings and fixing them sustainably.
Sources and further reading
Conclusion
An hour of preparation often creates more depth than another day with missing access. Clear objectives, complete scope, realistic roles, dependable communication and planned retesting turn a pentest into technical decision support rather than a compliance exercise.