DPDP Rules 2025 compliance checklist: the security safeguards CISOs must prove by May 2027

Most DPDP projects start in the legal team. They produce consent notices, privacy policies and a data map, and then someone asks the CISO a short question: "Can we prove our safeguards are reasonable?" That question is harder than it sounds. The DPDP Rules do not ask you to own a list of tools. They ask you to protect personal data well enough to prevent a breach, and to show your work when the Data Protection Board comes asking. This guide reads Rule 6 and Rule 7 the way a security team would: what each line asks for, what good evidence looks like, and how testing turns a policy into proof.

Last reviewed on 15 October 2026 against the DPDP Rules, 2025 (G.S.R. 846(E)), the DPDP Act, 2023, and PIB releases.

What do the DPDP Rules 2025 require from security teams?

The DPDP Rules 2025 require security teams to put in place at least seven safeguards under Rule 6, from encryption and access control to one-year log retention and processor contracts, and to run a breach process under Rule 7 that informs affected people and the Data Protection Board, with a detailed Board report within 72 hours.¹

The Digital Personal Data Protection Act, 2023 (the DPDP Act) sets the duties. The Rules fill in the detail. Two lines in the Act matter most to a security team. Section 8(5) says a Data Fiduciary "shall protect personal data in its possession or under its control" by "taking reasonable security safeguards to prevent personal data breach", and this includes processing done on its behalf by a Data Processor. Section 8(6) says that after a breach, the Data Fiduciary must inform the Board and each affected Data Principal.⁴

Key terms in plain words

Data Fiduciary: the organisation that decides why and how personal data is processed (your company). Data Processor: a vendor that processes data for you, such as a cloud, payroll or call centre provider. Data Principal: the person the data is about. Board: the Data Protection Board of India, which inquires into breaches and sets penalties.

Rule 6 then says what "reasonable security safeguards" must include "at the minimum". Rule 7 sets out who you tell after a breach, what you tell them, and by when. Rule 13 adds extra duties for Significant Data Fiduciaries, the large or sensitive processors that the government names.¹

Why this lands on the security team

Legal can write a notice. Only the security team can show that encryption is on, that access is limited, that logs exist for a year, and that the breach clock can be met. The penalty for failing the safeguard duty is also the largest one in the Act: up to ₹250 crore.⁴ That is why this is a security budget question as much as a legal one.

When do the DPDP Rules take effect?

The DPDP Rules take effect in three phases. Rules 1, 2 and 17 to 21 applied on publication on 13 November 2025. Rule 4 on Consent Managers applies after one year. Rules 3, 5 to 16, 22 and 23, which include security safeguards and breach intimation, apply after eighteen months, which means 13 May 2027.¹

The Rules carry the Gazette number G.S.R. 846(E) and are dated 13 November 2025. The government announced them on 14 November 2025 and said the Rules give "an eighteen-month period for phased compliance".²³ The Act itself received Presidential assent on 11 August 2023, after Parliament passed it earlier that week.⁵

Some law firms count "after" differently and give 14 November 2026 and 14 May 2027 as the dates.⁶ A one-day gap does not change a project plan. Treat 13 May 2027 as the date your evidence must be ready, not the date you start.

Could the deadline move earlier?

In January 2026, Business Standard reported that MeitY was considering a cut from 18 months to 12 months for some provisions, mainly for Significant Data Fiduciaries. It was a proposal, and industry pushed back.⁷ When we reviewed the text for this guide, we did not find a notified amendment that changes the dates above. Keep a watch on the MeitY site, because a shorter clock would put some firms in scope sooner.

What are "reasonable security safeguards" under Rule 6?

Reasonable security safeguards under DPDP Rule 6 are the minimum controls a Data Fiduciary must use to prevent a personal data breach: encryption, obfuscation, masking or virtual tokens; access control; logs, monitoring and review; continuity and backups; one-year retention of logs; security clauses in processor contracts; and measures that make these controls work.¹

Rule 6(1) applies to personal data "in its possession or under its control", including processing done for you by a Data Processor. So the scope is not just your data centre. It covers your cloud tenants, your SaaS tools and your vendors. Rule 6(2) says "computer resource" has the same meaning as in the Information Technology Act, 2000, which covers computers, networks, software and databases.¹

