Penetration Test Plan Example for SaaS Startups 2026

A penetration test plan is the written document that turns a pentest engagement into something an auditor, investor, or enterprise customer will actually accept as evidence. This guide walks through a complete penetration test plan example for a SaaS startup raising Series A, using the same template Cybersecify uses at kickoff for engagements in India, Australia, the EU, the UK, and Hong Kong. The 10 sections cover scope, methodology (PTES plus OWASP WSTG v5.0 plus OWASP API Security Top 10 plus NIST SP 800-115), timeline, evidence collection, deliverables, retest, and sign off. The worked example is a hypothetical 50 person AI first SaaS startup with one web app, one REST API, and a Stripe checkout integration, priced against the Cybersecify Startup Pentest at INR 74,999 and Growth Pentest at INR 1,79,999. For the deliverable format the plan eventually produces, see the Cybersecify SOC 2 plus ISO 27001 ready pentest report sample.

Key findings

• A pentest plan is the contract that decides whether the eventual report counts as evidence. Investor diligence, SOC 2 and ISO 27001 auditors, and enterprise customer security questionnaires increasingly ask for the plan alongside the report.
• 10 sections cover what a SaaS startup pentest plan needs in 2026. Scope, tester credentials, methodology, timeline, evidence collection, communication cadence, deliverables, retest, sign off, and risk and authorization.
• Four frameworks the plan should reference by name and version. PTES (seven phase model), OWASP WSTG v5.0 (web app test cases), OWASP API Security Top 10 2023 (API test cases), NIST SP 800-115 (engagement and reporting structure recognized by US auditors).
• Cybersecify pentest plans bundle into the engagement price. Startup Pentest INR 74,999 and Growth Pentest INR 1,79,999 both include the kickoff plan, with the Growth plan adding explicit SOC 2 Trust Services Criteria and ISO 27001 Annex A control mapping per finding plus a Letter of Attestation.
• The single most common pentest plan failure mode is scope drift between RFP, SOW, and plan. If the plan tests something different from what the RFP specified, the report is rejected by the auditor or investor downstream regardless of finding quality.
• One free retest within 30 days is the right model. Retests billed at 25 to 50 percent of engagement fee create an incentive to leave findings open. Both Cybersecify plans include one free retest.
• Founders can produce a draft plan in 60 to 90 minutes using a structured template. The vendor lead tester refines during a 45 to 60 minute kickoff. Total elapsed time from draft to signed plan: 24 to 48 hours.

Cybersecify is a founder-led penetration testing firm based in Bengaluru, India, serving AI-first and API-first SaaS startups. We currently deliver pentest engagements to startups in India, Australia, the EU, the UK, and Hong Kong, with founder-led delivery, USD/EUR/INR billing, and report formats accepted by SOC 2 and ISO 27001 auditors across jurisdictions. The pentest plan template below comes from real Series A and Series B SaaS engagement kickoffs in 2026, refined against auditor and investor feedback on what the eventual report consumer expects to see documented upstream. For the deliverable format the plan produces, see our pentest report sample. For the upstream filter that drives the plan, see our pentest RFP template.

Reading this from outside India? The methodology framework references (PTES, OWASP WSTG v5.0, OWASP API Security Top 10, NIST SP 800-115) are global and apply identically across jurisdictions. Sections 6 (compliance mapping) and 10 (risk and authorization) carry India-specific notes; substitute GDPR / UK DPA / Australian Privacy Principles / CCPA as relevant. Pricing references stay in INR with USD or EUR billing available on request.

International buyers: USD / GBP / EUR / SGD / AUD / HKD equivalents

Our INR pricing converts approximately as follows (rates as of 2026-06-24):

Plan	INR	USD	GBP	EUR	SGD	AUD	HKD
Startup Pentest	74,999	~900	~700	~830	~1,160	~1,330	~6,820
Growth Pentest	1,79,999	~2,150	~1,700	~2,000	~2,800	~3,200	~16,360
Security Retainer (per month)	24,999	~300	~230	~280	~385	~440	~2,275

Approximate conversions calculated 2026-06-24 (1 USD ≈ ₹84, 1 GBP ≈ ₹107, 1 EUR ≈ ₹90, 1 SGD ≈ ₹65, 1 AUD ≈ ₹57, 1 HKD ≈ ₹11). We invoice in INR per Indian regulation; international clients pay via wire transfer at the prevailing FX rate at time of invoice. GST does not apply on export of services from India (zero-rated).

