Run the engagement on the record the proposal promised
SecPortal stores the agreed scope, the named team, the findings, the report, the retests, and the invoice on a single engagement record. The audit trail your proposal claims is the audit trail you actually deliver. Free plan available.
No credit card required. Free plan available forever.
Full template
Copy the full proposal template
Twelve vendor-side sections covering executive summary, scope confirmation, methodology, project plan, named engagement team, deliverables, evidence handling, communications and severity SLAs, pricing, vendor security and references, assumptions and warranties, and signatures. Aligned with PTES, NIST SP 800-115, OWASP WSTG, OWASP ASVS, and CREST scheme expectations. Replace every {{PLACEHOLDER}} before issuing.
1. Cover and executive summary
The first page is what the procurement decision is built on. Make it self-contained so an evaluator can paste it into a board paper without rewriting it.
PENETRATION TESTING PROPOSAL
Issued in response to: {{BUYER_RFP_REFERENCE}}
Issued by (the Vendor): {{VENDOR_LEGAL_NAME}}, {{VENDOR_REGISTERED_OFFICE}}
Issued to (the Buyer): {{BUYER_LEGAL_NAME}}
Proposal reference: {{VENDOR_PROPOSAL_REFERENCE}}
Issue date: {{ISSUE_DATE}}
Validity period: this proposal is valid for {{VALIDITY_DAYS}} days from the issue date.
Executive summary:
- Engagement: {{ENGAGEMENT_NAME}} (a {{ENGAGEMENT_TYPE}}, e.g. external network and web application penetration test).
- Scope at a glance: {{SCOPE_AT_A_GLANCE}} (asset classes and approximate volumes).
- Test depth: {{TEST_DEPTH_AT_A_GLANCE}} (PTES Level 2 or Level 3, ASVS Level, MASTG depth, etc.).
- Effort: {{TESTER_DAYS}} tester-days across {{CALENDAR_WEEKS}} calendar weeks.
- Headline price: {{HEADLINE_PRICE}} {{CURRENCY}}, fixed fee for the scope as stated, exclusive of VAT or sales tax.
- Lead tester: {{NAMED_LEAD_NAME}}, {{NAMED_LEAD_TITLE}}, {{NAMED_LEAD_CERTS}}.
- Deliverables: executive summary, technical findings report, remediation roadmap, and machine-readable findings export, with a {{RETEST_WINDOW_DAYS}}-day included retest window.
- Methodology: aligned with PTES, NIST SP 800-115, OWASP WSTG v4.2, OWASP API Security Top 10, and OWASP ASVS where applicable.
The Vendor is responding to every numbered section in the Buyer's RFP. Where a section does not apply or where the Vendor proposes a deviation, the Vendor states this explicitly in the relevant section below rather than skipping it.
2. Scope confirmation
Restate the buyer scope back, by exact identifier. Any deviation from the RFP scope must be flagged here. Summarising the scope, or replacing buyer identifiers with vendor categories, is the most common cause of post-award disputes.
Scope as accepted by the Vendor (mirrors the Buyer's RFP scope):
- Web applications: {{WEB_APP_URLS}}
- APIs (with documentation references): {{API_BASE_URLS_AND_DOCS}}
- External network ranges (CIDR notation): {{EXTERNAL_IP_RANGES}}
- Internal network ranges: {{INTERNAL_IP_RANGES}}
- Cloud accounts (AWS account IDs / Azure subscriptions / GCP projects): {{CLOUD_ACCOUNT_IDS}}
- Mobile applications (with platforms): {{MOBILE_APP_BUNDLES_AND_PLATFORMS}}
- Source code repositories (where code review is in scope): {{REPO_URLS}}
- Identity providers and SSO endpoints: {{IDP_ENDPOINTS}}
Asset volumes accepted:
- Distinct user roles per application: {{USER_ROLE_COUNTS}}
- API endpoints in scope: {{API_ENDPOINT_COUNT}}
- Estimated lines of code (where code review is in scope): {{SLOC_ESTIMATE}}
Out-of-scope assets the Vendor will explicitly NOT test: {{OUT_OF_SCOPE_LIST}}.
Deviations from the RFP scope (if any):
- {{DEVIATION_1_DESCRIPTION}}: rationale {{DEVIATION_1_RATIONALE}}, commercial impact {{DEVIATION_1_IMPACT}}.
- {{DEVIATION_2_DESCRIPTION}}: rationale {{DEVIATION_2_RATIONALE}}, commercial impact {{DEVIATION_2_IMPACT}}.
If no deviations apply, the Vendor states: no deviations from the RFP scope.
Assumptions on which the scope is priced:
- Test environments are reachable from the Vendor's testing infrastructure on the agreed start date.
- Test credentials and any required allowlist entries are provisioned by the Buyer no later than {{CREDENTIAL_LEAD_TIME}} business days before testing begins.
- Source code (where in scope) is delivered as a tagged commit or a git URL with read access for the engagement team for the duration of the test.
- Asset count and complexity remain within the volumes stated above. Material additions are handled under the change control terms in Section 9.
3. Methodology and depth
Anchor methodology to public standards by name and version. Buyers and auditors trust public-standard alignment over proprietary marketing language.
Methodology references the Vendor will follow:
- PTES (Penetration Testing Execution Standard), pre-engagement through reporting phases.
- NIST SP 800-115 Technical Guide to Information Security Testing and Assessment.
- OWASP Web Security Testing Guide v4.2 for web application testing.
- OWASP API Security Top 10 ({{OWASP_API_EDITION}}) for API testing.
- OWASP Mobile Application Security Testing Guide (MASTG) for mobile testing, where in scope.
- OWASP Application Security Verification Standard (ASVS) Level {{ASVS_LEVEL}} for verification depth, where in scope.
- CIS Benchmarks ({{CIS_BENCHMARK_VERSIONS}}) for cloud configuration testing, where in scope.
How the Vendor's internal methodology maps to the standards above:
- {{INTERNAL_METHODOLOGY_NAME}} pre-engagement maps to PTES Section 1.
- Reconnaissance and intelligence gathering maps to PTES Section 2 and OWASP WSTG WSTG-INFO.
- Threat modelling maps to PTES Section 3.
- Vulnerability analysis and exploitation maps to PTES Sections 4 and 5, OWASP WSTG WSTG-IDNT through WSTG-CLNT, OWASP API Security Top 10, and OWASP ASVS verification controls.
- Post-exploitation and privilege escalation map to PTES Section 6.
- Reporting maps to PTES Section 7 and to NIST SP 800-115 Section 7.
Test depth applied per asset class:
- Web applications and APIs: {{WEB_API_DEPTH}} (PTES Level 2 standard or Level 3 advanced).
- Network and infrastructure: {{NETWORK_DEPTH}} (external host discovery, service enumeration, vulnerability validation, safe exploitation).
- Cloud configuration: {{CLOUD_DEPTH}} (CIS Benchmark alignment, identity surface, exposed services, public storage).
- Source code review (where in scope): {{CODE_REVIEW_DEPTH}} (manual review depth, SAST coverage, SCA coverage).
- Mobile applications (where in scope): MASTG profile {{MASTG_PROFILE}} ({{MASTG_PROFILE_DESCRIPTION}}).
Where the Vendor's internal methodology adds depth beyond the public-standard baseline, this is described per asset class in Annex A. The proposal price reflects the depth declared in this section.
4. Project plan and milestones
Calendar dates, not relative ones. Buyers schedule remediation, retests, and audit windows around proposal dates.
Project phases and milestones:
- Award and contracting: {{CONTRACTING_END_DATE}}.
- Pre-engagement, scoping confirmation, ROE finalisation, credential provisioning: {{PRE_ENGAGEMENT_END_DATE}}.
- Kickoff meeting: {{KICKOFF_DATE}} ({{KICKOFF_TIMEZONE}}).
- Active testing window: {{TEST_START_DATE}} to {{TEST_END_DATE}} ({{TEST_TIMEZONE}}).
- Mid-engagement checkpoint: {{MIDPOINT_DATE}}.
- Draft report delivery: within {{DRAFT_REPORT_DAYS}} business days of testing close.
- Buyer review window: {{BUYER_REVIEW_DAYS}} business days from draft report delivery.
- Final report delivery: within {{FINAL_REPORT_DAYS}} business days of buyer feedback.
- Retest window: {{RETEST_WINDOW_DAYS}} days from final report delivery.
- Retest report delivery: within {{RETEST_REPORT_DAYS}} business days of retest close.
- Engagement closure: written confirmation of evidence destruction within {{CLOSURE_DAYS}} business days of retest report acceptance.
Status cadence:
- Weekly written status update for the duration of the active testing window, in the engagement portal and in the Vendor's standard summary email format.
- Mid-engagement checkpoint: live walkthrough of progress, in-flight findings, and any scope or schedule risks.
- Draft report walkthrough: live session, scheduled within {{DRAFT_WALKTHROUGH_DAYS}} business days of draft report delivery.
- Final report walkthrough: live session, scheduled within {{FINAL_WALKTHROUGH_DAYS}} business days of final report delivery.
Schedule risks and dependencies:
- {{DEPENDENCY_1}} (e.g. test credentials available by {{CREDENTIAL_LEAD_TIME}} business days before testing).
- {{DEPENDENCY_2}} (e.g. code repository read access for the engagement team for the duration of the test).
- Schedule slip arising from a Buyer-side dependency is logged, costed under Section 9 if applicable, and does not reduce the Vendor's commitment to the deliverables in Section 6.
5. Engagement team
Name the lead. Name senior testers. Commit to the named lead at award, or document the substitution policy. Bait-and-switch staffing is the dominant complaint about vendor proposals.
Named engagement lead:
- Name: {{NAMED_LEAD_NAME}}.
- Role on this engagement: {{NAMED_LEAD_ROLE}} (e.g. Engagement Lead and Principal Tester).
- Years of testing experience: {{NAMED_LEAD_YEARS}}.
- Scheme accreditations and certifications: {{NAMED_LEAD_CERTS}} (e.g. CREST CCT App, OSCP, OSWE).
- Asset class experience relevant to this engagement: {{NAMED_LEAD_RELEVANT_EXPERIENCE}}.
Named senior testers:
- {{SENIOR_TESTER_1_NAME}}, {{SENIOR_TESTER_1_ROLE}}, {{SENIOR_TESTER_1_CERTS}}, {{SENIOR_TESTER_1_YEARS}} years.
- {{SENIOR_TESTER_2_NAME}}, {{SENIOR_TESTER_2_ROLE}}, {{SENIOR_TESTER_2_CERTS}}, {{SENIOR_TESTER_2_YEARS}} years.
Anonymised resumes for the named lead and named senior testers are attached as Annex B.
Substitution policy:
- The named lead in this proposal will be the actual lead at award. If the named lead becomes unavailable for medical, personal, or extraordinary operational reasons, the Vendor will propose a substitute of equivalent or greater seniority and the Buyer must approve the substitution in writing before the substitute joins the engagement.
- The Buyer may request a one-hour technical interview with the named lead before award; the Vendor will make the named lead available within {{LEAD_INTERVIEW_DAYS}} business days of request.
Engagement team supervision:
- The named lead is responsible for technical quality, including evidence integrity, severity calibration, and report quality.
- A second senior tester reviews the draft report before delivery to the Buyer (four-eyes review).
- A delivery manager (named in Annex B) is responsible for schedule, communications, and commercial change control.
6. Deliverables and acceptance criteria
Reporting quality is where engagements are judged. Specify deliverable formats, audiences, and acceptance criteria so the buyer cannot reject deliverables on undeclared grounds.
The Vendor will deliver, for the engagement defined in Section 2:
- Executive summary suitable for board and audit committee distribution: {{EXEC_SUMMARY_LENGTH}} pages, PDF.
- Technical findings report: one finding per page or per section, including severity, CVSS 3.1 vector and score, evidence (screenshots, traffic captures, configuration extracts, code excerpts as applicable), affected asset, business impact, technical impact, and remediation guidance. PDF, plus editable format on request (Word or equivalent), watermarked or controlled.
- Remediation roadmap: findings prioritised by severity and exploitability, grouped into phased timelines (immediate, short-term, medium-term).
- Compliance mapping (where applicable): findings mapped to PCI DSS, SOC 2, ISO 27001, HIPAA, NIST 800-53, or other frameworks listed in Section 2.
- Machine-readable findings export: structured CSV or JSON for ingestion into the Buyer's vulnerability management or ticketing system.
- Raw evidence package: encrypted archive of evidence captured during the engagement, retained per the data handling terms in Section 7.
Acceptance criteria:
- Deliverables are accepted by the Buyer in writing within {{ACCEPTANCE_DAYS}} business days of final report delivery.
- The Buyer may raise factual corrections or evidence requests in that window. The Vendor will respond within {{CORRECTION_RESPONSE_DAYS}} business days.
- Acceptance is not unreasonably withheld. If acceptance is silent past the acceptance window, the deliverables are deemed accepted.
- Disputes over severity are resolved by reference to the CVSS 3.1 vector evidence and the asset's business context, recorded against the finding.
Sample deliverables:
- A sanitised sample technical report and a sanitised sample executive summary are provided in Annex C of this proposal so the Buyer can see report quality before award.
7. Evidence handling and data protection
These commitments protect the buyer when an audit asks how testing data was handled, and they protect the vendor against disputes over data exposure.
Evidence handling commitments:
- All proof of compromise (screenshots, traffic captures, hashes, configuration extracts, code excerpts) is encrypted at rest and in transit.
- Evidence is transmitted to the Buyer only via the engagement portal or another channel agreed in writing before testing begins.
- Personally identifiable data, cardholder data, and other regulated data exposed during testing is masked in the final report unless the Buyer requests otherwise in writing.
- Test credentials provided by the Buyer are stored encrypted, never transmitted by email, and rotated by the Buyer at engagement closure. The Vendor confirms credential destruction in writing.
Data retention and destruction:
- Evidence and findings are retained for {{RETENTION_PERIOD}} after engagement closure to support retests, audit enquiries, or buyer-side incident review, then securely destroyed with written confirmation to the Buyer.
- The Vendor will accommodate a buyer-initiated request for early destruction with {{EARLY_DESTRUCTION_NOTICE}} business days' notice; an audit reference (timestamp, evidence inventory) is retained for the period legally required of a testing organisation, with the underlying evidence destroyed.
Data protection:
- The Vendor declares the legal entities that will process Buyer data under this engagement: {{PROCESSING_ENTITIES}}.
- The Vendor declares the locations of those entities: {{PROCESSING_LOCATIONS}}.
- The Vendor declares any sub-processors involved in delivery: {{SUBPROCESSORS}} (or states "none").
- Cross-border transfers comply with the Buyer's data protection terms attached to the SOW. Standard contractual clauses or equivalent transfer mechanisms apply where required.
Incident notification:
- The Vendor will notify the Buyer within {{INCIDENT_NOTIFICATION_HOURS}} hours of any incident affecting Buyer data, including a description, the data affected, the immediate containment actions, and a written follow-up within {{INCIDENT_FOLLOW_UP_DAYS}} business days.
8. Communications and severity SLAs
Vendors that cannot commit to a severity-driven SLA in the proposal rarely meet one in delivery. Make the commitments concrete.
Communication channels:
- Primary: Vendor-provided engagement portal with secure messaging, evidence storage, and finding tracking. Buyer stakeholders provisioned: {{BUYER_PORTAL_USERS}}.
- Secondary: email to named stakeholders, with PGP encryption available on request. Vendor public key fingerprint: {{VENDOR_PGP_FINGERPRINT}}.
- Out-of-band: phone numbers for critical findings and stop-test events. Vendor on-call contact: {{VENDOR_ONCALL_CONTACT}}.
Severity-driven communication SLA the Vendor commits to:
- Critical findings: communicated within the same business day, ideally within hours, by phone followed by written confirmation in the portal.
- High findings: communicated within one business day in the portal, with a summary at the next scheduled checkpoint.
- Medium findings: visible in the portal as logged, summarised at scheduled checkpoints.
- Low and informational findings: consolidated into the final report.
Stop-test triggers:
- The Buyer can pause testing by written notice to the named delivery manager. The Vendor will confirm pause within one business hour.
- The Vendor will pause testing if it observes any condition that risks production impact beyond the agreed envelope, and notify the Buyer immediately.
Escalation chain:
- Engagement Lead: {{NAMED_LEAD_NAME}}, {{NAMED_LEAD_EMAIL}}, {{NAMED_LEAD_PHONE}}.
- Delivery Manager: {{DELIVERY_MANAGER_NAME}}, {{DELIVERY_MANAGER_EMAIL}}, {{DELIVERY_MANAGER_PHONE}}.
- Vendor executive sponsor: {{EXECUTIVE_SPONSOR_NAME}}, {{EXECUTIVE_SPONSOR_EMAIL}}.
9. Pricing and commercial terms
Match the pricing structure the RFP requested so the proposal is comparable. Make assumptions explicit so any future change is a defensible change order rather than a dispute.
Pricing structure: {{PRICING_MODEL}} (fixed fee, day rate, retainer, or PTaaS subscription).
Fixed fee for the engagement as scoped in Section 2:
- Total fee: {{HEADLINE_PRICE}} {{CURRENCY}}, exclusive of VAT or sales tax.
- Tester-days included: {{TESTER_DAYS}}.
- Calendar weeks included: {{CALENDAR_WEEKS}}.
- Retest verification of all findings the Vendor identified, inside the {{RETEST_WINDOW_DAYS}}-day retest window: included at no additional fee.
Day rate for change orders during the engagement:
- Junior tester: {{DAY_RATE_JUNIOR}} {{CURRENCY}} per tester-day.
- Senior tester: {{DAY_RATE_SENIOR}} {{CURRENCY}} per tester-day.
- Principal tester: {{DAY_RATE_PRINCIPAL}} {{CURRENCY}} per tester-day.
Retest pricing outside the included window:
- Per retested finding, evidence-equivalent: {{OUT_OF_WINDOW_RETEST_FINDING}} {{CURRENCY}}.
- Bulk retest of all open findings: {{OUT_OF_WINDOW_RETEST_BULK}} {{CURRENCY}} per asset.
Assumptions baked into the fixed fee:
- Asset count and complexity as stated in Section 2.
- Test depth as stated in Section 3.
- Buyer-side dependencies met per Section 4 (credentials, allowlist, repo access, environment availability).
- Engagement team availability for the calendar weeks listed in Section 4.
Change control:
- Material additions to scope, depth, or schedule are raised as a change order, costed at the day rates above, and require written acceptance by both parties before work begins.
- Material reductions are reflected as a credit against the fixed fee at the same day rate.
Commercial terms:
- Payment terms: {{PAYMENT_TERMS}} (e.g. net 30 from invoice).
- Invoicing schedule: {{INVOICING_SCHEDULE}} (e.g. on award, at testing close, at final report sign-off).
- Expenses: {{EXPENSES_POLICY}} (e.g. travel and lodging for on-site testing reimbursed at cost on prior approval).
- Currency: {{CURRENCY}}.
- Tax treatment: pricing exclusive of VAT or sales tax; Vendor confirms jurisdiction and tax registration in Annex D.
10. Vendor security, references, and qualifications
The buyer is treating the vendor as a third party for risk management purposes. Provide evidence proportional to the data handled.
Vendor security posture:
- ISO/IEC 27001 certification status: {{ISO_27001_STATUS}} (certifying body, scope, expiry, certificate number).
- SOC 2 Type II report availability: {{SOC_2_STATUS}} (reporting period, auditor name).
- Cyber Essentials Plus or equivalent national scheme certification: {{CYBER_ESSENTIALS_STATUS}}.
- Background check policy for testers handling Buyer data: {{BACKGROUND_CHECK_POLICY}}.
- Cyber insurance: {{CYBER_INSURANCE_PROVIDER}}, policy limits {{CYBER_INSURANCE_LIMITS}}, coverage type {{CYBER_INSURANCE_COVERAGE}}.
Subcontractor policy:
- Subcontractor use on this engagement: {{SUBCONTRACTOR_USE}} (yes / no).
- If yes, named subcontractors and their roles: {{SUBCONTRACTOR_DETAILS}}.
- The Buyer may refuse a specific subcontractor at award without prejudice to the rest of the proposal.
Data residency:
- Evidence and findings storage location for this engagement: {{DATA_RESIDENCY_LOCATION}}.
- Cloud regions used by the Vendor portal: {{CLOUD_REGIONS_USED}}.
Corporate accreditations relevant to this engagement:
- CREST: {{CREST_STATUS}} (member status, scheme: CRT, CCT, OVS, STAR).
- CHECK: {{CHECK_STATUS}} (member, lead, team).
- FedRAMP 3PAO: {{FEDRAMP_STATUS}} (where US federal work is in scope).
- TIBER-EU / DORA TLPT panel: {{TLPT_PANEL_STATUS}} (where threat-led testing is in scope).
References from comparable engagements (last {{REFERENCE_WINDOW}} months):
- {{REFERENCE_1_ORGANISATION}} ({{REFERENCE_1_INDUSTRY}}, {{REFERENCE_1_ASSET_CLASS}}, {{REFERENCE_1_DATE}}). Contact on request.
- {{REFERENCE_2_ORGANISATION}} ({{REFERENCE_2_INDUSTRY}}, {{REFERENCE_2_ASSET_CLASS}}, {{REFERENCE_2_DATE}}). Contact on request.
- {{REFERENCE_3_ORGANISATION}} ({{REFERENCE_3_INDUSTRY}}, {{REFERENCE_3_ASSET_CLASS}}, {{REFERENCE_3_DATE}}). Contact on request.
Prior incidents involving Buyer data in the last {{INCIDENT_HISTORY_WINDOW}} months: {{INCIDENT_HISTORY}} (or "none").
11. Assumptions, exclusions, and warranties
Reading the small print is what auditors and procurement legal teams do first. Make the small print honest, then there is nothing to challenge later.
Assumptions:
- The scope and asset volumes in Section 2 reflect the engagement at the issue date of this proposal.
- Buyer-side dependencies (credentials, allowlist, environment availability, repo access) are met within the lead times in Section 4.
- The Buyer and the Vendor execute a master services agreement, statement of work, and rules of engagement before active testing begins.
Exclusions:
- This proposal does not include training, advisory work outside the scope of the engagement, remediation engineering, or implementation of recommended controls. Such work, if requested, is quoted separately under a change order.
- This proposal does not include legal, regulatory, or compliance opinion. The Vendor's findings inform Buyer decisions but are not a legal or compliance opinion.
Warranty:
- The Vendor warrants that the engagement will be delivered with reasonable skill and care, by suitably qualified personnel, in line with the methodology in Section 3 and the deliverables in Section 6.
- The Vendor does not warrant that the engagement will discover every vulnerability in the in-scope assets. Penetration testing is a point-in-time assessment and provides assurance to the depth declared, not absolute assurance.
Liability:
- Liability is capped at {{LIABILITY_CAP}} {{CURRENCY}} or the engagement fee, whichever is greater, except for matters which cannot lawfully be limited (death or personal injury caused by negligence, fraud, deliberate breach of confidentiality, or willful default).
- Indirect, consequential, and special damages are excluded except as required by applicable law.
Intellectual property:
- The Vendor retains intellectual property in its testing methodology, internal tooling, and templates.
- The Buyer owns the deliverables produced under this engagement, including the executive summary, technical report, and remediation roadmap.
- The Vendor may use anonymised, non-attributable insights from this engagement for internal training and methodology development.
Confidentiality:
- The Vendor and the Buyer treat all information exchanged during this engagement as confidential, subject to the master services agreement and any non-disclosure agreement in force.
- Findings, evidence, and credentials are not disclosed to third parties without written authorisation, except where compelled by law.
12. Signatures and acceptance
Acceptance of the proposal is the trigger that moves the agreed terms into the SOW. Make the trigger explicit.
Acceptance:
- Acceptance of this proposal is signified by the Buyer signing this section or by issuing a purchase order or letter of intent that references this proposal by reference {{VENDOR_PROPOSAL_REFERENCE}} and accepts its terms.
- On acceptance, the agreed scope, methodology, deliverables, evidence handling, retest policy, and pricing move into a statement of work executed by the parties. The day-to-day operational rules move into a rules of engagement document executed by the parties.
For the Vendor ({{VENDOR_LEGAL_NAME}}):
- Name: {{VENDOR_SIGNATORY_NAME}}.
- Title: {{VENDOR_SIGNATORY_TITLE}}.
- Date: {{VENDOR_SIGNATURE_DATE}}.
- Signature: ____________________________________
For the Buyer ({{BUYER_LEGAL_NAME}}):
- Name: {{BUYER_SIGNATORY_NAME}}.
- Title: {{BUYER_SIGNATORY_TITLE}}.
- Date: {{BUYER_SIGNATURE_DATE}}.
- Signature: ____________________________________
Annexes:
- Annex A: methodology depth detail per asset class.
- Annex B: anonymised resumes for the named engagement team.
- Annex C: sanitised sample executive summary and technical report.
- Annex D: vendor security questionnaire response and tax registration evidence.
- Annex E: rules of engagement draft for finalisation at award.
How to use this template
Read the buyer's RFP cover-to-cover before drafting. Mirror the buyer's scope back in Section 2 with exact identifiers; flag any deviation explicitly. If the buyer issued a request without an RFP, use the RFP template to reverse-engineer the structure the buyer is likely expecting.
Validate tester-day budget and price using the pentest scoping calculator so the headline price in Section 1 is defensible against the depth declared in Section 3.
Replace every {{PLACEHOLDER}} with engagement-specific values. Do not leave placeholders in the issued document.
Anchor methodology to public standards by name and version in Section 3. Buyers and auditors trust public standard alignment more than proprietary marketing language. The SecPortal PTES framework page and NIST SP 800-115 framework page map the standard phases to the operational reality of an engagement.
Commit to the named lead in Section 5. Bait-and-switch staffing on award is the dominant complaint about vendor proposals; addressing it in writing protects both sides.
On acceptance, lift the agreed terms into the statement of work template and the operational rules into the rules of engagement template. The RFP, the proposal, the SOW, and the ROE should all reference the same engagement record.
Methodology and reference standards
PTES (Penetration Testing Execution Standard) covers pre-engagement, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, and reporting. See the SecPortal PTES framework page.
NIST SP 800-115 Technical Guide to Information Security Testing and Assessment, planning, execution, and reporting phases. See the NIST SP 800-115 framework page.
OWASP Web Security Testing Guide v4.2 and OWASP API Security Top 10.
OWASP Application Security Verification Standard (ASVS) for application verification depth.
OWASP Mobile Application Security Testing Guide (MASTG) where mobile is in scope.
CREST Defensible Penetration Test specification and CREST CHECK / OVS / STAR scheme documentation. See the CREST penetration testing framework page for accreditation context.
This template is provided as a starting point for a penetration testing proposal. It is not legal advice or procurement advice. Have the final proposal reviewed by a delivery lead, a commercial lead, and counsel before issuing it to a buyer.