The Rule uses the word "appropriate" again and again. It does not name a product, an algorithm or a test. That gives you room to choose controls that fit your risk. It also means the burden sits with you to show your choice was reasonable. The table below turns each clause into evidence and a test.

Clause (a): encryption is an example, not the whole answer

The Rule says data security measures "such as" encryption, obfuscation, masking or the use of virtual tokens.¹ Encryption at rest protects a stolen disk. It does not protect data from an attacker who logs in as a real user. That is why clause (a) only works alongside clause (b). Tokens and masking matter most in the places teams forget: test databases, analytics exports, support tools and log files that capture full records.

Clause (b): access control is where most breaches start

Access control covers the computer resources used by you or your Data Processor. In practice, attackers rarely need to break encryption. Phishing, including voice and SMS phishing, was the most common first step in Indian breaches in IBM's 2026 study, at 19%.⁹ Stolen or guessed logins turn into valid access, which is why our guide on how attackers log in instead of breaking in is a useful companion to this clause.

Clauses (c) and (e): logs you can use a year later

Clause (c) asks for visibility "through appropriate logs, monitoring and review", so you can detect unauthorised access, investigate it and fix it.¹ Speed matters here. CrowdStrike measured an average eCrime breakout time of 29 minutes in its 2026 report, with the fastest at 27 seconds.¹² Logs that nobody reviews do not meet the word "monitoring". Clause (e) then asks you to keep those logs for one year. Rule 8 separately asks Data Fiduciaries to keep personal data, related traffic data and processing logs for at least one year for purposes listed in the Rules.¹

Clause (d): continuity means backups an attacker cannot reach

The Rule names data backups as one way to keep processing going if data is destroyed or access is lost.¹ A backup that sits on the same domain as production is not much of a safeguard against ransomware. Good evidence is a restore test with a start time, an end time and the name of the person who ran it.

Clause (f): your vendors are inside your scope

Section 8(5) makes you responsible for processing "on its behalf by a Data Processor".⁴ Verizon's 2026 report found third-party involvement in 48% of breaches, up 60%.¹¹ A contract clause is a start. Testing the actual connections your vendors use is how you find the gaps a clause cannot close.

Clause (g): the clause that asks for proof

Clause (g) asks for measures "to ensure effective observance of security safeguards".¹ Read plainly, it is not enough to have the controls. You need a way to know they are working. That is where testing comes in, and we cover it in its own section below.

How does DPDP breach notification work?

DPDP breach notification under Rule 7 has two tracks. The Data Fiduciary must tell each affected Data Principal without delay, in plain terms. It must also inform the Data Protection Board without delay, then send the Board a detailed report within 72 hours of becoming aware of the breach, unless the Board allows more time.¹

Track 1: telling each affected person

Rule 7(1) says the notice goes to each affected Data Principal "without delay", through their user account or a contact mode they registered. The notice must cover:¹

• what happened, including the nature, extent and timing of the breach;
• the consequences likely to affect that person;
• what you have done, or are doing, to reduce the risk;
• the safety steps the person can take; and
• contact details of someone who can answer their questions.

The government's own summary says the notice must be in plain language and explain the nature and possible consequences of the breach.²

Track 2: informing the Board

Rule 7(2) asks for two steps. First, an intimation "without delay" with a description of the breach. Second, within seventy-two hours of becoming aware of it, or a longer period the Board allows on a written request, a detailed report with updated facts, the events and cause, mitigation steps, findings about who caused it, remedial steps to stop it happening again, and a report on the notices sent to affected people.¹

What the 72 hours depend on

The 72-hour report needs facts: which systems, which records, which people, and how the attacker got in. You can only produce those facts fast if clause (c) logs exist and cover the right systems. Without them, the report will say "under investigation" in too many places. IBM found that Indian organisations without security AI and automation took 236 days to identify a breach and another 75 days to contain it.⁹ Rule 7 assumes you will know much sooner.

What are the DPDP penalties?

