By Xhield Team · July 8, 2026 · 14 min read
The law that doesn't mention penetration testing — but demands it anyway
India's Digital Personal Data Protection Act 2023 is now in force. It applies to every organisation that collects, stores, or processes personal data of Indian residents — regardless of size, sector, or whether that data is processed in India or abroad. Penalties for non-compliance reach ₹250 crore per breach of obligation.
The Act does not use the words "penetration test," "vulnerability assessment," or "security audit" anywhere in its text.
What it does say — in Section 8(5) — is that every Data Fiduciary must protect personal data "by taking reasonable security safeguards to prevent personal data breach." Six words carry the entire security obligation: reasonable security safeguards. The Act does not define them. The rules that will define them have not yet been notified.
Thousands of Indian organisations are now legally required to implement security measures they cannot fully specify, against a standard they cannot precisely measure, under penalties that are among the highest in Indian regulatory history.
This post maps the DPDPA's actual obligations to what they mean for a security testing program in practice — what the law demands, where it leaves deliberate ambiguity, and why VAPT is the most defensible way to demonstrate reasonable security safeguards when a regulator comes asking.
1. What the DPDPA actually says about security
The DPDPA's security provisions are deliberately principle-based rather than prescriptive. Understanding what each provision actually requires is the necessary starting point before any compliance program can be designed.
Section 8(5) — the core security obligation
Every Data Fiduciary shall protect personal data in its possession or under its control by taking reasonable security safeguards to prevent personal data breach. This is the primary obligation. Everything else in the Act's security framework flows from it.
Section 8(6) — breach notification
In the event of a personal data breach, the Data Fiduciary must notify the Data Protection Board of India and each affected Data Principal. The Act itself does not specify a notification timeframe — this will be defined in the rules. But the obligation to notify exists unconditionally, regardless of how a breach occurred or how the organisation discovers it.
Section 8(7) — data accuracy and integrity
Data Fiduciaries must ensure that personal data is accurate and complete. This has direct security implications: injection vulnerabilities, unauthorised write access, and data tampering vectors all create risks of data becoming inaccurate or incomplete in violation of this obligation.
Significant Data Fiduciaries
Organisations processing large volumes of sensitive personal data — financial records, health data, biometric data — may be designated Significant Data Fiduciaries by the central government. SDFs face additional obligations that will almost certainly include Data Protection Impact Assessments, which require documented risk assessments of every processing activity. VAPT findings are the most natural form of evidence for those assessments.
The penalty structure
Failure to implement reasonable security safeguards: up to ₹250 crore. Failure to notify a breach: up to ₹200 crore. The Data Protection Board of India has investigative and enforcement powers. These are not theoretical figures — they represent the highest data protection penalties in Indian regulatory history.
2. The "reasonable security safeguards" problem
The Act's deliberate ambiguity around "reasonable" is not unusual in data protection law globally. GDPR requires "appropriate technical and organisational measures." California's CCPA requires "reasonable security procedures and practices." In each case, the legislature chose flexibility over prescription — leaving courts and regulators to define the standard through enforcement decisions over time.
Indian courts and the Data Protection Board will do the same. The interpretation of "reasonable" under the DPDPA will emerge through enforcement cases, Board guidance, and eventually judicial decisions. Until then, organisations must make their best judgment about what a reasonable, prudent organisation would do to protect personal data.
In practice, the safest interpretive approach is to look at analogous frameworks. CERT-In's Information Security Guidelines, ISO 27001, NIST CSF, and the existing IT Act provisions are all likely to inform how the Board assesses reasonableness. An organisation that meets these standards has a credible argument that its security safeguards were reasonable. An organisation that meets none of them does not.
The due diligence argument matters enormously here. An organisation that can demonstrate active, documented security testing — VAPT reports showing what was tested and when, remediation records showing how findings were addressed, and ongoing monitoring showing continuous vigilance — is in a fundamentally stronger position before a regulator than one that cannot.
"Reasonable" in legal contexts almost always tracks to "what a prudent, similarly-situated organisation would do." A prudent organisation tests the security of systems holding personal data. It documents those tests. It remediates findings. And it repeats the process.
The DPDPA does not require a VAPT. But if a breach occurs and the organisation has never tested the security of the systems holding personal data, arguing that it had implemented reasonable security safeguards becomes very difficult in front of an enforcement body.
3. Five DPDPA obligations and what they demand from your security testing program
Mapping the Act's obligations to concrete security testing requirements makes the compliance picture actionable rather than abstract.
Reasonable security safeguards (Section 8(5))
The obligation to prevent personal data breaches requires active testing of the systems where personal data lives. A VAPT that covers every system processing personal data — with documented scope, methodology, findings, and evidence of remediation — is the most direct demonstration of reasonable security safeguards available to an organisation. The test itself is not the safeguard; remediating what the test finds is. But an untested system is an unsafeguarded one.
Breach notification readiness (Section 8(6))
Knowing your attack surface is a prerequisite for detecting a breach. Organisations that have never mapped their personal data processing systems cannot reliably detect when those systems have been compromised. Pre-VAPT discovery — identifying every system that processes personal data before any test begins — is simultaneously a compliance activity and a detection readiness activity.
Data accuracy and integrity (Section 8(7))
Standard VAPT test cases — SQL injection, parameter tampering, unauthorised write access, insecure direct object references — directly test the attack vectors that could cause personal data to become inaccurate or incomplete. These test cases have DPDPA relevance beyond their standard security significance. A VAPT report that covers data integrity vulnerabilities is evidence of meeting Section 8(7) obligations.
Data Principal rights systems (Chapter III)
The DPDPA gives Data Principals rights to access, correct, and erase their personal data. Every organisation must build systems to handle these requests — and those systems handle personal data. They are frequently built quickly, by teams focused on compliance deadlines rather than security quality, and are often under-secured relative to core production systems. They must be included in VAPT scope.
Data Protection Impact Assessments (SDF obligations)
Significant Data Fiduciaries will be required to conduct DPIAs — structured risk assessments of every high-risk processing activity. VAPT findings feed directly into DPIAs: they quantify the technical risks of processing activities, provide evidence that risks have been assessed and mitigated, and create the documentation trail that regulators will look for when auditing an SDF's compliance program.
4. Where DPDPA goes further than CERT-In for security testing
Organisations that are already CERT-In compliant sometimes assume that existing compliance programs satisfy DPDPA's security requirements. This assumption is worth examining carefully — because the two frameworks have different scopes, different focuses, and different coverage.
CERT-In's Information Technology security directions are infrastructure-focused. They address log retention periods, incident reporting timelines, vulnerability disclosure requirements, and specific technical controls for critical information infrastructure. They do not specifically address the security of personal data processing systems as a distinct category.
The DPDPA's scope is data-centric. It applies wherever personal data is processed — regardless of whether the underlying system would be classified as critical information infrastructure under CERT-In. A mid-size fintech company processing employee payroll data, a healthcare SaaS platform storing patient records, an e-commerce company holding customer purchase history — each is subject to DPDPA even if none falls within any CERT-In directive.
For organisations already CERT-In compliant, DPDPA is an additional layer — not a replacement. CERT-In compliance does not automatically satisfy DPDPA's reasonable security safeguards requirement for systems that process personal data but fall outside CERT-In's infrastructure categories.
The scope expansion implication for VAPT is significant. A VAPT conducted to satisfy CERT-In requirements may not cover all systems that process personal data. DPDPA compliance requires identifying and testing every system in scope of the Act — which is almost always a larger set than what CERT-In mandates, and may include applications, APIs, SaaS integrations, and data processing workflows that a pure infrastructure-focused VAPT does not reach.
5. What a DPDPA-aligned VAPT program actually looks like
A VAPT program designed for DPDPA compliance differs from a standard security testing engagement in five specific ways.
Data flow mapping before scoping
DPDPA compliance begins with knowing where personal data lives. Before any VAPT scope is defined, organisations need a data flow map — identifying every system, database, API, and third-party integration that collects, stores, processes, or transmits personal data. The VAPT scope is then built from this map. Not from a general asset inventory. Not from memory. From a documented picture of where personal data actually flows.
Personal data systems weighted in prioritisation
Not all systems carry equal DPDPA risk. Systems processing sensitive personal data — financial records, health information, biometric data — carry higher penalty exposure and should be prioritised in VAPT planning: tested more frequently, with deeper methodology, and with specific test cases designed to surface data exfiltration paths, access control weaknesses, and encryption failures.
API security testing is non-negotiable
Personal data flows primarily through APIs — between application layers, to third-party services, to data processors. API VAPT must be explicitly included in scope. Many VAPT programs treat API testing as optional or as a subset of application testing. Under DPDPA, any API that touches personal data is a mandatory test target. Gaps here are both a technical vulnerability and a compliance gap.
Third-party and vendor coverage
The DPDPA holds Data Fiduciaries responsible for the security of the Data Processors they engage. Cloud providers, SaaS tools, analytics platforms, and outsourced processing services that handle personal data on the organisation's behalf must be included in the security testing picture — either through direct testing rights negotiated in vendor contracts, or through documented security assessments and certifications from those vendors that the organisation reviews and retains.
Documentation for regulatory defensibility
A VAPT conducted for DPDPA purposes must produce documentation that can withstand regulatory scrutiny — not just a report for the internal security team. Scope documents showing what was tested and why. Methodology descriptions showing how testing was conducted. Findings reports showing what was discovered. Remediation plans showing how findings were addressed. Evidence of remediation completion. This documentation is what an organisation presents to the Data Protection Board in an investigation.
6. Why pre-VAPT discovery matters more under DPDPA
The DPDPA's obligations apply to all systems processing personal data — including ones the organisation does not know exist.
A forgotten database holding customer records from a deprecated application. A shadow IT tool collecting form submissions that flow to an external service. A deprecated API still receiving personal data from a third-party integration that was never formally decommissioned. Each of these is in scope under the DPDPA. Each creates liability. And none of them will appear in a VAPT scope document built from a conventional asset inventory.
Pre-VAPT discovery under DPDPA is not merely a best practice for improving testing quality. It is a compliance necessity. Finding unknown assets that process personal data is part of meeting the reasonable security safeguards obligation — because you cannot implement safeguards for systems you do not know you have.
The liability dimension of this is the sharpest point in the DPDPA compliance picture: if a breach occurs through a system the organisation did not know was processing personal data, the response of "we didn't know it existed" is not a defence. The obligation to protect personal data applies regardless of whether the organisation has complete visibility into its own data processing landscape. Ignorance of an asset's existence does not remove the obligation to protect the data it holds.
This is precisely the gap that pre-VAPT discovery addresses — finding the unknown personal data processing systems before a regulator or an attacker does.
7. What to do now — before the rules are notified
The DPDPA rules — which will define specific timelines, Significant Data Fiduciary thresholds, breach notification formats, and potentially specific security standards — had not been notified as of mid-2026. This creates an important window for organisations willing to act ahead of enforcement.
It is worth being clear about what this uncertainty means: the specific technical standards that will satisfy "reasonable security safeguards" under DPDPA may be further refined when the rules are notified. Regulatory guidance from the Data Protection Board, once operational, may clarify the standard further. Organisations should not treat anything in this post as legal advice, and should work with qualified legal counsel on their specific DPDPA compliance posture.
That said, the core security obligations in the Act itself are clear enough to act on now. Waiting for rules before beginning compliance work means scrambling after notification — building programs under time pressure, potentially after enforcement has already begun for early cases.
Practical steps that make sense under any likely interpretation of the rules:
Conduct a personal data flow audit — document every system that processes personal data, including systems owned by third parties processing on the organisation's behalf. Map existing VAPT coverage against the personal data processing landscape and identify gaps. Ensure API security testing is explicitly included in the next VAPT engagement scope. Review Data Processor contracts for security testing obligations and audit rights. Begin documenting all security testing activities with regulatory defensibility in mind — scope, methodology, findings, and remediation evidence.
Organisations that build DPDPA-aligned VAPT programs now will have documented security evidence when enforcement begins. Those that wait will be building their programs under scrutiny.
8. Closing
The DPDPA does not name your VAPT vendor. It does not prescribe a testing frequency. It does not specify which tools to use or which methodology to follow.
But when a breach happens and the Data Protection Board asks what reasonable security safeguards were in place — the answer had better be more than a firewall and a hope that nothing would go wrong.
Security testing is not sufficient by itself to achieve DPDPA compliance. But it is necessary. And an organisation that has never systematically tested the security of systems holding personal data will find the argument for "reasonable safeguards" very difficult to make.
The starting point is the same as it is for every security program: know what you have. Find every system that processes personal data. Test it. Fix what the test finds. Document all of it.
Start with knowing what's there. Begin your pre-VAPT discovery with xhield →
Related reading: