In November 2025, the Indian government notified the Digital Personal Data Protection Rules under the DPDP Act 2023. With them came an 18-month implementation clock — and an enforcement regime that carries penalties most Indian enterprises have never had to think about before. If your organisation processes personal data of Indian citizens, the question is no longer whether to comply. The question is whether you can prove you complied before the Data Protection Board comes asking.
Most compliance conversations stall at policy drafts, consent architecture, and data mapping. Critical and almost universally neglected is Section 8(5): the obligation to implement reasonable security safeguards to prevent personal data breaches. That obligation has teeth — and its proof is technical, not documentary.
What 'Reasonable Security Safeguards' Actually Means in Law
Section 8(5) of the DPDP Act requires every Data Fiduciary to implement appropriate technical and organisational measures to ensure effective adherence to the provisions of this Act and to prevent personal data breach. The Act deliberately does not prescribe a list of tools — that flexibility is both its strength and its enforcement trap.
The DPB's interpretation of "reasonable" will draw heavily from three already-active regulatory frameworks. CERT-In Directions (2022) mandate vulnerability assessments and penetration testing, asset inventory hygiene, and a 6-hour breach reporting window — already binding on all organisations operating ICT infrastructure in India. ISO 27001 and NIST CSF are internationally accepted baselines the DPB will treat as reference points for appropriate technical measures. For financial sector Data Fiduciaries, the RBI Master Direction on IT explicitly mandates VAPT — and the DPB will expect the same standard from anyone controlling comparable volumes of sensitive personal data.
Practically, "reasonable security safeguards" means you must be able to demonstrate with artefacts that you tested your systems for exploitable weaknesses, fixed what you found, and have a documented process for doing so continuously. A policy that says "we conduct regular VAPT" is not evidence. A signed report, remediation tracker, and retest certificate are.
The Three Safeguard Evidence Types the DPB Will Ask For
When a breach occurs — or when the DPB initiates a suo-motu inquiry — they will issue a notice requiring documentary evidence of your security posture at the time of the incident. Three categories of evidence will define whether you are compliant or negligent.
Type 1: Testing Evidence. VAPT reports with scope definitions, methodology, and findings. External pentest certificates. Automated DAST and SAST scan logs with timestamps. Frequency must be defensible — quarterly at minimum for critical systems.
Type 2: Remediation Evidence. Vulnerability tracking with SLAs, ticket closures, retest confirmations, and sign-off chains. Risk acceptance decisions with senior authorisation. Trend data showing improvement over time.
Type 3: Process Evidence. Security testing policy with defined scope, cadence, and ownership. Vendor security clauses and third-party VAPT inclusion. Breach response runbook with documented tabletop exercise results.
DPDP + CERT-In + RBI: How the Three Regimes Overlap
Indian enterprises increasingly face a tripartite regulatory environment for data security. The DPDP Act is not an isolated obligation — it layers onto CERT-In directions and, for financial institutions, RBI's IT frameworks. Understanding where they intersect helps you build one defensible programme rather than three siloed compliance exercises.
CERT-In requires regular vulnerability assessment of ICT infrastructure on a continuous or quarterly basis. RBI and CERT-In together require annual VAPT with scope including critical applications. DPDP Section 8(5) creates an ongoing obligation to prevent personal data breaches. Breach reporting requires DPB notification and a CERT-In 6-hour report per incident. Third-party risk obligations under DPDP and RBI require data processor contractual obligations and annual vendor VAPT review. CERT-In and RBI both mandate 180-day log retention minimum, rolling continuously.
The practical implication: your security testing programme cannot be scoped only to satisfy DPDP in isolation. A CERT-In-compliant VAPT that excludes personal data processing systems because they are a separate team's responsibility creates a gap directly in the DPDP Section 8(5) blast radius.
Building a DPDP-Defensible Security Testing Programme
A programme that satisfies the DPDP's evidentiary burden is not necessarily more expensive than what you already do — but it must be more systematic, more documented, and more continuous.
Step 1: Scope personal data flows first. Map every system that stores, processes, or transmits personal data of Indian citizens. This is your DPDP VAPT perimeter — and it must include SaaS tools, internal APIs, third-party integrations, and data warehouses, not just the customer-facing web application.
Step 2: Establish a testing cadence with artefact trails. Quarterly automated scanning plus annual manual pentest is the defensible minimum. Every test must produce a signed report with scope, methodology, findings severity, and a remediation SLA. Store these with access logs — you may need to prove the chain of custody to the DPB.
Step 3: Close vendor coverage gaps. Data processors under DPDP are entities you have contracted to handle personal data. Contractually mandate that they provide VAPT reports annually. Maintain a vendor security register. If they breach, you may be liable — and "we did not ask" is not a defence.
Step 4: Test your breach response — actually test it. A breach response plan that has never been exercised is a document, not a capability. Conduct a tabletop exercise annually, time your simulated CERT-In notification, and document the results. The DPB will ask whether you could have responded faster.
Step 5: Build an evidence repository with 24-hour retrieval. Assume the DPB will give you 24 hours to produce your security testing evidence pack when a breach is reported. Centralise all VAPT reports, remediation logs, retest certificates, and policy documents in a single accessible location with clear version control.
How Arxiis Generates DPDP-Ready Evidence Automatically
Arxiis is Vryxa's AI red teaming platform built for the Indian compliance environment. Every test Arxiis runs is architected to produce the exact evidence artefacts that the DPDP Act, CERT-In, and RBI frameworks require — not as a post-hoc add-on, but as the native output of every assessment.
Personal data-scoped VAPT: Arxiis automatically identifies and prioritises systems that process personal data, ensuring your VAPT perimeter is DPDP-aligned from day one. Regulator-ready reports: every assessment generates a DPB-submission-ready report with signed methodology, CVSS-scored findings, and a remediation SLA tracker built in. Continuous retesting: Arxiis retests fixed vulnerabilities automatically and generates retest certificates, closing the evidence gap between initial assessment and remediation. Vendor coverage module: track third-party VAPT submissions, set renewal reminders, and flag coverage gaps in your data processor ecosystem. 24-hour evidence pack: one-click evidence export assembles your complete DPDP compliance artefact pack, formatted for DPB submission, in under five minutes. Breach simulation exercises: structured tabletop scenarios with timed CERT-In notification drills and documented outcomes — giving the DPB proof that your response is real, not hypothetical.