DPDP penalties are set in the Schedule to the DPDP Act. Failing to take reasonable security safeguards can cost up to ₹250 crore. Failing to notify the Board or affected people of a breach, or breaching duties on children's data, can cost up to ₹200 crore each. Significant Data Fiduciary lapses can cost up to ₹150 crore.⁴

The full Schedule has seven items:⁴

1. Reasonable security safeguards under Section 8(5): up to ₹250 crore.
2. Breach intimation to the Board or affected people under Section 8(6): up to ₹200 crore.
3. Additional duties for children's data under Section 9: up to ₹200 crore.
4. Additional duties of Significant Data Fiduciaries under Section 10: up to ₹150 crore.
5. Duties of Data Principals under Section 15: up to ₹10,000.
6. Breach of a voluntary undertaking accepted by the Board: up to the amount for the original breach.
7. Any other breach of the Act or Rules: up to ₹50 crore.

The government's backgrounder repeats the headline amounts: up to ₹250 crore for security safeguard failures, up to ₹200 crore for breach notice and children's data failures, and up to ₹50 crore for other violations.³

How the Board decides the amount

These are maximums, not fixed fines. Under Section 33, the Board sets a penalty after an inquiry and must weigh factors such as the nature, gravity and duration of the breach, the type of personal data affected, whether it was repeated, and the action taken to reduce its effects, including how quickly and how well it was done.⁴ That last factor is where security evidence helps. A team that can show tested safeguards and a fast, complete Rule 7 report is in a very different position from one that cannot.

The penalty is a ceiling. Your evidence decides how close you get to it.Arxiis Research

The larger cost is often the breach itself. IBM put the average Indian breach at ₹25.5 crore in 2026, up 15.9% on the year before, and financial services breaches in India averaged INR 409 million, about ₹40.9 crore.⁹ The global average was USD 4.99 million.¹⁰

What extra duties do Significant Data Fiduciaries have?

Significant Data Fiduciaries have extra duties under Section 10 of the DPDP Act and Rule 13: appoint a Data Protection Officer based in India, appoint an independent data auditor, run a Data Protection Impact Assessment and audit every twelve months, check that algorithmic software does not put people's rights at risk, and keep specified data inside India.⁴¹

The Central Government decides who is a Significant Data Fiduciary (SDF). Section 10(1) lets it notify a Data Fiduciary, or a class of them, based on factors such as the volume and sensitivity of personal data, the risk to Data Principals, and risks to the sovereignty of India, electoral democracy, the security of the State and public order.⁴ Large banks, insurers and platforms should plan as if they may be named.

What Rule 13 adds for security teams

• Yearly DPIA and audit. Rule 13(1) asks an SDF to carry out a Data Protection Impact Assessment and an audit once in every twelve months.¹ An audit that looks at Rule 6 will ask for the evidence in the table above.
• Report to the Board. Rule 13(2) asks the SDF to make sure the person who ran the DPIA and audit gives the Board a report with the significant observations.¹
• Algorithm checks. Rule 13(3) asks an SDF to verify that technical measures, including algorithmic software used to process personal data, are not likely to pose a risk to Data Principals' rights.¹
• Data localisation for specified data. Rule 13(4) asks an SDF to make sure personal data specified by the government, on the advice of a committee, is not moved outside India.¹

The penalty for breaching the added SDF duties can reach ₹150 crore, on top of any penalty for the safeguard failure itself.⁴ Many SDF candidates are also regulated by RBI or SEBI, and those rules already require testing. See our breakdown of the RBI Cyber Security Directions 2026 VAPT rules for banks and NBFCs to line up both sets of evidence.

How does security testing prove your safeguards work?

Security testing proves DPDP safeguards work by attacking them the way a real adversary would and recording what held and what failed. A penetration test shows whether encryption, access control, logging and backups stop or reveal an attack, which is the evidence Rule 6(1)(g) and a yearly SDF audit look for.¹¹³

A policy says "we control access". A test shows whether a phished user can reach the customer database in an afternoon. NIST SP 800-115 describes technical testing as a way to find weaknesses and check that controls are in place and working, not just documented.¹³ That is the same idea as clause (g).

