ESSENTIAL GUIDANCE · BUYER GUIDE · 10 min read
Part of Validate insights →Penetration-testing proposal template: what a defensible scope should contain
A practical proposal structure covering objectives, scope, authority, methodology, evidence, reporting, retesting, responsibilities and price.
A useful penetration-testing proposal makes the assurance decision, testing boundary and commercial commitment clear before work begins. Use this structure to compare providers consistently and expose assumptions that could otherwise become shallow coverage, unsafe activity or later change requests.
Need an acronym translated?Open the cyber glossary →State the decision the test must support
Begin with the reason for testing: a release decision, customer requirement, regulatory expectation, material change or investigation of a specific risk. Name the business services and stakeholders that depend on the result. A proposal built only around a list of assets can be technically valid while failing to answer the organisation's actual assurance question.
Document rules of engagement
Set testing windows, communication routes, escalation contacts, stop conditions, prohibited actions and data-handling requirements. Explain how critical findings will be raised during testing and how potential service impact will be managed. These controls make meaningful investigation safer without reducing the work to a superficial checklist.
Allocate responsibilities and prerequisites
State who will provide test accounts, architecture information, allow-listing, test data, access and internal approvals; who will monitor the environment; and who has authority to pause or extend testing. Record dependencies, lead times and what happens if prerequisites are late or incomplete. Clear responsibilities protect the schedule, commercial assumptions and safety of the engagement.
Describe the approach and depth
Explain how automated coverage and human investigation will be combined, which recognised methodologies inform the work and how business logic, access control and chained weaknesses will be examined. Name any assumptions about accounts, architecture information or test data. Methodology should support repeatability and safety while leaving room for expert judgement.
Identify the proposed delivery team
State the provider's relevant company accreditation, the experience needed for the technologies in scope, how consultants are supervised and how findings are quality-assured. Individual qualifications and company accreditation answer different questions, so buyers should verify both where they matter to the engagement.
Specify evidence and deliverables
Define what the customer will receive: live notification of material findings, reproducible technical evidence, severity rationale, practical remediation guidance, an executive view, a technical report and any portal access. Require limitations and untested areas to be stated clearly so the final report cannot be mistaken for assurance over a wider environment.
Include remediation support and retesting
The proposal should explain how questions will be handled after delivery, which fixes are eligible for retest, the retest window and what closure evidence will be provided. A report identifies work; retesting checks whether the agreed fixes address the previously demonstrated finding within the agreed retest scope and records any remaining limitations.
Make price assumptions visible
Separate scope, tester effort, optional work, expenses, tax and any continuing service. Record the inputs that could change the price, such as additional roles, endpoints, APIs or environments. Compare proposals on the decision they support, the depth provided and the complete route to verified closure—not simply the lowest headline day rate.
This guide covers the essentials. Continue into our technical analysis for a firmer position, practical implications and recommended action.
Read “Modern penetration testing should create decisions, not just findings” →
