Of all the obligations in the DPDP Act, the duty to implement reasonable security safeguards is the one that carries the most financial weight. The largest penalty in the Act — up to ₹250 crore — attaches to failing to secure personal data that then suffers a breach. That makes security the single highest-leverage area of any compliance effort.
For a long time 'reasonable security' was a vague standard. The 2025 Rules changed that, pointing to concrete measures that give the obligation real substance and let organisations build to a defined target rather than guess.
This guide explains what reasonable security safeguards mean under the Act and the Rules, the specific measures expected, how the duty extends to processors, and how to turn it into an auditable programme.
Why security carries the heaviest penalty
The Act's penalty structure is deliberate. By attaching its highest ceiling — ₹250 crore — to security failures that lead to a breach, it signals that protecting data in your custody is the obligation the regulator takes most seriously.
This reflects reality: the harm from a breach — identity theft, fraud, distress — falls on individuals, and the Act holds the custodian responsible for preventing it.
For leadership, the practical consequence is clear: security is not an IT line item but a board-level risk, and underinvesting in it is the most expensive mistake a fiduciary can make.
Framing security as enterprise risk also unlocks the budget and authority it needs. When leadership understands that a single lapse can cost up to ₹250 crore, security stops competing for scraps and gets treated with the seriousness the exposure warrants.
Encryption and masking
The Rules point to encryption, masking or comparable measures that render personal data unintelligible to unauthorised parties. Encrypting data both at rest and in transit is a baseline expectation, not an advanced nicety.
Masking and tokenisation help where full data is not needed — showing only the last digits of an identifier, for instance — reducing the data exposed in everyday use.
A failure to encrypt can be treated by the Board as a fundamental lapse in the duty to protect personal data, so it is among the first things to get right.
Key management is the often-overlooked companion to encryption. Encrypted data protected by poorly managed or widely shared keys offers little real protection, so handling keys securely is as important as turning encryption on in the first place.
Access control and authentication
Restricting who can access personal data is central. The Rules point to strong access controls and multi-factor authentication, ensuring that only authorised people, with verified identities, can reach sensitive data.
The principle of least privilege — giving each person only the access their role requires — limits both accidental and malicious exposure, and makes breaches easier to contain.
Access control should extend to administrative and developer access, which is often the most powerful and the most overlooked. Strong identity management here is part of the dpdp compliance foundation.
Regular access reviews keep this control honest over time. Permissions accumulate as people change roles, and a periodic review that strips access no longer needed is what prevents the slow drift toward everyone being able to see everything.
Logging and monitoring
The Rules expect logs to be maintained, with retention of at least one year, so that access and activity can be reviewed and a breach reconstructed. Logging is what makes the 72-hour breach-reporting duty achievable.
Without logs, an organisation cannot say what happened, when, or to whom — which makes both breach response and the required notifications nearly impossible.
Monitoring on top of logging turns passive records into active defence, surfacing anomalies before they become full-blown incidents.
Logs are only useful if they are protected and actually reviewed. Tamper-resistant storage and alerting turn a passive archive into a genuine control, and they are what let you reconstruct an incident accurately when the 72-hour clock is running.
Backups and resilience
Reasonable security includes the ability to restore data after an incident. Regular, secure backups protect against ransomware, accidental deletion and corruption, supporting both availability and the integrity of personal data.
Backups themselves must be secured, since a poorly protected backup is just another copy of the data waiting to be breached. They should be encrypted and access-controlled like any production store.
Resilience also intersects with retention: backups should not become a place where data you were supposed to delete lives on indefinitely.
Periodically testing your restores is what separates a real backup strategy from a theoretical one. Many organisations discover only during an incident that their backups were incomplete or unrecoverable, exactly when they can least afford the surprise.
Safeguards extend to processors
Your security duty does not stop at your own perimeter. Because you remain accountable for data held by your processors, you must ensure they apply appropriate safeguards too, through contract and oversight.
This means assessing a processor's security before onboarding, requiring equivalent measures in the data processing agreement, and maintaining visibility into the sub-processor chain.
A breach at a processor is, in compliance terms, your breach to report and answer for, so processor security is an extension of your own.
Documenting processor security in your contracts and reviews also gives you a ready answer when customers run their own due diligence on you. Your security is only as strong as your weakest vendor, so this oversight protects your reputation as well as your compliance.
Free resource
DPDP Evidence Tracker
A ready-to-use tracker for the records and evidence the Act and the 2025 Rules expect you to keep.
From safeguards to evidence
The Act effectively rewards organisations that can demonstrate, not just assert, that safeguards are in place and operating. That means keeping evidence: configuration records, access reviews, log retention, test results and incident drills.
If a breach occurs, the difference between a manageable outcome and a maximal penalty often comes down to whether you can show you took reasonable measures in good faith.
Maintaining an evidence trail — ideally in a structured tracker — turns your security posture from a claim into something you can prove on request.
A structured evidence tracker turns this from a scramble into a routine. Recording configurations, access reviews, test results and drills as you go means that, if the Board ever asks, your proof of reasonable safeguards is already assembled.
Building an auditable security programme
The practical goal is a security programme that is not only effective but auditable: defined controls, assigned owners, regular reviews, and evidence that each control operates as intended.
Frameworks like ISO 27001 map closely onto these expectations, so organisations with existing certifications can reuse much of that work to evidence DPDP safeguards.
Approached this way, security compliance is not a separate burden but the same disciplined protection any sensitive system deserves — with the added benefit of shielding you from the Act's heaviest penalties.
Reusing existing assurance work is the efficient path here. If you already hold ISO 27001 or run a SOC 2 programme, much of the evidence the DPDP regime expects is a mapping exercise away, which is a natural part of joined-up DPDP compliance.
Free consultation
Need help getting DPDP-ready?
Talk to our compliance team — we’ll map your gaps against the Act and the 2025 Rules.