Map each test to a clause

1. Start from the data map. List the systems that store or process personal data, including vendor connections. Those systems are your test scope.
2. Test the way in. Check external exposure and exploitable flaws. Exploitation of vulnerabilities was the top way into breaches in Verizon's 2026 report, at 31%.¹¹
3. Test access control (clause b). Try weak passwords, missing MFA, excess privileges and paths from a normal user to admin.
4. Test detection (clauses c and e). Record the time of each attack step and check it against your alerts and logs.
5. Test data protection (clause a). When you reach a data store, check whether the data you see is encrypted, masked or tokenised.
6. Test resilience (clause d). Check whether an attacker with high privileges could reach, change or delete backups.
7. Fix, retest and file the evidence. A finding closed without a retest is a claim, not proof.

Two related guides help here. If your team is choosing between scans and attack-based tests, read vulnerability assessment vs penetration testing. If you are building the budget line, see our guide to VAPT cost in India in 2026.

How often should you test?

The DPDP Rules do not set a test frequency. Rule 13 sets a twelve-month cycle for SDF audits, and sector rules often set their own cadence.¹ Safeguards change every time a system, vendor or access rule changes, so a single test a year leaves long gaps. Our piece on the 363-day blind spot explains why testing after major changes matters as much as the annual test.

The DPDP security compliance checklist

A DPDP Rules 2025 compliance checklist for security teams turns Rule 6 and Rule 7 into tasks with owners and evidence: a data map, encryption and masking, access control, logging with one-year retention, isolated backups, processor clauses, a 72-hour breach runbook, and regular testing with retests, all ready before 13 May 2027.¹

• Map personal data. List every system, database, SaaS tool, export and vendor that holds personal data, with an owner for each. (Rule 6(1) scope)
• Encrypt stores and connections. Record the setting for each personal data store and each network path. (Rule 6(1)(a))
• Mask or tokenise non-production copies. Cover test, analytics, support tools and log files. (Rule 6(1)(a))
• Manage keys. Keep a record of who can use and rotate encryption keys. (Rule 6(1)(a))
• Enforce MFA and least privilege. Start with admins, remote access and apps that hold personal data. (Rule 6(1)(b))
• Review access on a schedule. Keep signed review records and remove leavers quickly. (Rule 6(1)(b))
• Control privileged and service accounts. Inventory, vault and monitor them. (Rule 6(1)(b))
• Log access to personal data. Send logs from every mapped system to a central platform. (Rule 6(1)(c))
• Alert and review. Write alert rules for unusual access and keep review tickets. (Rule 6(1)(c))
• Keep logs for one year. Set retention, size the storage, and restrict deletion. Check CERT-In's 180-day rule too. (Rule 6(1)(e))
• Isolate and test backups. Run a timed restore and keep the record. (Rule 6(1)(d))
• Update processor contracts. Add safeguard and breach-notice clauses for every Data Processor. (Rule 6(1)(f))
• Assess vendor access. List vendor accounts and integrations and include them in testing. (Rule 6(1)(f))
• Write the Rule 7 runbook. Name owners for the Board intimation, the 72-hour report and user notices. (Rule 7)
• Prepare notice templates. Cover the five items Rule 7(1) requires in plain language. (Rule 7(1))
• Align with CERT-In. Put the 6-hour CERT-In report and the DPDP steps in one incident timeline. (Rule 7 and CERT-In directions)
• Drill the breach clock. Run a tabletop exercise at least once a year and time each step. (Rule 7)
• Test the safeguards. Run a penetration test or red team exercise, fix the findings and retest. (Rule 6(1)(g))
• Build an evidence pack. Keep one folder per clause with settings, reports and dates, ready for an audit or Board inquiry. (Rule 6(1)(g), Rule 13)

Common gaps in DPDP security readiness

Common gaps in DPDP security readiness across the industry are incomplete data maps, unmasked personal data in test and analytics systems, logs kept for less than a year, vendor contracts without safeguard clauses, untested backups, breach plans that ignore the 72-hour Board report, and safeguards that have never been tested by an attacker.

