Security safeguards under the DPDP Act

Security safeguards should be boring; breaches rarely respect theatre.

Indian organisations preparing for the DPDP Act need a security-safeguards file that privacy, security, engineering and vendor teams can all use. Section 8 of the Digital Personal Data Protection Act, 2023 requires a Data Fiduciary to protect personal data in its possession or under its control by taking reasonable security safeguards to prevent personal data breach. That sentence should not live only in a policy. It needs owners, proof, review dates and an incident path that works when a system, vendor or employee account fails.

The notified DPDP Rules, 2025 add practical detail for notices, rights handling, consent managers and the Data Protection Board architecture, while commencement provisions are staggered through the official notification and rules. For security work, that means teams should separate what is already live from what needs readiness before later provisions take effect. CERT-In directions also remain relevant for cyber incident reporting, log retention and coordination where an incident is a cyber security incident as well as a personal data breach.

What to review

Start with a narrow inventory of systems processing digital personal data: production databases, support tools, analytics products, marketing systems, identity stores, backups, file shares and vendor platforms. For each system, record the Data Fiduciary owner, processor or vendor owner, categories of personal data, access groups, retention position, logging coverage, encryption approach and breach contact.

Then check whether the control is evidenced, not merely asserted. A security policy is useful, but a board, auditor or incident team will ask for access reviews, ticket history, vulnerability reports, backup restore tests, vendor assurance records, incident drills, training logs and exception approvals. Keep those records linked to the system they protect.

For vendors, review whether contracts require appropriate security measures, prompt incident notice, audit support, deletion or return of data, sub-processor controls and cooperation with regulatory or Data Principal communications. The DPDP Act places responsibility on the Data Fiduciary even where processing is carried out by a processor, so vendor evidence should be part of the same file, not a procurement side-folder.

Implementation steps

Map each processing system to a named business owner and technical owner. If nobody owns a system, nobody owns the evidence when something breaks. Give each owner a short quarterly task: confirm access groups, review exceptions, check unresolved vulnerabilities and confirm that logs are retained in the expected location.

Create a safeguard register with plain columns: system, personal data category, risk rating, key controls, evidence link, last review date, next review date, open exceptions and vendor dependency. Avoid scoring models that produce attractive numbers but no work. The register should show which controls are missing and who is accountable for closing them.

Align incident response with privacy escalation. Security teams may focus on containment, forensics and restoration; privacy teams need to assess whether the event is a personal data breach, what data was involved, whether Data Principals or the Board may need to be informed, and what records should be preserved. Use one triage form so the same facts do not have to be collected twice.

Check CERT-In overlap early. CERT-In directions refer to cyber incident reporting and supporting information. A DPDP breach may not always be a CERT-In reportable cyber incident, and a CERT-In incident may not always involve personal data, but the first-hour triage should test both paths. Record who can make that decision on weekends and holidays.

Run one tabletop exercise using a realistic scenario: compromised support account, exposed storage bucket, ransomware alert, vendor API leak or accidental bulk email. The output should be a corrected contact tree, evidence gaps, decision log template and a short list of control fixes. That is more useful than a long playbook nobody has tried.

Common mistakes

• Treating section 8 as an IT-only duty and leaving privacy, legal, product and vendor teams outside the evidence loop.
• Recording controls without proof, review dates or owners, which makes the register impressive until anyone asks for the file.
• Running separate cyber and privacy incident processes, creating delay exactly when facts, clocks and communications matter.

How DataNuance can help

DataNuance helps Indian organisations translate DPDP security safeguard duties into working registers, vendor evidence packs, incident triage forms and board-ready status notes. We can review existing security and privacy material, identify missing evidence, map CERT-In and DPDP incident paths, and build a practical remediation tracker that fits the organisation's systems rather than a generic checklist.

For teams preparing for audits, vendor diligence or board reporting, we can also turn technical control material into privacy-facing evidence: what data is protected, why the control matters, who owns it, how it is tested and what remains open. To discuss a focused safeguard review, contact DataNuance.

FAQs

What counts as a reasonable security safeguard under the DPDP Act?

The Act does not provide a single fixed control list for every organisation. Reasonableness should be evidenced through risk-based controls, ownership, review, vendor management, incident readiness and proof that controls operate in practice.

Should the safeguard register include vendors and processors?

Yes. If a processor handles personal data for the organisation, the Data Fiduciary still needs evidence that vendor security, breach notice and cooperation commitments are understood and monitored.

How does CERT-In reporting connect with DPDP breach response?

CERT-In reporting is a cyber incident pathway, while DPDP breach response focuses on personal data breach duties. Many incidents should be screened under both paths at triage, with the decision and rationale recorded.

How often should safeguards be reviewed?

High-risk systems, major vendors and unresolved exceptions should be reviewed more frequently. For most operating registers, a quarterly owner review plus event-triggered review after incidents, product changes or vendor changes is a practical baseline.

Sources

• Digital Personal Data Protection Act, 2023, India Code: https://www.indiacode.nic.in/handle/123456789/22037?view_type=browse
• Digital Personal Data Protection Rules, 2025, MeitY: https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf
• DPDP Act commencement notification, eGazette: https://egazette.gov.in/WriteReadData/2025/267647.pdf
• CERT-In directions press release, Press Information Bureau: https://www.pib.gov.in/PressReleasePage.aspx?PRID=1820904
• CERT-In directions under section 70B, CERT-In: https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf