Penetration Testing Scope Template: Get Comparable Quotes

A penetration testing scope template should let two suppliers quote the same work. A domain name and an endpoint count are a start, but they do not say whether the assessment includes authenticated workflows, separate tenants, human investigation, evidence review or remediation retesting. Put those decisions in writing before treating one proposal as cheaper than another.

The template below is an original planning worksheet for a web application and its API. It includes a fictional SaaS example and a way to compare supplier responses. Use it to prepare a request for quotation or a bounded software evaluation. It is not an executed statement of work, a permission letter or a substitute for the approvals your engagement requires. Reviewed October 27, 2026.

Separate the scope worksheet from the agreement that authorizes work

For this worksheet, use three working distinctions. The scope describes what the assessment will examine and the questions it should answer. The statement of work records the deliverables and commercial responsibilities the parties agree to. The rules of engagement describe how authorized testing will operate. Organizations may combine these documents; the important point is that naming an asset does not settle execution conditions or contractual obligations.

NIST SP 800-115, Appendix B supplies an illustrative rules-of-engagement template covering boundaries, assumptions, logistics, communication, target systems and exclusions. It also addresses stopping and resuming work after an incident. Published in 2008, it is a planning reference, not a new product certification. Use the responsible organizational reviewers to turn your worksheet into the appropriate approved documents.

Keep unresolved questions visible. If ownership of an integration is uncertain, mark it pending rather than putting it under a broad wildcard. If the buyer has not decided whether independent assessment is required, settle that before buying a tool subscription. Those are different decisions from choosing a testing method.

Define the business question before counting assets

Consider a fictional billing SaaS with a browser portal, an API and an administrative interface. The immediate buyer question is whether an ordinary customer can obtain another tenant’s invoice or perform an administrative action. That does not automatically commission an assessment of the entire cloud account, the payment provider, the identity provider and every employee device.

For an initial assessment, the product owner could nominate three workflows: view an invoice, export a statement and invite a team member. Engineering would identify the browser and API paths serving those workflows. The application owner would prepare synthetic records in two test tenants and the identities needed to exercise the permitted and forbidden actions. The scope would state which configuration is being tested and which production differences remain.

This example is deliberately narrow. It demonstrates how to make a question testable, not what every SaaS assessment must contain. A different business may care more about account recovery, bulk data export or administrative integrations. Select the workflows whose failure would change a release or purchasing decision.

Copy this penetration testing scope template

Complete the fields that change the work. Replace placeholders with approved identifiers; keep passwords and session tokens in the agreed credential channel. A short first pass is enough if every unresolved item has an owner and a decision date.

Do not accept a completed-looking form with empty dependencies. “SSO supported” does not say who creates the test identities or who handles an interrupted login. “Retesting included” does not say when it can occur or whether only original findings are eligible. Turn these phrases into responsibilities and observable deliverables.

Specify the permitted action as carefully as the forbidden one

For the fictional invoice workflow, user A should be able to read an approved invoice belonging to tenant A. The same user should not receive tenant B’s private invoice. Together, those observations test the intended ownership rule. If user A cannot read its own fixture, the setup may be broken before the ownership boundary is exercised.

Write down deliberate sharing exceptions. If the product permits a customer to share a statement with a partner, cross-user access may be the expected result for that shared object. Use a separate private object for the denied case. The assessment needs the product’s permission policy; a supplier should not have to guess whether a successful action violates it.

Also identify where an action finishes. An export submission may create a background job; an invitation may trigger a notification. Decide which stages can be exercised with synthetic recipients and how the tester will observe the result. If the scope stops at job submission, the report should not imply that downstream file delivery or customer notification behavior was verified.

Resolve third-party boundaries before testing starts

A cloud account is not blanket permission to test the provider. AWS’s penetration-testing policy permits assessments of customer infrastructure on listed services subject to its conditions, while excluding assessments of AWS infrastructure or the services themselves. It requires prior approval for testing that includes command and control and lists prohibited activities such as request flooding. Check the current policy for the exact proposed activity; ordinary application testing and a broader attack simulation can have different conditions.

Apply the same boundary question to external identity, messaging, payment and analytics dependencies. Describe the application interaction that is included, the external system that is excluded, and what the tester should do when progress would require crossing that boundary. A redirect or newly discovered hostname should trigger review when it falls outside the approved scope.

Record the consequence of each exclusion. If the assessment uses a simulated payment callback, it may help examine your application’s handling of that fixture, but it does not establish how the live payment service behaves. Exclusions are easier to accept when the remaining uncertainty is visible.

Compare three proposals without inventing a market price

The following proposals are fictional. They demonstrate different allocations of work rather than typical industry packages. Ask suppliers to answer against the same completed worksheet, then compare what each response commits to deliver.

