The DPDP security safeguards are the seven minimum measures in rule 6 of the Digital Personal Data Protection Rules: protect the data itself, control access to the systems holding it, keep logs that make access visible, be able to keep processing when something breaks, retain those logs and the data for a year, push the duty to your processors by contract, and put technical and organisational measures behind all of it.
Rule 6 is the most prescriptive rule in the set and the one attached to the largest number in the Schedule to the Act. It binds eighteen months after the Rules were published in the Gazette on 14 November 2025 — mid-May 2027, as a single cliff rather than a ramp.
Why Rule 6 of DPDP Carries the Largest Penalty Band
Rule 6 of DPDP sits under the security-safeguards duty in section 8(5) of the Act, and that duty has its own entry in the Schedule: failure to take reasonable security safeguards to prevent a personal data breach can draw a penalty of up to 250 crore rupees. Nothing else in the Schedule has a higher ceiling.
Two corrections before you budget against that figure. The 250 crore band is not a general-purpose number — failing to report a breach is a separate band of up to 200 crore, and most other contraventions fall into a residual band of up to 50 crore. And there is no doubling provision, so claims of 500 crore exposure have no basis in the Act. Our guide to DPDP penalties and their ceilings has the full structure.
The Seven Minimum DPDP Security Safeguards
The seven minimum DPDP security safeguards in rule 6 are a floor, not a ceiling — and unusually for this Act, they are named rather than left to principle. For each one: what it asks for in engineering terms, and what you would hand over to demonstrate it.
Measure One: Encryption, Masking or Virtual Tokens
The DPDP encryption requirements are stated as a family rather than a mandate. Rule 6 asks for data security measures such as encryption, obfuscation, masking, or virtual tokens mapped to the personal data, so the first measure is satisfied by whichever of those actually reduces the exposure for a given store.
In practice: encryption at rest and in transit everywhere personal data lands, and one of the other three where encryption alone does not help. Masking in non-production is the usual gap — a production dump restored into staging is personal data outside your control boundary with none of the protections you claim for it.
Evidence: a data inventory naming every store holding personal data, each one's encryption state, the key management arrangement, and the transformation applied in lower environments. Our note on encryption requirements for SOC 2 covers the same artefacts.
Measure Two: Access Control Over the Computer Resources
Rule 6(1)(b) requires access control over the computer resources used by the Data Fiduciary or its processor. Note the scope: not access control over the data, access control over the resources — and it reaches the processor's environment as well as yours.
The word "used" does the work. A bastion host, a CI runner holding production credentials and a BI tool on a read replica are all computer resources used in processing, and all three usually sit outside whatever access control review the team runs.
Evidence: the access review record, the role definitions, and a reconciliation between the HR leavers list and the accounts that still exist.
Measure Three: Visibility on Access Through Logs
Rule 6's third measure asks for visibility on who accessed what, through logs, monitoring and review, and it states the purpose: to enable detection of unauthorised access, and to support investigation and remediation.
That purpose clause is the specification, and logs nobody reviews do not meet it. What meets it is an access log per store, forwarded somewhere the store's owner cannot quietly edit, with detection rules and a review cadence with named reviewers. If you cannot answer "who read this record, and when" within 30 minutes, measure three is not satisfied however much log volume you are paying for. The structure in our ISO 27001 logging and monitoring guide transfers directly.
Evidence: the log inventory, the detection rules, the review minutes, and one worked investigation.
Measure Four: Continued Processing When Something Breaks
Rule 6's fourth measure asks for reasonable measures to enable continued processing where confidentiality, integrity or availability of personal data is compromised, and names backups as an example. It is a resilience duty inside a privacy rule.
Backups count, but only tested ones — a successful job proves the job ran, not that you can restore. The integrity half is the one teams skip: if a store is tampered with rather than lost, you need to detect that and roll back to a known-good point, a different capability from restoring a deleted volume.
Evidence: restore test records with dates, durations and outcomes, plus your recovery objectives.
Measure Five: One Year of Log and Data Retention
DPDP log retention has a floor. The fifth measure requires retention of the logs and the personal data for one year, unless a longer or different period is required by another law.
It is an anti-tampering control: a breach that only becomes visible in month 7 cannot be investigated against logs rotated out in month 2. Rule 8 restates the same floor more broadly — retain personal data, associated traffic data and processing logs for a minimum of one year from the date of processing — and that applies to everyone, not only the large platform classes.
Evidence: retention configuration per log stream and per store, with the one-year floor visible in the configuration rather than asserted in a policy.
Measure Six: A Security Provision in the Processor Contract
The sixth measure requires an appropriate provision in the contract with any Data Processor requiring the processor to take reasonable security safeguards. This duty is discharged contractually, not technically.
It sits on top of section 8(2) of the Act, under which a Data Fiduciary may involve a Data Processor only under a valid contract. Measure six specifies what that contract carries on the security side, and a generic confidentiality clause does not satisfy it.
Evidence: the clause text, the processors it is in force with, and the dates of the amendments where you had to go back and add it.
Measure Seven: Effective Observance of the Other Six
Rule 6's seventh measure asks for appropriate technical and organisational measures to ensure effective observance of the other 6. It is the clause that turns a set of controls into a programme.
Effective observance means ownership, cadence and escalation: a named owner per measure, a review frequency, a path for exceptions, and a record showing the reviews happened. It is what an assessor reaches for when controls are present on paper and unoperated in practice.
Evidence: the control register, the owners, the review history, and the exception log with expiry dates.
Want rule 6 mapped against the controls you already run?
Share your work email and we'll send a measure-by-measure worksheet for rule 6, marking which of the seven your existing ISO 27001 or SOC 2 evidence already covers and which need new work.
The Retention Floor Hiding Inside a Security Rule
The retention floor inside the security rule is the collision most coverage misses. Measure five makes you keep logs and personal data for a year; your privacy programme, your data minimisation principle and probably your own marketing all point the other way.
Two conflicts follow. The first is with aggressive deletion: teams who spent 2 years shortening log retention to control cost now have a legal floor underneath them, and a 90-day setting is a non-compliance rather than a cost optimisation. The second is with privacy-by-default instincts — an engineer who deletes a record the moment its purpose ends is doing what the rest of the regime trained them to do, and breaching this one.
Separate the two clocks. One year from the date of processing is the floor; purpose limitation sets the ceiling, and where another law requires longer, that period governs. Erasure logic has to check both, which makes retention a per-record computation rather than a per-table TTL. We work through the interaction in DPDP data retention and erasure.
Measure Six Makes This a Vendor Management Problem
Measure six turns rule 6 into a vendor management problem as much as an engineering one. Encryption and logging are things you can ship; a security provision in every processor contract has to be negotiated, with counterparties under no deadline pressure of their own.
List every processor rather than every vendor. A processor is anyone processing personal data on your behalf: the infrastructure providers, and also the support desk tool, the email sender, the offshore QA contractor with a production login, and the subprocessors under each of them. That list runs longer than procurement's register, because procurement tracks spend and rule 6 tracks data.
Then triage. Large providers offer a standard addendum you accept as-is; mid-size vendors negotiate. The long tail is where this stalls, and some of them will not sign — at which point you are choosing between replacing the tool and carrying the exposure knowingly. Start that conversation 12 months out, not 3. The tiering mechanics in our third-party risk guide for SOC 2 carry over.
What ISO 27001 and SOC 2 Work You Can Reuse
An organisation already running ISO 27001 or SOC 2 can reuse most of measures 1 to 4 and 7, and should expect genuinely new work on 5 and 6.
The reusable part is substantial. Cryptographic controls, access provisioning and review, logging and monitoring, restore testing, and the management-system layer of owners, reviews and exceptions all map onto control work you already evidence. With an ISO 27001 certificate the Statement of Applicability is close to a rule 6 crosswalk, and access review and restore test artefacts hand over unchanged.
The honest limits are three. The one-year retention floor is not an ISO or SOC 2 control — both ask you to define retention and meet your own definition, so a shortened period that passes an audit can still breach measure five. The contractual flow-down is narrower and more mandatory than a supplier-security control: ISO expects proportionate supplier risk management, rule 6 expects a specific provision in every processor contract. And scope — your ISMS or trust services scope was drawn around a product, while rule 6 is drawn around personal data wherever it sits, which pulls in HR, recruiting and support systems the certificate never covered.
Treat the certificate as a head start on 5 of the 7, and plan the other 2 as new work.
What Reasonable Security Safeguards Means in India
The phrase "reasonable security safeguards" in India is doing a lot of work, deliberately. The duty in section 8(5) is to take reasonable safeguards to prevent a personal data breach; rule 6 names a floor, and reasonableness scales above it with what you hold and what you are.
So meeting the 7 named measures is necessary and may not be sufficient. A fiduciary holding financial or health data at scale will be judged against a higher standard than a ten-person B2B tool, and no size threshold exempts either from the duty. Nor does any certification discharge it — nobody issues a rule 6 certificate.
The other half of the picture is section 33(2). The Schedule sets ceilings, not tariffs — every entry reads "may extend to" — and the Board must have regard to the nature, gravity and duration of the breach, the type of personal data affected, whether it was repetitive, any gain realised or loss avoided, the mitigation taken and its timeliness, proportionality, and the likely impact of the penalty. Mitigation is written into the statute as a factor. A fiduciary that detected its own incident, contained it, and can show the logs and review records that made detection possible is in a materially different position from one that cannot — the practical argument for measures three and five beyond their text.
DPDP Security Safeguard Questions Teams Ask
These are the DPDP security safeguard questions teams ask most often after reading rule 6 against their own control set.
Yes. The fifth measure requires retention of the logs and the personal data for one year unless another law requires a different period, and rule 8 restates a minimum of one year from the date of processing for personal data, associated traffic data and processing logs. That obligation is not limited to large platforms, so a ninety-day retention policy becomes a non-compliance once the eighteen-month tranche binds.
No. The sixth measure asks for an appropriate provision in the contract with the Data Processor requiring the processor to take reasonable security safeguards. A confidentiality obligation restricts disclosure; it does not require the processor to implement security measures, so it does not discharge measure six. Expect to amend existing agreements rather than rely on what is already signed.
It covers most of it and not all of it. Cryptographic controls, access control, logging and monitoring, backup and recovery, and the management-system layer of owners and reviews map closely onto measures one to four and seven, and that evidence transfers. What does not transfer is the one-year retention floor, which neither ISO 27001 nor SOC 2 imposes, and the mandatory security provision in every processor contract. Scope is the third gap: an ISMS drawn around a product rarely covers employee and candidate data.
That is the Schedule's ceiling for failure to take reasonable security safeguards to prevent a personal data breach under section 8(5), and the highest figure in the Schedule. It is a maximum rather than a tariff — the entry reads "may extend to" — and section 33(2) requires the Board to weigh gravity, duration, the type of data, repetition, gain or loss, mitigation, proportionality and the penalty's impact before fixing an amount. The band attaches only to the security duty: failure to notify a breach is a separate band of up to 200 crore, and most other contraventions fall into a residual band of up to 50 crore.
See rule 6 tracked as seven controls with live evidence
Book a demo and we'll show how Konfirmity maps the seven minimum safeguards to owners, pulls the access and log evidence continuously, and flags a retention setting that drops below the one-year floor.
Book a demo
Build the Evidence While You Build the Controls
Rule 6 will be assessed from evidence, not from architecture diagrams. Build the record as you build each measure — the access review with names and dates, the restore test with a duration, the retention configuration showing a year, the signed processor addendum. Reconstructing 12 months of operation after an incident is not possible, and section 33(2) rewards organisations that can show their working.
Two items should move first, because they have the longest lead times and the least to do with engineering. Raise the retention floor now, since every month on 90-day retention is a month of logs you will not have in May 2027. And open the processor contract conversation now — the vendors who will not sign are the ones you need time to replace.
The Ministry of Electronics and Information Technology is the primary source for the Act and the Rules; check meity.gov.in for notifications rather than relying on circulating summaries, which get the breach clocks and the penalty bands wrong more often than not. Then place rule 6 in the context of the whole regime with the DPDP compliance checklist, which sequences every duty against the same cliff.
