DPDP Act Penetration Testing: What Section 8(5) Requires

India's Digital Personal Data Protection Act doesn't use the words "penetration test" anywhere in its text — and the DPDP Rules, 2025 that followed it still don't name VAPT as a line-item requirement either. That's led to genuine confusion about whether it's actually needed. Here's what Section 8(5) and the notified Rules actually say, and why the practical answer is yes regardless of the literal wording.

What Section 8(5) actually says

Section 8(5) of the Digital Personal Data Protection Act, 2023 requires every Data Fiduciary — broadly, the entity that determines the purpose and means of processing personal data — to protect personal data in its possession or control, including data processed on its behalf by a Data Processor, by taking "reasonable security safeguards" to prevent a personal data breach.

That's the entire operative text on this specific point. It's an outcome-based obligation — "prevent a breach" — not a checklist, and it deliberately doesn't name penetration testing, encryption, or any other specific control in the Act itself. This is the same structural pattern as SOC 2's CC4.1/CC7.1 and ISO 27001's Annex A 8.8: the law states a result, and leaves the technical means largely to be filled in by rules, guidance and accepted practice.

Where the DPDP Rules, 2025 fill in the detail

The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025, and they're where the "reasonable security safeguards" obligation gets a more concrete technical shape. The Rules set out baseline expectations including:

• Encryption of personal data, consistent with its sensitivity
• Access controls and access logs governing who can reach personal data and when
• Continuous monitoring for unauthorised access or processing
• Data backups to maintain the ability to restore access in the event of an incident
• A minimum one-year log retention period, so there's a usable record if something needs investigating
• Contractual security obligations flowed down to processors, so a Data Fiduciary can't outsource the risk along with the processing

Compliance under the Rules is phased rather than a single hard cutover date, which is worth tracking directly against the Rules rather than assuming a fixed deadline from any single source — the practical point for security teams is that the direction of travel is toward more specific, auditable technical controls, not fewer.

So where does penetration testing actually fit?

None of the controls listed above are "run a penetration test" in so many words. But put together, they describe a security posture that's very hard to credibly claim without having tested it: you can't demonstrate your access controls actually hold, or that your monitoring would catch what it's supposed to catch, purely by having a policy document that says they exist. Penetration testing is the practical evidence that "reasonable security safeguards" are real rather than aspirational — the same logic that makes VAPT the de facto expected evidence for SOC 2's CC4.1/CC7.1 or ISO 27001's Annex A 8.8, even though neither of those frameworks names it outright either.

For a Data Fiduciary handling meaningful volumes of personal data, or any internet-facing application that processes it, periodic exploitation-led testing — not just automated scanning — is the most direct way to show a regulator, an enterprise customer's security review, or your own board that Section 8(5) isn't just a policy statement.

What's actually at stake

The Section 8(5) safeguards failure carries the single highest penalty tier in the entire Act — higher than the breach-notification failure itself. And a single incident that's both a safeguards failure and an unreported breach can attract both penalties on top of each other, with no stated annual or lifetime cap limiting total exposure. This is, by design, the provision the Act treats most seriously.

"The DPDP Act never says 'penetration test.' It says the one thing a penetration test is built to prove: that your safeguards actually work."

Does this apply to you if you're not based in India?

Yes, in the relevant circumstances. The Act applies to the processing of personal data of Data Principals located in India — including processing carried out entirely outside India, where that processing relates to offering goods or services to individuals in India. A SaaS company headquartered anywhere, with Indian users or customers, falls within scope for the data it processes about them. This mirrors how GDPR extends extraterritorially to non-EU companies serving EU residents.

How ComplyArmor supports DPDP evidence

ComplyArmor's Smart PTaaS runs exploitation-led testing across eight attack surfaces — web, mobile, API, network, source code, thick client, AI agents and MCP servers — with every finding verified by a human tester, mapped to OWASP Top 10, ASVS, PCI-DSS, ISO 27001 and SOC 2 control language. See our full compliance mapping and methodology. As a company headquartered in India, we track the DPDP Rules' phased timeline directly and can help you build Section 8(5)-grade evidence into your existing testing cadence rather than treating it as a separate exercise.

Frequently asked questions

If you process personal data of anyone in India and can't currently point to recent exploitation-led testing of the systems that handle it, that's the gap worth closing before a regulator — or the Rules' phased timeline — asks about it.