1. The data map stops at production

Teams map the core application and forget the copies: a reporting database, a CSV export on a shared drive, a CRM, a call recording store. Every Rule 6 control is only as good as the list of systems it covers.

2. Test data is real data

Developers copy production to test so bugs are easier to reproduce. Those environments rarely have the same access controls or logging. Clause (a) names masking and virtual tokens for a reason.

3. Logs exist but are not kept or read

Many log platforms default to 30 or 90 days to save cost. Rule 6(1)(e) asks for one year, and CERT-In asks for 180 days of ICT system logs within India.¹⁸ Retention without review also misses the "monitoring and review" part of clause (c).

4. Vendors sit outside the programme

Contracts signed years ago rarely mention reasonable safeguards or breach notice timing. With third parties involved in 48% of breaches in Verizon's 2026 data, this gap is not theoretical.¹¹

5. Backups have never been restored under pressure

A backup job that reports "success" is not the same as a restore that works in hours. Ransomware groups look for backups early, often with the same admin rights they used to get in.

6. The breach plan predates DPDP

Older incident plans focus on CERT-In and sector regulators. Many lack the user notice template, the Board intimation step and a named owner for the 72-hour report.

7. Safeguards are documented, not proven

Policies say MFA is on everywhere. A test finds the one legacy VPN that skips it. Clause (g) is the reminder that effective observance needs evidence from testing, not just from paperwork.

Sources

1. Ministry of Electronics and Information Technology (MeitY), "Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E))", Gazette of India, 13 November 2025. https://www.meity.gov.in/documents/act-and-policies/digital-personal-data-protection-rules-2025
2. Press Information Bureau, "Digital Personal Data Protection (DPDP) Rules, 2025", 14 November 2025. https://www.pib.gov.in/PressReleasePage.aspx?PRID=2190014
3. Press Information Bureau, "DPDP Rules, 2025 Notified (backgrounder)", 17 November 2025. https://www.pib.gov.in/PressReleasePage.aspx?PRID=2190655
4. Ministry of Law and Justice, "The Digital Personal Data Protection Act, 2023 (No. 22 of 2023)", Gazette of India, 11 August 2023. https://egazette.gov.in/WriteReadData/2023/248045.pdf
5. PRS Legislative Research, "The Digital Personal Data Protection Bill, 2023 (bill track)", August 2023. https://prsindia.org/billtrack/digital-personal-data-protection-bill-2023
6. Shardul Amarchand Mangaldas & Co, "Enforcement of the DPDP Act and notification of the DPDP rules", 21 November 2025. https://www.amsshardul.com/insight/enforcement-of-the-dpdp-act-and-notification-of-the-dpdp-rules/
7. Business Standard, "Meity may cut compliance timeline for key DPDP rules to 12 months", 22 January 2026. https://www.business-standard.com/technology/tech-news/meity-may-cut-compliance-timeline-for-key-dpdp-rules-to-12-months-126012201293_1.html
8. CERT-In, "Directions under sub-section (6) of section 70B of the Information Technology Act, 2000", 28 April 2022. https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf
9. IBM India, "India Records its Highest Average Cost of a Data Breach at INR 255 Million (INR 25.5 Crore) in 2026", 3 August 2026. https://in.newsroom.ibm.com/India-Records-its-Highest-Average-Cost-of-a-Data-Breach-2026
10. IBM, "IBM Study: One in Four Malicious Breaches are AI-Enabled, Costing Companies $6 Million on Average", 29 July 2026. https://newsroom.ibm.com/2026-07-29-ibm-study-one-in-four-malicious-breaches-are-ai-enabled,-costing-companies-6-million-on-average
11. Verizon, "2026 Data Breach Investigations Report (news release)", 19 May 2026. https://www.verizon.com/about/news/breach-industry-wide-dbir-finds
12. CrowdStrike, "2026 Global Threat Report", 2026. https://www.crowdstrike.com/en-us/global-threat-report/
13. NIST, "SP 800-115: Technical Guide to Information Security Testing and Assessment", September 2008. https://csrc.nist.gov/pubs/sp/800/115/final