VAPT & Penetration Testing in India

VAPT in India combines a vulnerability assessment, which finds and ranks weaknesses at breadth, with a penetration test, in which an assessor exploits them to prove real impact. Indian regulators expect it periodically: the RBI of banks, NBFCs and payment system operators, SEBI under the CSCRF, IRDAI of insurers, and PCI DSS of anyone handling cardholder data. CyberSigma is CERT-In empanelled and PCI QSA authorised (CEMEA, Asia Pacific and the USA), so where a tender or regulator requires an empanelled organisation's report, ours is accepted.

Who requires VAPT in India, and how often

VAPT in India is usually driven by a regulator or a customer rather than chosen, and the cadence is generally annual with additional testing after significant change:

• RBI-regulated entities — banks, NBFCs, payment system operators and card issuers, under the IT governance and cyber security directions, with testing expected periodically and after material change to in-scope systems.
• SEBI CSCRF — market infrastructure institutions, intermediaries and asset managers, with defined testing and reporting expectations.
• IRDAI — insurers, brokers and intermediaries under the information and cyber security guidelines.
• PCI DSS — any entity storing, processing or transmitting cardholder data must run internal and external vulnerability scanning and penetration testing, with segmentation testing where segmentation is relied on to reduce scope.
• Aadhaar ecosystem — AUA, KUA and related entities carry security testing and audit obligations for Aadhaar-linked systems.
• Government and PSU tenders — commonly require a security audit and testing report from a CERT-In empanelled organisation before go-live and periodically thereafter.
• Enterprise customers — increasingly ask for a current penetration test report as a condition of onboarding, irrespective of sector.

What we test, and how

We test against established methodology — the OWASP Web Security Testing Guide and NIST SP 800-115 — rather than running a scanner and forwarding the output:

• Web applications — authentication and session handling, access control and privilege escalation, injection, business-logic flaws and insecure direct object references.
• Mobile applications — Android and iOS, covering local storage, transport security, certificate handling, hardcoded secrets and platform-specific weaknesses.
• APIs — authentication, authorisation at object and function level, rate limiting, mass assignment and excessive data exposure, which is where modern breaches concentrate.
• Network — external perimeter and internal segments, including segmentation testing where PCI DSS scope reduction depends on it.
• Cloud — AWS, Azure and Google Cloud configuration, identity and privilege design, exposed storage and workload hardening.
• Manual exploitation and chaining — the difference between a scanner finding and a penetration test is whether someone demonstrated the impact of combining findings. That is what we do, within agreed rules of engagement.

What you receive

A report is only useful if a developer can act on it and a regulator can accept it, so we produce both:

• An executive summary stating business risk plainly, for the board and the regulator.
• Technical findings with reproduction steps, evidence, affected assets and CVSS-based severity, ordered so the highest-risk items are addressed first.
• Specific remediation guidance for each finding, written for the team that has to fix it rather than as a generic reference.
• A retest after remediation, and a report you can put in front of the regulator or customer evidencing closure.
• Where required, a report from a CERT-In empanelled organisation, which is the form many Indian tenders and regulated entities must have.

How is testing scoped safely against production?

Most Indian engagements involve production systems, so rules of engagement are agreed in writing before any testing begins: in-scope assets and explicitly out-of-scope ones, testing windows, rate limits, prohibited techniques such as denial of service, escalation contacts on both sides, and an immediate stop condition. Destructive testing is not performed without written authorisation. Where a staging environment genuinely mirrors production we will use it, but we will also tell you when it does not and the test would therefore prove little.

What is the difference between a vulnerability assessment and a penetration test?

A vulnerability assessment is broad and largely automated: it enumerates weaknesses across your estate and ranks them. A penetration test is narrow and manual: an assessor attempts to exploit those weaknesses, and to chain them, in order to demonstrate what an attacker could actually achieve. Regulators generally expect both, which is why they are usually commissioned together as VAPT.

Do we need a CERT-In empanelled organisation to do our testing?

For many government departments, PSUs and regulated entities, yes — the tender or the regulator specifies that the audit must be performed by a CERT-In empanelled organisation, and a report from a non-empanelled provider will not be accepted. CyberSigma is empanelled. If you are unsure whether empanelment is required for your engagement, send us the clause and we will tell you.

How often does the RBI or SEBI expect VAPT?

The common pattern across Indian sectoral guidance is at least annually, plus testing after any significant change to in-scope systems — a new application, a major release, an infrastructure or cloud migration. Specific expectations vary by entity type and by the direction that binds you, so we confirm the applicable cadence for your entity during scoping rather than assuming.

Will testing disrupt our production systems?

We scope to avoid it. Rules of engagement are agreed in writing beforehand — testing windows, rate limits, prohibited techniques including denial of service, escalation contacts and a stop condition — and destructive testing is never performed without explicit written authorisation. In practice most production testing is invisible to users.

Is a retest included?

Yes. A finding is not closed because it was reported; it is closed because a retest showed the fix works. We retest remediated findings and issue an updated report, which is what a regulator or enterprise customer will actually want to see.

Can one test satisfy both PCI DSS and our regulator?

Often, yes. PCI DSS has specific testing requirements including segmentation testing, and sectoral directions have their own, but the underlying work overlaps substantially. Because we are both CERT-In empanelled and PCI QSA authorised, we can scope a single engagement that produces the evidence each one needs rather than running two tests over the same estate.