Why DPDP Compliance in India Needs Continuous Security Testing

A Pune healthtech platform (hypothetical, but a familiar shape) passes its annual VAPT in March, then in June ships a new API endpoint for a partner pharmacy that hands back any patient’s full profile once you change the patient number in the request. Nothing tests that endpoint until next March, and that gap is what needs continuous security testing in India to close.

The DPDP Act expects your safeguards to hold up between audits, not only on the day of one. This guide covers why, what a working programme looks like, and where Wattlecorp’s continuous security testing services in India fit.

What the DPDP Act Asks of Your Security Team

The DPDP Act makes the data fiduciary responsible for protecting the personal data it holds, including data a vendor processes on the fiduciary’s behalf. A data fiduciary is the business that decides why and how personal data gets processed, which usually means you, if you collect customers’ data.

The Act covers digital personal data processed in India, plus processing outside India linked to offering goods or services to people in India. Section 17 carves out specific exemptions, including for some of that processing outside India.

For businesses in scope, two duties matter here: take reasonable security safeguards to prevent a personal data breach and notify when one happens. The DPDP Rules roll out in three phases over 18 months. Rule 6 (security safeguards) and Rule 7 (breach intimation) sit in the final phase, which takes effect on 13 May 2027.

The word doing the heavy lifting is “reasonable”: do your safeguards fit the data you hold and the risks you face, and can you show they work?

The DPDP Rules set out seven reasonable security safeguards as a minimum, including encryption or masking of personal data, access controls, logging and monitoring that can spot unauthorised access, and measures to keep processing going after an incident. Each of those is a control that can quietly stop working. The only way to know a DPDP security safeguard still works is to test it.

The Act lets the Data Protection Board of India impose financial penalties, and failing to take reasonable security safeguards is one of the penalty heads in its schedule. The defense that holds up is evidence that your safeguards worked, which is what the rest of this guide is about.

Also read : Business Security Improvement Through Manual and Automated Penetration Testing in India

Why a Once-a-Year VAPT Leaves a DPDP Gap

A VAPT is a point-in-time exercise. It shows what an attacker could have done while the testers were inside your systems, and your systems don’t stop changing when the report is signed.

That’s no knock on good VAPT services in India, and an annual test still belongs in your programme.

The trouble is the other eleven months. Between two annual tests, a typical product company changes things like these:

• New releases that touch login, payments, or profile data.
• New APIs and partner integrations, like the pharmacy endpoint above.
• Cloud configuration changes made under deadline pressure.
• New vendors and processors who get access to personal data.
• Newly disclosed vulnerabilities in software you already run.

Now picture a breach in month eight. You’ll be asked what you did to keep safeguards reasonable after the last test. A March report answers for March, and only for March.

Scanning alone doesn’t fill the gap either. A scanner finds known weaknesses with known signatures, so it is unlikely to catch the healthtech endpoint. Handing one patient’s record to another is a broken access control flaw, and finding it reliably needs a human tester.

What Continuous Security Testing in India Looks Like in Practice

Continuous security testing combines ongoing vulnerability scanning with manual penetration testing triggered by change, plus retesting to prove fixes worked. The scanning, prioritising, and fix-tracking side of that work is what’s usually called continuous vulnerability management; penetration testing is a separate control that sits beside it.

In practice, a working programme has four moving parts:

1. Scheduled scanning. Vulnerability scanning runs against your external and internal assets on a fixed schedule, so known exposures surface between manual tests.
2. Change-triggered manual testing. A new API, a new payment flow or a new integration gets a focused penetration test before or shortly after it goes live.
3. Retesting after fixes. A fix isn’t closed until someone confirms it, which is the point of VAPT remediation verification.
4. A way to take in outside reports. A responsible disclosure route or bug bounty programme means a researcher who finds your hole can tell you before anyone else uses it.

The nearest public example from Wattlecorp’s own work is a consent management platform serving millions of website integrations. Wattlecorp triaged and validated the reports coming into the platform’s global bug bounty programme, alongside black-box testing (no inside knowledge), grey-box testing (partial knowledge) and cloud, application server, and network configuration reviews.

That platform’s tooling serves the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA) and Brazil’s Lei Geral de Proteção de Dados (LGPD), not DPDP, so it says nothing about DPDP enforcement. What carries over is the combination of outside reports, active testing, and configuration review.

Also read : Understanding Your VAPT Report: A Complete VAPT Report Guide for Indian Businesses

