Last updated: 14 Nov 2025 — On this date, the Government of India notified the Digital Personal Data Protection (DPDP) Rules, 2025, formally operationalising the DPDP Act, 2023. Press Information Bureau
India has notified the DPDP Rules, 2025. A phased rollout gives organisations 18 months to comply: DPB/administrative pieces are live now, Consent Manager provisions follow at 12 months, and the core operational duties—notices, rights, security safeguards, breach reporting, cross‑border—start around 18 months. Build to a dual breach timeline: CERT‑In 6h + DPB ~72h.
Executive TL;DR
India’s privacy regime just moved from “enacted law” to operational. The DPDP Rules, 2025 confirm an 18‑month phased path with clearer obligations on notices, children’s data, persons with disabilities, and a digital‑first Data Protection Board (DPB). The press note also emphasises 90‑day response SLAs for data rights requests and consent‑management guardrails.
For cloud teams, the question is no longer “if” but “how fast.” The Act’s “reasonable security safeguards” obligation sits squarely in cloud posture, access, detection/response, and vulnerability management. That is exactly where Cy5’s ion platform works: CSPM for misconfigurations, CIEM for least‑privilege, SIEM/CDR for breaches, KSPM for clusters, and VM for patch discipline. If you can’t evidence those five pillars, penalties can escalate quickly.
What Changed Today
- Rules notified. The Ministry of Electronics & IT (MeitY) announced that the DPDP Rules, 2025 are now in force, taking the Act live through a phased implementation window of up to 18 months.
- Digital‑first enforcement. The DPB will operate online (portal + app) and appeals route to TDSAT—important for your playbooks and executive briefings.
- Breach expectations. Coverage confirms Board notification within ~72 hours and prompt user notices. Align this with the continuing CERT‑In 6‑hour cyber‑incident rule (dual‑clock).
- Consent Managers. Specifics on consent tooling and Indian entity requirement; plan integrations into your logging and SIEM trails.
- Children & persons with disabilities. Verifiable parental consent and lawful‑guardian consent duties are explicit—expect UX and record‑keeping work.
- Cross‑border. The Act continues a “negative‑list” model (transfers allowed unless restricted by government). Architect for region agility and keep a transfer register.
Heads‑up on retention: Some legal coverage suggests a minimum one‑year retention for certain processing records/logs in the final rules. Treat this as an engineering assumption until you review the final PDF; design SIEM/storage to accommodate the stricter setting.
The Compliance Clocks You Must Reconcile: 72h vs 6h
CERT‑In (still in force): The 2022 Directions mandate reporting specified cyber incidents to CERT‑In within six hours of becoming aware, with an expanded list of reportable categories and expectations on logging (commonly implemented as ≥180 days). Build muscle memory for T+0 triage and rapid regulatory notification.
DPDP breach flow (new rules): Expect Board notice within ~72 hours and plain‑language notices to affected individuals “promptly.” Your notices must describe nature, timing, scope, impact, mitigation, and user safety steps. Use Board‑style templates now; you don’t want to write these during an incident.
One playbook, two clocks (how to operationalise):
- T+0 to 6h: IR lead activates CERT‑In path; collect IOCs, initial narrative, affected services.
- ≤72h: Privacy/DPO lead files the DPB package; sequentially notify affected individuals with clear calls‑to‑action (e.g., password resets, transaction checks).
Evidence: ticket timeline, SIEM case, forensics artifacts, comms drafts, and sign‑offs.
Cy5’s SIEM/CDR helps consolidate the incident storyline and timelines; CSPM/CIEM data shows pre‑breach posture and least‑privilege enforcement.
The 0/12/18‑Month Rollout
Here’s a pragmatic path that mirrors the Rules’ phasing, tuned to cloud realities. Use it as your project plan.
Now → Month 3 (Day 0–90): “Stand‑up the evidence”
- Map your cloud data flows. Identify workloads that process personal data across AWS/Azure/GCP; tag risky flows (e.g., PII in logs). Evidence: data‑flow diagram + inventory CSV.
- Baseline posture (CSPM). Switch on baseline policies; kill public storage exposures and enforce encryption at rest/transit; enable auto‑remediation for high‑risk misconfigs. Evidence: policy export + violation history.
- Least‑privilege (CIEM). Clean stale service accounts, right‑size roles, implement JIT access. Evidence: last‑used access reports + approvals.
- Detection & retention (SIEM/CDR). Instrument cloud‑trail events, identity‑driven detections (mass S3 GET, unusual KMS decrypts), and set retention to cover investigations. Evidence: use‑case catalog + storage metrics.
- Breach drill (dual clocks). Run one tabletop with T+0/6h/72h injects; produce a debrief. Evidence: war‑room notes + drill report.
- Publish contacts. Expose a DPO/designated officer contact and grievance channels (the Rules emphasise clarity). Evidence: web page capture + monitoring.
Month 4–6 (Day 90–180): “Make consent and notices real”
- Notices. Create standalone, plain‑language notices (purpose‑linked) and log date/time/basis of collection. Evidence: templates + screenshots + consent logs.
- Consent Managers. Draft your integration approach; ensure the entity you work with is Indian‑incorporated and can expose event logs to your SIEM.
- Children/PWD flows. Implement verifiable parental and lawful‑guardian consent where applicable; keep proof artifacts.
- Kubernetes posture (KSPM). Baseline cluster policies (network, secrets, image provenance). Evidence: KSPM policy & exceptions.
Month 7–18 (Day 180–540): “Harden for audits & cross‑border”
- Vulnerability management (VM). Set risk‑based SLAs and track attainment; maintain an exception register. Evidence: SLA dashboard.
- Vendor & cross‑border. Maintain a transfer register; contractualise breach cooperation and audit rights; architect region agility in case of negative‑list restrictions. Evidence: executed DPAs + region controls.
- SDF‑readiness. If likely to be designated Significant Data Fiduciary, line up audits, DPIAs, and stronger due diligence—these are flagged in today’s press note. Evidence: audit calendar.
The cloud‑control map the DPB will expect to “see”
Below is a Rule/Theme → Cloud Control → Evidence → Retention map you can paste as an HTML table. It’s adapted from the mapping approach in your existing long‑form post and LP; I’ve extended it to emphasise audit‑ready artifacts.
How to use this table: during incidents or inquiries, your team should be able to pull every artifact listed—in minutes, not days.
| DPDP Theme (Rule family) | Cy5 / Cloud Control | What to Evidence (show, don’t tell) | Frequency / Retention |
|---|---|---|---|
| Security safeguards (prevent breaches) | CSPM baseline & auto‑remediation | Policy set, violation history, before/after screenshots, remediation logs | Continuous; keep policy & remediation logs ≥12–24 months (engineer to stricter retention if the final PDF confirms 1‑year+ for processing records/logs) |
| Access minimisation & least privilege | CIEM (JIT, stale‑access cleanup, toxic‑combo checks) | Last‑used access, role definitions, break‑glass approvals | Monthly access reviews; keep approvals ≥12 months |
| Detect & investigate | SIEM/CDR (detections, timelines) | Use‑case catalog, alert volumes, incident tickets, forensics exports, MTTR | 24/7; size storage for investigations + DPB questions |
| Vulnerability discipline | VM / KSPM | Scan cadence, risk scores, SLA attainment, exception register | Weekly–monthly; maintain exception register continuously |
| Breach notices | IR runbook + templates | CERT‑In notice pack (<6h), DPB pack (~72h), user messaging drafts | Drill quarterly; preserve all comms + timelines. |
| Children & PWD | Consent verification service + logging | Age‑gate logic, parental/guardian proof, revocation flows | Keep proofs with DSR logs; purge on schedule |
| Data rights & grievances | Portal + workflow | Requests, responses, identity checks; ≤90‑day SLA proof | Track to SLA dashboards; log decisions. |
| Cross‑border | Region controls + Transfer Register | Country routing, processor clauses, fallback regions | Refresh quarterly; react to any negative‑list change |
| SDF extras | Governance & Audit | Audit reports, DPIAs, technology due diligence | Annual + on material change |
Cross‑border transfers: architecture choices to lock in now
The DPDP Act adopts a “negative‑list” regime: transfers are generally permitted except to countries the government restricts by notification. That means two things for cloud architects:
- Be region‑agile by design. Place data in regions you can keep compliant if a jurisdiction moves onto a negative list.
- Contract for agility. Bake in cooperation clauses (breach support, log provision), sub‑processor transparency, and audit rights with processors.
Keep a Transfer Register (dataset → purpose → destination → processor → basis) and link it to your CSPM/CIEM metadata for traceability.
Children’s Data & Persons with Disabilities: Operational Nuance
The final Rules emphasise verifiable parental consent for children and lawful‑guardian consent for certain persons with disabilities who cannot make legal decisions even with support. In practice: build age‑gating, verification, revocation, and proof retention into your flows; treat these like high‑risk paths in your SIEM/KSPM detections.
The DPB’s Digital Posture (and Why that Changes How you Prepare)
The Data Protection Board is meant to be a fully digital institution, with an online complaint and tracking platform. That increases the likelihood of faster cycles from complaint → inquiry → decision. Prepare your “evidence kit” now—so you can respond in days, not weeks:
- Policy PDFs with version history
- CSPM/CIEM/SIEM/KSPM/VM reports (exportable)
- DPO contact page and grievance logs
- Incident timelines (ticketing + SIEM)
- Training & drill completion logs
Publish clear contact info (DPO/designated officer) and commit publicly to ≤90‑day rights‑request SLAs—both are stress‑tested in the Rules and press note.
Real‑World Scenarios (Micro‑Stories You Can Recognise)
- Public storage exposure: A dev creates a public bucket for testing; logs include emails and phone numbers. CSPM blocks public ACLs and triggers auto‑remediation; SIEM correlates with unusual GET volumes. Incident clock starts; CERT‑In 6h notification sent, DPB pack ready at ~72h, affected users warned.
- Permission creep: A legacy service account retains full‑admin. CIEM shows it hasn’t been used in 90 days; JIT auto‑grants when needed. That single control can be the difference between a routine day and a regulator‑scrutinised breach.
Container drift: A cluster pulls an unscanned image; runtime anomalies spike. KSPM blocks deployment; SIEM raises a CDR case; VM tracks the CVE backlog to closure. Your audit trail shows prevention, not just remediation.
FAQs: DPDP Rules Enacted, Now What for Security Leaders
Short answer: The DPDP Act is now operational, but not everything bites on day one. The Rules create an 18-month phased timeline:
–> Immediately (on notification): Core definitions, constitution of the Data Protection Board (DPB), basic duties, grievance-redress mechanisms and transparency obligations become live.
–> +12 months: The Consent Manager regime (registration, governance, oversight) kicks in, giving time for the ecosystem to mature.
–> +18 months: Most operational duties take effect—standalone notices, security safeguards, detailed breach reporting, data-retention rules, cross-border conditions, and a big share of the penalty-bearing obligation.
Practically, that means you can’t wait 18 months. Boards and regulators will expect you to use this window to implement controls and build an evidence kit—especially around cloud posture (CSPM), access (CIEM), detection/retention (SIEM/CDR), and VM—so you’re not scrambling when the 18-month mark hits.
Yes—but there’s more nuance than just “72 hours”.
Under the DPDP Rules 2025, breach handling has two key expectation.
1. “Without delay” / immediate intimation
As soon as you become aware of a personal-data breach, you’re expected to promptly inform the DPB of the breach and its likely impact. Think of this as a quick, initial notice, not a fully-formed forensic report.
2. Within ~72 hours – detailed report
Within 72 hours, you must submit a more complete report covering:
–> Nature, extent, timing, and location of the breach
–> How it happened (circumstances leading to it)
–> Impact assessment
–> Mitigation and remedial steps
–> Who/what caused the breach
–> Confirmation of how and when you notified affected individuals
The Board can grant extensions if you write to them, but you should treat 72 hours as your default design target. Failing to report a breach can attract penalties up to ₹200 crore, and separate fines (up to ₹250 crore) apply if you lack “reasonable” security safeguards in the first place.
Your IR runbook should therefore:
–> Trigger a fast preliminary notification to the Board, and
–> Orchestrate a cross-functional response (SecOps, Legal, Privacy, Comms) to assemble the fuller 72-hour pack—ideally using SIEM/CDR timelines and CSPM/CIEM posture evidence.
Yes. The CERT-In Directions of April 2022 haven’t gone away, and they still require specified cyber incidents to be reported within six hours of you “noticing such incidents or being brought to notice about such incidents”.
So you now have a dual-clock reality:
CERT-In:
–> 6-hour deadline for notifiable cyber incidents
–> Mandatory logging for ICT systems for at least 180 days (within India)
DPDP / DPB:
–> Immediate intimation and detailed breach report within 72 hours
–> At least one-year retention of traffic and processing logs under the Rules (for breach detection/investigation), unless another law prohibits it.
For incident management, you should run one integrated playbook:
–> T+0–6 hours: triage, contain, collect IOCs, and file a CERT-In report where required.
–> ≤72 hours: deep-dive investigation, DPB report, user notification, and internal board-level communication.
–> Post-incident: update CSPM/CIEM/VM controls, tune SIEM detections, capture all artifacts as “proof” for any future DPB or CERT-In inquiry.
The DPDP Act does not impose blanket data localisation for all processing. Instead, it uses a “negative-list” (blocklist) model:
–> By default, you can transfer personal data outside India.
–> Transfers may be restricted to specific countries/entities if the Central Government issues a notification blacklisting them or prescribing conditions.
Sectoral regulators (e.g., RBI, SEBI, IRDAI) may still enforce stricter localisation for particular categories (payments, trading data, etc.), so you must look at DPDP plus sector rules.
For cloud and SaaS, the safest pattern is:
–> Architect for region agility (e.g., Indian regions as default, with the ability to re-route away from blocklisted jurisdictions).
–> Maintain a Transfer Register (dataset → purpose → region → processor → legal basis).
–> Bind vendors contractually to DPDP obligations, breach-cooperation, and audit rights.
The DPDP framework now hard-codes a maximum 90-day response deadline for rights requests.
Under the Act + Rules, Data Principals can:
–> Access information about processing
–> Correct and update their data
–> Request erasure in many cases
–> Seek grievance redressal
–> Exercise the Right to Nominate (appoint someone who can exercise their rights if they die or become incapacitated)
Data Fiduciaries must:
–> Provide simple, digital-first channels (portals, apps, email) to receive these requests
–> Verify the requester’s identity
–> Respond within 90 days, including reasons if a request is rejected
From an operational angle, treat this as a tracked SLA:
–> Expose self-service dashboards for access/correction/erasure
–> Route requests into a workflow system (ticketing/CRM)
–> Flag overdue cases to compliance and DPO
–> Log every step (request, verification, response) for at least the same period as your other processing records sa-server-file-api-user-upload
You don’t self-declare as an SDF. The Central Government designates SDFs based on risk factors such as:
–> Volume and sensitivity of personal data processed
–> Risk to electoral democracy, sovereignty, national security
–> Impact on public order, financial stability, public health, or minors
If you are designated an SDF, you must:
–> Appoint a Data Protection Officer (DPO) based in India
–> Engage an independent data auditor
–> Conduct regular Data Protection Impact Assessments (DPIAs)
–> Apply tighter technology due diligence and potentially comply with additional localisation for notified categories of data
Even if you’re not yet tagged as SDF, it’s smart to:
–> Assign an internal DPO/owner
–> Maintain an audit calendar
–> Keep your CSPM/CIEM/SIEM/VM evidence pack ready
That not only de-risks future designation, it also plays well in board conversations and any DPB inquiries.
The final Rules explicitly emphasise logging and retention for security and investigations:
–> Data Fiduciaries must maintain traffic logs and processing logs for at least one year, to detect unauthorised access and support investigations, unless another law specifically forbids such retention.
–> For breaches, companies must be able to reconstruct who accessed what, when, from where, and what was done, which implies robust log coverage across apps, infra, and cloud services.
CERT-In Directions separately require all ICT system logs to be retained for at least 180 days within India.
In practice, most mid-to-large organisations should aim for the stricter superset:
–> ≥12 months of security-relevant logs (access, admin actions, data processing, API calls)
–> At least 180 days stored in India, to satisfy CERT-In
–> Clear retention policies + SIEM/storage metrics proving you’re meeting those thresholds
For cloud and SaaS players, DPDP isn’t a “policy-only” law; it directly hits your technical stack:
1. Security safeguards are now prescriptive
The Rules talk about encryption, masking/tokenisation, access controls, logging, backup and business-continuity, making these baseline expectations rather than “nice to have” controls.
2. Breach-reporting and evidence burden
You must detect breaches, contain them, file dual-clock notifications (6h CERT-In / 72h DPB) and show that your cloud posture and access model were “reasonable” at the time (CSPM/CIEM/VM evidence). sa-server-file-api-user-upload
3. Multi-tenant and processor responsibilities
Even when you act as a Data Processor, customers (Data Fiduciaries) remain on the hook—but you are contractually expected to provide logs, support notifications, and implement DPDP-aligned safeguards.
4. Cross-border and region controls
You should be able to tell exactly which region each customer’s data resides in and how quickly you can adapt if a country lands on the blocklist.
Think of it this way:
1. The DPDP Act 2023 is the law: it sets out high-level principles, rights (access, correction, erasure, nomination), duties, penalty ranges (including the ₹250-crore ceiling), and the existence/powers of the Data Protection Board.
2. The DPDP Rules 2025 are the operating manual: they explain how to implement those principles—what must appear in notices, how consent should be captured, how breaches must be reported, how long logs must be kept, what Consent Managers do, how SDFs are governed, and how the 18-month rollout works.
How Cy5’s ion Closes the Gaps
If your board asks “show me the evidence,” here’s what you can hand them within minutes using ion:
- CSPM: Configuration baselines, “before/after” remediation screens, encryption and public‑exposure guardrails.
- CIEM: Last‑used access reports, role rightsizing history, JIT approvals, and toxic‑combination reviews.
- SIEM/CDR: Cloud‑trail anomaly detections, incident timelines, storage retention proof.
- KSPM & VM: Cluster policy adherence, image provenance, CVE cadence, and SLA attainment.
Implementation Checklist (Month‑by‑Month)
Month 0–1
- Data inventory & Transfer Register
- CSPM baseline; CIEM cleanup of dormant roles
- SIEM data sources; breach runbook with 6h/72h timers
Month 2–4
- Consent/notice UX; event logging to SIEM
- KSPM baselines (cluster/network/secrets)
- Vendor clauses: breach cooperation, log provision, audit rights
Month 5–7
- VM SLAs + exception handling
- Rights‑request portal with ≤90‑day SLA
- Consent Manager integration plan (Indian entity)
Month 8–12
- Tabletop drills (dual clocks)
- SDF‑readiness work (audits/DPIAs)
- Region‑control patterns for cross‑border agility
Through 18 months
- Evidence pack maturity; Change Log on your site; quarterly refresh of control maps and FAQs.
Already set up for this cadence: your DPDP LP sections “How to comply” and “Cloud‑centric path” (see illustrations and step sequence on pp. 8–11). Reuse those visuals in this post for message consistency and LLM extractability.
Final word
You now have clarity and a clock. The DPDP Rules, 2025 create a practical runway—if you use the time to prove security, not just declare it. Ship the posture baselines, clean up identity, wire detections, rehearse the breach clocks, and keep a tidy evidence kit. That’s how you protect people, satisfy regulators, and walk into your next board meeting with confidence.