Why a SaaS startup actually needs a written pentest plan

Three buyer triggers drive the need for a written plan, and a fourth confirms it. The first three match the buyer trigger framework Cybersecify uses on every pentest engagement (compliance, investor diligence, enterprise customer onboarding). The fourth is what happens when the plan is missing.

Investor diligence. Series A and Series B investors in 2026 increasingly ask for the pentest report AND the pentest plan as part of technical diligence. The investor or their hired technical reviewer wants to confirm that what was tested matches the production stack they are funding. A report without a plan signals scope ambiguity. The investor cannot tell whether the auth bypass finding came from testing the production app or a stale staging instance. Plans answer that question upfront.

SOC 2 and ISO 27001 audit evidence. SOC 2 Type 2 auditors evaluate pentest reports as evidence for Trust Services Criteria CC7.1 (vulnerability detection) and CC7.2 (anomaly monitoring). The auditor needs to see the plan to confirm that scope, methodology, and tester qualifications meet the framework expectations. A report without a plan typically triggers an auditor follow up requesting the scope statement and methodology, which delays the audit by 1 to 3 weeks. ISO 27001:2022 Annex A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance) have similar plan documentation expectations. See the SOC 2 pentest requirements walkthrough for what auditors specifically check at audit time.

Enterprise customer security questionnaire. Enterprise security teams (especially in BFSI, healthcare, and Fortune 500 procurement) ask for the pentest plan as a separate attachment alongside the report. Vanta, Drata, OneTrust, and custom security questionnaires increasingly have a Penetration Testing Plan upload field separate from the report upload. Founders who only have the report end up writing a retroactive plan to fill the field, which signals to the security reviewer that testing was unstructured.

The fourth trigger is what happens when there is no plan. Scope drifts during the engagement (vendor tests the wrong asset, founder asks for an out of scope test, methodology shifts from manual to scanner mid week), and the report becomes hard to defend at audit, investor, or customer review. The plan is the upstream artifact that prevents the downstream dispute.

The penetration test plan example walkthrough (10 sections)

The plan structure below is what Cybersecify ships at kickoff for Startup Pentest (INR 74,999) and Growth Pentest (INR 1,79,999) engagements. Section 1 through Section 10 cover the full plan. Each section opens with the question the section answers, then the structured content, then a worked example for our hypothetical 50 person AI first SaaS startup raising Series A.

The worked example uses a hypothetical company called Acme AI Labs (Series A SaaS, 50 employees, INR 8 crore ARR, one React web app at app.acmeai.example, one customer facing REST API at api.acmeai.example, Stripe checkout integration). The example is anonymized; numbers and names are illustrative. Real engagement plans replace these placeholders with actual customer specifics under NDA.

Section 1: Scope statement

The scope section answers: which production assets are being tested, which user roles are included, what is explicitly out of scope, and which test environment is used.

What to include in this section:

• Asset list. Every production URL, REST or GraphQL endpoint, mobile app bundle, admin console, and third-party integration in scope. Mark internal versus external surfaces explicitly.
• User roles tested. Anonymous, regular user, admin, super-admin, tenant isolated user. Each role catches a different class of findings.
• Out of scope explicitly. Third party services (Stripe, Twilio, AWS console), DDoS testing, social engineering, physical access, anything else the founder wants excluded.
• Test environment. Production with rate limited credentials, staging with production like data, or a dedicated test instance. Each has tradeoffs.
• Data classes in scope. PII, payment data, healthcare data, business logic data. DPDP Act 2023 reasonable safeguards apply if PII is processed during testing.

Worked example for Acme AI Labs:

Scope (1 web app, 1 API, 2 scopes total):

• In scope: https://app.acmeai.example (production web app, all customer facing routes, admin console at /admin); https://api.acmeai.example (production REST API, all v1 endpoints).
• User roles tested: anonymous, regular user (free tier), regular user (paid tier), workspace admin, super admin.
• Out of scope: Stripe checkout (payment flow tested at the Acme integration boundary only, not Stripe infrastructure), Twilio SMS gateway, AWS console and IAM (separate cloud scope, not contracted), DDoS or volumetric testing, social engineering of employees, physical access.
• Test environment: production with rate limited credentials provided by Acme founder for each role; staging not used (production assets in scope per founder request).
• Data classes: PII (customer name, email, workspace metadata), no payment data in scope.

