Last verified: 8 May 2026
On the morning of 20 September 2024, a leading listed Indian health insurer (market capitalisation around USD 4 billion, roughly 30 million policyholders on the books) filed a stock-exchange disclosure that reads, in retrospect, like a regulatory training manual. Customer data, the disclosure said, had been compromised. By the time the Sunday boardroom call wrapped up, sample policy records, claim histories, Aadhaar numbers and clinical images were already being circulated through Telegram bots. The threat actor demanded USD 68,000. The company refused. It is exactly the kind of incident that India’s DPDP Rules 2025, notified barely 14 months later, were designed to govern.
Now, here’s where the math gets uncomfortable. Roughly 30 million policyholders. Health data, which sits in the most sensitive category any privacy regulator anywhere takes seriously. Re-leaks reported through 2025, each one a fresh news cycle. By May 2026, the matter is the most-cited cautionary tale in Indian privacy commentary. And yet, when the breach landed, the regime that would have actually bitten (Phase 3 of the DPDP Rules) was still nearly three years away from full enforcement. That delta (the gap between what existed and what arrived in November 2025) is the entire reason this guide had to be written.
Translate the breach into the Rules vocabulary, and the operational picture sharpens fast. Under Rule 6, the company would have owed encryption, access controls and a one-year log retention floor. Under Rule 7, a 72-hour Data Protection Board notification plus per-Data Principal notice. Under Rule 13, a 30-million-policyholder health insurer is a textbook candidate for Significant Data Fiduciary status (DPIA, an India-based Data Protection Officer, algorithmic due diligence). Under Section 33 of the parent Act, the aggregate penalty cap is INR 250 crore. Each of those provisions is now live (or about to be) and each one rewrites the cost-benefit calculus of casual data handling.
Here’s the thing every reader of this guide arrives with: the same five questions, regardless of role. What changed in November 2025? What must my business actually do, by when? What happens if a breach lands on my desk on a Tuesday morning? How do the dual reports (CERT-In’s six-hour rule and the DPB’s 72-hour rule) reconcile without one contradicting the other? And what does the realistic INR-bill look like (gap-assessment, DPO, RegTech, audits, insurance) for a mid-market Indian company that doesn’t run a Big-4 budget? This guide answers each in operational detail, anchored in the text of the Rules.
The DPDP Rules 2025 are subordinate rules under India’s Digital Personal Data Protection Act 2023. Notified on 13 November 2025, they operationalise the Act in three phases: the Data Protection Board took effect immediately, Consent Manager registration opens 13 November 2026, and substantive obligations on every Indian Data Fiduciary become enforceable from 13 May 2027, with penalties up to INR 250 crore.
What follows is the playbook. Skim the Table of Contents, then drop into the section your job actually needs first.
What changed on 13 November 2025: the DPDP Rules 2025 vs the DPDP Act 2023
Why did India wait two full years between enacting a Data Protection Act and giving it teeth? The short answer: an Act without subordinate rules is a manifesto, not a regime. The Digital Personal Data Protection Act, 2023 was passed in August 2023 with most operative duties (notice format, consent mechanics, breach reporting timelines, Significant Data Fiduciary criteria, cross-border transfer mechanics) explicitly conditioned on rules to be made by the Central Government under Section 40 of the Digital Personal Data Protection Act, 2023. Until those rules dropped, every “operationalise me later” provision sat in suspended animation. The 13 November 2025 notification, published in the Gazette of India Extraordinary as the Gazette notification of 13 November 2025, ended that suspension.
So what actually changed on the night of 13 November 2025? Three things, structurally. First, the enabling provisions of the Act (Sections 2, 6 and 7, plus the broader definitional and rights architecture) were paired with mechanical rules: how to draft a Rule 3 notice, how a Consent Manager registers, how a breach is reported, what counts as a reasonable security safeguard. Second, the Data Protection Board of India was operationalised under Rule 16 of the Digital Personal Data Protection Rules, 2025, with procedural rules (Rule 17) tucked alongside. Third, the substantive obligations on Data Fiduciaries (those flowing from Sections 11 to 15, Section 16 cross-border, and the Section 33 penalty matrix) were placed on a phased timeline ending 13 May 2027.
The legislative arc, for those who want the longer view, runs through the legislative history of the DPDP Bill. India tried, and abandoned, two earlier draft Personal Data Protection bills (2019 and 2021) before withdrawing the JPC version in August 2022. The November 2022 redraft became the 2023 Act. And the 2023 Act, in turn, sat in regulatory limbo until the January 2025 draft Rules opened a public-consultation window that closed 18 February 2025 and produced the final text notified ten months later.
Why does the gap between Act and Rules matter at the founder level? Because most general counsel teams in India spent 2024 and the first half of 2025 in a holding pattern. Notice templates were drafted but not deployed. DPA addenda were negotiated but kept in legal-hold. Consent flows were redesigned but not pushed live. The 13 November 2025 notification is what flipped that work from “drawer” to “production”. For the inter-platform data-sharing question that originally surfaced in Karmanya Singh Sareen v. Union of India, (2017) 10 SCC 268 (the 2016 challenge to a major messaging-platform privacy update that triggered the policy push for an Indian privacy law in the first place), the Rules now provide the operational answer the courts couldn’t.
A common founder question, asked on every Slack channel between November 2025 and May 2026: “Did the Act not already apply to us?” The honest answer is: the definitional framework did, but the substantive operational duties (the ones with penalties attached) were stayed pending these Rules. The trap to avoid is the inverse assumption: that everything in the Act is now live. It is not. Phase 3 (13 May 2027) is the cliff. Until then, what is mostly live is the regulator (the DPB), not the substance.
Constitutional pedigree: Puttaswamy to SPDI to DPDP
Where, exactly, does an Indian business’s privacy obligation come from? Not from the DPDP Act alone. The constitutional pedigree of every clause in the 2023 Act and the 2025 Rules runs through Article 21 and the Justice K.S. Puttaswamy (Retd.) v. Union of India, (2017) 10 SCC 1 decision. In that decision, the 2017 nine-judge bench unanimously held that the right to privacy is a fundamental right under Articles 14, 19 and 21, expressly overruling the older positions in M.P. Sharma v. Satish Chandra (1954) and Kharak Singh v. State of Uttar Pradesh (1962). That ruling didn’t create the DPDP regime by itself, but it set the constitutional floor that every subsequent statute had to meet, and it crystallised the four-prong proportionality test (legitimate aim, rational nexus, necessity, balancing) that returns later in the penalty-quantum analysis.
Before Puttaswamy, India did have a digital data-protection regime, but it was sparse. Section 43A of the Information Technology Act, 2000 inserted in 2008 created a civil-compensation right for negligent handling of “Sensitive Personal Data or Information” by a body corporate. Section 72A criminalised disclosure of personal information in breach of contract. The 11 April 2011 Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules (the “SPDI Rules”) put names to categories: passwords, financial information, health, biometrics, sexual orientation. For deeper context on the SPDI Rules and the broader pre-DPDP framework, the iPleaders hub-page on data protection laws in India walks through the older regime in detail.
The chronology, condensed for orientation. 2000: IT Act enacted. 2008: Sections 43A and 72A inserted. 2011: SPDI Rules notified. 2012: the government-appointed expert group on privacy submitted its report. 24 August 2017: Puttaswamy delivered. 27 July 2018: the expert committee chaired by a former Supreme Court judge tabled the first draft Personal Data Protection Bill. December 2019, then 2021: PDP Bill versions and a JPC report. August 2022: PDP Bill withdrawn. 18 November 2022: draft DPDP Bill released. 11 August 2023: DPDP Act 2023 enacted (Act 22 of 2023). 13 November 2025: DPDP Rules 2025 notified. That’s twenty-five years of legislative gestation, and every line of the Rules carries the fingerprints of the cases and committees that came before.
The proportionality test from Puttaswamy is not an academic flourish. It returns in two practical places. First, in any constitutional challenge to a Section 16 negative-list notification restricting cross-border transfer to a specific jurisdiction, the test is what the court will apply. Second, in any DPB penalty order that a Data Fiduciary appeals to the TDSAT and beyond, the proportionality reasoning later reinforced in Anuradha Bhasin v. Union of India, (2020) 3 SCC 637 (analysis: iPleaders case explainer) governs whether the penalty quantum stands or falls.
In practice, the SPDI Rules will continue to apply to incidents and contracts that pre-date Phase 3 of the DPDP regime. Compliance officers should not throw out the older mechanics: many existing contracts (especially long-tail vendor agreements) carry SPDI-flavoured language that needs to be migrated, not rewritten from scratch. The mistake here is treating the DPDP arrival as a clean break. It is a layered transition.
Who must comply: scope, applicability and extraterritorial reach
Does this hit me? That is the first question every founder, GC and product head asks the day after the DPDP Rules 2025 drop. Under Section 3 of the Digital Personal Data Protection Act, 2023, the answer turns on two limbs. The Act applies to processing of digital personal data within the territory of India where the data is collected in digital form, or where it is collected in non-digital form and subsequently digitised. It also applies to processing of digital personal data outside India, if such processing is in connection with any activity related to offering goods or services to Data Principals within the territory of India. So a Singapore-headquartered SaaS company billing Indian users from a US datacentre is squarely in scope.
What counts as “personal data”? The Act defines it broadly. Names, contact details and government identifiers are obvious. So are IP addresses, device identifiers, behavioural data, voice prints and any other data that can identify (alone or in combination) a Data Principal. The personal/household exemption under Section 17 carves out personal or domestic processing (your phone’s contacts, your family WhatsApp group). It does not carve out a sole proprietor running a shop and capturing customer phone numbers for promotional SMS. That falls inside the Act.
A common pitfall: assuming that “we don’t store data in India” exempts you. The Act doesn’t ask where the servers sit. It asks whether the data was collected from a Data Principal in India, or whether your goods or services are offered to Data Principals here. A US-incorporated marketing-automation tool selling to Indian e-commerce companies (and processing the customer database for those Indian companies) is in scope. And so is a UK-based EdTech platform with Indian users. So is an Australian fintech offering BNPL services to Indian customers through a co-branded card.
There’s one subtlety that catches foreign GCs off guard. The Act applies to digital personal data; non-digitised paper records are out of scope. But the moment those paper records are scanned, photographed, OCR-ed or otherwise digitised, they fall in. So the legacy paper KYC files in a Tier-2 city bank branch are exempt today. The moment the bank’s digitisation programme picks them up, they are within scope, and the bank’s existing notice/consent obligations need to extend to that legacy corpus.
Worth flagging: the Act does not differentiate by company size. A two-person Bengaluru startup processing a thousand customer records is a Data Fiduciary. A 30,000-employee listed enterprise is also a Data Fiduciary. The Rules grant some proportionality (we’ll get to the SDF threshold and the MSME prioritisation question further down), but the underlying duties (notice, consent, security, breach, retention, rights) attach the moment processing begins. There is no de minimis carve-out for “small businesses”.
In practice, the first task is a data-mapping exercise. Catalogue every system that holds personal data, every flow into or out of those systems, every third-party processor, every legacy paper-to-digital migration in flight. The mistake we see most often is treating data mapping as an IT exercise. It is a legal-IT-marketing-HR exercise, because each of those teams owns part of the data lifecycle. Get the GC, the CISO and the CMO on the same call, or the map will be missing limbs.
The 18-month implementation timeline: phased compliance map
What does the DPDP Rules 2025 implementation calendar actually look like between November 2025 and May 2027? Most competitors recite the three headline dates without translating them into an internal Gantt. Here is the operational map (the one to print and tape next to the audit-committee dashboard).
| Phase | Trigger date | What takes effect | Internal actions to complete |
|---|---|---|---|
| Phase 1 | 13 November 2025 | Rules notified; DPB and TDSAT operationalised; Rule 16 of the Digital Personal Data Protection Rules, 2025 (DPB constitution) and Rule 17 (DPB procedure) live | Quarter 1 (Nov 2025 to Jan 2026): map data flows, identify role, run gap assessment. Quarter 2 (Feb to Apr 2026): assemble cross-functional steering group; identify the prospective DPO. |
| Phase 2 | 13 November 2026 | Consent Manager registration window opens; Rule 4 and First Schedule live | Quarter 3 (May to Jul 2026): rebuild notice (Rule 3), consent flows (Rule 5), grievance protocol; localise notice into Eighth Schedule languages. Quarter 4 (Aug to Oct 2026): security baseline under Rule 6, breach runbook, DPA addenda renegotiation. |
| Phase 3 | 13 May 2027 | Substantive compliance enforceable: notice, consent, children, security, breach (72-hour DPB), retention (Third Schedule), erasure, cross-border (Rule 15), Data Principal rights, SDF designation (Rule 13), Section 33 penalties up to INR 250 crore | Quarter 5 (Nov 2026 to Jan 2027): SDF self-assessment; if SDF, appoint India-based DPO, run first DPIA, file annual compliance report. Quarter 6 (Feb to May 2027): test breach runbook under simulation; dry-run rights workflow; finalise restriction-ready vendor architecture. |
The set-piece worth marking: the MeitY notification itself. At 23:30 IST on 13 November 2025, MeitY published the final Rules in the Gazette of India Extraordinary, simultaneously activating the DPB and starting the 18-month enforcement clock. The MeitY notification press release (PRID 2190655) is the canonical reference, and post-notification analyses such as post-notification commentary in LiveLaw have parsed the technical departures from the January 2025 draft.
A common mistake at this stage is to start with Phase 3 deliverables (DPIA, DPO appointment, full retention engine) and work backwards, but that misallocates. The single highest-impact Phase 1 task is the data-flow map. Without it, the Phase 2 notice rebuild is built on guesses, and the Phase 3 retention engine has no schema to enforce. Spend the first 90 days on mapping, not on hiring.
What about owner roles? Phase 1 is steering-group plus DPO designate. Phase 2 is DPO plus Legal plus CISO. Phase 3 is DPO plus audit committee plus board. The shift from operational ownership (CISO/DPO) to fiduciary ownership (audit committee/board) is by design, because the penalty exposure is large enough that it has to land in the boardroom, not in IT.
In practice, the realistic budget bands are: INR 8 to 15 lakh in Phase 1 (gap assessment plus tooling RFP), INR 25 to 60 lakh in Phase 2 (RegTech subscription plus DPA renegotiation plus audits), and INR 40 lakh to 2 crore in Phase 3 depending on whether SDF status applies. The lower end of each band is where MSMEs land if they prioritise correctly; the upper end is where listed enterprises and Big-4-advised SDFs land. We’ll come back to the budget composition further down.
The compliance stack: ten obligations on every Data Fiduciary
What does a Data Fiduciary actually owe under the DPDP Rules 2025? The text adds up to ten anchoring obligations. Industry-body DPDP guidance from industry-body DPDP guidance from DSCI phrases them slightly differently, but the operational core is identical. The compliance stack, in one place:
| # | Obligation | Source | Key deliverable |
|---|---|---|---|
| 1 | Notice | Rule 3 of the Digital Personal Data Protection Rules, 2025 | Plain-language notice covering purpose, categories, rights, withdrawal, grievance officer; offer Eighth Schedule language option |
| 2 | Consent | Section 6 plus Rule 5 | Free, specific, informed, unconditional, unambiguous; granular per purpose; no pre-ticks; one-click withdrawal |
| 3 | Children plus persons with disabilities | Rule 10 plus Rule 11 | Verifiable parental consent under-18; no behavioural ads on minors; lawful guardian consent for PwD |
| 4 | Security safeguards | Rule 6 | Encryption, access controls, MFA, one-year log retention, vulnerability management, BCP |
| 5 | Breach reporting | Rule 7 | Notify affected Data Principals plus DPB within 72 hours; reconcile with CERT-In 6-hour rule |
| 6 | Retention plus erasure | Rule 8 plus Third Schedule | Sector-specific retention; hard 3-year cap for e-commerce, social media, online gaming above thresholds |
| 7 | Data Principal rights plus grievance | Rule 14 plus Section 13 | Access, correction, erasure, nomination; published grievance officer |
| 8 | Cross-border transfer | Rule 15 | Default permitted; restricted to negative-list jurisdictions notified by Central Government |
| 9 | Significant Data Fiduciary obligations | Rule 13 | DPIA, periodic audit, India-based DPO, algorithmic due diligence, annual compliance report |
| 10 | Consent Manager interaction | Rule 4 plus First Schedule | Where used, integrate with registered CM; no contract that compromises Data Principal autonomy |
Three of these obligations carry enough operational complexity that they get their own subsection here. The others (children, security, breach, cross-border, retention, rights, SDF) get full treatment in their dedicated sections later. So what is the sensible reading order for a compliance officer building a workplan? Start with notice (because the consent flow inherits its purpose-categories from the notice), then consent, then the Consent Manager model (if your business plans to use one). And everything else is downstream.
A point of foundational vocabulary, often muddled: the difference between a Data Fiduciary, a Data Processor and a Consent Manager. A Data Fiduciary is the entity that determines the purpose and means of processing (the “controller” equivalent). A Data Processor processes data on the Fiduciary’s behalf (the “processor” equivalent). A Consent Manager is a separate registered intermediary that gives Data Principals a single dashboard to review, give and withdraw consent across multiple Fiduciaries. Most Indian businesses are Data Fiduciaries; their cloud and SaaS vendors are Data Processors; only specialised registered entities are Consent Managers.
Notice under Rule 3: the eleven-clause skeleton
What must a DPDP-compliant notice contain? Rule 3 is prescriptive. The notice must be clear, in plain language, and must give the Data Principal genuine ability to understand what they are consenting to. Eleven clauses are operationally non-negotiable: identity of the Fiduciary, contact for the DPO or grievance officer, categories of personal data being collected, specific purposes for each category, intended uses, rights available to the Data Principal (access, correction, erasure, grievance, nomination), the manner to withdraw consent, complaints route to the DPB, the period for which the data will be retained, the recipients with whom data will be shared, and the option to communicate in any of the 22 languages listed in the Eighth Schedule.
Do you need to translate the notice into all 22 Eighth Schedule languages by default? No. The Rules require that the option be made available; the practical posture is to default to English and the regional language(s) appropriate to your customer base, and to provide a translation on request. A pan-India consumer-facing platform should think harder about defaulting into multi-language; a B2B SaaS targeting CFOs of listed companies can sensibly default to English and offer regional translations on request.
In practice, an Indian e-commerce checkout that today bundles “marketing communications, analytics, product personalisation” into one tick-box must split that into three tick-boxes (one per purpose) with the option to consent to any subset. The notice is what tells the user what each tick-box covers. Bundled consent is the single most common mistake we see in early-Phase-2 audits.
Consent and the free, specific, informed, unambiguous standard
What makes consent “valid”? Section 6 plus Rule 5 lay down five attributes: free, specific, informed, unconditional and unambiguous. Translate that into operational rules. Pre-ticked checkboxes fail the “unambiguous” limb. Bundled toggles (“I agree to all the above”) fail the “specific” limb. Conditioning a service on consent that is not necessary for the service (“you can use our calculator only if you give us your contact list”) fails the “free” and “unconditional” limbs. A consent form not in the Data Principal’s preferred language (where they have requested it) fails the “informed” limb.
Can you rely on legitimate interest the way GDPR allows? No. The DPDP regime does not have an open-ended legitimate-interest catch-all. What it has, under Section 7 of the Digital Personal Data Protection Act, 2023, is a closed list of “certain legitimate uses” (employment, medical emergency, public health response, voluntary provision of data for a specified purpose, response to legal obligation). Anything outside that list needs consent. This is one of the cleanest doctrinal differences from GDPR, and it’s where most globally-operating companies trip up when they cargo-cult their European compliance language into India.
Withdrawal must be as easy to give as it is to revoke. The reference test: if your consent capture takes one click, your withdrawal must take one click too. A multi-step CAPTCHA-locked email-confirmation withdrawal flow is non-compliant where consent capture was a single in-app toggle. Build the withdrawal flow with a one-click “withdraw all” option, plus granular per-purpose toggles for partial withdrawal.
The audit log of consent events is what carries you through a DPB inquiry. Every consent event (capture, modification, withdrawal) must be timestamped, attributed to the Data Principal, tagged to the purpose category, and retained for the entire processing period plus a reasonable post-processing window. The mistake we see most often: storing consent events in application logs that rotate at 30 days. Consent records need their own immutable store.
The Consent Manager interaction model
What is a Consent Manager and how does your business interact with one? Under Rule 4 and the First Schedule, a Consent Manager is a separately registered entity that gives Data Principals a single dashboard to review and manage consents across multiple Fiduciaries. The Consent Manager registers with the DPB, must maintain a net worth of at least INR 2 crore, is bound by strict conflict-of-interest restrictions, and must retain consent records for seven years.
How does the interaction work in practice? The Data Fiduciary integrates with the registered Consent Manager via APIs. When a Data Principal grants or withdraws consent, the Consent Manager pushes the event to the Fiduciary, and the Fiduciary’s downstream systems (marketing automation, analytics pipelines, data warehouses) honour the event. The Fiduciary remains liable for its own processing; the Consent Manager is a record-of-truth intermediary, not a liability shield.
Worth flagging: the INR 2 crore net-worth floor disqualifies most early-stage startups from being Consent Managers themselves. So 99 percent of Indian startups will be users of Consent Managers, not providers. The market for Consent Managers will be small (probably 10 to 30 nationally registered entities by Phase 3) and oligopolistic, which has its own concentration-risk implications for any business that bets its consent layer on one provider.
A common founder question: what happens if the Consent Manager you’ve integrated with gets suspended or de-registered? You inherit the operational continuity problem. The mitigation is to design the integration as Consent-Manager-agnostic (use abstraction, support multiple CMs) and to maintain a contingency plan for direct-consent capture if the CM goes offline. Don’t hard-code one CM into your stack.
Sector playbooks: BFSI, healthcare, edtech, e-commerce, SaaS-export, HR
Why do generic compliance guides fall apart at the sector-specific layer? Because the DPDP Rules 2025 layer on top of pre-existing sector regulators (RBI, SEBI, IRDAI, MoHFW, CDSCO, MeitY’s IT Rules, the Online Gaming Rules) and the operational deltas across sectors are large. Six sectors, six different playbooks. The summary first; the detail in each subsection.
| Sector | Primary overlay | Key delta | Must-do |
|---|---|---|---|
| BFSI | RBI / SEBI / IRDAI | Layered on RBI 2018 data localisation plus SEBI cyber guidelines plus IRDAI Information & Cybersecurity 2023 | Map DPDP fields against RBI Master Direction on IT Governance; reuse CERT-In 6-hour pipe but extend to DPB 72-hour |
| Healthcare / health-tech | DISHA draft, NDHM, CDSCO | Health data triggers SDF analysis on volume plus sensitivity; clinical-trial carve-outs may apply | Hospital-grade access logs; encrypted at rest and in transit; explicit consent per encounter |
| EdTech / gaming | Children plus DigiLocker | Verifiable parental consent for under-18 is the biggest operational lift; behavioural advertising on under-18 banned | DigiLocker integration or virtual-token alternative; teacher / parent dashboards segregated |
| E-commerce, social media, online gaming | Third Schedule retention | Hard 3-year retention cap for e-commerce (2 cr+ users), social media (2 cr+ users), online gaming (50 lakh+ users) | Retention engine that auto-purges at 3 years from last interaction; pre-erasure 48-hour notice |
| SaaS / IT-export | Cross-border plus GDPR dual | DPDP cross-border default-permitted unless negative-list; GDPR plus DPDP dual stack becomes a sales asset | Restriction-ready architecture (India DR fallback); DPA addendum library |
| HR / employer | Employee data lifecycle | Employee data is personal data; consent must be free of duress | Employee privacy notice; separate background-check consent; departed-employee erasure |
BFSI: RBI, SEBI and IRDAI overlay
The BFSI sector starts from a fortunate position: it already runs the most mature data-protection stack in India. The RBI 2018 payments-data localisation circular (storage of payment system data in India) pre-dates DPDP and continues to apply. SEBI’s Cyber Security and Cyber Resilience Framework for market infrastructure institutions and stockbrokers is operational. IRDAI’s Information and Cybersecurity Guidelines 2023 govern insurers. The DPDP layer adds Rule 3 notice, Rule 5 consent, Rule 7 breach (72-hour DPB on top of RBI’s incident-reporting timelines and the CERT-In six-hour pipe), and Rule 13 SDF analysis.
How should a BFSI compliance officer approach the layering? Map every DPDP field onto the equivalent RBI Master Direction on IT Governance / Information Security item. Reuse the CERT-In incident-reporting pipe (it’s already operational), but extend the post-incident workflow to include the DPB Rule 7(1) and Rule 7(2) tracks. Treat all Aadhaar-linked KYC as super-sensitive in your retention engine (because the Aadhaar Act and the SPDI categorisation continue to apply alongside DPDP).
The BFSI sector is the obvious first cohort for SDF designation under Rule 13. Volume thresholds (every retail bank crosses a 2-crore-customer threshold easily), sensitivity (financial data plus Aadhaar-linked KYC), and risk-of-harm (financial fraud) all push BFSI into the SDF zone. Plan for it. Treat the SDF DPIA, audit and India-based DPO appointment as Phase 2 deliverables, not Phase 3.
Healthcare and health-tech
Why does healthcare get its own playbook? Because health data is the most-sensitive category any privacy regulator anywhere takes seriously, and the DPDP Rules treat it as such. Volume plus sensitivity plus risk-of-harm under Rule 13 means most mid-to-large hospitals and health-tech platforms will be SDFs. The pre-existing overlays (the draft Digital Information Security in Healthcare Act, the National Digital Health Mission, the Central Drugs Standard Control Organization for clinical trials) all apply alongside DPDP.
What does the operational stack look like? Hospital-grade access logs (every access to a patient record logged, attributed and retained for at least one year), encryption at rest and in transit with key management isolated from application servers, role-based access (a billing clerk does not see clinical history), explicit consent per encounter (a fresh consent for each new purpose, not a lifetime omnibus consent at first registration), and a breach playbook tuned to the 30-lakh-record threshold that the September 2024 health-insurer episode made famous.
Frankly, this gets overlooked: clinical-trial carve-outs may apply to specific processing under Section 17(2)(b) of the Act, but the documentary burden of claiming the carve-out is high. CDSCO-approved clinical-trial data may have a different consent and retention regime than ordinary patient data. Don’t assume the carve-out without documenting it.
EdTech, gaming and the children-data layer
The EdTech and online-gaming sectors share the single biggest operational lift in the DPDP regime: verifiable parental consent for under-18 users. Rule 10 prohibits behavioural advertising and tracking on minors. Rule 11 requires verifiable parental consent before any processing of a minor’s personal data. The verification mechanism is meant to be tight: DigiLocker-backed parent identity verification, virtual tokens issued by a trusted intermediary, or other mechanisms recognised by the DPB.
How does this work for a 14-year-old signing up to an EdTech platform? The platform must collect the parent’s verified consent before activating the child’s account. DigiLocker-backed parental verification is the cleanest path: the parent authenticates via DigiLocker, the platform receives a verified-parent token, and the consent event is bound to the verified parent identity. Virtual-token alternatives are emerging from Indian RegTech players, but DigiLocker is the regulator-preferred path.
A pitfall: assuming the existing self-declaration consent (“I confirm I am over 18 and have my parents’ permission”) is sufficient. It is not. Self-declaration fails the “verifiable” limb of Rule 11. The penalty for processing a minor’s data without verifiable parental consent is the same as any other unlawful processing under the Schedule, and the DPB has signalled (through the press conference following the November 2025 notification) that children’s data will be an early enforcement priority.
Behavioural advertising on under-18 users is banned outright. Profiling for product recommendations, retargeting, or any activity that monitors a child’s behaviour to predict future behaviour falls within the prohibition. And the mistake we see most often in EdTech: the marketing team continues running retargeting pixels on the child-facing app pages because the engineering team didn’t strip them. Audit your tag manager.
E-commerce, social media, online gaming: Third Schedule retention reality
What does the Third Schedule actually require? Hard retention caps for three classes of high-volume Data Fiduciary. E-commerce platforms with 2 crore or more registered users: retain personal data only for 3 years from the date of last interaction, then erase. Social media intermediaries with 2 crore or more registered users: same 3-year cap. Online gaming intermediaries with 50 lakh or more registered users: same 3-year cap.
How does the 3-year clock work? It runs from the last interaction (last login, last transaction, last engagement event), not from initial registration. So a user who logs in once a year keeps their data alive. A user who lapses gets purged at the 3-year mark. The pre-erasure notice obligation under Rule 8(3) requires the Fiduciary to give the Data Principal at least 48 hours’ notice before erasure, giving them a window to object or to re-engage.
The retention-engine architecture matters. Tag every record with a data category, a purpose, a last-interaction timestamp, and a sector-class flag (e-commerce / social / gaming / other). Run a daily purge job that identifies records crossing the 3-year mark, fires the 48-hour pre-erasure notice, and then erases. Don’t rely on manual quarterly cleanups; the volume is too high and the audit trail is too thin.
In practice, the existing IT Rules 2021 (intermediary obligations) and the Online Gaming Rules 2023 (where gaming-specific rules apply) layer on top of DPDP. Treat the DPDP Third Schedule as the floor; the sector-specific rules may impose stricter retention or more granular obligations.
SaaS and IT-export: the dual GDPR plus DPDP stack
For Indian SaaS companies serving EU and UK clients, DPDP creates a competitive moat. A SaaS that is genuinely GDPR-compliant plus DPDP-compliant has a cleaner story than one that is only one or the other. And the dual stack becomes a sales asset, not just a compliance burden.
What does restriction-ready architecture look like? An India-based disaster-recovery (DR) fallback for any data tied to Indian Data Principals, so that if the Central Government issues a Section 16 negative-list notification restricting transfers to a specific jurisdiction (where your primary processing happens to sit), you can flip to the India DR within hours and continue serving Indian customers. Vendor contracts should carry negative-list-trigger clauses that obligate the vendor to support an emergency rerouting if a notification lands.
The DPA addendum library is the second pillar. Every IT and SaaS vendor agreement (whether the vendor is the controller or the processor) needs DPDP-aligned terms: purpose limitation, processor obligations under Rule 12, sub-processing restrictions, audit rights, breach cooperation timelines aligned to Rule 7, indemnities calibrated to Section 33 penalty exposure. Maintain a master template; negotiate variations from there.
Worth flagging: smaller pure-domestic Indian SMEs may actually lose ground in this transition. A SaaS that serves only Indian SMEs sees the DPDP cost without the GDPR competitive uplift. So the Indian-SaaS-export segment grows; the Indian-SaaS-domestic-only segment compresses. That asymmetric outcome is one of the second-order effects we’ll come back to.
HR and employer obligations
Is employee data personal data? Yes. Under the DPDP regime, every payroll record, every background-check report, every performance review, every leave-request log is personal data, and the employer is the Data Fiduciary. That means employee data needs a notice, a lawful basis, retention rules and erasure mechanics, just like customer data.
Is consent the lawful basis for employee data? In most cases, yes (with carve-outs under Section 7 for “employment” purposes that are necessary). But the consent must be “free”, and consent obtained under duress (i.e., consent that the employee couldn’t realistically refuse without adverse employment consequences) doesn’t satisfy the “free” limb. The cleaner path is to identify which processing genuinely fits within the Section 7 employment carve-out and to obtain explicit consent for everything outside that carve-out (background checks, marketing-style internal communications, voluntary wellness programmes).
How do you handle erasure requests from departed employees or customers? Carefully, because two statutory regimes override DPDP erasure for HR data. The Income-tax Act’s 8-year minimum on payroll/TDS records, and the EPFO 7-year minimum on PF records, both override the Data Principal’s erasure right under Section 12 of the DPDP Act. The retention engine must be smart enough to honour the statutory floor while still erasing data outside the floor.
The departed-employee protocol: at separation, freeze active processing, retain only the statutory-minimum records (income-tax, EPFO, gratuity, BGV reports for the disclosure window), erase everything else (active emails, internal access logs, performance evaluations beyond the necessary retention window), and document the action. The mistake we see most often: HR teams retaining everything indefinitely because “it might be needed for litigation”. That blanket-retention posture fails DPDP and creates exposure to a Data Principal erasure complaint.
Sector
Primary overlay
Key delta
Must do
Watch
BFSI
RBI / SEBI / IRDAI
DPDP layered on RBI 2018 data localisation + SEBI cyber guidelines + IRDAI Information & Cybersecurity 2023
Map DPDP fields against RBI Master Direction on IT Governance; reuse CERT-In 6h pipe but extend to DPB 72h; treat all Aadhaar-linked KYC as super-sensitive
Likely first SDF designation cohort
Healthcare / health-tech
DISHA draft, NDHM, CDSCO
Health data triggers SDF analysis on volume + sensitivity; clinical-trial carve-outs may apply
Hospital-grade access logs, encrypted at rest + in transit, role-based access; explicit consent per encounter; breach playbook tuned to 30L-record threshold
Expected MoHFW / CDSCO health-data DPDP-plus guidance
EdTech
Children + DigiLocker
Verifiable parental consent for under-18 is the single biggest operational lift; behavioural advertising on under-18 banned
DigiLocker integration or virtual-token alternative; clinical/educational exemption documentation; teacher / parent dashboards segregated
Expect Rule 10 enforcement to be early and high-profile
E-commerce, social media, online gaming
Third Schedule retention
Hard 3-year retention cap for e-commerce (2 crore+ users), social media (2 crore+ users), online gaming (50 lakh+ users)
Retention engine that auto-purges at 3 years from last interaction; pre-erasure 48-hour notice
Pair with IT Rules 2021 + Online Gaming Rules 2023
SaaS / IT-export
Cross-border + GDPR dual
DPDP cross-border default-permitted unless negative-list; GDPR + DPDP dual stack becomes a sales asset
Restriction-ready architecture (India DR fallback); DPA addendum library; vendor contracts indemnify on negative-list inclusion
—
HR / employer
Employee data lifecycle
Employee data is personal data; consent must be free of duress; payroll, BGV, performance reviews each need a notice + lawful basis
Employee privacy notice; separate background-check consent; departed-employee erasure protocol; retention by Income-tax / EPFO statutory periods
—
BFSI
Healthcare / health-tech
EdTech
E-commerce, social media, online gaming
SaaS / IT-export
HR / employer
Drafting artefacts: notice skeleton, DPA clauses, breach runbook, SDF self-assessment
What does the DPDP Rules 2025 paperwork actually look like in drafted output? Most top-10 SERP guides describe what notices and DPA clauses should contain without giving the reader anything to copy. So here are four artefacts, each ready to adapt: a privacy notice skeleton, a DPA addendum, a breach response runbook, and an SDF self-assessment grid.
The eleven-clause privacy notice skeleton
Every DPDP-compliant notice should have these eleven sections. The model wording is illustrative; adapt to your business.
- Identity and contact. “This privacy notice is issued by [Data Fiduciary name and registered address]. For any privacy queries, contact our Data Protection Officer / Grievance Officer at [email] / [phone].”
- Categories of personal data collected. A list, by category, of what you collect (account data, transaction data, device and usage data, location data, communication data, sensitive categories where applicable).
- Specific purposes. A purpose-by-category table. “Account data is collected to create and manage your account. Transaction data is collected to process orders and provide receipts. Device data is collected for security, fraud prevention and product analytics.”
- Lawful basis. Identify whether the basis is consent (for marketing, profiling, optional features) or one of the Section 7 “certain legitimate uses” (for medical emergency response, employment, statutory obligation).
- Recipients. Identify the categories of third parties with whom data is shared (payment processors, cloud infrastructure providers, analytics providers, regulatory authorities under legal obligation), and whether the data is transferred outside India.
- Retention period. State the retention period or the criteria used to determine it, by purpose category.
- Rights available. Access, correction, erasure, nomination, grievance redressal, withdrawal of consent. State the contact route for each.
- Withdrawal of consent. A clear, single-action withdrawal mechanism, plus the implication of withdrawal (which services will be affected).
- Grievance officer. Name (or role title), contact email and physical address. State the resolution timeline.
- Complaint to DPB. State that the Data Principal may complain to the DPB if the grievance officer fails to resolve.
- Language option. State that the notice is available in any of the 22 languages listed in the Eighth Schedule on request.
The ten-clause DPA addendum
Every Data Fiduciary-Processor contract should carry these ten clauses. Phase 2 (May to October 2026) is when the renegotiation cycle peaks; start the contract review in Q1 2026 to be ready.
- Purpose limitation: the Processor processes personal data only for the specific purpose set out in the agreement and for no other purpose.
- Confidentiality and personnel obligations: the Processor binds its personnel to confidentiality and trains them on data protection obligations.
- Security measures: the Processor implements security measures consistent with Rule 6 (encryption, access controls, MFA, log retention, vulnerability management).
- Sub-processing: prior written consent of the Fiduciary required; flow-down obligations on any approved sub-processor.
- Data Principal rights cooperation: the Processor assists the Fiduciary in responding to access, correction, erasure and nomination requests within agreed timelines.
- Breach cooperation: the Processor notifies the Fiduciary within a defined window (typically 24 hours of awareness, to give the Fiduciary time to comply with the Rule 7 72-hour DPB obligation), and supports incident response.
- Cross-border transfer: the Processor warrants compliance with Rule 15 and the negative-list mechanism; commits to operational rerouting if a notification under Section 16 affects its hosting jurisdiction.
- Audit rights: the Fiduciary has the right to audit the Processor (or to commission a third-party audit) on reasonable notice, with results shared.
- Return or destruction at termination: at termination, the Processor returns or destroys all personal data and certifies the action.
- Indemnity and liability: calibrated indemnities for DPDP penalties traceable to the Processor’s breach of the agreement, subject to liability caps that the parties negotiate (typically a multiple of annual contract value).
T plus 0 to T plus 72 breach response runbook
A breach lands at 09:14 on a Tuesday morning. Who does what, when?
| Hour | Action | Owner | Tasks |
|---|---|---|---|
| T+0 | Confirm and contain | CISO / IR lead | Trigger incident response; isolate affected systems; preserve logs and forensic snapshots; convene the breach committee (CISO, DPO, GC, CEO delegate) |
| T+6 | CERT-In incident report | CISO plus CERT-In liaison | File the CERT-In 6-hour incident notification per the CERT-In Directions of 28 April 2022; flag whether it is a Schedule-listed reportable incident; do not yet name the Data Principal cohort if uncertain |
| T+24 | Scope and draft DPB report | DPO plus GC | Confirm volume and categories of personal data affected; identify the Data Principal cohort; begin drafting Rule 7 DPB notification template; loop in cyber-insurance carrier |
| T+48 | Notify affected Data Principals (parallel) | DPO plus Comms | Send individual notifications under Rule 7(2) covering description of breach, likely consequences, mitigation taken, contact for the grievance officer; resist the temptation to delay until the DPB filing is final |
| T+72 | DPB notification | DPO | File the formal Rule 7(1) DPB report; reconcile with the CERT-In file; update the public statement; trigger the post-incident review and lessons-learned within 14 days |
How do the CERT-In 6-hour and DPB 72-hour reports reconcile? The CERT-In report is incident-focused (what happened, what systems were affected, what is being done). The DPB Rule 7(1) report is data-focused (which Data Principals were affected, what categories of data, what mitigations are being offered to affected individuals). The two reports are not the same document. Build a master incident-data store that feeds both, with the CERT-In template ready in 6 hours and the DPB template ready in 72 hours.
What information must the Rule 7(2) Data Principal notification contain? A description of the breach in plain language, the likely consequences for the affected individual, the mitigation measures taken or proposed, and a contact for the grievance officer. Don’t legalese the notification: a Tier-2 city customer needs to understand what happened in two paragraphs, not five pages.
A common pitfall: the breach committee panics and either over-notifies (notifying every Data Principal in the database when only a subset were affected) or under-notifies (waiting until the forensic picture is fully complete, which can take weeks). The right posture is to notify the realistic-best-estimate cohort within 72 hours and follow up with corrections if the cohort changes. Electronic-evidence certification under Section 63 of the Bharatiya Sakshya Adhiniyam, 2023 (and the older Section 65B of the Indian Evidence Act, 1872, as clarified in Arjun Panditrao Khotkar v. Kailash Kushanrao Gorantyal, (2020) 7 SCC 1) governs the admissibility of the forensic snapshots, server logs and consent records that any DPB inquiry will rely on. Don’t store evidence in formats that fail the certification standard; build the certification into the incident-response workflow.
SDF self-assessment grid
When does Rule 13 designate you a Significant Data Fiduciary? The Rules don’t fix a hard numeric threshold. Designation is the Central Government’s prerogative, applied against a four-factor test: volume and sensitivity of personal data processed, risk to the rights of Data Principals, potential impact on the sovereignty and integrity of India, and risk to electoral democracy and public order. A self-assessment grid:
- Volume: if you process more than 50 lakh Data Principals’ records, lean SDF. If more than 2 crore, near-certain SDF.
- Sensitivity: if a meaningful fraction of your data is health, financial, biometric, or children’s data, lean SDF.
- Risk to rights: if a breach in your environment would create material financial-fraud, identity-theft or physical-safety risk, lean SDF.
- National security or electoral: if your data could be weaponised for influence operations, lean SDF (this catches most large social platforms and ad-tech players).
If you score “lean SDF” on two or more factors, plan for SDF designation as if it has already happened. Appoint the India-based DPO. Run the first DPIA. Build the algorithmic due-diligence audit log. The cost of preparing for SDF status and not being designated is much lower than the cost of being designated and not being prepared.
Retention and erasure: Third Schedule mechanics
What does the Third Schedule under the DPDP Rules 2025 actually do, mechanically? It imposes a hard 3-year retention cap on three classes of high-volume Data Fiduciary (e-commerce 2 crore-plus users, social media 2 crore-plus users, online gaming 50 lakh-plus users), with the clock running from last interaction. Outside those classes, retention is purpose-bound: you keep data for as long as the purpose requires, and you erase it when the purpose ends.
How do you operationalise the 48-hour pre-erasure notice under Rule 8(3)? The retention engine flags records crossing the 3-year mark (or any other configured retention threshold). The system fires a notice to the Data Principal: “We will erase your data on [date 48 hours from now] unless you log in / contact us / object.” If the Data Principal does not act, the erasure executes. If they act (re-engage or formally object), the record is retained and the clock resets or the objection is processed.
Are there carve-outs? Yes, three big ones. Statutory retention obligations under other laws (Income-tax 8 years, EPFO 7 years, RBI KYC retention floors) override DPDP erasure. And pending litigation or regulatory inquiry holds suspend erasure for the relevant records. Voluntary retention with renewed consent can extend the clock if the Data Principal explicitly opts back in.
The departed-employee erasure puzzle is the most-asked HR question in 2026. An employee resigns. They submit an erasure request three months later. What do you erase, what do you retain, and how do you document the decision? Erase: active access logs beyond the security-incident retention window, performance evaluations beyond the appraisal-record window, voluntary-wellness-programme data, marketing-style internal-communications targeting. Retain: payroll and TDS records (8 years from the relevant assessment year), PF records (7 years), gratuity records (per the Payment of Gratuity Act), BGV reports for the disclosure window, any record subject to ongoing litigation hold.
The retention engine architecture: tag-based purge by data category, purpose, last-interaction timestamp, and statutory-floor flag. Run a daily reconciliation job. Maintain an immutable audit log of every erasure event (which record, when, on what basis, with reference to which retention rule). The audit log is what carries you through a Data Principal complaint to the grievance officer or to the DPB.
What about traffic data and access logs? Rule 6 requires log retention for at least one year for security purposes. So security logs sit in their own bucket, with their own retention rule (1 year minimum, often 3 to 7 years for SDF-class entities), separate from the personal-data retention engine that governs business records. Don’t conflate the two.
Security safeguards under Rule 6
What does “reasonable security safeguards” actually mean in operational terms under the DPDP Rules 2025? Rule 6 is not aspirational. It lists specific safeguards: encryption, masking, tokenisation as appropriate; access controls; multi-factor authentication for privileged users; vulnerability management with timely patching; log retention for at least one year; business continuity arrangements. Each item is auditable, and the absence of any item is evidentiary in a DPB inquiry.
Is encryption mandatory? The literal text of Rule 6 lists encryption among the appropriate safeguards rather than as an absolute mandate, but functionally, satisfying the “reasonable security safeguards” standard without encryption is near-impossible for digital personal data at rest or in transit. The practical posture: encrypt by default, document the algorithm and key-management approach, and keep your standards aligned to ISO 27001 Annex A controls plus the CIS Top 18.
Why does the alignment to ISO 27001 and CIS Top 18 matter? Because the DPB will, in time, need a measurable yardstick to assess “reasonable safeguards”, and the most likely yardstick is the same one already used by RBI, SEBI and IRDAI in their cyber-resilience frameworks. Aligning to the global standards now is the cheapest way to be defensibly compliant when the DPB starts adjudicating Schedule-1 breach matters.
To anchor scale: in October 2023, a threat actor on Breach Forums listed for sale what was claimed to be personally identifiable data (Aadhaar and passport details among other categories) of more than 815 million Indians, allegedly extracted from a national medical research body’s COVID-test database. Whatever the eventual attribution, the listing crystallised the order-of-magnitude problem: when leaks happen in India, they happen at population scale. Rule 6 is the regulatory response to that scale. Encryption and access logs aren’t bureaucratic flourishes; they’re the difference between a contained incident and a national-scale exposure.
What does the access-control architecture look like? Role-based access (no shared accounts), MFA for any privileged-user role, just-in-time access for production systems, immutable audit logs for every privileged action, automated anomaly detection on log streams. The CERT-In Directions of 28 April 2022 already mandate parts of this stack for entities subject to CERT-In’s Directions; the DPDP Rule 6 layer adds the “reasonable” overlay across all Data Fiduciaries.
A common founder question: do you need to certify ISO 27001 to demonstrate Rule 6 compliance? No. Rule 6 doesn’t mandate any specific certification. But certification is the cheapest evidence of “reasonable safeguards” if the DPB ever asks. The mistake we see most often: companies that have spent two years on ISO 27001 controls but never run the audit and never received certification. If you’re already at the controls-implementation stage, finish the audit and bank the certificate.
Cross-border data transfers and the negative list
Can you transfer personal data outside India for cloud, SaaS or analytics processing under the DPDP Rules 2025? Yes, by default. Under Section 16 of the Digital Personal Data Protection Act, 2023 read with Rule 15, cross-border transfers are permitted unless the Central Government notifies a negative list of specific countries or territories to which transfers are restricted. As of May 2026, no negative list has been notified. So practical Indian businesses today can use AWS (US), GCP (US/EU), Azure (US/EU), Snowflake (US), Salesforce (US), HubSpot (US) and so on.
What changes if a negative-list notification lands? The notification will identify specific jurisdictions and (typically) specific categories of data. Your cross-border vendor architecture must be ready to flip: India-based DR fallback, vendor contracts with negative-list-trigger clauses, data-residency tags so you know what’s hosted where. The proportionality test from Justice K.S. Puttaswamy (Retd.) v. Union of India (Aadhaar), (2019) 1 SCC 1 and from Internet and Mobile Association of India v. Reserve Bank of India, (2020) 10 SCC 274 (which struck down the RBI’s blanket ban on banking services to crypto exchanges as disproportionate) is what an Indian court will apply if a Section 16 notification is challenged. So overbroad negative-listing is unlikely to survive proportionality review; tightly-scoped, evidence-supported negative-listing will.
Which sectoral carve-outs already mandate India localisation? BFSI is the obvious one: the RBI 2018 payments-data localisation circular requires payment-system data to be stored in India (with limited carve-outs for cross-border transactions). Some government data is implicitly localised by procurement rules. Defence-adjacent and biometric data are likely first targets for any future negative-list activation. Outside these, the default is “permitted unless restricted”.
How does DPDP cross-border compare to GDPR? GDPR runs on a default-restricted, transfer-allowed-only-on-permitted-mechanism (adequacy decisions, SCCs, BCRs, derogations) model. DPDP runs on a default-permitted-unless-negative-listed model. The two are practically opposite. For an Indian SaaS exporter serving EU clients, that means GDPR transfer mechanics (SCCs, transfer impact assessments) still apply when EU personal data flows to India, regardless of what DPDP says. The DPDP regime governs the Indian-to-foreign direction; GDPR governs the EU-to-India direction; both apply in parallel for most cross-border SaaS.
In practice, the right response is to treat the absence of a negative list as a temporary state rather than a permanent feature. Build the restriction-ready architecture now (during Phase 2), so that if the first Section 16 notification lands in Q3 2027 (a realistic timeframe), you’re not redesigning the data layer under regulatory deadline pressure.
Penalties, the Data Protection Board and the appeal ladder
What happens if you don’t comply? The penalty regime under Section 33 of the Digital Personal Data Protection Act, 2023 read with the Schedule is calibrated to produce real deterrence. The aggregate cap is INR 250 crore per breach instance (not per affected individual; per breach event). The Data Protection Board adjudicates. Appeal lies to the TDSAT, then to the High Court, then to the Supreme Court.
The Schedule penalty matrix and Section 33 caps
The Schedule under the DPDP Act lists categorised penalty caps. Failure to take reasonable security safeguards: up to INR 250 crore. Failure to notify the DPB or affected Data Principals of a breach: up to INR 200 crore. Non-fulfilment of additional SDF obligations: up to INR 150 crore. Non-fulfilment of duties of children’s data: up to INR 200 crore. Breach of any other provision: up to INR 50 crore. Section 33 caps the aggregate at the highest applicable category for any given breach event.
Are these per-incident or per-individual? Per incident. So a breach affecting 30 million Data Principals doesn’t multiply 30 million times INR 250 crore (which would be absurd); it caps at INR 250 crore for the breach. And the DPB’s penalty discretion within that cap is governed by the four-factor test below.
DPB inquiry, natural justice and the four penalty-quantum factors
How does a DPB inquiry actually work? A complaint or a suo motu trigger initiates a preliminary inquiry. If the preliminary inquiry indicates a prima facie case, a formal inquiry begins. The Data Fiduciary receives notice, an opportunity to respond, and a right to be heard. The DPB issues a reasoned order. The natural-justice obligations are what Shreya Singhal v. Union of India, (2015) 5 SCC 1 and Anuradha Bhasin v. Union of India, (2020) 3 SCC 637 put on every state body adjudicating digital-rights matters: published reasons, proportionate response, an audi alteram partem opportunity to be heard.
What four factors does the DPB consider when fixing penalty quantum? Gravity of the breach (how many Data Principals affected, what categories of data, what risk of harm). Repetition (whether the Fiduciary has prior breach history). Mitigation (whether the Fiduciary acted promptly to contain and remedy). Gain (whether the Fiduciary derived any financial or operational benefit from the breach). The four factors are the structured discretion that the DPB applies within the Schedule cap.
Has the DPB issued any enforcement orders yet? As of May 2026, no public enforcement orders have been issued by the DPB. And Phase 3 substantive enforcement does not begin until 13 May 2027, so a marquee enforcement order is realistically a 2027 to 2028 event. The first cohort is likely to be in BFSI, health-tech and ad-tech, mirroring the early GDPR rollout pattern in the EU (BA, Marriott, Meta).
The TDSAT to High Court to Supreme Court appeal ladder
What is the appeal route from a DPB order? The Telecom Disputes Settlement and Appellate Tribunal (TDSAT) is the first appellate forum, exercising jurisdiction extended by the DPDP Act. TDSAT operates under the existing TRAI Act framework, with established procedure and a body of digital-regulation jurisprudence. Appeal from TDSAT lies to the relevant High Court on substantial questions of law, and onward to the Supreme Court.
How long does an appeal typically take? Indian appellate timelines vary, but a realistic estimate is: TDSAT first hearing within 60 to 90 days of filing, final order in 6 to 12 months; High Court within 12 to 24 months; Supreme Court (if special leave is granted) 24 to 48 months. So the full appeal ladder is a 3-to-6-year process. Plan for it, but don’t rely on appellate delay as a compliance strategy.
Cyber-insurance and DPDP penalties
Are DPDP penalties insurable under cyber-insurance? Partially. Most cyber-insurance policies in the Indian market today cover incident-response costs, third-party liability, business-interruption losses and notification costs. Regulatory fines and penalties are typically excluded, except where the policy specifically endorses fine cover (which Indian insurers are increasingly willing to do, at a premium).
What’s the practical structure? Most Indian listed enterprises now buy a primary cyber-insurance tower with INR 50 to 250 crore aggregate cover, often with a “DPDP rider” that explicitly covers the cost of regulatory response, the legal fees of the DPB inquiry, and a sub-limit for fine cover (where insurable under Indian law). The rider market is nascent in 2026; expect product maturity by 2028.
Worth flagging: even where fines are not insurable, the legal-defence and regulatory-response costs are. A DPB inquiry can run six-figure-INR-per-month in external counsel and forensic-expert costs; insurance is what keeps that from compounding the operational damage.
Future outlook: DPDP Rules 2025 enforcement to watch through 2030
Where does this go from May 2027 onwards? Five forecasts, each anchored in early signals.
First, DPB enforcement ramp. Once Phase 3 hits in May 2027, expect a “marquee order” cycle: 4 to 8 high-profile penalty orders in the first 12 months of enforcement. The early cohort is likely to be in BFSI, health-tech and ad-tech, mirroring the EU’s GDPR rollout pattern (where the British Airways, Marriott and Meta orders set the early precedents). Practitioners expect the first DPB order to be in the high-INR-double-digit-crore range, calibrated to send a deterrence signal.
Second, negative-list activation. Early signals suggest the Central Government will first restrict transfers to specific sanctioned or adversarial jurisdictions, and to specific categories of data (Aadhaar-linked, defence-adjacent biometric). A first notification under Section 16 is likely within 12 to 24 months of May 2027, narrowly scoped and proportionality-defensible.
Third, sector-specific DPDP-plus guidance. RBI, SEBI, IRDAI and TRAI are likely to issue layered DPDP-plus guidance for their regulated entities (BFSI customer data localisation already pre-exists). A CDSCO or MoHFW health-data DPDP-plus is expected, given the sensitivity of clinical-trial data and the inadequacy of the draft DISHA framework.
Fourth, the children-tech compliance market. Verifiable parental consent will spawn an Indian RegTech sub-sector (DigiLocker-integrated SDKs, parent-pairing tokens, age-verification intermediaries). On EY-style estimates, the segment is likely to reach USD 200 to 400 million by 2028. EdTech and gaming will be the demand-side drivers; the supply-side will be a mix of Indian RegTech startups and Aadhaar-platform extensions.
Fifth, the DPDP-AI intersection. The right to erasure colliding with model training is the unresolved frontier. What does erasure mean once Data Principal data has been used to train a model that has already been deployed? Practitioners expect either a clarificatory rule from MeitY or a DPB order that establishes the operational principle (likely some variant of “remove from training corpus and retrain at next refresh, document the action”). For deeper coverage of how the DPDP regime affects MSMEs and startups in particular, iPleaders’ January 2025 startup-focused DPDPA explainer walks through the upstream foundational position.
Common mistakes and second-order effects
What goes wrong on the DPDP Rules 2025 implementation path, and what non-obvious downstream consequences follow? Five layers, each worth its own treatment.
Top operational mistakes
The legitimate-interest fallacy. Many global compliance teams reflexively reach for legitimate-interest as the lawful basis (because GDPR allows it). DPDP doesn’t. Section 7 is a closed list; everything else needs consent. The first audit finding in a Phase 3 DPB inquiry is likely to be “claimed lawful basis not available under Section 7”.
The existing-policy carry-over assumption. Many businesses assumed their pre-DPDP privacy policies would survive notification with light edits. They won’t. Rule 3’s eleven-clause requirement, the granular per-purpose consent obligation under Rule 5, and the Data Principal rights schema under Rule 14 each require fresh language. A surface-edit of an SPDI-era policy is detectable in audit.
Bundled consent. Marketing teams default to one-tick consent at signup (“I agree to all the above”). That fails Rule 5’s specificity requirement. The retrofit (split into per-purpose toggles, push the change across the user base, manage the partial-consent state in downstream systems) is a 6-to-12-month engineering project. Start it in Phase 1, not Phase 3.
Missing grievance officer. Section 13 requires a published grievance officer with contact details. Many businesses publish a generic legal@[domain] email and call it done. That fails the “easily contactable” standard. The grievance officer needs a name (or role title), a dedicated communication channel, a response timeline, and an actual workflow behind the channel.
SDF traps
Discretionary designation. Many businesses assume SDF status is tied to a fixed numeric threshold (50 lakh users, 2 crore users). It isn’t. Designation is the Central Government’s prerogative against the four-factor test in Rule 13. So the question isn’t “have I crossed 50 lakh users?” but “do my volume, sensitivity, risk-of-harm and public-interest factors collectively warrant designation?”.
India-DPO mis-staffing. The Rule 13 obligation is to appoint a DPO based in India, reporting to the board. Many MNCs default to designating a global DPO who has India responsibilities. That fails the “India-based” requirement. The DPO must be a person resident in India with operational authority over the Indian data lifecycle.
DPIA cargo-culting. The Data Protection Impact Assessment obligation under Rule 13 is substantive, not a paperwork exercise. The assessment must identify high-risk processing, evaluate mitigations, and feed into the actual processing-design decisions. The mistake we see most often: a 60-page DPIA template completed once at SDF designation and never updated. The DPIA should be a living document, refreshed at every material change to processing.
Data Principal rights workflow pitfalls
The 90-day grievance window. Section 13 read with Rule 14 requires the Data Fiduciary to publish redressal timelines for Data Principal grievances. The reference point most businesses use is 30 days (mirroring the consumer-protection model), but the Rules let the Fiduciary set its own reasonable timeline within outer bounds. Publish a timeline you can actually meet; missing a published timeline is itself a breach.
Direct DPB filing. Under Section 13(3) of the Act read with Rule 14, a Data Principal can file a complaint directly with the DPB if the grievance officer fails to resolve within the published timeline. The trap: assuming the Data Principal must exhaust internal redress before approaching the DPB. They must approach the grievance officer first, but the published-timeline failure opens the direct-DPB channel without further hurdles.
Nomination. Section 14 lets a Data Principal nominate another individual to exercise rights on the Principal’s behalf in the event of death or incapacity. The mechanic is straightforward, but most consent-management platforms don’t support nomination capture today. Build the nomination field into your account-management UI as part of the Phase 2 rebuild.
Second-order effects across the market
The DPO labour-market squeeze. Inc42-tier reporting puts mid-career DPO salaries in India at INR 9 to 18 lakh, with senior DPO bands at INR 20 to 40 lakh. Demand exceeds supply by a factor of three to five (the rough estimate from talent firms in early 2026), and cyber-law diploma-grade certifications are emerging as the hiring filter. A LawSikho-tier diploma in Cyber Law and FinTech Regulations is now a meaningful CV signal for a DPO role.
The vendor renegotiation wave. Every Indian Data Fiduciary’s IT and SaaS contracts (with Indian and foreign vendors alike) need DPA addenda aligned to Rule 12 and Rule 6. And the renegotiation cycle is a 12-to-18-month wave through Phase 2, with mass contract reopenings, indemnity reshuffling, and audit-rights insertions. Procurement, legal and security teams will all be at peak load during the cycle.
Cyber-insurance recalibration. DPDP penalties up to INR 250 crore are not always insurable, and the existing cyber-insurance market is repricing. Premiums on the renewal cycle in 2026 to 2027 are expected to harden by 15 to 30 percent, with narrower indemnity language and the rise of explicit “DPDP rider” products. Buyers who renewed long-term policies in 2024 will be re-quoted heavily at renewal.
Indian SaaS export competitiveness. SaaS companies serving EU and UK clients face dual compliance (DPDP plus GDPR), which paradoxically becomes a competitive moat: an “India plus EU compliant” stack is sellable. But smaller pure-domestic Indian SMEs lose ground (they pay the DPDP cost without the GDPR uplift). The asymmetric outcome: SaaS-export segment grows; SaaS-domestic-only segment compresses.
Board-level liability shift. Penalties of INR 250 crore size move data privacy from the IT department to the audit committee. Expect a parallel rise in D&O insurance for privacy-related claims, and a structural shift in CISO-to-board reporting lines. Most listed Indian companies will, by 2027, have a designated audit-committee data-protection sub-charter.
GDPR comparison snapshot
How does DPDP compare to GDPR, axis by axis? The short version:
| Axis | DPDP | GDPR |
|---|---|---|
| Lawful basis | Consent (default) plus Section 7 “certain legitimate uses”; no legitimate-interest catch-all | Six lawful bases including legitimate-interest balancing |
| Children | Verifiable parental consent under-18; no behavioural ads on minors | 13-to-16 age threshold (Member-State variable); GDPR-K for marketing |
| Breach reporting | 72 hours to DPB plus affected Data Principals; no harm threshold | 72 hours to DPA; affected individuals only if high-risk |
| Cross-border | Default permitted; negative list of restricted jurisdictions | Default restricted; transfer requires adequacy / SCC / BCR / derogation |
| Penalty cap | Up to INR 250 crore per Schedule-listed breach | EUR 20 million or 4 percent of global turnover (whichever higher) |
| DPO | Mandatory only for SDFs; must be India-based | Mandatory for public bodies plus large-scale systematic monitoring |
| Right to erasure | Yes, with statutory carve-outs | Yes, with overriding-public-interest balancing |
| Regulator and appeal | DPB to TDSAT to High Court to Supreme Court | National DPA to national courts to CJEU |
The takeaway: DPDP is not a copy of GDPR. It’s an India-first regime that borrows architecture but pivots on consent and ministerial discretion. Indian SaaS exporters who are GDPR-mature start ahead, but they still need DPDP-specific work (consent granularity, Section 7 mapping, breach-reconciliation with CERT-In, India-based DPO, restriction-ready cross-border architecture).
Axis
DPDP (India)
GDPR (EU)
Lawful basis
Consent (default) + “certain legitimate uses” (Section 7); no legitimate-interest catch-all
Six lawful bases including legitimate interest balancing test
Children
Verifiable parental consent under-18; no behavioural ads / tracking on minors
13-16 age threshold (Member-State variable); GDPR-K for marketing
Breach reporting
72 hours to DPB + affected Data Principals; no harm threshold
72 hours to DPA; affected individuals only if high-risk
Cross-border
Default permitted; negative list of restricted jurisdictions (Section 16)
Default restricted; transfer requires adequacy / SCC / BCR / derogation
Penalty cap
Up to INR 250 crore per Schedule-listed breach; aggregable
EUR 20 million or 4 percent of global turnover (whichever higher)
DPO
Mandatory only for SDFs; must be India-based + report to board
Mandatory for public bodies + large-scale systematic monitoring + special-category processors
Right to erasure
Yes, with statutory carve-outs (Section 12)
Yes, with overriding-public-interest balancing
Regulator + appeal
Data Protection Board of India then TDSAT then High Court then Supreme Court
National DPA then national courts then CJEU
Realistic compliance budget for Indian businesses
What does a real DPDP Rules 2025 compliance bill look like? The numbers below are 2026 market ranges, drawn from Inc42 and Storyboard18 founder-pain reporting, Tsaaro-style RegTech price discovery, and cross-checks with DSCI member surveys.
- Gap assessment (Phase 1). INR 8 to 15 lakh for a mid-sized Indian business; INR 25 lakh-plus for a listed enterprise. Includes data-flow mapping, role identification, baseline-controls audit, and a remediation roadmap.
- DPO salary. Mid-career DPO: INR 9 to 18 lakh per annum. Senior DPO with India-based operational authority (mandatory for SDFs): INR 20 to 40 lakh. Big-4 advisory secondment: INR 50 lakh-plus.
- RegTech subscription. INR 15 to 60 lakh per annum, depending on scope (consent management, retention engine, breach response, Data Principal rights workflow, audit module). Larger enterprises with custom integrations sit at the upper end.
- Audits. Annual DPIA refresh and security audit: INR 5 to 25 lakh, depending on scope. SDF audits (Rule 13) at the higher end.
- Cyber-insurance recalibration. 15 to 30 percent renewal premium hike on existing policies; INR 50 lakh-plus for a fresh INR 50 crore tower for a mid-market business.
For MSMEs and early-stage startups, the prioritisation question matters. Start with the cheapest, highest-impact items: gap assessment (a one-time INR 8 lakh investment that scopes the rest), notice rebuild (in-house if you have GC capacity, INR 3 to 5 lakh if outsourced), and a basic breach runbook (INR 2 to 4 lakh consulting). Defer DPIA and DPO appointment until SDF status is realistic. Defer full RegTech tooling until the user-volume justifies it; spreadsheet-based consent registers are acceptable for sub-50,000-Data-Principal businesses through Phase 2.
The honest framing: the iPleaders editorial line is journalism, not vendor-selling. The cheapest high-impact compliance is built in-house with a structured roadmap and a Cyber-Law-trained legal lead. The most expensive (and often least-effective) compliance is built by procuring a RegTech tool first and reverse-engineering the workflow to fit the tool. Start with the workflow; the tool is the last decision, not the first.
Where does this leave the founder of a 25-person SaaS company processing 5 lakh customer records? Roughly INR 12 to 20 lakh in Phase 1 and 2 (gap assessment, notice rebuild, breach runbook, DPA template library, consent flow rebuild). Skip DPIA and DPO until SDF status looks realistic. Pick a RegTech subscription only when consent volumes exceed manual capacity. That’s a defensible, journalism-grade compliance posture, not a Big-4-brochure number.
Frequently asked questions
1. What are the DPDP Rules 2025 and how are they different from the DPDP Act 2023? The DPDP Rules 2025 are subordinate rules made under the Digital Personal Data Protection Act 2023. The Act lays down the principles and rights; the Rules operationalise the duties (notice format, consent mechanics, breach reporting, security safeguards, retention timelines, SDF criteria, cross-border transfer mechanics). Without the Rules, most operative provisions of the Act sat in suspended animation between August 2023 and November 2025.
2. When were the DPDP Rules 2025 notified and what date do they take effect? Notified 13 November 2025 in the Gazette of India Extraordinary. Phase 1 (DPB activation) was immediate. Phase 2 (Consent Manager registration) opens 13 November 2026. Phase 3 (substantive compliance with notice, consent, breach, retention, SDF, cross-border, penalties) becomes enforceable 13 May 2027.
3. Does the DPDP Act apply to my company if it is headquartered outside India? Yes, if you offer goods or services to Data Principals in India. Section 3(b) of the Act gives extraterritorial reach. A Singapore-headquartered SaaS company billing Indian users from a US datacentre is in scope, regardless of where its servers sit or where it is incorporated.
4. Does the DPDP Act apply to data processed for personal or household purposes? No. Section 17(2)(a) carves out personal or domestic processing. Your phone’s contact list and your family WhatsApp group are exempt. But a sole proprietor capturing customer phone numbers for promotional SMS is not exempt; that’s commercial processing and falls within the Act.
5. What is the difference between DPDP and the EU GDPR? DPDP runs on a closed list of lawful bases (consent plus Section 7 “certain legitimate uses”); GDPR has six lawful bases including a legitimate-interest balancing test. DPDP cross-border is default-permitted with a negative list; GDPR is default-restricted requiring adequacy or SCCs. Penalty caps are different (INR 250 crore versus EUR 20 million / 4 percent global turnover). Architecture is similar; doctrine is not.
6. Are existing privacy policies and consent flows still valid after notification? Mostly no. SPDI-era policies typically fail the Rule 3 eleven-clause notice requirement, and bundled consent flows fail the Rule 5 specificity requirement. Plan for a full rebuild during Phase 2 (May to October 2026). Surface-edits to legacy policies are detectable in any audit and won’t survive a DPB inquiry.
7. What is verifiable parental consent and how do I obtain it for a child user? Verifiable parental consent (Rule 11) requires that the platform verify the parent’s identity before processing a minor’s data. The clean path is DigiLocker-backed parent verification: the parent authenticates via DigiLocker, the platform receives a verified-parent token, and consent is bound to the verified identity. Self-declaration (“I am over 18”) fails the standard.
8. Can I use DigiLocker or Aadhaar for parental verification? DigiLocker yes, directly. Aadhaar use is permitted only through approved channels (the UIDAI ecosystem) and within the boundaries of the Aadhaar Act. Most platforms layer DigiLocker on top of Aadhaar-based authentication, since DigiLocker provides the verified-parent token without exposing raw Aadhaar to the platform.
9. How do I reconcile the DPDP 72-hour DPB notification with CERT-In’s 6-hour rule? Treat them as two separate reports from one master incident-data store. The CERT-In 6-hour report is incident-focused (what happened, what systems were affected). The DPB Rule 7(1) report is data-focused (which Data Principals were affected, what categories of data, what mitigations). Build templates for both, with the CERT-In template ready in 6 hours and the DPB template ready in 72 hours.
10. How long must I retain personal data, traffic data and access logs? Personal data: as long as the purpose requires, then erase, with sector-specific 3-year caps under the Third Schedule for high-volume e-commerce, social media and online gaming. Statutory floors override (Income-tax 8 years, EPFO 7 years, RBI KYC retention floors). Access logs and security logs: at least 1 year under Rule 6, often 3 to 7 years for SDF-class entities.
11. What are the retention timelines under the Third Schedule for e-commerce, social media and online gaming? Hard 3-year cap from last interaction. Applies to e-commerce platforms with 2 crore-plus registered users, social media intermediaries with 2 crore-plus users, and online gaming intermediaries with 50 lakh-plus users. Pre-erasure 48-hour notice to the Data Principal under Rule 8(3) is mandatory before each erasure event.
12. Who is a Significant Data Fiduciary and what are the criteria for designation? The SDF designation under Rule 13 is the Central Government’s prerogative against a four-factor test: volume and sensitivity of personal data, risk to rights of Data Principals, potential impact on national security and integrity, and risk to electoral democracy and public order. There is no fixed numeric threshold; designation can apply at lower volumes if other factors are weighty.
13. Can I transfer personal data outside India for cloud, SaaS or analytics processing? Yes, by default. Section 16 plus Rule 15 permit cross-border transfers unless the Central Government notifies a negative list of restricted jurisdictions. As of May 2026, no negative list has been notified. Build restriction-ready architecture (India-based DR fallback) so you can flip if a notification lands, but operate with cross-border transfers freely until then.
14. What penalties apply for non-compliance and how are they calculated? The Schedule under the DPDP Act lists category caps: up to INR 250 crore for failure of reasonable security safeguards, up to INR 200 crore for breach-notification failures or children’s-data breaches, up to INR 150 crore for SDF-obligation failures, up to INR 50 crore for other breaches. Section 33 caps the aggregate per breach event at the highest applicable category. And penalties are per-incident, not per-affected-individual.
15. How should startups and MSMEs prioritise DPDP work given limited budgets? Start with the cheapest, highest-impact items: gap assessment (one-time INR 8 lakh), notice rebuild, breach runbook, DPA template library, consent flow rebuild. Defer DPIA and DPO appointment until SDF status looks realistic. Defer full RegTech tooling until consent-volume justifies it. Spreadsheet-based consent registers are acceptable for sub-50,000-Data-Principal businesses through Phase 2.
References
Case Law
- Anuradha Bhasin v. Union of India, (2020) 3 SCC 637. Supreme Court of India, decided 10 January 2020.
- Arjun Panditrao Khotkar v. Kailash Kushanrao Gorantyal, (2020) 7 SCC 1. Supreme Court of India, decided 14 July 2020 (Section 65B Indian Evidence Act / Section 63 Bharatiya Sakshya Adhiniyam: electronic-evidence certification).
- Internet and Mobile Association of India v. Reserve Bank of India, (2020) 10 SCC 274. Supreme Court of India, decided 4 March 2020.
- Justice K.S. Puttaswamy (Retd.) v. Union of India, (2017) 10 SCC 1. Supreme Court of India (9-judge Constitution Bench), decided 24 August 2017 (right to privacy as a fundamental right).
- Justice K.S. Puttaswamy (Retd.) v. Union of India (Aadhaar), (2019) 1 SCC 1. Supreme Court of India (5-judge Constitution Bench), decided 26 September 2018 (proportionality test applied to Aadhaar).
- Karmanya Singh Sareen v. Union of India, (2017) 10 SCC 268. Supreme Court of India, order dated 23 September 2016 (challenge to inter-platform data sharing under a messaging-platform privacy update).
- Shreya Singhal v. Union of India, (2015) 5 SCC 1. Supreme Court of India, decided 24 March 2015.
Statutes and Rules
- Information Technology Act, 2000. Sections cited: 43A, 72A.
- Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 (SPDI Rules).
- CERT-In Directions, 28 April 2022. Six-hour incident reporting under section 70B of the Information Technology Act, 2000.
- Bharatiya Sakshya Adhiniyam, 2023. Section cited: 63 (electronic-evidence certification; counterpart to Section 65B of the older Indian Evidence Act, 1872).
- Digital Personal Data Protection Act, 2023. Sections cited: 2, 3, 6, 7, 11 to 15, 16, 17, 33 plus Schedule (Act 22 of 2023).
- Digital Personal Data Protection Rules, 2025. Rules cited: 3, 4, 5, 6, 7, 8, 10, 11, 13, 14, 15, 16, 17, First Schedule, Third Schedule (notified 13 November 2025).
Sectoral and other regulatory references
- Reserve Bank of India: Storage of Payment System Data Notification, 6 April 2018.
- Securities and Exchange Board of India: Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, August 2024.
- Insurance Regulatory and Development Authority of India: Information and Cybersecurity Guidelines, 2023.
- Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021.
- Online Gaming Rules, 2023 (under the IT Rules 2021 framework).
- Income-tax Act, 1961 (statutory retention provisions for payroll and TDS records).
- Employees’ Provident Funds and Miscellaneous Provisions Act, 1952 (statutory retention provisions for PF records).
- Press Information Bureau: DPDP Rules 2025 notification press release (PRID 2190655).
- PRS India: Legislative tracker for the Digital Personal Data Protection Bill, 2023.
This article is for informational purposes only and does not constitute legal advice. For specific legal guidance, consult a qualified legal professional.
Serato DJ Crack 2025Serato DJ PRO Crack
Allow notifications
