Start with the decision the test should support
Before counting IP addresses, name the question you need answered. Could an internet-facing service expose sensitive data? Could a compromised employee account reach critical systems? Can one customer access another customer’s records? Each question implies a different starting point, access level, and test plan.
NIST SP 800-115 treats planning as a core part of security assessment, including objectives, scope, constraints, responsibilities, and deliverables. A useful scope turns those planning decisions into a shared agreement the business owner and technical team can both understand. [1]
Describe workflows as well as assets
A list of domains tells a tester where an application lives. It does not explain what a purchasing manager can approve, which records belong to each tenant, or how an account changes roles. For an application engagement, include a short walkthrough of important workflows and provide agreed test accounts for the relevant roles.
OWASP’s business logic testing guidance includes workflow circumvention, integrity checks, and limits on repeated actions. For example, a fictional customer portal might allow a refund request to be submitted after its approval expires. That is a business rule to examine, even when the underlying software is fully patched. [2]
Set operational boundaries before execution
Document authorized targets, excluded systems, the test window, emergency contacts, and the conditions that pause testing. Agree on acceptable validation methods and how evidence will be protected, shared, and removed. Third-party infrastructure and production dependencies need explicit treatment in the authorization and rules of engagement. NIST’s guide includes a rules-of-engagement template to structure these decisions. [1]
Consider what the team needs on day one: working accounts, a stable environment, an accurate owner list, and a way to resolve scope questions. An engagement should not lose its most valuable testing time to preventable access problems. Record assumptions about the starting access as well. An external unauthenticated test and an internal assessment using an employee account answer different questions, even when they touch some of the same infrastructure.
Compare the work behind the price
A pentest estimate is useful only when the assumptions are visible. Five simple public pages can require less investigation than one workflow with several roles, tenant boundaries, an API, and sensitive approval steps. Count the meaningful ways the application behaves, the starting access the tester receives, and the depth of validation the business needs.
When comparing proposals, ask each provider to identify the testing time, environment preparation, manual workflow testing, report walkthrough, and remediation verification included. Separate a vulnerability scan from an engagement that validates attack paths. Agree on how new assets or workflows discovered during the test affect scope and cost. These are our suggested comparison questions, not a universal pricing formula.
- Which environments, applications, APIs, roles, and tenant boundaries are included?
- What access will the tester have, and who prepares realistic test data?
- Which manual business-logic and authorization checks are included?
- What reporting, engineering handoff, and retest window are included?
- What change in scope would require a revised estimate?
Define what happens after the report
Agree on a report that explains impact for decision makers and provides reproducible evidence for engineers. OWASP recommends reporting that supports both audiences. Request a clear account of coverage, limitations, and findings so an untested feature is not mistaken for a verified control. [3]
Assign an owner to each accepted remediation task. Decide in advance whether verification is included, what it covers, and when it can happen. A useful final conversation is specific: which risks were reduced, what remains unresolved, and which changes warrant another assessment.
See what useful reporting looks like. Our illustrative sample pentest report shows scope, evidence, risk, remediation, and verification using a fictional environment.