This is 2 scopes in Cybersecify pricing terms. Pricing reference: Growth Pentest at INR 1,79,999 covers 2 scopes in the base price. For deeper guidance on scope sizing, see how to scope your first pentest.

Section 2: Tester credentials block

The credentials section answers: who is testing, what are their qualifications, and is there founder involvement on the engagement.

What to include:

• Lead tester named. Full name plus role at the vendor firm.
• Certifications. OSCP, OSWE, CREST CRT, CompTIA PenTest+, or equivalent. Generic claims like senior tester without certs are a quality red flag.
• Years of relevant experience. Years doing pentest specifically, not general security or IT.
• Founder involvement statement. Does a vendor founder participate in the engagement, or is the engagement delegated to a junior team member.
• Tester sign off authority. Who at the vendor signs the technical report and the Letter of Attestation.

Worked example:

Tester credentials:

• Lead tester: Rathnakara GN, Co-founder and CHO, Cybersecify.
• Certifications: OSCP (Offensive Security Certified Professional), CompTIA PenTest+, M.Sc. Cyber Security.
• Years pentest experience: 9 years (including 4 years founder led at Cybersecify, prior 5 years in SaaS and BFSI engagement delivery).
• Founder involvement: lead tester is co-founder; both founders participate on every engagement. Co-founder Ashok S Kamat supports on triage, scoping, and compliance mapping.
• Sign off authority: Rathnakara GN signs the technical report and the Letter of Attestation as Lead Pen Tester (OSCP).

The founder led test confirmation matters because the SOC 2 auditor and the investor diligence reviewer both look for tester continuity from kickoff to retest. Bait and switch (named senior tester on the plan, junior tester actually delivers) is the most common vendor failure pattern in Indian SaaS pentest engagements.

Section 3: Methodology reference

The methodology section answers: which published frameworks does the engagement follow, by version, and which test cases apply per scope.

What to reference:

• PTES (Penetration Testing Execution Standard). The seven phase engagement model: pre engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation, and reporting.
• OWASP WSTG v5.0 (Web Security Testing Guide). Per category test cases for web application scope: configuration and deployment, identity management, authentication, authorization, session management, input validation, error handling, weak cryptography, business logic, client side, API testing.
• OWASP API Security Top 10 (2023 edition). Per category test cases for API scope: BOLA, broken authentication, broken object property level authorization, unrestricted resource consumption, BFLA, SSRF, security misconfiguration, lack of protection from automated threats, improper inventory management, unsafe consumption of APIs.
• NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment). Engagement structure and reporting format recognized by US based auditors and US enterprise security teams.

For business logic depth specifically, see OWASP Top 10 versus business logic pentest. For API specific methodology depth, see API pentest methodology for REST, GraphQL, and webhooks.

Worked example:

Methodology:

• Engagement structure: PTES seven phase model.
• Web app scope (app.acmeai.example): OWASP WSTG v5.0, all 11 categories applicable to React SaaS web apps.
• API scope (api.acmeai.example): OWASP API Security Top 10 (2023), all 10 categories applicable; supplemented by REST specific test cases per OWASP WSTG v5.0 API testing category.
• Engagement and reporting structure: NIST SP 800-115 sections 3 (overview of testing techniques), 5 (security testing), and 7 (security assessment results management).
• Manual plus tool assisted testing. Tools used: Burp Suite Professional (proxy, scanner as supplementary), custom scripts per engagement. No tool only output; every finding is manually verified before inclusion in the report.

Section 4: Timeline and milestones

The timeline section answers: when does each engagement phase happen, when does the founder need to be available, and when is the report due.

What to include:

• Kickoff date. Date the engagement formally starts.
• Testing window. Calendar days for testing phases. Day by day breakdown is not required, but week 1 versus week 2 emphasis helps.
• Mid engagement check in. Day for vendor to update founder on findings so far, scope clarifications, and any environment access issues.
• Draft report delivery. Date the draft technical report and executive summary are delivered for founder review.
• Draft review meeting. 45 to 60 minute meeting for founder and vendor to walk through the draft, agree on severity ratings, and confirm reproduction.
• Final report delivery. Date the final report is delivered.
• Retest window. Number of calendar days post final report during which retest can be scheduled at no extra cost.

