Every year, security teams hand auditors a PDF titled "VAPT Report" that turns out to be an automated vulnerability scan with a cover page. The auditor reads it, asks three questions about scope, methodology and retesting, and the conversation becomes uncomfortable. A scan is not a penetration test, and regulators in India's financial and technology sectors increasingly know the difference.

If you are regulated by the RBI or SEBI, supply critical sectors, or must align with CERT-In guidance, a VAPT exercise has to withstand scrutiny. Here is how to make sure yours does.

Vulnerability assessment versus penetration testing

The two terms are often used interchangeably, but they answer different questions.

  • Vulnerability assessment (VA) identifies known weaknesses across systems, usually with automated scanners, and ranks them by severity. It tells you what might be wrong.
  • Penetration testing (PT) has skilled testers actively attempt to exploit weaknesses, chain them together, and demonstrate real impact: access to data, privilege escalation, lateral movement. It tells you what an attacker could actually do.

"VAPT" combines both. A credible report shows evidence of each: scanner output that has been validated and de-duplicated, plus manual testing that went beyond what tools can find. Business logic flaws, broken access control, authorisation bypasses and flawed workflows are typical examples that scanners miss.

What regulators look for

Specific requirements vary by regulator and entity type, and they change over time, so always check the current circulars and directions that apply to you. In general, assessors and inspectors look for the following qualities.

Defined scope tied to risk. Which systems were tested, and why? Internet-facing applications, core banking or trading platforms, APIs, mobile apps, cloud environments, network infrastructure and privileged internal paths all matter. If critical assets are missing from scope without a documented reason, expect questions.

Recognised methodology. Testers should follow established approaches, such as OWASP guidance for web and API testing, NIST SP 800-115, or PTES, and say so in the report. The report should describe what was done, not only what was found.

Independent, competent testers. Many regulated entities are expected to use qualified independent testers. In some contexts, CERT-In empanelled auditors are specified or preferred. Check what your regulator or contract requires before you engage a provider.

Appropriate frequency. Periodic testing, and testing after significant changes, is generally expected. A single test at launch and nothing for three years is a red flag.

Documented remediation and retest. Findings must have owners, deadlines and evidence of closure. A retest that confirms fixes is the proof an auditor wants.

Management oversight. Results and open risks should reach senior management or the board, with decisions about risk acceptance recorded.

Building a compliance-ready VAPT scope

Scoping is where most programmes succeed or fail. A practical approach:

  1. Start from the asset inventory. Rank applications and infrastructure by business criticality and data sensitivity.
  2. Include the full attack surface. Web applications, mobile apps, APIs, external network ranges, wireless, cloud configuration, and relevant internal segments.
  3. Define test types. Black box, grey box (with credentials) or white box. For critical applications, authenticated grey box testing usually finds far more than unauthenticated testing.
  4. Set rules of engagement. Testing windows, excluded systems, data handling, emergency contacts, and what happens if a test causes disruption.
  5. State compliance drivers. Document which regulatory requirement, standard or contractual clause the exercise supports, so the report can reference it directly.

Anatomy of a report an auditor will accept

A strong report typically contains:

  • An executive summary in business language, with an overall risk rating.
  • Scope, dates, tester details, and methodology.
  • A findings table with unique identifiers, severity, affected assets, and risk rating using a recognised scoring approach such as CVSS, adjusted for context.
  • For each finding: description, evidence such as screenshots or request and response samples, impact, and specific remediation guidance.
  • Positive observations, so management also sees what works.
  • Limitations and assumptions.
  • A remediation tracker and retest results, either in the same document or as an addendum.

Reports that read like generic scanner exports, with hundreds of unverified low-severity items and no narrative, lose credibility quickly.

Common pitfalls

  • Scoping by convenience. Testing the easy systems and avoiding the legacy platform everyone is afraid to touch.
  • No retest. Reporting findings but never proving closure.
  • Testing in non-representative environments. A staging system that differs from production can hide real problems.
  • Treating the report as the goal. The goal is reduced risk; the report is evidence of the work.
  • Ignoring third parties. Vendors and integrators often expose paths into your environment.
  • Poor severity handling. Rating everything "critical" or everything "medium" makes prioritisation impossible.

Making findings useful to engineers

Developers and system administrators need clarity, not alarm. Good remediation guidance names the specific control to change, shows secure code or configuration patterns, and distinguishes quick fixes from structural ones. Offering a debrief call where testers walk the engineering team through the findings often accelerates fixes more than any document does.

From project to programme

Compliance-driven VAPT works best as a recurring programme rather than an annual scramble. Combine scheduled penetration tests of critical systems with regular vulnerability scanning, secure development practices and a clear patching process. Tie findings into your risk register and your wider ISMS, whether you follow ISO 27001, SOC 2 or sector rules.

Request a scope that fits your regulator

F9 Infotech designs VAPT engagements around your regulatory obligations, with clear scope, recognised methodology, evidence-rich reporting and retesting. Request a compliance-ready VAPT scope and quote and bring your regulator's requirements; we will map them to the work.

This article is general information. Always confirm current regulatory requirements for your entity type.