How to Scope a VAPT Engagement: An RFP Guide for India

A good VAPT scope answers three questions before a single test begins: what assets are in play, how deep should testing go (black, grey, or white box), and what rules govern the testers while they work. Get these three right in your RFP and the resulting report will be actionable; get them wrong and you will pay for a document that tells you nothing you can act on. This guide walks through building that scope, asset by asset, so you can write an RFP that vendors can quote against accurately and that produces a report your engineering team can actually fix.

Why Scoping Fails Before Testing Even Starts

Most Indian VAPT engagements go sideways at the RFP stage, not during testing. A vague scope like "test our web application" invites wildly different quotes because one vendor assumes a 3-day automated scan and another assumes two weeks of manual exploitation. Neither is wrong — the RFP just didn't specify. The result is apples-to-oranges bids, a testing window that either finishes too fast to be credible or drags past your compliance deadline, and a report that doesn't map cleanly to what your board or auditor actually needed to see.

Step 1: Build the Asset Inventory First

Before you write a single line of the RFP, build a complete asset inventory. This is the single highest-leverage step in the whole process, because everything else — timeline, cost, testing methodology — is a function of what's actually in scope.

Your inventory should separate assets into categories, each of which typically requires a different testing approach:

1. Web applications — every subdomain, staging environment, and admin panel, not just the production marketing site
2. APIs — REST/GraphQL endpoints, internal microservices, third-party integrations that touch customer data
3. Cloud infrastructure — AWS/Azure/GCP accounts, IAM configurations, storage buckets, serverless functions
4. Network — internal segments, VPN gateways, exposed ports, on-prem servers if you still run any
5. Mobile applications — Android and iOS builds, including any hybrid/webview components
6. Third-party and vendor connections — payment gateways, CRM integrations, SSO providers

Step 2: Choose Your Testing Depth — Black, Grey, or White Box

This decision drives cost, duration, and what kind of vulnerabilities the engagement will actually surface. There's no universally "best" choice — it depends on what you're trying to validate.

Step 3: Define Rules of Engagement Before Signing

The Rules of Engagement (RoE) document is what protects both you and the tester. It should be finalized and signed before testing starts, not drafted after the fact. At minimum, your RFP should require the vendor to produce an RoE covering:

1. Testing window — exact start/end dates and, for production systems, permitted hours (many Indian companies restrict live testing to off-peak windows to avoid customer impact)
2. Explicit exclusions — systems, endpoints, or test types (e.g., no denial-of-service testing) that are off-limits
3. Emergency contact and stop conditions — who the tester calls immediately if they find something actively exploited by someone else, or if a test causes unexpected service degradation
4. Data handling — how the vendor stores, encrypts, and eventually destroys any customer data or credentials they access during testing
5. Legal authorization — a signed letter of authorization is not optional; testing without one exposes both parties to liability under the IT Act, 2000, and falls outside the reporting and coordination guidance CERT-In publishes for security incidents

Step 4: Specify Deliverable Quality in the RFP, Not After

This is where most Indian RFPs are weakest — they specify testing scope in detail but leave the deliverable vague, which means you only discover the report is inadequate after you've already paid for it. Your RFP should explicitly require the report to contain:

1. Executive summary written for non-technical stakeholders (board, auditors) — risk posture in plain language, not just a vulnerability count
2. Technical findings, each with a CVSS score, clear reproduction steps, affected asset, and business impact statement
3. Evidence — screenshots, request/response captures, or proof-of-concept code for every finding, not just a one-line description
4. Remediation guidance specific to your stack, not generic "apply patches" boilerplate
5. A mapping to compliance frameworks you care about (ISO 27001, SOC 2, DPDP) if the engagement is compliance-driven
6. A retest of every finding once fixes are deployed, with written confirmation of closure

Step 5: Negotiate Retest Rights Up Front

A VAPT report without a retest is an incomplete engagement — you've paid to find vulnerabilities, not to confirm they're fixed. Your RFP should require the vendor to include at least one retest cycle within a defined window (commonly 30-90 days) after the initial report, covering every finding your team has remediated. Without this written into scope, "retest" quietly becomes a separate, renegotiated ask later — often with a scheduling delay that pushes your compliance deadline.

Bringing It Together: The Scoping Workflow

Where does testing effort typically go once scope is set? For a company with a standard web-plus-API-plus-cloud footprint, allocation qualitatively skews toward the assets with the largest and most dynamic attack surface — web and API — followed by cloud misconfiguration review, with network and mobile taking a smaller share unless those are the primary product surface.

Common RFP Mistakes to Avoid

A few patterns show up repeatedly in Indian VAPT RFPs that weaken the resulting engagement:

1. Scoping by tool count instead of asset count. "We want an automated scan" tells a vendor nothing about coverage depth — specify assets and testing depth, not tooling.
2. Omitting staging and pre-production environments. These often carry weaker controls than production and are a common source of credential leakage.
3. No named point of contact for the testing window. If your engineering lead is unreachable during an active test, a genuine finding (like a live exploit by a third party) can go unactioned for hours.
4. Treating the RFP as a one-time document. Asset inventories change — a scope written for last year's architecture will miss this year's new microservices.

Frequently Confused: VAPT Scope vs Compliance Audit Scope

A VAPT engagement and a compliance audit (ISO 27001 certification, SOC 2, or a DPDP readiness review) are not the same exercise, though they overlap. A compliance audit checks whether your documented controls and processes exist and are followed. A VAPT engagement actively tries to break those controls. Many Indian companies scope a VAPT expecting it to double as compliance evidence — which is reasonable, but only if the RFP explicitly requires the report to map findings to the relevant framework's control clauses. Don't assume this mapping happens automatically; write it into the deliverable requirements.

For organisations building toward DPDP Act compliance specifically, VAPT findings around access control, encryption at rest, and data minimisation feed directly into your compliance posture — see DPDP compliance guidance for how these map together.

Bachao.AI runs automated and manual VAPT engagements for Indian companies, scoped exactly along the asset-inventory and testing-depth model in this guide, delivered with a CERT-In empanelled partner where empanelled sign-off is required. Dhisattva AI Pvt Ltd built the platform specifically to remove the ambiguity that makes RFPs hard to compare across vendors.

If your last VAPT report was a PDF with no reproduction steps or retest clause, that's a scoping problem, not a testing problem — fix it at the RFP stage next time. You can start with a free VAPT scan to see what an asset-mapped baseline looks like before you write your next RFP, or browse more scoping and compliance guides on the blog.