Worked example:

Timeline (Cybersecify Growth Pentest, 10 calendar days testing):

• Kickoff: Monday 2026-07-07 at 11:00 IST, 60 minutes via Zoom.
• Testing window: 2026-07-08 to 2026-07-17 (10 calendar days).
• Mid engagement check in: Friday 2026-07-11 at 16:00 IST, 30 minutes.
• Draft report delivery: 2026-07-20 (3 days post testing).
• Draft review meeting: 2026-07-22 at 11:00 IST, 60 minutes.
• Final report delivery: 2026-07-24.
• Retest window: 2026-07-24 to 2026-08-23 (30 calendar days). Retest scheduled within window at founder request.

For typical engagement timelines per scope size, see VAPT for SaaS startups in India and when to re pentest your SaaS app.

Section 5: Evidence collection plan

The evidence section answers: what format does evidence take, where does it get stored during the engagement, and how does it transfer to the founder at delivery.

What to include:

• Evidence format per finding. Screenshots (PNG), request and response captures (HAR or raw HTTP), video PoC (MP4) for chained Critical or High findings, code snippets where remediation requires fix at the source level.
• Evidence storage during engagement. Local encrypted disk on the tester laptop, no cloud sync during testing. Some engagements use a dedicated client side bucket; specify per engagement.
• Evidence transfer at delivery. Final report delivered via encrypted email or secure share (Google Drive customer owned folder, AWS S3 customer bucket, encrypted ZIP via WhatsApp Business). Founder choice at kickoff.
• Evidence retention post engagement. Vendor retains evidence for 12 months post final report delivery for retest support, then purges. Customer can request earlier purge in writing.
• Chain of custody for sensitive evidence. PII screenshots are redacted before inclusion in the report. Raw evidence with PII is purged at engagement end unless customer requests retention for legal hold.

Worked example:

Evidence collection:

• Per finding: 2 to 5 screenshots (PNG), full HAR capture, raw HTTP request and response for the vulnerable endpoint. Critical and High chained findings include a 30 to 90 second MP4 video PoC.
• Storage during engagement: tester local encrypted FileVault disk (macOS); no cloud sync.
• Transfer at delivery: final report and supporting evidence delivered via Google Drive folder owned by Acme; access revoked 14 days post delivery confirmation.
• Retention: 12 months for retest support; purged 2027-07-24.
• PII redaction: customer names and emails in screenshots redacted to user_id and email_hash before inclusion in report.

Section 6: Compliance mapping

The compliance section answers: which frameworks does the report support evidence for, and at what depth.

For SaaS startups in India, the typical compliance hook stack is SOC 2 plus ISO 27001 plus DPDP Act, with sector specific layers (RBI, IRDAI, SEBI) added per industry. International engagements substitute GDPR, UK DPA, Australian Privacy Principles, or CCPA per buyer geography.

What to specify:

• Framework and version. SOC 2 Trust Services Criteria 2017, ISO 27001:2022, DPDP Act 2023, GDPR (EU) 2016, UK Data Protection Act 2018, CCPA or CPRA, Australian Privacy Principles.
• Controls touched. Per framework, list the specific controls the pentest provides evidence for.
• Mapping depth in the deliverable. Per finding mapping versus appendix only mapping versus no mapping. Per finding mapping (Cybersecify Growth Pentest standard) is the format auditors prefer.
• Letter of Attestation. Standard with Cybersecify Growth Pentest; references ISO 27001:2022 Annex A.8.8 plus A.8.29 plus Clause 9.1 plus 10.2.

Worked example:

Compliance mapping:

• SOC 2 Trust Services Criteria 2017: CC6.1, CC6.3, CC6.6, CC7.1, CC7.2, CC8.1 mapped per finding.
• ISO 27001:2022: Annex A.5.7, A.8.8, A.8.29, A.8.30, Clause 9.1, Clause 10.2 mapped per finding.
• DPDP Act 2023: Section 8(5) reasonable security safeguards documentation provided as appendix.
• Letter of Attestation: included, signed by Rathnakara GN as Lead Pen Tester (OSCP), references ISO 27001:2022 Annex A.8.8, A.8.29, Clause 9.1, Clause 10.2.

For deeper guidance on which compliance framework comes first for a SaaS startup, see SOC 2, ISO 27001, DPDP: which compliance first and DPDP Act pentest requirements for India SaaS.