Continuous Security Testing for CERT-In Compliance and the 6-Hour Clock

CERT-In’s Directions of 2022 apply broadly to service providers, intermediaries, data centres, body corporates, government organisations, virtual private server (VPS), cloud and virtual private network (VPN) providers, and virtual asset service and exchange providers. They require specified cybersecurity incidents to be reported within 6 hours of noticing them or being made aware of them. The clock starts when you notice the incident, not when it began.

That puts the weight on detection. An intrusion your monitoring misses for weeks, or first hear about from a customer, has had weeks to grow before the six hours start.

A vulnerability your tester finds is a ticket, while the same vulnerability found by an attacker can become a reportable incident. Regular testing also exercises your alerting, because a tester’s activity should show up in your logs, and if it doesn’t, you’ve learned something cheaply.

For working out which incidents you must report to CERT-In, and how, see Wattlecorp’s CERT-In compliance consulting.

DPDP adds a second notification track. One incident involving personal data may need both a CERT-In report and a DPDP breach notification, which under Section 8(6) of the DPDP Act and Rule 7 of the DPDP Rules, 2025 goes to both the Data Protection Board of India and each affected data principal (the person the data is about). Data fiduciaries are expected to report a breach within 72 hours of noticing it. Agree before an incident who files which report, so the two don’t contradict each other.

Banks, lenders, and securities firms have a third layer. The Reserve Bank of India (RBI) issued Directions on Cybersecurity, Technology Risk, Resilience and Assurance (Ref: RBI/DoS/2026-27/410) on 31 July 2026. They cover commercial banks, non-banking finance companies, credit information companies, all-India financial institutions, urban cooperative banks and non-bank payment system operators.

The Securities and Exchange Board of India (SEBI) governs capital market intermediaries through its Cybersecurity and Cyber Resilience Framework (circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024, with technical clarifications on 28 August 2025). Check the instrument that applies to your licence for its testing expectations.

Turning DPDP Security Safeguards Into Evidence

Whether a safeguard was “reasonable” usually gets judged after something has gone wrong. That’s why continuous security testing for DPDP compliance matters as much for the record it leaves as for the tests themselves.

Neither the DPDP Act nor the Rules appear to set a testing frequency. That doesn’t make any schedule acceptable. A sector regulator may set one, and either way you’ll need to explain the cadence you chose.

The evidence that holds up is plain and dated:

• A map of where personal data lives and which systems touch it.
• Test reports with dates, scope, and findings, written so a non-technical reader understands them.
• Remediation tickets showing when each finding was fixed.
• Retest results proving the fix worked.
• A short note on why you test at the cadence you do.

Plain-language reporting is one of the three delivery pillars Wattlecorp states for its penetration testing, alongside in-depth testing and industry-standard tools.

Reasonable security safeguards are easier to defend with a year of dated test records than with one clean report. Your board, auditors and enterprise customers will likely ask for that trail before any regulator does.

Testing evidence is one part of a wider DPDP programme, and Wattlecorp’s DPDP compliance checklist for Indian businesses covers the other obligations around it.

Also read : Third-Party Vendor Security Risk Assessment Under DPDP: A Guide for Indian Enterprises

Setting a Testing Cadence That Matches Your Risk

You don’t need to test everything constantly. You need testing tied to the moments your risk actually changes. (Nobody wants a pentester living in their staging environment full time, including the pentester).

A practical starting point looks like this:

• Always on: Automated scanning of internet-facing assets, assigning every critical finding an owner and a fix date as soon as it appears.
• Before go-live: A focused manual test for any new API, payment flow, login change, or partner integration that touches personal data.
• After every fix: A retest, so a closed ticket means a closed hole.
• At least once a year: A full manual penetration test of your applications and infrastructure.
• When a vendor joins: A check of what that vendor can reach, and how.

Start with the systems that hold the most personal data and change most often. For most Indian product companies, that’s the customer-facing app and its APIs.

Make Your DPDP Security Safeguards Testable All Year

For the Pune healthtech platform, a focused test before the pharmacy integration went live would most likely have caught a flaw that simple, nine months before the next annual test.

Point-in-time reports go stale as fast as your release cycle moves, and as the DPDP Rules’ obligations phase in, customers and auditors are likely to ask for evidence more often.

If you want testing that produces that evidence every month, talk to Wattlecorp about continuous security testing in India.

Continuous Security Testing in India FAQs