Security

Reasonable security safeguards under the DPDP Act and Rule 6

Audience: engineering, security and infrastructure leads, CTOs, vendor managers · Last reviewed: October 2026

Security is where the DPDP Act puts its biggest penalty. The Act states the duty in one line; the DPDP Rules, 2025 spell out the minimum. This guide reads Rule 6 clause by clause and turns each into a control you can assign and evidence.

Section 8(5): a Data Fiduciary shall protect personal data in its possession or under its control, including in respect of any processing undertaken by it or on its behalf by a Data Processor, by taking reasonable security safeguards to prevent personal data breach.

What you are protecting against

A “personal data breach” is any unauthorised processing, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises its confidentiality, integrity or availability (section 2(u)). That covers far more than hacking: an over-shared spreadsheet, a deleted database with no backup, or a ransomware outage can all qualify.

The seven minimum safeguards in Rule 6(1)

Rule 6(1) says the safeguards “shall include, at the minimum” the following. Each line below gives the clause and a practical way to meet it.

(a) Protective data security measures

Appropriate measures such as encryption, obfuscation, masking or virtual tokens mapped to the personal data. In practice: encrypt data at rest and in transit, mask identifiers in support and analytics tools, and tokenise high-risk fields such as payment or identity numbers where you can.

(b) Access control

Appropriate measures to control access to the computer resources used by you or your Data Processor. “Computer resource” takes its meaning from the Information Technology Act, 2000 (Rule 6(2)). In practice: single sign-on, multi-factor authentication, least-privilege roles and prompt removal of leavers.

(c) Visibility through logs and monitoring

Visibility on access to personal data through appropriate logs, monitoring and review, so unauthorised access can be detected, investigated and fixed. In practice: log access to production data stores and admin consoles, alert on anomalies, and review access regularly.

(d) Continuity of processing

Reasonable measures for continued processing if confidentiality, integrity or availability is compromised, for example by data backups. In practice: tested backups, documented restore steps and a recovery target you have actually rehearsed.

(e) One-year retention of logs and data

To enable detection, investigation, remediation and continuity, retain those logs and personal data for one year, unless another law requires otherwise. Rule 8(3) separately requires every Data Fiduciary to keep personal data, associated traffic data and processing logs for at least one year from the date of processing for the purposes in the Seventh Schedule. Make sure your log pipeline and your processors' default retention settings meet this.

(f) Security clauses in processor contracts

An appropriate provision in your contract with each Data Processor for taking reasonable security safeguards. This pairs with section 8(2), which allows you to engage a Data Processor only under a valid contract. See the vendor DPA review guide.

(g) Technical and organisational measures

Appropriate technical and organisational measures to ensure the safeguards are effectively observed. This echoes the general duty in section 8(4). In practice: written policies, named owners, staff training, change management and periodic review.

Processors do not dilute your duty

Section 8(1) makes the Data Fiduciary responsible for compliance for processing done on its behalf by a Data Processor, irrespective of any agreement to the contrary. Rule 6(1) expressly covers data processed “on its behalf by a Data Processor”. A breach at your cloud host, support desk tool or marketing platform is still your breach to manage. Use the vendor and processor checklist to cover them.

When safeguards fail: breach intimation

If a breach happens, section 8(6) and Rule 7 require intimation to each affected Data Principal without delay, and to the Board without delay followed by a detailed report within seventy-two hours of becoming aware (or longer if the Board allows on written request) (Rule 7(1) and 7(2)). Good logging under Rule 6(1)(c) and (e) is what makes that report possible. See the incident response playbook.

Penalties

  • Breach of the obligation to take reasonable security safeguards under section 8(5): may extend to two hundred and fifty crore rupees (Schedule, item 1).
  • Breach of the obligation to notify the Board or affected Data Principals under section 8(6): may extend to two hundred crore rupees (Schedule, item 2).

These are maximums. The Board must find the breach significant, hold an inquiry and give a hearing (section 33(1)). It considers factors including the type of data affected and whether you took timely, effective action to mitigate (section 33(2)(b) and 33(2)(e)). Fast containment and good records count. See DPDP penalties explained.

Practical security checklist

  1. List the systems and processors holding personal data, and who can access each.
  2. Encrypt in transit and at rest; mask or tokenise high-risk fields (Rule 6(1)(a)).
  3. Enforce MFA and least-privilege access; review access quarterly (Rule 6(1)(b)).
  4. Centralise access logs and alerts; keep them at least one year (Rule 6(1)(c), 6(1)(e), 8(3)).
  5. Test restores from backup, not just backups (Rule 6(1)(d)).
  6. Add security clauses to every processor contract (Rule 6(1)(f); section 8(2)).
  7. Write it down: policies, owners, training records (Rule 6(1)(g)).
  8. Rehearse the breach intimation steps in Rule 7.

Engineering teams can go deeper with DPDP for engineering teams.

Frequently asked questions

What are reasonable security safeguards under the DPDP Act?

Section 8(5) requires a Data Fiduciary to protect personal data, including data processed by its Data Processors, with reasonable security safeguards to prevent personal data breach. Rule 6(1) lists the minimum: protective measures such as encryption or tokenisation, access control, logging and monitoring, continuity measures such as backups, one-year retention of logs, processor contract clauses, and organisational measures.

Does DPDP require ISO 27001 or another certification?

The Act and the DPDP Rules, 2025 do not name any mandatory certification or standard. Rule 6 requires appropriate measures; a recognised framework can help you show that, but it is not a legal requirement under the DPDP text.

How long must logs be kept under the DPDP Rules?

Rule 6(1)(e) requires logs and personal data to be retained for one year to support detection, investigation and remediation, unless another law requires otherwise. Rule 8(3) also requires personal data, traffic data and processing logs to be kept for at least one year for the purposes in the Seventh Schedule.

What is the penalty for failing to take reasonable security safeguards?

Item 1 of the Schedule to the Act sets a penalty that may extend to two hundred and fifty crore rupees for breach of section 8(5). The Board decides the amount after an inquiry, considering the factors in section 33(2).

Am I responsible for a breach at my vendor?

Yes. Section 8(1) makes the Data Fiduciary responsible for processing done on its behalf by a Data Processor, irrespective of any agreement to the contrary, and section 8(5) and Rule 6(1) cover data processed by a Data Processor.

Practical next step

Map each Rule 6(1) clause to a named control, an owner and a piece of evidence. Start with what is visible from outside, such as the scripts and trackers your public pages load.

Advertisement