Section 7: Communication cadence

The cadence section answers: how often does the vendor update the founder, what is the immediate escalation path for Critical findings, and who attends each touchpoint.

What to include:

• Daily async update. Brief Slack or email update at end of testing day, listing what was tested, what was found, and what is queued for the next day.
• Immediate escalation path for Critical. WhatsApp or phone call to founder within 2 hours of Critical finding discovery. Critical findings are not held until the report; the founder needs to know immediately to start incident assessment.
• Mid engagement check in. 30 minute call mid testing for founder to clarify scope edges, raise concerns, or surface environment access issues.
• Draft review meeting. 45 to 60 minute meeting post draft delivery to walk through findings, agree on severity, and confirm reproduction.
• Post engagement retest scheduling. Founder initiated, vendor confirms availability within 2 business days, retest typically completes within 5 business days of scheduling.

Worked example:

Communication cadence:

• Daily async: Slack channel #cybersecify-acme; end of testing day update (1 to 3 lines).
• Critical escalation: WhatsApp to Acme founder within 2 hours of discovery; phone fallback.
• Mid engagement check in: Friday 2026-07-11 at 16:00 IST, 30 minutes via Zoom, founder plus head of engineering plus Rathnakara plus Ashok.
• Draft review meeting: 2026-07-22 at 11:00 IST, 60 minutes via Zoom.
• Retest scheduling: Acme initiates via Slack or email; Cybersecify confirms within 2 business days.

Section 8: Deliverables

The deliverables section answers: what artifacts does the founder receive at engagement end, in what format, and which are addressable to which downstream consumer.

What to include:

• Technical report. Per finding detail: title, severity, CVSS v3.1 score, description, business impact, reproduction steps, remediation guidance, framework mapping (where mapped per finding).
• Executive summary. 2 to 4 page narrative summary for non technical readers (founder, board, investor). Includes engagement scope, methodology summary, finding counts by severity, top risks, and remediation roadmap.
• Framework mapping appendix. If not mapped per finding, the appendix consolidates SOC 2 and ISO 27001 control mapping.
• Letter of Attestation. Growth Pentest standard. References ISO 27001:2022 controls.
• Retest report. Separate document or appended status block after retest; format specified in the plan.
• Raw evidence package. Screenshots, HAR captures, video PoCs, delivered via secure share.

Worked example:

Deliverables:

• Technical report (PDF, approximately 40 to 60 pages depending on finding count): per finding detail with SOC 2 and ISO 27001 control mapping inline.
• Executive summary (PDF, 3 pages): scope, methodology, findings by severity, top 3 risks, remediation roadmap.
• Letter of Attestation (PDF, 1 page): signed by Rathnakara GN, references ISO 27001:2022 Annex A.8.8 plus A.8.29 plus Clause 9.1 plus 10.2.
• Retest report (PDF, 10 to 15 pages): status per finding post retest, signed off by Rathnakara GN.
• Raw evidence package: ZIP delivered via Google Drive, password protected.

For what a good pentest report looks like in detail, see how to read a VAPT report and what a good pentest report looks like.

Section 9: Retest plan

The retest section answers: when does retest happen, what is in scope for retest, and what is the retest deliverable.

What to include:

• Retest window. Calendar days post final report delivery (Cybersecify standard: 30 days).
• Retest scope. Which severity tiers are retested in the included fee (Cybersecify standard: Critical plus High; Medium and Low on request).
• Retest depth. Full re exploitation attempt versus configuration check (Cybersecify standard: full re exploitation, audit acceptable).
• Retest evidence. Same format as initial testing.
• Retest deliverable. Separate retest report or appended status (Cybersecify standard: separate retest report PDF).
• Re engagement after retest window. If retest is not scheduled within the 30 day window, retest is billed at a fixed re engagement fee (specify at kickoff).

Worked example:

Retest:

• Window: 30 calendar days post final report delivery (2026-07-24 to 2026-08-23).
• Scope: all Critical and High findings, plus any Medium that Acme specifically requests at retest scheduling.
• Depth: full re exploitation attempt, same methodology as initial testing.
• Evidence: same format as initial (screenshots, HAR, video PoC for chained re tested findings).
• Deliverable: separate retest report (PDF, approximately 10 to 15 pages), signed by Rathnakara GN.
• Post window re engagement: if retest not scheduled within 30 days, retest billed at INR 24,999 (single retest session, 1 day effort).

