DPDP Penetration Testing Requirements: What India's Data Protection Law Actually Demands

1. What DPDP Actually Says About Security

Section 8(5) of the Digital Personal Data Protection Act, 2023 reads:

That's it. No list of controls. No specific technical requirements. No mention of penetration testing, vulnerability scanning, encryption standards, or anything else you'd find in a framework like PCI DSS or ISO 27001.

"Reasonable security safeguards" is doing all the work. And deliberately so — the drafters didn't want to bake in a technical checklist that'd be outdated in three years. What they left instead is a standard that gets interpreted after something goes wrong.

The Data Protection Board of India (DPBI) decides what "reasonable" means case by case. And they'll use the facts in front of them: what data was involved, how sensitive it was, what the organization knew about the risks, and what they actually did about it.

That last part is the one that matters. What did you actually do.

2. Who DPDP Covers — Including Companies Outside India

DPDP applies to processing of digital personal data of individuals in India. The definition of personal data is broad — name, phone number, email, IP address, health records, financial data, location. Basically anything that identifies or can be used to identify a person.

The entity that determines why and how that data is processed is called a Data Fiduciary. If you're running a SaaS product and your users include people in India, you're probably a Data Fiduciary under DPDP.

There's a carve-out for data processed outside India under a contract with an Indian entity. But that exception is narrow and often doesn't apply to SaaS companies with direct user relationships.

If you have Indian users and you're unsure whether DPDP applies — it probably does. Get proper legal advice on that specific question. The security requirements here assume you've already established that it applies.

3. Penalties: What's at Stake

The penalty structure under DPDP is tiered. The maximum penalty for failing to implement adequate security safeguards (Section 8(5) violations) is significant.

For a breach of duty to notify the DPBI — if a breach happens and you don't report it — the penalty goes up to ₹200 crore. On top of whatever penalty applies for the underlying security failure.

These aren't hypothetical numbers. GDPR showed what happens when a data protection regime actually enforces. India's DPBI is a new regulator establishing precedent. Early enforcement decisions usually set a tone. It's worth not being in the first batch.

4. What "Reasonable Security Safeguards" Means in Practice

Because DPDP doesn't define this, you have to infer from context. A few sources are useful here.

First, the draft DPDP Rules released by MeitY in 2025 give some indication. The draft rules for Significant Data Fiduciaries (more on those below) reference periodic data protection audits and security assessments. That language doesn't appear in the public rules as of the time of writing, but it signals what the government considers reasonable for higher-risk organizations.

Second, Indian courts and regulators have historically looked at ISO 27001, the CERT-In guidelines, and RBI cybersecurity frameworks when evaluating whether an organization took security seriously. If your controls can be mapped to any of those, you're in better shape than if you can't.

Third, and most practically: "reasonable" usually means proportionate to the risk. The sensitivity of the data, the volume of data processed, the technical sophistication of likely threats. A healthcare startup processing patient records has a higher baseline than a B2B tool that only processes business email addresses. But both are covered.

• Encryption at rest and in transit. Not optional if you're holding sensitive personal data. DPDP doesn't specify standards but "reasonable" would be hard to argue without it.
• Access controls and least privilege. Who can see personal data in your systems, and why. Logs of who accessed what. Role separation.
• Vulnerability management. Knowing what's in your environment and whether it's patched. Not just a scan — actually tracking and remediating findings.
• Penetration testing. Active testing by someone trying to actually break in, not just a scanner looking for known CVEs. This is the difference between knowing your locks exist and knowing whether they hold under pressure.
• Breach detection and response. DPDP requires breach notification. You can't notify if you don't know. Detection capability is implicitly required by the notification obligation.
• Vendor security. If a third party processes personal data on your behalf, you remain responsible as the Data Fiduciary. Their security posture is part of your security posture.

None of these are explicitly listed in the Act. But if you faced a DPBI inquiry after a breach and couldn't demonstrate most of them, "reasonable security safeguards" would be a hard argument to win.

5. Significant Data Fiduciaries: Higher Bar

The government can designate certain organizations as Significant Data Fiduciaries (SDFs) based on factors like volume of data processed, sensitivity, risk to data subjects, and potential impact on national security or public order.

SDFs have additional obligations that regular Data Fiduciaries don't. The draft rules have referenced periodic data protection audits and the appointment of a Data Protection Officer (DPO) who reports to the board. These aren't finalized yet but the direction is clear.

If you're a large platform processing health data, financial data, or significant volumes of Indian user data, SDF designation is a real possibility when the government starts notifying categories. The security bar for SDFs will be higher, and "we didn't know we'd be designated" isn't a defense for having nothing in place when you are.

6. What a Penetration Test Proves Under DPDP

A penetration test generates documented evidence that you actively tested whether your security controls hold against real attack techniques. That's different from a vulnerability scan, which generates a list of known weaknesses. And it's very different from nothing.

