DPDP Rule 6: the seven security safeguards, and the runway to May 2027

Rule 6 of the Digital Personal Data Protection Rules, 2025 is the clause that lands on a security team's desk. Five of its seven limbs are answerable from an asset inventory in a fortnight. The other two need a budget line and a procurement cycle, which makes the runway the first thing to settle, and the gazette record states the start of that runway twice.

The commencement map

G.S.R. 846(E) is dated "New Delhi, the 13th November, 2025" and sits under an issue line reading "NEW DELHI, THURSDAY, NOVEMBER 13, 2025". Page 1 of the same file carries the e-gazette identifier CG-DL-E-14112025-267650, and the PIB release of 17 November 2025 dates the notification to 14 November 2025, and does so twice. The Act commencement notification, G.S.R. 843(E), carries the same dateline and the identifier CG-DL-E-14112025-267647. Both instruments count their tranches from the date of publication rather than from the date the notification bears, so every date derived from them is a pair.

Tranche	Rules, G.S.R. 846(E)	Act, G.S.R. 843(E)	Date
On publication	Rules 1, 2 and 17 to 21	s.1(2), s.2, ss.18 to 26, ss.35 and 38 to 43, s.44(1) and (3)	13 or 14 November 2025
One year	Rule 4, Consent Manager registration	s.6(9) and s.27(1)(d)	13 or 14 November 2026
Eighteen months	Rules 3, 5 to 16, 22 and 23	ss.3 to 5, s.6(1) to (8) and (10), ss.7 to 10, ss.11 to 17, s.27 other than (1)(d), ss.28 to 34, 36 and 37, s.44(2)	13 or 14 May 2027

Read the eighteen-month row across and three things arrive together. Rule 6 sits inside "Rules 3, 5 to 16". Section 8, whose sub-section (5) carries the safeguards duty that Rule 6 sets the floor for, sits inside "sections 7 to 10". Section 33, the penalty section the Schedule is read with, sits inside "sections 28 to 34". The duty, its minimum content and the power to price a breach of it all become live on one day. Plan against 13 May 2027 and the one-day ambiguity stops costing anything.

The Rule 7 intimation duty and the Rule 13 audit cycle sit in this same tranche and are covered in the companion pieces.

Quote the two notifications separately

G.S.R. 892(E), the corrigenda of 10 December 2025, amends G.S.R. 846(E) and nothing else. The first of its five items sits on page 24 and has two limbs, at line 22 and at line 24, each replacing "of this Gazette" with "in the Official Gazette". Those two lines are Rule 1(3) and Rule 1(4), the one-year and eighteen-month commencement sub-rules, and they are the only two places that phrase occurs anywhere in the Rules. The Act notification was untouched. Clause (c) of G.S.R. 843(E) still reads "eighteen months from the date of publication of this gazette", lowercase and uncorrected. A Board note that renders the two instruments in the same words has misquoted one of them.

What each limb has to produce

The stem of Rule 6(1) says these seven are what safeguards "shall include, at the minimum", and every limb is drafted as an outcome rather than as a control. Below is our reading of the artefact each outcome has to produce, which is what an assessor asks to see.

Limb	Operative words	What has to exist on the file
(a)	"encryption, obfuscation, masking or the use of virtual tokens"	A map naming which of the four applies to each personal-data store, with key and token-vault ownership assigned. The recurring gap is the copies: the primary store is encrypted, the nightly export and the analytics replica are not
(b)	"control access to the computer resources"	Joiner-mover-leaver records, a privileged-access register, a dated recertification. Rule 6(2) borrows "computer resource" from the Information Technology Act, 2000, so the limb reaches the host, the network device and the storage layer alongside the application's login page
(c)	"visibility on the accessing of such personal data"	Three separate artefacts, below
(d)	"continued processing ... such as by way of data-backups"	A dated restore test. The limb names "destruction or loss of access", which puts a revoked cloud credential and a lost encryption key in scope beside disk failure
(e)	"retain such logs and personal data for a period of one year"	Retention configured on the logging platform, and a year of access history producible for a named record
(f)	"appropriate provision in the contract"	The safeguards clause in each processor contract, indexed against a current schedule of processors. The schedule goes missing more often than the clause, and sub-processors added by a SaaS vendor after signature are the usual gap
(g)	"technical and organisational measures to ensure effective observance"	A named owner, a review cadence, and a record showing observance was checked. The limb says "effective", so that record has to show what the check found