Section 10: Sign off and risk authorization

The sign off section answers: who authorizes testing, who signs off on findings, and what legal framework governs the engagement.

What to include:

• Authorization to test. Founder or designated security owner signs the plan, providing written authorization for the named scope and the named tester. Without authorization, testing is unauthorized access under the IT Act 2000 (India) or equivalent jurisdiction (US Computer Fraud and Abuse Act, UK Computer Misuse Act 1990, EU member state cybercrime statutes).
• Sign off on findings. Head of engineering or CTO signs off on findings post draft review meeting, confirming each finding is reproducible in the founder environment and acknowledging the severity rating.
• Sign off on retest closure. Founder signs off on retest report acknowledging the closure status of each retested finding.
• Governing law. Indian Contract Act 1872 for India engagements. International engagements per master service agreement (typically founder home jurisdiction).
• Liability and remedy. Per Cybersecify master service agreement: liability cap at invoice value paid, refund as maximum remedy, disclaimer that pentest is best effort snapshot in time of the tested scope at the testing window.

Worked example:

Sign off and authorization:

• Plan and authorization to test: signed by Acme founder (CEO) 2026-07-04 (3 days before kickoff).
• Plan signed by vendor lead tester: Rathnakara GN 2026-07-04.
• Sign off on findings: Acme head of engineering signs off post draft review meeting (2026-07-22), confirming reproduction and severity acknowledgment.
• Sign off on retest: Acme founder signs off on retest report post retest delivery.
• Governing law: Indian Contract Act 1872; jurisdiction Bengaluru courts.
• Liability and remedy: per Cybersecify MSA, liability capped at invoice value paid, refund as maximum remedy, pentest delivered as best effort snapshot in time of tested scope.

For founders comparing this engagement structure against alternative vendor options, see 5 questions to ask a pentest vendor before signing and how to evaluate a pentesting firm.

The full Acme AI Labs penetration test plan example: summary

Putting the 10 sections together for our hypothetical Series A SaaS startup, the plan reads as one cohesive document of approximately 4 to 6 pages. Cybersecify ships this plan 48 hours before kickoff for founder review, refines it during the 60 minute kickoff call, and counter signs at kickoff end. The plan then governs the engagement from Day 1 of testing through retest closure 30 days after final report delivery.

For Acme AI Labs (2 scopes, Series A, SOC 2 plus ISO 27001 audit prep needed, investor diligence pending Q3 2026), the right Cybersecify engagement is the Growth Pentest at INR 1,79,999. This price covers the 10 calendar day testing window, both scopes (web app plus API), all 10 plan sections, technical and executive reports with per finding compliance mapping, Letter of Attestation, one free retest within 30 days, and 12 hours of bundled founder led consulting hours useable 12 months from kickoff.

For a pre Series A SaaS startup with one scope and no audit deadline, the Cybersecify Startup Pentest at INR 74,999 covers the same 10 plan sections, one scope, 7 calendar day testing window, technical and executive reports without per finding compliance mapping (the report itself is still SOC 2 and ISO 27001 acceptable; mapping is the value differentiator on Growth), one free retest within 30 days, and 6 hours of bundled consulting hours useable 6 months from kickoff.

Common pentest plan failure modes (and how this template prevents them)

Five failure modes account for the vast majority of disputed pentest engagements Cybersecify has seen in 2026 inbound. Each failure mode is addressed by a specific section of the plan template above.

Failure 1: scope drift mid engagement. Vendor starts testing the agreed scope, founder asks to add a third asset mid week, vendor stretches the original budget to cover it, both surfaces get shallow testing, neither is audit acceptable. Prevented by Section 1 (explicit scope statement) plus Section 4 (timeline that does not flex without re scoping). If additional scope is needed, the right path is a Section 1 amendment and a Section 4 timeline extension, not silent in flight scope creep.

Failure 2: tester swap mid engagement. Senior tester named in the plan does kickoff, then a junior tester actually executes the engagement. Report quality drops; founder discovers at draft review. Prevented by Section 2 (named lead tester with sign off authority on the technical report and Letter of Attestation). Bait and switch becomes a contractual breach, not an undocumented vendor behavior.