Normalize the omissions before negotiating price. Ask proposal A for the cost and timing of adding the missing authenticated work. Ask B to state its retest terms. Ask C what happens if engineering cannot deploy a fix within the included window. If the proposals still differ, document the difference as a purchasing choice rather than treating the lowest total as the lowest price for equivalent coverage.

For software evaluations, identify work your own team supplies. Account preparation, operating the runner, reviewing ambiguous findings and correcting the final report can consume staff time even when they are not invoice line items. Record those responsibilities alongside subscription or usage charges. Avoid converting an advertised allowance into an assumed complete-application price.

Make evidence and retesting part of acceptance

OWASP WSTG’s reporting guidance suggests recording scope and limitations, providing actionable finding details, masking sensitive information and connecting retest results to earlier findings. It describes suggestions rather than universal reporting rules. Agree the recipient’s actual needs before delivery.

For this worksheet, request a coverage record alongside the findings. Use separate labels for completed actions, blocked actions and excluded actions, with enough context to explain the distinction. A completed test with no confirmed issue and a test that could not reach the protected function should not collapse into the same blank cell.

Tie each confirmed finding to the tested deployment, identity, business action, expected behavior and sanitized evidence. Require a reviewer to understand the path without receiving raw credentials. Agree who handles an unconfirmed lead and how it will appear in the handoff. Finding counts alone do not tell the buyer whether a result is reproducible.

For remediation retests, identify the original finding and the replacement deployment. Repeat the relevant permitted and forbidden cases where applicable. Record reproduced, not reproduced under the stated conditions, or blocked, together with the evidence. If the underlying workflow changes substantially, agree whether it is a retest or additional assessment work before execution.

Turn the worksheet into a bounded AI pentesting evaluation

Use a representative workflow from the approved scope as the first evaluation task. Give the operator the target, test identities, synthetic fixtures, expected permission decisions and excluded actions. Choose a pilot that tests a prerequisite for the next purchase: reaching the authenticated operation and producing evidence another engineer can review.

The fictional brief below can be adapted after the engagement is approved. It is task context, not authorization and not a technical boundary. Confirm the actual scope restrictions in the execution environment; wording in a prompt does not prove that a tool enforces them.

Evaluation objective: assess the approved invoice-viewing workflow.
Environment: [approved deployment and build].
Assets: [explicitly approved portal and API identifiers].
Identities: tenant-A user and tenant-B user, supplied securely.
Fixtures: one private synthetic invoice in each test tenant.
Expected behavior: each user can read its own invoice;
neither may receive the other tenant's private invoice.
Exclusions: [named systems, actions and data].
Execution conditions: [approved window, intensity and stop contact].
If login, fixtures or access fail: stop the affected action and record it.
Output: identity and deployment context, observed action/result,
sanitized evidence, unresolved coverage and review notes.
Do not infer broader coverage from this one workflow.

Evaluate the outcome in three parts: reach, evidence and operating effort. Did the task reach the intended action under the correct identity? Can a reviewer distinguish the observation from an interpretation? How much preparation and review did the team supply? Use the answers to define the next bounded scope. A single successful pilot does not establish coverage of every role, tenant or integration.

Penligent’s homepage offers a 19-page English sample report using synthetic data; downloading requires signing in or creating a free account. Use the sample to discuss delivery structure with the intended recipient. Its SOC 2 and ISO/IEC 27001 mapping is not certification or a guarantee of audit acceptance.

The published workflow describes operator-controlled tasks, finding verification and PDF or Markdown reporting. Those are functions to evaluate against your scope, not proof that a particular SSO flow, role comparison or independent-assessor requirement is satisfied. Confirm data-processing and deployment requirements before providing sensitive information.

Keep the approved version connected to the report

Give the completed scope a version and retain the supplier’s response against that version. If a new tenant, integration or administrative workflow is added, record who approved the addition, whether it changes operating conditions and how it affects delivery. A new application build should be identified even when the parties agree it does not require commercial change.

At handoff, compare the coverage record with the approved scope. Resolve missing actions before accepting an apparently complete report, or record them as accepted limitations with an owner for the remaining work. This is the point of the template: a purchase should leave the team knowing what was examined, what the evidence supports and what still needs attention.

Questions to resolve before sending the request

Can one domain be enough for a scope?

• It can identify an asset, but the worksheet still needs the environment, identities, important actions, exclusions and deliverables. One domain may expose several distinct workflows.

Should the template demand source code?

• Only when source review is part of the intended work. State what documentation, accounts and code access will be provided so suppliers price the same assessment approach.

Does a completed scope authorize testing?

• Treat this worksheet as preparation. The responsible parties must approve the engagement and required permissions before execution; a copied template or AI task brief does not supply them.

Is an AI-generated report enough for a customer request?

• Ask the recipient to confirm scope, methodology, assessor requirements and deliverables before purchase. Agree that acceptance separately from the report format.

What if access fails during the assessment?

• Record the affected actions as blocked, identify the access owner and agree how to resume. Do not treat an unreachable workflow as a completed negative test.