VAPT vs Red Team in 2026 — The India BFSI Procurement Guide

If you have already read our 'Red team vs penetration testing' explainer, you know the difference. This one is for the procurement officer, the CISO who has to defend the RFP at the next Board IT Committee, and the vendor manager who has to write a scope of work that holds in a regulator inspection. We cover the RFP language, the SLA tiers, the deliverable spec, and the questions to ask vendors — specifically for Indian BFSI buyers.

Why the procurement processes diverge

VAPT procurement is a vendor-management exercise — you are buying a known service, with a known shape, from an empanelled list. Comparison across bidders is straightforward: coverage, methodology, retest commitment, CERT-In certificate timeline, price. Red team procurement is a partnership exercise — you are buying capability with substantial discretion, where the vendor's operator pedigree and opsec discipline matters more than their proposal pretty-print. Treating a red team RFP as a VAPT RFP — lowest-price-technically-compliant — produces a poor outcome.

RFP language — VAPT

A defensible VAPT scope of work for an Indian BFSI buyer should specify, at minimum:

• Asset list — public IP ranges, hostnames, application URLs, mobile app bundle IDs, AD domain(s), cloud account IDs
• Test types — external infra VAPT, internal infra VAPT, web app VAPT (per-app), mobile app VAPT, API VAPT, cloud configuration review, source code review (where applicable)
• Methodology references — OWASP WSTG, OWASP ASVS, MASVS, PTES, NIST SP 800-115; CERT-In empanelled audit methodology
• Reporting standard — CVSS v3.1 or v4.0, CWE mapping, OWASP Top 10 mapping, executive summary + technical findings + remediation guidance
• Retest commitment — full retest within 30-45 days of remediation, included in fee
• CERT-In audit certificate issuance timeline (typically 4 weeks after retest closure)
• Personnel commitment — named lead auditor, minimum CV requirements (OSCP / CEH / CISA / ISO LA)
• Exclusions — DoS, social engineering (unless separately scoped), physical access

RFP language — Red team

A defensible red team scope of work looks completely different — it should focus on objectives, not assets, and on rules of engagement:

• Objectives — specific, measurable, board-approved (e.g. 'gain Domain Admin in production AD without triggering EDR alert'; 'exfiltrate sample of credit card processing data')
• Scope boundaries — which entities, environments, geographies are in/out; explicit safe-listed assets (e.g. trading-day infrastructure during market hours)
• Permitted initial-access vectors — phishing yes/no, vishing yes/no, exposed services yes, physical no, supply-chain compromise no
• Rules of engagement — operator opsec posture, allowed tooling categories, prohibited actions (data destruction, privacy of unrelated customers, named systems)
• Deconfliction — white cell composition, contact tree, abort signal, daily situation report cadence
• Detection budget — how many alerts the vendor is allowed to trigger before blue team is informed (often: zero in stealth phase)
• Deliverables — attack narrative chronological, detection gap report per kill-chain phase, replay artifacts (timestamped indicators), executive readout
• Replay / purple team phase — included or separately scoped; typically 5 working days post-engagement
• Operator pedigree expectations — OSCP/OSEP/CRTO minimum, named operators, references

SLA tiers — what to put in the contract

Deliverable specification — set expectations in the contract

• VAPT report — executive summary (≤3 pages), methodology, scope, findings table (severity, CVSS, CWE, OWASP), per-finding evidence with screenshots + reproduction steps, remediation guidance, retest results, CERT-In audit certificate
• Red team report — executive narrative (≤5 pages), attack chronology mapped to MITRE ATT&CK, per-stage detection gap analysis, indicator-of-compromise list with timestamps, recommended detection content (Sigma / KQL / SPL), remediation roadmap (P0-P3), purple-team replay log
• Both — debrief presentation to CISO + audit committee; raw evidence pack with chain-of-custody

Vendor questionnaire — VAPT

1. Are you on the current CERT-In empanelment list? Provide URL + valid-from / valid-to dates.
2. List the certifications held by the lead auditor (OSCP, OSWE, CEH, ISO LA, CISA).
3. Last 5 comparable engagements in Indian BFSI — sector, scope, anonymised reference.
4. Methodology document — share your audit methodology (OWASP/PTES alignment).
5. Reporting sample — share an anonymised report from a comparable engagement.
6. Retest commitment — is retest included in fee or charged separately?
7. Average time from final report to CERT-In audit certificate?
8. How do you handle out-of-scope discoveries (e.g. customer data exposed in third-party SaaS)?

Vendor questionnaire — Red team

1. Named operators — share CVs for the operators who will be on this engagement. We will Google them.
2. Last 5 comparable red team engagements — sector, objectives achieved, anonymised reference (we will call references).
3. Sample attack narrative from a comparable Indian BFSI engagement (anonymised).
4. What is your opsec posture — payload signing infrastructure, redirector hygiene, beacon C2 platform?
5. Have you run engagements against EDRs we use (CrowdStrike Falcon / Defender for Endpoint / SentinelOne)? Show evidence.
6. Deconfliction process — describe how you would integrate with our white cell and CSITE incident reporting flow.
7. What happens if you trigger a customer-impacting outage during operations?
8. Provide a sample purple-team handover document.

Common procurement pitfalls

Indicative pricing — India BFSI 2026

UAE and cross-border considerations

For BFSI groups with India + UAE presence, run red team objectives across the group (e.g. 'reach the India payment system via the UAE branch network') — this is where adversary simulation pays off. Procurement should ensure the vendor has resident operators in both geographies; remote-only delivery from one side adds 3-4 weeks and reduces opsec quality. DIFC and ADGM regulated firms additionally require any offensive testing to be notified to the regulator; build a 7-business-day notification window into the engagement plan.