DPDP Act Security Testing and VAPT

No, not explicitly. The Digital Personal Data Protection Act, 2023 does not name penetration testing or set a testing cycle the way PCI DSS does; what it requires, under Section 8(5), is that a Data Fiduciary protect the personal data in its possession or control by taking reasonable security safeguards to prevent a breach. The Act deliberately does not list the safeguards, which means you are held to their effectiveness rather than to a checklist, and that is exactly where testing earns its place: a penetration test is the practical way to show the safeguards actually work rather than merely exist in a policy. There is also no DPDP Act certificate to obtain, so be wary of anyone selling one. In short, a test is not mandatory, but for any organisation holding meaningful amounts of personal data it is the most credible evidence that the reasonable-security-safeguards duty is met, and it is increasingly what enterprise customers and the Data Protection Board's expectations point towards. We scope the test to the systems that actually hold personal data.

The DPDP Act, in Section 8(5), requires a Data Fiduciary to protect personal data with reasonable security safeguards to prevent a personal data breach, and the 2025 Rules add detail on what good practice looks like, but the Act stops short of a prescriptive list, which is deliberate: what is reasonable for a large platform differs from what is reasonable for a small one. In practice reasonable safeguards include access control, encryption, logging and monitoring, secure configuration, and a tested ability to detect and respond to a breach. Testing helps in two ways. First, a penetration test reproduces how an attacker would actually reach personal data, so it shows whether your safeguards hold under pressure rather than on paper, which is the standard the Act sets. Second, because the breach-intimation duty under Section 8(6) depends on noticing a breach at all, we test detection and logging alongside the applications, so you can show that a breach would be seen in time to report it. The output is dated evidence you can put in front of a board, a customer or the Data Protection Board.

No. There is no official DPDP Act certification scheme, no government-backed certificate and no empanelled-auditor sign-off that makes you "DPDP certified", so treat any firm selling a DPDP certificate with caution, because it is overstating what exists. What you can hold instead is demonstrable readiness: evidence that your consent, notices, data-principal rights workflows, security safeguards and breach process meet the Act and the 2025 Rules, assembled so it stands up to an enterprise buyer's due diligence or the Data Protection Board's attention. For the security-safeguards part specifically, that evidence is a penetration test that reproduces real weaknesses and confirms them closed, plus the detection and logging checks that show a breach would be noticed. This is the honest framing we use throughout: the DPDP Act is about being able to show your safeguards and processes work, not about collecting a certificate. If you also need a recognised certification for customer assurance, ISO 27001 is the one that certifies your security management system, and we can run the testing for that at the same time.

This page is deliberately the narrow, technical slice; the broader work lives on our DPDP Act consultant and DPDP compliance pages. A DPDP consultant or audit engagement covers the whole programme: data discovery and mapping, applicability and scoping, a gap assessment against the Act and the 2025 Rules, consent and notice design, data-principal rights workflows, processor contracts, a breach playbook and, for many organisations, standing up a Data Protection Officer function. DPDP security testing, which is what this page is about, is the part that evidences one specific duty, the reasonable security safeguards under Section 8(5), by testing the systems that hold personal data and confirming the safeguards hold. Most organisations need both, and they fit together: the consulting defines what good looks like and the testing proves the technical safeguards actually work. If you are not sure which you need first, the honest answer for a team early in its DPDP journey is usually the programme work before the testing, and we will say so on the scoping call rather than sell you a test you are not ready to act on.

The ones that hold personal data, and the infrastructure that supports them. The Act's safeguards duty attaches to the personal data in your possession or control, so the test follows the data rather than the org chart: the customer-facing applications that collect it, the APIs that move it, the databases and cloud storage that hold it, and the authentication, administration and logging systems around them. For most organisations that is the product and its backend; for a data processor it is the systems that handle other companies' personal data on their behalf. On the scoping call we map where personal data is collected, processed and stored, because testing the wrong systems produces evidence that does not match the duty, and a system you forgot holds personal data is exactly where a breach and a penalty come from. Where your estate is large or legacy, we help you prioritise the systems that hold the most, or the most sensitive, personal data first, including children's data, which carries extra weight under the Act, rather than trying to test everything at once.

Read the dates as a sequence. The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025, bringing the Data Protection Board into force; Consent Manager provisions apply from 13 November 2026; and most duties for Data Fiduciaries, including security safeguards, breach intimation and data-principal rights, apply from 13 May 2027. The security-safeguards duty is one of those that bites at the last date, so the work in front of it is not paperwork: finding and fixing the weaknesses in the systems that hold personal data takes time, and remediation of real findings runs at your development speed, not ours. The sensible sequence is to get the programme work moving, map your data and close the obvious gaps, then test the safeguards with enough runway to fix and retest what the test finds before the duty applies, rather than discovering exploitable weaknesses the month the deadline lands. On the scoping call we help you place the test in that timeline so the evidence is ready when it matters.

No. SecureRoot Risk Advisory LLP is not a CERT-In empanelled information security auditing organisation, and we will not blur that line. CERT-In empanelment is an Indian scheme that matters where a regulator or a tender specifically requires the formal VAPT report to be signed by an empanelled auditor; it is separate from the DPDP Act, which names neither empanelment nor a certificate. For DPDP Act security testing, what you need is credible evidence that your reasonable security safeguards work, and that is what we provide: manual, exploit-driven testing of the systems that hold personal data, with a proof of concept for every finding, a fix, and a retest that confirms closure, plus the detection and logging checks that support the breach-intimation duty. Where your situation separately requires an empanelled auditor's signature for some other obligation, that is a different party, and we will tell you so on the scoping call rather than after the work. SecureRoot does hold ISO/IEC 27001:2022, certificate IN60432E, if certification-backed assurance is also useful to you.