The DPDP Act requires every Data Fiduciary to protect personal data by taking "reasonable security safeguards to prevent personal data breach" (Sec. 8(5)). Rule 6 of the DPDP Rules, 2025 says what that includes at a minimum: seven measures covering protection of the data, access control, logs and monitoring, backups, a one-year retention period, Processor contracts, and the technical and organisational measures that tie it together.
The stakes are set by the Schedule to Sec. 33(1). Failing to take reasonable security safeguards carries a ceiling of 250 crore rupees, the highest figure in the Act. Rule 6 commences on 13 May 2027 under Rule 1(4).
What Sec. 8(5) covers
Sec. 8(5) protects personal data "in its possession or under its control", including data processed on the Fiduciary's behalf by a Data Processor. The reach follows the data, not the building.
That ties to two neighbours. Sec. 8(1) keeps the Fiduciary responsible for processing done by a Processor, irrespective of any agreement to the contrary. And Sec. 8(4) requires appropriate technical and organisational measures to ensure effective observance of the Act, which Rule 6(1)(g) repeats in the security context.
The standard is reasonable, and the Rules treat Rule 6 as the floor. They do not name a certification or a specific control framework.
The seven minimum measures in Rule 6(1)
(a) Data security measures. Appropriate measures "such as securing of personal data through encryption, obfuscation, masking or the use of virtual tokens mapped to that personal data." The examples are illustrations, so a different method can qualify if it is appropriate to the data.
(b) Access control. Appropriate measures to control access to the computer resources used by the Fiduciary or its Processor, wherever applicable. Rule 6(2) takes "computer resource" from the Information Technology Act, 2000.
(c) Visibility. Visibility on the accessing of personal data through appropriate logs, monitoring and review, to enable detection of unauthorised access, its investigation, and remediation to prevent recurrence.
(d) Continuity. Reasonable measures for continued processing if the confidentiality, integrity or availability of the data is compromised by destruction or loss of access, such as data backups.
(e) Retention of logs. To enable detection, investigation, remediation and continued processing, retain logs and personal data for one year, unless a law requires otherwise.
(f) Processor contracts. Appropriate provision in the contract between the Fiduciary and a Processor, wherever applicable, for taking reasonable security safeguards.
(g) Technical and organisational measures. Appropriate measures to ensure effective observance of the security safeguards. This is the clause that covers people and process: who may do what, who reviews it, and who is told when it fails.
The one-year retention period
Two rules mention one year, and they are easy to run together.
Rule 6(1)(e) is a security measure. The purpose is to detect unauthorised access, investigate, remediate and continue processing after a compromise, and the retention is for one year unless the law requires otherwise.
Rule 8(3) is a retention floor. A Fiduciary must retain personal data, associated traffic data and other logs of processing, whether processed by it or by a Processor on its behalf, for a minimum of one year from the date of such processing, for the purposes in the Seventh Schedule. After that, it must cause the data and logs to be erased unless further retention is required by another law or notified by the Government.
The Rule 8(3) illustration says an e-book platform must keep order details and processing logs for at least one year even if the customer deletes her account, and a company must ensure its cloud Processor retains the data and logs for the same period.
This sits in tension with erasure on request under Sec. 12(3) and Sec. 8(7). Those yield where retention is necessary for compliance with law, and Rule 8(3) expressly requires retention for its purposes, so the two need to be read together. Logs should be designed so that they hold what investigation needs and no more.
What this means for processors
Rule 6(1)(f) puts security into the contract, but the duty to protect does not move to the Processor. Sec. 8(2) allows engaging a Processor only under a valid contract, and Sec. 8(5) covers its processing.
A contract should say which safeguards the Processor applies, who holds the logs, how long it keeps them, how fast it reports an incident, and what happens to the data on exit. Several of those points also feed the breach clock. See DPDP data breach notification: Rule 7 runs the 72-hour period from the moment the Data Fiduciary becomes aware of the breach, so the contract should make sure it hears quickly.
Safeguards that show up in an audit
Because the Act asks for reasonableness, the proof is evidence of reasoning. A Board inquiry under Sec. 33 weighs, among other things, the gravity and duration of the breach and whether mitigation was prompt. Records that help include:
- a data inventory showing where personal data sits, in your systems and your Processors';
- an access-control matrix and review log;
- the logging and monitoring configuration, and proof logs are kept for one year;
- backup and restore test results;
- executed Processor contracts with security terms; and
- the incident response plan with named owners.
The processing register is where the inventory lives, and the compliance map ties Sec. 8(5) and Rule 6 to controls. For the stakes on the other side of safeguards, read DPDP penalties explained, which sets out the full Schedule and how the Board imposes a penalty.
What is not in the rules
Rule 6 does not prescribe an encryption standard or key length, a penetration-testing cadence, a certification, or a data-localisation requirement. Those would come from other laws or sector regulators, not from the DPDP Rules. Treat any checklist claiming a specific cipher is "required by DPDP" with caution, and read Rule 6(1) directly.
Significant Data Fiduciaries have additional duties: under Rule 13(3) due diligence that technical measures, including algorithmic software, are not likely to pose a risk to Data Principals' rights, and under Rule 13(4) a restriction on transfers of data the Central Government specifies. See DPDP key definitions for who that covers.