Under DPDP's "reasonable safeguards" standard, a penetration test demonstrates a few things:

• You knew the threat model. A scoped penetration test shows you understood what an attacker would target — your authentication, your APIs, your data access controls — and specifically tested those paths.
• You tested, not just assumed. Declaring your controls secure based on internal review is one thing. Having an external tester attempt to break them and documenting what they found is another. The latter is evidence of active due diligence.
• You acted on findings. The remediation process — findings documented, severities assigned, fixes implemented, retest confirming remediation — is a paper trail showing your security posture was actively managed, not just declared.
• You're doing it regularly. A single pentest from three years ago doesn't show ongoing reasonable safeguards. Annual testing, or testing after major changes, shows an active program.

The DPBI hasn't yet issued detailed guidance on what constitutes "reasonable" in specific technical terms. But regulators like India's CERT-In have made clear that periodic security assessments are expected for organizations handling significant personal data. A pentest report is the most credible form that assessment can take.

7. What the DPBI Will Ask After a Breach

DPDP requires Data Fiduciaries to notify the DPBI of a personal data breach "as soon as possible." The rules will specify the exact timeframe, but breach notification is mandatory — no hiding it, no choosing whether to report based on severity.

When you notify, the DPBI can investigate. The investigation will look at:

• What personal data was involved and how many data principals were affected
• How the breach occurred — what the attack vector was, how long access persisted
• What security measures were in place to prevent this type of breach
• When those measures were last assessed or tested
• Whether the organization knew of the vulnerability before the breach and what they did about it
• How quickly the breach was detected after it occurred
• What the organization did to contain and remediate after discovery

The worst position is: "we had controls but hadn't tested them recently, and yes, the vulnerability that was exploited had existed for a while." That's the gap a penetration test closes.

If you can produce a pentest report from the past year showing your controls were tested, findings were documented and remediated, and your security posture was actively maintained — that changes the character of the DPBI's investigation significantly. You're not an organization that ignored security. You're an organization that got hit despite reasonable efforts. That distinction matters for penalty assessment.

8. What to Test and When

The scope of your penetration test should cover the systems that process, store, or transmit personal data of Indian residents. For most SaaS organizations, that's:

• The web application and APIs. Where users authenticate, where their data lives, what endpoints expose personal data, how role separation is enforced. This is typically the primary test target.
• Authentication and session management. How users log in, how sessions are maintained, whether account takeover is possible, how password reset flows are secured.
• Data access controls. Can a user access another user's data? Can a lower-privileged user escalate to admin? Can an unauthenticated caller reach personal data through API paths?
• Third-party integrations. OAuth flows, webhooks, data export endpoints, integrations with third-party SaaS tools that receive personal data.
• Infrastructure. Cloud configuration, storage bucket permissions, database exposure, network segmentation. If you process health or financial data, the infrastructure test is not optional.

On timing: annual testing is the baseline. You should also test after major changes — new authentication system, significant API additions, cloud migration, major product releases. Changes introduce new attack surface. Waiting for the next annual cycle to test a new auth flow means carrying unknown risk for months.

If you're pursuing DPDP compliance alongside SOC 2 or ISO 27001, a single well-scoped penetration test can generate evidence for all three frameworks simultaneously. The test only runs once — the report maps to each framework's requirements. This is worth discussing at scoping time.

9. How NullStrike Structures DPDP-Mapped Engagements

Most pentest firms don't think about how their report maps to regulatory requirements. They run the test, document the findings, hand over a PDF, and move on. That's fine if the report is just for your engineering team. It's not enough if you need to demonstrate compliance to a regulator or an enterprise customer asking for evidence.

When we scope an engagement for an organization handling DPDP-covered data, the report is structured from the start to serve as compliance evidence. That means:

• Scope documentation that explicitly identifies the systems processing personal data of Indian residents
• Testing methodology mapped to the categories of safeguard that "reasonable" requires — authentication, access controls, data exposure, encryption in transit
• Findings with clear business impact descriptions, not just CVSS scores — the DPBI is not reading CVSS, they're asking what a finding means for the data subjects
• Remediation tracking with a retest attestation letter confirming critical and high findings were closed
• An executive summary written for non-technical readers — legal counsel, your DPO, or a DPBI inquiry, not just your engineering team

If you're running HIPAA or SOC 2 alongside DPDP, we scope the test to cover all three in one engagement. One test, one report, evidence for each framework. The alternative is running separate tests for each, which costs more and introduces inconsistency between reports.

The Short Version

DPDP doesn't have a penetration testing checkbox. What it has is Section 8(5) and a regulator that will decide after a breach whether your safeguards were reasonable.

"We had an annual pentest, here's the report, here's what we fixed, here's the retest confirming it was closed" is a defensible position. "We relied on our cloud provider's security and assumed we were fine" is not.

The test is inexpensive relative to the penalty. The evidence it generates is real. Get it done before you need it.