“Test our application” leaves too many important decisions open. Does that include the production API, an old staging hostname, the cloud account, customer exports, or a tool connected to an AI assistant? A useful penetration testing scope makes those choices explicit before anyone sends test traffic.
This planning template gives buyers, engineering teams, agencies, and assessors a shared starting point. It includes fourteen scoping fields and a worked SaaS example. It is an operational worksheet. The parties still need an appropriate written authorization and engagement agreement before testing begins.
1. Start with the decision the report must support
Describe why the assessment is happening and what evidence the recipient needs. An enterprise buyer asking about tenant isolation needs different coverage from an operations team checking newly exposed cloud services. Name the decisions the report should inform and the systems those decisions depend on.
Translate the objective into testable questions. For a billing application: can a customer read or change another customer’s invoices, can a member perform an owner-only action, and can a revoked user collect an export created earlier? Those questions identify the roles and interfaces that must be available.
Identify any required methodology and its version. OWASP ASVS can help specify application verification requirements. A scope should name the selected requirements and evidence rather than implying that mentioning a standard establishes complete coverage.
2. Complete the fourteen scope fields
Copy these fields into your planning document and assign an owner to unresolved entries. Do not use “all systems” as a substitute for an inventory. Include exact environments and identifiers, particularly when similar hostnames lead to different owners or production data.
| Field | What to record |
|---|---|
| Objective and acceptance | Business question; intended decisions; evidence required; what the assessment does not establish. |
| Authorized asset inventory | Exact hostnames, API base URLs, applications, environments, cloud account IDs, and an accountable owner for each. |
| Ownership and third parties | Who controls each asset; provider restrictions; evidence of any required permission; excluded shared services. |
| Test identities and roles | Synthetic tenants and records; approved roles; provisioning and revocation owners; secret exchange channel. |
| Allowed methods | External checks, authenticated business-logic tests, configuration review, source review, and individually approved deeper techniques. |
| Exclusions | Unlisted systems; denial of service; destructive writes; phishing; physical access; persistence; production customer-data extraction unless separately authorized. |
| Schedule and traffic | Start and end with time zone; production windows; source IPs; concurrency and request limits; monitoring contacts. |
| Stop and restart | Observable stop conditions; immediate notification path; named restart authority; time and method of restart approval. |
| Evidence handling | Permitted data; minimal proof; redaction; secure storage; recipients; retention and deletion dates. |
| AI and subcontractors | Approved providers and tools; data each may receive; human review; agreed handling and retention. |
| Finding verification | Reproduction conditions; evidence standard; severity method; business context; false-positive handling. |
| Deliverables and coverage | Executive summary; technical findings; tested and untested assets; blocked cases; limitations and handover format. |
| Retest and closure | Included fixes and paths; time window; configuration/build to retest; result definitions; who accepts residual risk. |
| Fee and scope changes | Fixed fee or agreed model; qualifying finding definition if applicable; approval before adding assets or methods. |
3. Build an asset and access register
Give each application, API, and cloud account a stable asset ID. Record its exact location, environment, owner, authorization status, allowed methods, data sensitivity, and exclusions. Identify connected services that the team can observe but is not permitted to test.
An application may call a payment provider without giving your business authority to assess that provider’s infrastructure. Define the permitted test through your own integration and use its supported test environment. Record provider restrictions and any permission that must be obtained separately.
For authenticated testing, list the required roles and tenant relationships. Two ordinary customer accounts can establish some horizontal boundaries, but they do not establish whether an administrator can misuse a support function. Use synthetic tenants and records so meaningful tests do not require extracting real customer information.
| Asset | Location and environment | Approved access | Boundary |
|---|---|---|---|
| APP-01 | https://app.example.test · staging | Owner A, member A, owner B | Synthetic records; no production account access. |
| API-01 | https://api.example.test/v1 · staging | Tenant-scoped test credentials | Named endpoints and agreed request rate. |
| JOB-01 | Staging export worker | Read-only job logs and disposable exports | No unlisted storage or third-party account testing. |
4. Make stopping and escalation unambiguous
Define observable stop conditions such as unexpected production writes, service degradation beyond the agreed threshold, exposure of real customer data, or activity outside an authorized asset. Use thresholds the operators can measure and specify who watches them during the test window.
Name a primary and backup contact, the urgent channel, the information to provide, and the person who can authorize a restart. A tester should not have to improvise whether an unanswered email permits continued activity. Record how queued actions and active sessions are handled when work stops.
For AI-assisted work, also identify the allowed tools, data destinations, and provider handling terms. A model or automation receives only the authority the engagement permits. A human reviewer should be able to explain what ran, what evidence it produced, and how activity can be interrupted.
5. Worked example: a two-tenant billing application
Objective: establish whether ordinary customers can access another tenant’s invoices or exports. Assets: APP-01, API-01, and JOB-01 in the register above. Access: two synthetic tenants, an owner and member in A, and an owner in B. Include direct reads, writes, searches, queued exports, and download delivery.
Methods: authenticated requests through named staging interfaces, inspection of the provided authorization logs, and harmless changes to disposable records. Exclude payment settlement, production records, denial of service, social engineering, and unlisted third-party services. The team must fill in the actual request limits and test window before approving this plan.
Evidence: sanitized requests and responses, actor and tenant identity, job IDs, and final record state. Deliverables: a boundary-by-boundary result, verified findings with reproduction steps, coverage limits, and a retest plan. A missing test account is reported as blocked coverage, not a passing authorization test.
The tenant-isolation test matrix expands that example into eighteen reusable cases. If the application includes an assistant, add the relevant AI assessment cases and the connected services explicitly to scope.
6. Review readiness, deliverables, and retesting
Before kickoff, verify that authorization is complete, inventory owners agree, test identities work, monitoring is available, and urgent contacts know the window. Resolve gaps by narrowing the authorized work or supplying the missing prerequisite. Additional assets and methods need an agreed scope change.
Ask how a finding becomes verified, how severity incorporates business context, and how the report distinguishes tested, failed, blocked, and excluded areas. Agree the secure delivery format and who may receive the technical evidence. Keep evidence retention and deletion dates concrete.
Define retesting separately from implementation. Name the fixes and paths included, the deadline, the build to examine, and what happens if the original issue is fixed but another route remains. Ceron’s pricing and scope information describes its engagement model; a planning call can establish the actual coverage and fee.
References and reuse
NIST SP 800-115 discusses planning and conducting technical security assessments. The OWASP Web Security Testing Guide supplies testing-method guidance. This original worksheet helps organize engagement decisions and does not replace either publication or confer compliance.
The original Ceron worksheet and test cases on this page are available under CC BY 4.0. You may adapt them with attribution to Ceron, a link to this resource, and an indication of changes. The license applies to this resource’s original worksheet and cases, not third-party standards, Ceron branding, or other site content. The scenarios are illustrative and contain no customer results.