Limb (c): the limb most likely to need a platform change

Logs of accessing, not of signing in

Authentication events answer who signed in. This limb attaches visibility to "the accessing of such personal data", which is a different question and in most estates a different log source. At a datastore it is often a feature that has to be switched on, at a cost in throughput and volume that a DBA will want to argue about before a deadline rather than after one. The scoping question is which personal-data stores emit data-access events today and which would have to be reconfigured.

Monitoring, and the review that has to close

The limb names three nouns in sequence — logs, monitoring and review — and the purpose clause sets one standard for all three: detection of unauthorised access, its investigation, and remediation to prevent recurrence. Monitoring is detection running against those logs. Review is the artefact most often missing: an output on a cadence, owned by a named person, carried through to a recorded change that stops the finding recurring. A review that closes an item without recording what prevents its return has stopped short of the end of the sentence.

Detection also feeds clocks the organisation is already running. An entity reporting under the CERT-In Directions of 28 April 2022 owes a report within six hours of noticing an incident, and the noticing is done by the monitoring this limb requires. The telemetry that serves a six-hour clock serves everything slower, so build limb (c) against the tightest obligation the entity already carries.

Limb (e) and Rule 8(3) run at the same time

Limb (e) fixes a period of one year, its object is "such logs and personal data", both of them, and it qualifies itself with a saving for any law that "requires otherwise". Rule 8(3), which commences on the same day, requires personal data, associated traffic data and other logs to be kept "for a minimum period of one year from the date of such processing", after which the Data Fiduciary "shall cause such personal data and logs to be erased", subject to its own saving.

One rule states a period. The other states a minimum period followed by an erasure duty. A platform satisfying both has to hold the same records for a year, then erase them on a schedule, per record, with a documented exception path for each class where a named statute runs longer. That is a retention design rather than a retention setting, and it is the second of the two limbs that needs a budget line.

What the penalty turns on

The Schedule to the Act is rubricked "[See section 33 (1)]", and its first head covers breach of the section 8(5) safeguards duty. The penalty column reads "May extend to two hundred and fifty crore rupees": the largest figure in the Schedule, and a ceiling rather than a tariff.

The gate is in section 33(1). A penalty follows where "the Board determines on conclusion of an inquiry that breach of the provisions of this Act or the rules made thereunder by a person is significant", and after that person has had an opportunity of being heard. Section 33(2) then lists seven matters the Board is to have regard to in setting the amount. One of them is decided long before any incident: "whether the person took any action to mitigate the effects and consequences of the breach, and the timeliness and effectiveness of such action".

That is where the Rule 6 evidence set stops being paperwork. Timeliness of mitigation gets reconstructed from logs. Effectiveness gets reconstructed from review records and from the restore test. The artefacts limbs (c), (d) and (e) call for are the same artefacts section 33(2)(e) is assessed on, so the compliance file and the mitigation file are one file, assembled once.

Where to start

Count backwards from 13 May 2027, the earlier of the pair.

Limbs (a), (b), (d), (f) and (g) are inventory questions, and a fortnight of asking around answers them. Start with limb (f), because its artefact lives in contracts owned by procurement and legal, and a contract cycle is longer than a control cycle.

Limbs (c) and (e) are the two that move money. Data-access logging at personal-data granularity is a platform change. A year of retained logs and personal data, with an erasure schedule behind it, is a storage line item sized against the volume the estate actually generates. Both go through procurement, and a programme that opens them a year out lands them with time to test what it bought.

Security Brigade has been CERT-In empanelled since 2008, with 6,700+ assessments delivered for 1,000+ clients. We work Rule 6 as a control set rather than a clause list: mapping every copy of a personal-data store against limb (a), testing the access paths into the computer resources under limb (b), checking that what an estate logs is accessing rather than authentication under limb (c), and evidencing the restore that limb (d) turns on.

Which of the seven limbs your estate already satisfies is a conversation with your asset inventory and your log retention settings open. Talk to our team about scoping Rule 6 readiness against the May 2027 tranche.