Home / Blog / Dpdp act security requirements
Compliance
DPDP Act security requirements: what Rule 6 and Rule 7 mean for app teams
The DPDP Act asks for reasonable security safeguards and a fast breach notice. Here is what that means for the code you ship, with the evidence to keep.
Cyberlop Labs · Updated · 15 min read
DPDP Act security requirements are the duty under Section 8(5) of the Digital Personal Data Protection Act, 2023 to take reasonable security safeguards against personal data breach. Rule 6 of the 2025 Rules sets the minimum safeguards, Rule 7 requires a Board report within 72 hours of awareness, and penalties reach up to ₹250 crore.
- Section 8(5) of the DPDP Act requires reasonable security safeguards, and Rule 6 lists seven minimums.
- Rule 7 requires a first notice to the Board without delay and a detailed report within 72 hours of awareness.
- Failing the security safeguards can attract a penalty of up to ₹250 crore; failing to notify can attract up to ₹200 crore.
- Rules 6 and 7 come into force eighteen months after publication, in mid-May 2027, while CERT-In's six-hour reporting already applies.
- The Act does not mandate penetration testing by name, but a test with a verified retest is strong evidence of reasonable safeguards.
- Access control, logging of personal data reads and processor contracts are where app teams should start.
The DPDP Act security requirements come down to one duty and one clock. The duty: a Data Fiduciary must take "reasonable security safeguards to prevent personal data breach" (Section 8(5)). The clock: on becoming aware of a breach it must tell the Data Protection Board without delay and give full detail within 72 hours (Rule 7). Rule 6 of the DPDP Rules, 2025 lists the minimum safeguards, and the penalty cap for failing them is up to ₹250 crore.
The Digital Personal Data Protection Act, 2023 (DPDP Act) is India's data protection law. Its security duties are in Section 8, and the DPDP Rules, 2025 (dated 13 November 2025 in the Gazette and announced by the Press Information Bureau on 14 November) say what "reasonable" means in practice. This guide is for the people who must turn those rules into code, tickets and evidence: engineering leads, CTOs, product owners and security or compliance owners. It is a practical reading of the text, not legal advice, so have counsel confirm how it applies to you.
What are the DPDP Act security requirements?
There are four security duties, spread across the Act and the Rules: protect personal data with reasonable safeguards, keep technical and organisational measures that make the Act work, tell people and the Board when a breach happens, and stay answerable for your processors. Each one is short in the Act and more concrete in the Rules.
The duties in the Act: Section 8
Section 8 of the DPDP Act, 2023 is the general-obligations section. The security-relevant parts are:
- Section 8(1): the Data Fiduciary is responsible for compliance, "irrespective of any agreement to the contrary", including for processing done by a Data Processor on its behalf.
- Section 8(2): a Data Processor may be used only under a valid contract.
- Section 8(4): implement appropriate technical and organisational measures to ensure effective observance of the Act and the Rules.
- Section 8(5): protect personal data in your possession or under your control, including data handled by a processor, by taking reasonable security safeguards to prevent a personal data breach.
- Section 8(6): if a breach happens, give the Board and each affected Data Principal intimation in the form and manner prescribed.
Who carries the duty
A Data Fiduciary is whoever decides why and how personal data is processed, alone or with others. In a typical software company that is you, not your cloud host or your analytics vendor. A Data Processor handles data on your behalf. A Significant Data Fiduciary is a fiduciary the Central Government singles out after weighing factors such as how much personal data it handles and how sensitive that data is. It carries extra duties, covered further down.
What counts as a personal data breach
Section 2(u) defines it broadly: unauthorised processing, or accidental disclosure, sharing, alteration, destruction or loss of access, counts if it compromises the confidentiality, integrity or availability of personal data. Note the last part. A ransomware lock-out (loss of availability) and a customer seeing another customer's record (loss of confidentiality) are both data breaches in this sense. See also our plain-English page on the DPDP Act.
When do the DPDP security rules start applying?
Rules 6 and 7 come into force eighteen months after the Rules were published in the Gazette, which puts the date in mid-May 2027. The Rules themselves set a phased start, and the PIB note on the notification confirms "an eighteen-month period for phased compliance".
Commencement of the DPDP Rules, 2025
| Rules | What they cover | In force |
|---|---|---|
| 1, 2 and 17 to 21 | Title, definitions, and the Board's constitution and working | On publication in the Gazette |
| 4 | Registration of Consent Managers | One year after publication |
| 3, 5 to 16, 22 and 23 | Notice, security safeguards (6), breach intimation (7), retention, children's data, Significant Data Fiduciaries (13), and more | Eighteen months after publication |
Source for the table: Rule 1 of the DPDP Rules, 2025 as published in the Gazette of India.
Do not wait for May 2027 to start
Eighteen months sounds long, but an app team needs most of it. Fixing authorisation flaws, adding access logs, and rehearsing a 72-hour notice all touch code and process. Separately, the CERT-In directions of 28 April 2022 already apply to service providers, intermediaries, data centres, bodies corporate and government organisations. They require incident reporting to CERT-In "within 6 hours of noticing" an incident, and logs of ICT systems kept "for a rolling period of 180 days" within Indian jurisdiction, per the CERT-In directions. The DPDP rules add to that, they do not replace it.
DPDP breach rules and CERT-In directions side by side
The two regimes run in parallel, so one incident can start two clocks. This table shows the wording of each.
| Point | DPDP Rules, 2025 | CERT-In directions, 28 April 2022 |
|---|---|---|
| Who must report | Data Fiduciary, to the Board and each affected Data Principal | Service providers, intermediaries, data centres, bodies corporate and government organisations, to CERT-In |
| Report deadline | Board: without delay, then detail within seventy-two hours of becoming aware | Within 6 hours of noticing or being told of the incident |
| Logs | Retain logs and personal data for one year (Rule 6(1)(e)) | Rolling period of 180 days, kept within Indian jurisdiction |
| In force for you | Rules 6 and 7 from mid-May 2027 | Already in force |
What does Rule 6 require, safeguard by safeguard?
Rule 6 requires a Data Fiduciary to protect personal data by taking reasonable security safeguards "which shall include, at the minimum" seven things, items (a) to (g). The words "at the minimum" matter: the list is a floor, and "reasonable" is judged against your size, data and risk. The Rules name no certification, standard or test method.
Rule 6(1) at a glance
| Clause | What the rule says | What it means for an app team |
|---|---|---|
| 6(1)(a) | Data security measures: encryption, obfuscation, masking or virtual tokens tied to the personal data | Encryption at rest, in transit, masking in non-production copies, tokenisation of identifiers |
| 6(1)(b) | Controls on access to the computer resources you or your processor use | Access control in the application and in the cloud, least privilege, MFA on admin access |
| 6(1)(c) | Logs, monitoring and review that show who accessed personal data, so misuse can be detected, investigated and fixed | An audit log of who read or changed personal data, with someone reviewing it |
| 6(1)(d) | Reasonable measures for continued processing if confidentiality, integrity or availability is compromised, such as backups | Tested backups and a recovery plan |
| 6(1)(e) | Retain such logs and personal data for one year, unless another law requires otherwise | One-year log retention, kept lean and protected |
| 6(1)(f) | Appropriate provision in the contract with each Data Processor for reasonable security safeguards | Security clauses in processor and vendor contracts |
| 6(1)(g) | Technical and organisational measures that make the safeguards work in practice | Owners, policies, training and checks that show the controls work |
The clause wording is condensed from Rule 6 of the DPDP Rules, 2025; the right-hand column is our reading, not text from the Rules.
6(1)(a): encryption, masking and tokens
The Rule lists techniques, and says "such as", so none is mandated by name. In practice reviewers look for encryption in transit and at rest, keys held apart from data, and masked or tokenised data in test environments. A production database copied into staging with real names and phone numbers is a common gap. See data classification for deciding what needs which treatment.
6(1)(b): access control
This clause covers "computer resources", which has the meaning given in the Information Technology Act, 2000 (Rule 6(2)). That reaches the application, its APIs, databases, cloud consoles and admin tools. For an app team the most important failure is broken access control: a signed-in account reading or changing another account's data through an IDOR or BOLA flaw. No firewall stops that, because the request looks legitimate.
6(1)(c) and (e): logs you can actually use
Logging is there "for enabling detection of unauthorised access, its investigation and remediation to prevent recurrence". Log reads and exports of personal data, not just logins. Keep them a year, but do not write full personal data into them, or your log store becomes the most valuable thing to steal. Rule 8(3) separately requires retention of personal data, traffic data and logs for a minimum of one year for the purposes in the Seventh Schedule, so check how the two rules apply to your product with counsel.
6(1)(d), (f) and (g): recovery, vendors and proof
Backups are only a safeguard if a restore has been tried. Processor contracts must carry security terms, because Section 8(1) leaves you responsible whatever the contract says. Clause (g) is the catch-all: the safeguards need owners and a way to show they work, which is where testing evidence comes in (see below).
What are the penalties for failing the security safeguards?
The highest penalty in the DPDP Act, up to ₹250 crore, applies to a Data Fiduciary's failure to maintain reasonable security safeguards. Failing to notify the Board or affected individuals of a breach can attract up to ₹200 crore. The PIB note on the DPDP Rules states both figures, and says any other violation can attract up to ₹50 crore.
These are ceilings, not fixed fines, and the Data Protection Board decides each case. Two things follow. First, a leak caused by a missing safeguard and a leak you then hide are penalised separately. Second, the Board can only judge "reasonable" on what you can show, so the quality of your records matters as much as the controls themselves.
How does breach notification work under Rule 7?
Rule 7 sets two notices. Affected individuals must be told "without delay". The Board must get a first notice "without delay" and a detailed one "within seventy-two hours of becoming aware of the breach", or within a longer period the Board allows on a written request. The clock starts when you become aware, not when you finish investigating.
What each notice must contain
| Recipient | Timing | Content required by Rule 7 |
|---|---|---|
| Each affected Data Principal | On becoming aware, without delay, via her user account or a registered mode of communication | What happened (nature, extent, timing); likely consequences for her; measures taken to mitigate risk; safety steps she can take; business contact for queries |
| Data Protection Board, first notice | Without delay | Description of the breach: nature, extent, timing, location and likely impact |
| Data Protection Board, detailed report | Within 72 hours, or longer if the Board allows on written request | Updated detail; broad facts and reasons; mitigation; findings on who caused it; remedial steps to prevent recurrence; a report on the notices given to individuals |
Summarised from Rule 7(1) and 7(2) of the DPDP Rules, 2025.
No materiality threshold in the text
Section 8(6) says "in the event of a personal data breach" and the definition in Section 2(u) has no size floor. Nothing in Rule 7 limits notice to serious breaches, so plan on the basis that any confirmed personal data breach triggers it. Ask counsel how to treat edge cases.
What you must be able to answer in 72 hours
The detailed report asks things you cannot answer without preparation: which accounts were affected, how the attacker got in, and whether the hole is closed. That needs logging and monitoring, an incident response plan with named owners, and a way to prove the fix works. Our page on breach notification covers the wider pattern, and the CERT-In six-hour report runs alongside this one.
Why do application flaws matter most for DPDP security?
Because most personal data is reached through an application, and the application is where the safeguard most often fails. Public data points the same way: vulnerability exploitation is a leading way in, India's breach costs are rising, and broken access control tops the OWASP Top 10 for web apps.
- The Verizon 2026 Data Breach Investigations Report headlines that "31% of breaches now start with software vulnerabilities".
- IBM's Cost of a Data Breach 2025 India findings put the average total cost of a breach in India at INR 220 million, 13% higher than the year before, with an average breach lifecycle of 263 days.
- In the same IBM data the top three initial attack vectors in India were phishing (18%), third-party vendor and supply chain compromise (17%) and vulnerability exploitation (13%).
- The OWASP Top 10:2021 reports that 94% of applications were tested for some form of broken access control, with over 318,000 occurrences in its dataset.
The numbers do not prove your app is weak. They explain why a regulator reading Rule 6(1)(b) and (c) will care about who can reach which record, and whether you would notice. Two of the vectors above (vulnerabilities and vendors) are exactly the ones Rule 6 asks you to control through testing and contracts.
Where the safeguard usually fails in an app
| Failure in the app | Rule 6 clause it undermines | How it is found |
|---|---|---|
| One account can read another's records by changing an id | 6(1)(b) access control | Testing with two or more signed-in accounts; access control testing |
| Personal data in API responses the screen never shows | 6(1)(a) and (b) | Reading raw responses; see excessive data exposure |
| Reads and exports of personal data are not logged | 6(1)(c) visibility | Walk-through of logging for each sensitive route |
| Real data copied into a test environment | 6(1)(a) masking | Data inventory and environment review |
| Hardcoded keys or tokens in the repository | 6(1)(a) and (b) | Secret scanning and code review |
| Vulnerable library on a page that handles personal data | 6(1)(g) organisational measures | SCA and patching process |
Does the DPDP Act require penetration testing?
No. Neither the Act nor the Rules use the words "penetration test" or "VAPT", and neither names a certification or an auditor you must hire. What they require is reasonable safeguards, with Rule 6(1)(g) asking for "appropriate technical and organisational measures to ensure effective observance". A penetration test is the most direct way to show that the access-control and data-protection controls work.
Why testing is still the sensible evidence
If the Board asks why you believed your safeguards were reasonable, "we have a policy" is weak. "We tested the running app, found these access-control flaws, fixed them and re-tested" is stronger. The method is not new: NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment) describes planning and running technical tests and examining the findings, and the OWASP Web Security Testing Guide is a widely used checklist for web apps.
Be careful with claims you read elsewhere
Some compliance pages state that the DPDP Act demands quarterly scans and an annual test by a CERT-In-empanelled firm. The text of the Act and Rules does not say that. Empanelment may matter for some regulated sectors or contracts, so check whether it applies to you rather than assuming; our note on CERT-In empanelled VAPT explains what it does and does not guarantee. For the basics of the process, see what is VAPT and the VAPT checklist.
Black-box, grey-box or white-box for DPDP evidence
All three styles can serve. Black-box shows what an outsider can reach. Grey-box, with test accounts, is the right style for finding one account reaching another's data. White-box adds the code, so a finding points to the file and line. Pick by the question you need answered, and keep the output: scope, date, findings, proof and the retest result.
What should an app team do before May 2027?
Work through eight steps in order: find your personal data, assign owners, close access-control gaps, log reads of personal data, test the running app, prepare the 72-hour notice, tighten processor contracts and keep the evidence. Each one maps to a clause of Rule 6 or 7.
- Inventory personal data. List every store, API field, log, backup and third party that holds it, and tag it by sensitivity. You cannot protect what you have not found.
- Name owners. One person owns each safeguard in Rule 6(1)(a) to (g), and one person owns the breach plan.
- Fix access control first. Review authorisation on each route that returns personal data, using server-side authorisation and ownership checks. Apply least privilege in the cloud and in admin tools.
- Log reads, not only logins. Record who accessed or exported personal data, keep it for a year, and review it on a schedule.
- Test the running app. Run a penetration test with at least two signed-in accounts, and re-test each fix. Repeat after major releases.
- Rehearse the notices. Draft the Rule 7(1) message and the Rule 7(2) report, then run a tabletop exercise against the 72-hour limit.
- Update processor contracts. Add security terms (Rule 6(1)(f)) and a duty to tell you promptly about incidents, so your own clock is not lost waiting on a vendor.
- Keep an evidence file. One folder per clause with the policy, the configuration, the test report and the retest result.
What evidence should you keep for each Rule 6 clause?
Keep the artefact that shows the control exists, the artefact that shows it works, and the date. Evidence made at the time of the work is far more convincing than a reconstruction after an incident.
Evidence pack by clause
| Clause | Shows the control exists | Shows it works |
|---|---|---|
| 6(1)(a) | Encryption and key-management settings; masking rules | Test that staging holds no real personal data; configuration review |
| 6(1)(b) | Role design and admin access list | Penetration test findings on cross-account access, with retest results |
| 6(1)(c) | Logging standard for personal data access | A sample investigation traced end to end from the logs |
| 6(1)(d) | Backup and recovery plan | A restore test with date and outcome |
| 6(1)(e) | Retention setting of one year, with its exceptions | Proof that old logs are removed and current ones are protected |
| 6(1)(f) | Signed processor contracts with security terms | Vendor review or questionnaire on file |
| 6(1)(g) | Policies, owners, training records | Internal audit or management review minutes |
A good test report is part of that file. Our posts on how to read a finding and why exploited findings beat suspected ones explain what proof looks like, and the vulnerability remediation process covers closing findings with a verified fix. Related terms: vulnerability management and closed-loop retest.
What extra duties do Significant Data Fiduciaries have?
Under Rule 13, a Significant Data Fiduciary must, once in every period of twelve months, carry out a Data Protection Impact Assessment and an audit, and have the person who does it send the Board a report with significant observations. It must also check that its technical measures, including algorithmic software, are not likely to pose a risk to Data Principals' rights.
Section 10 of the Act adds a Data Protection Officer based in India and an independent data auditor. Rule 13(4) lets the Government specify personal data that must not be transferred outside India. If you may be notified as significant, treat the annual audit as a fixed event in the calendar and keep test reports ready for the auditor. Our page on regulated industries covers this kind of buyer.
How do processors and vendors change your risk?
They do not move the duty. Section 8(1) keeps you responsible for processing done by a Data Processor "irrespective of any agreement to the contrary". Your analytics tool, support desk, payment gateway and hosting provider can all become part of a breach you must report.
Vendor controls to ask for
- A written security schedule matching the Rule 6(1) clauses.
- A commitment to report incidents quickly enough for you to meet your 72-hour limit.
- The right to see test summaries or audit reports.
- A list of sub-processors, and what data each can reach.
Share only the fields a vendor needs. Data minimisation is also the cheapest security control you have, since data you never send cannot leak from them.
Where does Cyberlop fit in DPDP security work?
Cyberlop does not make you compliant, and no tool can. What it can supply is evidence for Rule 6(1)(b) and (g): findings from testing the running app, each with proof. It finds vulnerabilities in web apps and APIs with black-box, grey-box and white-box pentesting, and in white-box mode it reads your code while testing, so a finding can point to the file and line.
It reports what it actually exploited, with the request, the response and a screenshot where a person can see it. A fix is proven by re-running the exact exploit against the new code. It checks business-logic flaws and cross-account access, and it can run inside your own network through private scanning, so your code does not leave it. See how it works and what the evidence looks like, and use continuous testing to keep it current.
Questions people ask
Dpdp act security requirements: FAQs
What are the security requirements under the DPDP Act?
A Data Fiduciary must protect personal data with "reasonable security safeguards to prevent personal data breach" (Section 8(5)), keep appropriate technical and organisational measures (Section 8(4)), and notify the Board and affected individuals of a breach (Section 8(6)). Rule 6 of the DPDP Rules, 2025 sets the minimum safeguards.
What does Rule 6 of the DPDP Rules require?
Seven minimums: encryption, masking or tokens; access control; logs and monitoring; backups for continued processing; one-year retention of logs and personal data; security terms in processor contracts; and technical and organisational measures to make the safeguards work.
How fast must a data breach be reported under the DPDP Rules?
Affected individuals must be told without delay. The Board gets a first notice without delay and a detailed report within 72 hours of becoming aware, or a longer period if it allows on written request (Rule 7).
If you also fall under the CERT-In directions, the separate duty to report incidents to CERT-In within 6 hours still applies.
What is the penalty for not having reasonable security safeguards under the DPDP Act?
Up to ₹250 crore. Failing to notify the Board or affected individuals of a breach can attract up to ₹200 crore, and other violations up to ₹50 crore, according to the PIB note on the Rules. These are ceilings set by the Act, and the Board decides each case.
Is penetration testing mandatory under the DPDP Act?
Not by name. The Act and Rules do not mention penetration testing or VAPT, or require a particular auditor. A penetration test with a verified retest is, though, strong evidence that your access-control and data-protection safeguards are reasonable and effective.
When do the DPDP security and breach rules come into force?
Rules 6 and 7 start eighteen months after the Rules were published in the Gazette in November 2025, so in mid-May 2027. Rules 1, 2 and 17 to 21 applied on publication, and Rule 4 starts after one year.
Does the DPDP Act apply to a small SaaS startup?
Yes, if it decides why and how personal data is processed, it is a Data Fiduciary regardless of size. Extra duties apply only to those notified as Significant Data Fiduciaries. Check the Act and Rules for exemptions that may apply to you with counsel.
Do DPDP and CERT-In both apply to the same breach?
They can. The CERT-In directions of 28 April 2022 require reporting of specified cyber incidents within 6 hours and 180 days of log retention. DPDP Rule 7 covers personal data breaches and adds notice to individuals and the Board. Plan one process that satisfies both.
Sources
Where the facts come from
- PIB: DPDP Rules, 2025 Notified (17 November 2025)
- MeitY: Digital Personal Data Protection Rules, 2025 (Gazette)
- MeitY: Digital Personal Data Protection Act, 2023
- CERT-In: Directions under section 70B(6) of the IT Act, 28 April 2022
- Verizon: 2026 Data Breach Investigations Report
- IBM: Cost of a Data Breach Report 2025, India findings
- OWASP: Top 10:2021, A01 Broken Access Control
- NIST: SP 800-115, Technical Guide to Information Security Testing and Assessment
- OWASP: Web Security Testing Guide
Keep reading
Related articles
Access control testing checklist: sideways, upward and across tenants.
A step-by-step access control testing checklist for web apps and APIs: account planning, sideways, upward and cross-tenant checks, evidence and retests.
CERT-In empanelled VAPT: who needs it, and how to check one
Who really needs a CERT-In empanelled VAPT, what the 2022 directions and 2025 audit guidelines say, how to verify an auditor, and what it does not guarantee.
Continuous penetration testing: how to run it alongside your annual pentest
What continuous penetration testing really means, how it compares with annual pentests, DAST and PTaaS, and how to run both in your pipeline.
Show your safeguards work
Cyberlop tests your running app and reports only what it actually exploited, with the request, the response and the line of code, then proves each fix by re-running the exploit. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.