How to write a VAPT RFQ / scope brief (India SaaS)
A paste-ready checklist for Indian SaaS and product teams scoping vulnerability assessment and penetration testing. Clear assets, environments, roles, rules of engagement and deliverables — so vendor quotes are comparable and useful.
Why a written scope brief beats a one-line RFQ
Many India SaaS RFQs still say little more than “need VAPT for our application ASAP.” Vendors then invent assumptions — which environments, which roles, whether APIs and admin panels are in scope, whether cloud configuration is included — and quotes become incomparable. A short, precise scope brief reduces rework, surprises on kickoff calls, and reports that miss the assets your customers and auditors care about.
This guide is for buyers (founders, engineering leads, security owners, procurement). It is not a legal tender template. Use counsel for regulated contracts. For pricing context see our penetration testing cost in India guide; for empanelment questions see Do you need CERT-In empanelled VAPT?.
Decide the purpose before you write the RFQ
State the primary reason for testing in one sentence. Typical India SaaS drivers:
- Customer security questionnaire or enterprise sales cycle
- SOC 2 / ISO 27001 evidence (confirm with your auditor what they expect — see also our companion note on VAPT for SOC 2 / ISO)
- Pre-release risk reduction for a major product change
- Contractual or regulator-linked requirement that may cite CERT-In empanelment
If a written contract or tender explicitly requires a CERT-In empanelled organisation, verify vendors on the official list: Empanel_org.pdf. PocForge does not claim CERT-In empanelment. If you do not need that checkbox, evaluate methodology, reporting and retest — not badges alone.
Paste-ready RFQ / scope brief checklist
Copy the sections below into your email or RFP. Fill the bracketed fields. Delete items that do not apply.
1. Organisation and contacts
- Legal entity name and billing entity (if different)
- Primary technical contact (name/role/email) and escalation contact
- Preferred engagement window and hard deadlines (sales, audit, release)
- Time zone for testing windows (Asia/Kolkata unless stated)
2. Purpose and success criteria
- Why we are testing: [customer / SOC 2-ISO evidence / release / other]
- What “done” means: validated findings with evidence, prioritised remediation advice, and [one] remediation retest included / not included
- Report audience: engineering only / also customers or auditors (redaction needs)
3. In-scope assets (be concrete)
- Web application URLs / environments: [staging URL], [production — yes/no, constraints]
- APIs: base URLs, OpenAPI/Postman if available, auth scheme (session, JWT, API keys, OAuth)
- Mobile apps: platform (iOS/Android), build delivery method, backend APIs shared with web
- Cloud accounts / projects in scope for configuration review: [AWS/GCP/Azure account IDs — read-only roles]
- External infrastructure: public IP ranges, domains, VPN/edge endpoints
- Active Directory / identity providers if internal network testing is requested
- AI/LLM features if prompt injection, tool abuse or data leakage is a concern
Link canonical service pages when scoping specific work: web, API, mobile, cloud, Active Directory, AI/LLM, external infrastructure.
4. Explicitly out of scope
- Denial-of-service / load testing: [not authorised / limited]
- Social engineering / phishing of staff: [not authorised]
- Physical security: [not authorised]
- Third-party SaaS tenants we do not control: [list]
- Production destructive tests: [forbidden / only with written change window]
5. Environments, data and accounts
- Preferred environment: dedicated staging mirroring production auth and roles
- Test accounts for each major role (e.g. org admin, member, read-only, unauthenticated)
- Multi-tenant expectations: at least two tenant contexts for isolation tests
- PII / production data: use anonymised or synthetic data where possible; state retention rules for evidence
6. Authorisation and rules of engagement
- Written authorisation from someone empowered to approve testing
- Allowed testing hours and blackout periods
- Safe harbour / point of contact for emergency stop
- IP allowlisting needs for scanners or tester egress IPs
- Disclosure policy for critical findings (same-day call vs ticket only)
7. Methodology expectations (ask vendors to confirm)
- Human-led testing of authentication, authorisation and business logic — not scanner-only output
- Manual validation of automated findings; false positives filtered
- Attack-path thinking for multi-step issues (e.g. IDOR + privilege escalation)
- Standards referenced as guidance (OWASP ASVS/Testing Guide, API Top 10) — not as a substitute for judgement
8. Deliverables
- Technical report: executive summary, scope, methodology, findings with severity, evidence, reproduction steps, remediation guidance
- Optional customer-facing summary (sanitised)
- Retest of remediated items within [N] days of fix notification
- Format: PDF; raw evidence retained per agreed period
9. Commercial and logistics
- Fixed-fee preferred for defined scope; change control for scope creep
- GST invoice requirements (India)
- NDA / DPA status
- Ask vendors for indicative ranges aligned to published guides where available — PocForge publishes India ranges on the cost guide and overview on VAPT services India
Scoping tips that improve quote quality
- Prefer staging that behaves like production. Auth, roles, feature flags and payment flows that only exist in prod will be missed or under-tested.
- Name roles, not just “the app”. Authorisation bugs live between roles and tenants.
- Separate “scan the perimeter” from “test the product”. External infrastructure and application VAPT answer different questions; budget both if you need both.
- Do not bury CERT-In as a soft preference. If it is mandatory, say so and verify the PDF. If it is not, say that too so non-empanelled specialists can bid honestly.
- Ask for a sample report structure (redacted), not marketing PDFs alone.
Common RFQ mistakes (India SaaS)
- Requesting “complete VAPT of everything” with no asset list — produces either refusal or padded quotes
- Production-only access with no test tenants — slows testing and raises blast-radius risk
- Confusing vulnerability scanning with penetration testing in the same line item without defining depth
- Omitting retest — then arguing about whether fixes were verified
- Assuming any pentest report automatically satisfies a named regulator or CERT-In direction — keep legal/compliance separate from technical scope
How PocForge uses your brief
Send a filled checklist to contact. We will confirm in-scope assets, flag gaps (for example missing second tenant), and return a fixed-fee proposal where possible. We compete on clear scope, human-led testing and a remediation retest — not on invented rankings or false empanelment claims. More context: penetration testing company India, solutions, case studies, about.
Frequently asked questions
How long should a VAPT RFQ be?
One to three pages is enough for most SaaS scopes if assets, environments, roles, out-of-scope items and deliverables are explicit. Long appendices help only when they add asset inventory, not marketing fluff.
Should we include production?
Many teams test a production-like staging first. If production is required, document change windows, data handling and emergency contacts. Destructive tests should be forbidden unless separately authorised.
Do we need CERT-In empanelment in the RFQ?
Only if a contract, tender or policy requires it. Then verify vendors on the official CERT-In Empanel_org.pdf. Otherwise say empanelment is not mandatory so you get comparable technical bids. See our CERT-In decision guide.
What is the difference between VAPT and a vulnerability scan in an RFQ?
Say which you want. Scanning finds known signatures at scale; penetration testing validates exploitability and business logic. Mixing them without depth requirements leads to mismatched quotes.
How many vendors should we invite?
Two to four capable firms with the same written brief is usually enough. More than that rarely improves quality if the brief is vague.
What should we ask about retesting?
Ask whether one remediation retest is included, within what window, and whether it covers all fixed findings or only critical/high. Put the answer in the SOW.
Can we reuse this brief for SOC 2 evidence?
Yes as a starting point, but add auditor expectations on independence, report contents and period coverage. Confirm with your auditor — a pentest is evidence, not a certificate.
Where do we send a draft for a PocForge quote?
Use the contact page on pocforge.com with your filled checklist. Indicative India pricing is published on the cost guide for planning.
Related PocForge guides
Have a draft RFQ already?
Paste it — we will tell you what is missing before you waste a week of vendor calls.