Failure 3: methodology slide from manual to scanner. Vendor starts with manual testing as agreed, finds nothing in 2 days, falls back to running a Burp scanner, delivers the scanner output as the report. Auditor or enterprise customer rejects. Prevented by Section 3 (named frameworks plus the explicit no tool only output statement) plus Section 5 (evidence format that requires per finding manual verification artifacts beyond a scanner export).

Failure 4: retest disputed at audit time. Audit deadline arrives; founder schedules retest; vendor says retest is out of contract or bills for it. Auditor flags open findings. Prevented by Section 9 (retest window, scope, depth, evidence, deliverable, and post window re engagement fee all specified upfront).

Failure 5: report delivered, audit deferred, no plan to defend at audit. Engagement completes, founder files the report, 4 months later the auditor asks for the plan, founder has none, vendor has moved on. Prevented by Section 10 (signed plan stored with the report as a permanent record of the engagement contract).

Pentest plan example: India versus international substitution table

The plan template above is built for Indian SaaS startup engagements. International engagements use the same template with these substitutions in Sections 6 and 10.

Plan section	India default	International substitution
Compliance: privacy law (Section 6)	DPDP Act 2023, Section 8(5) reasonable safeguards	GDPR Article 32 (EU), UK Data Protection Act 2018, CCPA / CPRA (US), Australian Privacy Principles
Compliance: sector law (Section 6, if applicable)	RBI cybersecurity directives, IRDAI, SEBI, CERT-In	PSD2 (EU fintech), FCA Operational Resilience (UK fintech), APRA CPS 234 (AU fintech), MAS TRM (Singapore fintech), HKMA TM-E-1 (Hong Kong fintech)
Currency in pricing reference	INR with 18 percent GST	USD or EUR; GST does not apply on export of services from India (zero rated)
Governing law (Section 10)	Indian Contract Act 1872; Bengaluru jurisdiction	Per master service agreement; typically founder home jurisdiction
Authorization legal framework (Section 10)	IT Act 2000 unauthorized access definition	US Computer Fraud and Abuse Act, UK Computer Misuse Act 1990, EU member state cybercrime statutes

The methodology references (PTES, OWASP WSTG v5.0, OWASP API Security Top 10, NIST SP 800-115), tester credentials block (Section 2), evidence collection (Section 5), timeline (Section 4), and sign off chain structure (Section 10) stay identical across jurisdictions. Cybersecify currently delivers engagements with this same plan structure to startups in India, Australia, the EU, the UK, and Hong Kong.

How to use this pentest plan example

Three paths depending on where the founder is in the buying cycle.

Path 1: founder evaluating vendors, has not selected one yet. Use the Cybersecify pentest RFP template as the upstream filter. Score 2 to 3 vendors against the 12 RFP sections, shortlist based on responses, request a sample plan from each shortlisted vendor. Compare the sample plans against the 10 sections in this article; the vendor whose plan most closely mirrors this structure (or whose deviations the founder understands and accepts) is the right pick.

Path 2: founder has selected a vendor, kickoff in next 7 to 14 days. Send this article to the vendor lead tester as the plan structure expected at kickoff. If the vendor cannot produce a plan that covers all 10 sections, that is a quality signal worth raising before the engagement starts. The vendor should be able to walk all 10 sections in the kickoff call and produce a signed plan within 24 to 48 hours.

Path 3: founder evaluating Cybersecify directly. The plan template above is what we ship at kickoff for both Startup Pentest (INR 74,999) and Growth Pentest (INR 1,79,999). The plan is sent for founder review 48 hours before kickoff, refined during the 60 minute kickoff call, and counter signed at kickoff end. To see the deliverable format the plan produces, review the Cybersecify SOC 2 plus ISO 27001 ready pentest report sample. To compare against the broader Indian pentest market, see pentest cost in India 2026. To book a 30 minute scoping call with both founders, the Cybersecify pricing page has direct links into the Book a Call flow.

What is next

For Series A or Series B SaaS founders with an audit deadline, investor diligence, or enterprise customer security questionnaire pending, the right next step is a 30 minute founder led scoping call. The call confirms scope, walks the plan structure, and produces a signed plan within 24 to 48 hours. For founders pre evaluating vendors, the pentest RFP template is the upstream filter and this article is the plan structure that flows from a clean RFP into a clean engagement.

The plan is the contract. The report is the artifact the auditor reads. The plan is what makes the report defensible.