A pentest starts before the first request
Scope, test roles and stopping criteria. Plan an assessment that produces useful results.
Define the scope
An agreed scope turns “test the website” into a concrete assignment. Record the domains, APIs, environments and user roles included in the assessment. List third-party integrations separately: a payment provider being reachable through the application does not automatically put it in scope.
Build a working matrix
For each function, document who can use it and which data it operates on. A customer reads their own order, an operator changes its status, and an administrator manages roles. These expectations become the baseline against which you compare actual application behavior.
Agree on operational limits
Before active testing, agree on request rates, permitted changes and an incident contact. Prepare test records and a cleanup procedure. Load testing and actions involving real payments need a separate decision; they are not automatically part of the engagement.
Define the deliverable
Useful results are reproducible observations with an explanation of risk and remediation. Record assessment limitations too: an unavailable role, a broken staging environment or an excluded integration. Finding nothing in an untested feature does not demonstrate that it is secure.