Written by: Prakhar Rai, Advocate | Enrolled with the Bar Council of India | NLSIU Bangalore alumnus | Contracts and data protection lawyer in India
Last reviewed: 16 October 2026, against the Digital Personal Data Protection Act, 2023, the DPDP Rules, 2025 and the CERT-In Directions of 28 April 2022
The short answer
Yes, they will run in parallel, and nothing I could find in the statutes, rules or official guidance joins them up.
When the main DPDP duties start (scheduled for about 13 May 2027), a single incident at an Indian organisation can create two separate reporting duties. One is to CERT-In, under Section 70B of the Information Technology Act, 2000. The other is to the Data Protection Board of India and to every affected individual, under Section 8(6) of the DPDP Act and Rule 7 of the DPDP Rules.
The two regimes have different triggers (a specified cyber incident versus a personal data breach), different clocks (six hours versus “without delay” with detail inside 72 hours), different people who must act (any covered entity that notices the incident versus the Data Fiduciary) and different audiences (a technical response agency versus a data protection regulator and the people affected).
This is not a story about one regime replacing the other. CERT-In keeps its role. The DPDP Act says it applies “in addition to and not in derogation of” other laws (Section 38(1)), so both sets of duties will be live together. The interesting questions are in the gaps between them, especially when a service provider discovers a breach before its client does. That is where I think organisations are most exposed, and where clearer guidance from the government would help most.
This article is a legal research and implementation gap analysis. It compares the two regimes, tests four processor scenarios, and ends with an incident-to-obligation matrix and a design for one incident-response process that serves both.
Where things stand today
Before the analysis, three facts about timing, because they change what “work in parallel” means in practice.
- CERT-In’s Directions are already in force. They were issued on 28 April 2022 and have applied since mid-2022.
- The DPDP breach duties are not yet in force. The Rules were notified on 13 November 2025. Provisions on the Board took effect that day. The consent manager rules follow about 13 November 2026, and the main obligations, including Section 8(6) and Rule 7, are scheduled for about 13 May 2027, which is 18 months after notification. A proposal reported in January 2026 to shorten that period to 12 months had not been notified when I last checked sources dated early October 2026. Please re-check before you rely on the date.
- The Board is established in law but, as far as I could find, not yet staffed. A MeitY circular dated 6 May 2026 invited applications for a Chairperson and four Members. I found no notification of appointments. Some commentary calls the Board “operational”. Treat that carefully: a Board without members cannot yet receive intimations or hear complaints.
Until the DPDP breach duties start, the older regime (Section 43A of the IT Act and the 2011 SPDI Rules) continues. Section 44(2) of the DPDP Act omits Section 43A when it commences.
For the general DPDP picture, see our guide to the DPDP Act and its implications. For a practical hour-by-hour response plan, see our data breach response playbook. This article does something different: it looks at where the two regimes collide.
The two regimes side by side
Here is the comparison, extended beyond deadlines.
| Issue | CERT-In (Directions of 28 April 2022) | DPDP framework (Act, 2023 and Rules, 2025) |
|---|---|---|
| Authority | Indian Computer Emergency Response Team | Data Protection Board of India |
| Source of power | Section 70B(6), IT Act, 2000 | Section 8(6), DPDP Act; Rule 7 |
| Primary focus | Specified cyber security incidents (the list in Annexure I includes data breaches and data leaks) | Personal data breaches (Section 2(u)) |
| What triggers a duty | A listed cyber incident, whether or not personal data is involved | Unauthorised processing or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data that compromises its confidentiality, integrity or availability |
| When the clock starts | “Noticing” the incident or “being brought to notice” of it | “On becoming aware” of the breach (Rule 7) |
| Reporting deadline | Six hours | Individuals: without delay. Board: description without delay, then detailed information within 72 hours or a longer period the Board allows on a written request |
| Who has the duty | Service providers, intermediaries, data centres, body corporate and government organisations covered by the Directions. The FAQs (as summarised by law firms) say any entity that notices the incident should report | The Data Fiduciary |
| Are individuals told? | No general requirement to notify affected individuals under the Directions | Yes, without delay, in plain language, through their account or registered contact mode |
| Is there a harm threshold? | Reportable categories, with FAQs indicating that only listed incidents meeting stated criteria must be reported within six hours | None in Rule 7. Any personal data breach triggers the duty |
| What is reported | Incident details, as set out in the Directions’ reporting format. Further information can follow later | Nature, extent, timing, location and likely impact first. Then facts and reasons, mitigation, findings on the person responsible, remedial steps and a report on notices to individuals |
| Records | Logs of ICT systems kept for a rolling 180 days, with time synchronised to NPL or NIC sources | Logs and personal data kept for one year for detection and remediation (Rule 6), unless another law requires otherwise |
| Consequence of non-compliance | Section 70B(7): imprisonment up to one year, a fine up to one lakh rupees, or both | Penalty up to ₹200 crore for failure to notify (Section 8(6)) and up to ₹250 crore for failing to maintain reasonable security safeguards (Section 8(5)), after a Board inquiry. Not yet enforceable |
| Relationship to the other | Independent | Section 38(1): additional to other laws. Section 38(2): the Act prevails only where there is a conflict |
Three things stand out from this table.
The triggers overlap but are not the same. A denial-of-service attack is a cyber incident with no personal data breach. A misdirected email with customer data is a personal data breach with no attack. A ransomware attack is usually both. Because the DPDP definition covers loss of availability, encrypting a database so the organisation cannot use it can be a personal data breach even if nobody copied a single record.
The clock-start wording is different. The CERT-In trigger expressly includes being “brought to notice” by someone else. Rule 7 says “becoming aware”. That difference matters when the person who finds out first is not the one with the duty.
There is no cross-reference. Rule 7 does not mention CERT-In or data processors. The Directions do not mention DPDP, which did not exist when they were issued. Section 38 tells us only that the regimes are cumulative.
Why the regimes were built differently
It helps to see why parallel operation is not an oversight.
CERT-In is a technical, systemic body. Its job under Section 70B is to collect and analyse incident information across the Indian internet, issue alerts and coordinate responses. It wants a fast, early signal about attacks, even if details are thin. That is why the clock is short and the content can be supplemented later.
The Data Protection Board is a rights-protection body. Its job is to examine whether an organisation protected personal data, told people the truth, and fixed the problem. That is why individuals must be told, why the report to the Board has two stages, and why the second stage asks about causes and remedial measures.
These are different public purposes, so it is reasonable for the law to create two channels. The problem is not that there are two. The problem is that a single event produces two different sets of paperwork, from the same people, in the same hours, with no agreed way to share facts between the authorities.
The central problem: the service provider who finds out first
Most large incidents do not start in the Data Fiduciary’s own systems. They start at a cloud host, a payroll provider, a CRM vendor, a customer support platform, a payment gateway or an offshore development team. Under the DPDP Act that vendor is usually a Data Processor. Under the CERT-In Directions it may be a service provider, intermediary or body corporate in its own right.
The Act is clear on one thing. Under Section 8(1), the Data Fiduciary is responsible for compliance “irrespective of any agreement to the contrary”, including for processing done by a processor on its behalf. Section 8(5) requires the fiduciary to protect data it controls, including data a processor handles. Rule 6(1)(f) requires the contract with a processor to contain appropriate provisions on reasonable security safeguards.
What the Act and Rules do not say is when the fiduciary’s clock starts if the processor discovers the breach first, or what the processor must do. Rule 7 does not mention processors at all. I take the four questions in turn.
Who starts the reporting clock when a processor discovers an incident?
There is no single answer, because the two regimes ask different questions.
Under CERT-In, the Directions apply to entities such as service providers, intermediaries, data centres and body corporate, and the clock runs from “noticing” the incident or “being brought to notice” of it. Law-firm summaries of the CERT-In FAQs say that where several parties are involved, any entity that notices the incident should report to CERT-In, and that this duty cannot be passed to someone else by contract. So:
- If the processor notices the incident, it may have its own six-hour duty if it is a covered entity and the incident is of a reportable kind. That duty exists whether or not it tells its client.
- When the processor tells its client, the client is then “brought to notice” and, if it is a covered entity, a separate six-hour clock starts for the client.
The result can be two filings to CERT-In about one incident, from two entities, with different start times. I have not found guidance telling organisations how to handle that duplication.
Under DPDP, the duty to notify belongs to the Data Fiduciary alone, and the trigger is that the fiduciary “becomes aware”. There are two plausible readings.
| Reading | Argument | Consequence |
|---|---|---|
| Narrow (actual awareness) | Rule 7 speaks of the fiduciary becoming aware. A processor’s knowledge is not the fiduciary’s. The processor has no duty under Rule 7 | The clock starts when the processor tells the fiduciary (or the fiduciary otherwise learns of it) |
| Wide (constructive awareness) | Section 8(1) makes the fiduciary answerable for processing done “on its behalf”. The processor acts for the fiduciary, and Section 8(5) and Rule 6 require the fiduciary to have systems that detect and escalate incidents. A regulator could say a fiduciary that set up slow processor reporting cannot benefit from the delay | The Board could treat the fiduciary as late if the delay came from a weak contract or poor oversight, even if it acted quickly once told |
The narrow reading matches the text. The wide reading matches the purpose of the Act and the risk allocation in Section 8. No authoritative decision or guidance resolves this, and the Board has not yet issued any.
A useful comparison is the EU. Under the GDPR, the 72-hour clock runs from the controller becoming aware, and the European Data Protection Board’s guidelines on breach notification say a controller should in principle be considered aware once its processor has informed it, while the processor must tell the controller without undue delay. India’s Rule 7 has no equivalent processor duty. That omission is the heart of the gap.
My view: organisations should plan on the assumption that the Board may take a wide view. The safest practical position is to behave as if the clock starts when the processor first becomes aware, by contract and by monitoring, even if the law might allow later.
Can the client realistically meet DPDP duties if its processor waits 24 hours?
Twenty-four hours is a common figure in vendor contracts and some commentary suggests it as a standard. Whether it works depends on what the fiduciary is promising to do and when.
Take an illustrative scenario (hypothetical, for analysis only). A processor hosting a fiduciary’s customer database detects unauthorised access at hour 0. Its contract lets it notify the client within 24 hours.
| Time | Processor | Fiduciary | Problem |
|---|---|---|---|
| Hour 0 | Notices intrusion | Unaware | If the processor is a CERT-In covered entity, its own six-hour clock starts |
| Hour 6 | Should have reported to CERT-In if it is a covered entity | Unaware | Processor may be late already if it waits for contract timing |
| Hour 24 | Notifies the client | Becomes aware. CERT-In six-hour clock starts if it is covered. DPDP clock starts under the narrow reading | Individuals and the Board must be told “without delay” |
| Hour 30 | CERT-In report due (client) | Information is thin because it only learned a day later | |
| Hour 96 | 72-hour detailed Board report due on the narrow reading | Fine on the narrow reading. Under the wide reading, the 72 hours expired at hour 72 |
Four points follow.
- On the narrow reading, a 24-hour contract can technically work for the 72-hour report because the fiduciary still has 72 hours from awareness. It does not obviously work for the “without delay” duties to individuals and to the Board. “Without delay” is not defined, and a day of silence by a vendor looks poor if the fiduciary then takes more hours to assess.
- On the wide reading, the same contract can leave the fiduciary in breach before it knew anything.
- The processor’s own CERT-In duty is not satisfied by a 24-hour contract. If it is a covered entity and noticed the incident, a contractual notice period does not suspend the six-hour direction.
- The contract does not protect the fiduciary against the regulator. Section 8(1) says responsibility remains with the fiduciary “irrespective of any agreement to the contrary”. The contract gives a right to compensation, not immunity.
So the realistic answer is that 24 hours is too long for any processor that holds significant personal data. A defensible contract clause has two stages: an immediate alert on a suspected incident, followed by structured detail. Many organisations will want the first alert within a few hours of the processor becoming aware, and some will want it quicker for high-risk data. The right figure depends on risk and bargaining power, and I would not set it by copying a template.
What if an incident is reportable to CERT-In but the parties disagree whether personal data was affected?
This will be one of the most common disputes, because the two regimes use different triggers and the facts are murky in the first hours.
The processor may say “this was a network intrusion, no personal data was accessed”, while the fiduciary’s data map says the affected server held customer records. Or the processor may not know what data was on the system, because it is only a hosting layer.
How to handle it:
- CERT-In does not wait for the data question. If the incident is of a reportable type, the six-hour direction applies whether or not personal data is involved. The disagreement is irrelevant to that filing.
- The DPDP decision belongs to the fiduciary. Section 8(6) places the duty on the Data Fiduciary, so it, not the processor, decides whether there has been a personal data breach. The processor’s role is to supply facts quickly. A clause that lets the processor decide whether to tell the client is a risk.
- The definition is wide. Section 2(u) covers breaches of confidentiality, integrity or availability. Rule 7 contains no minimum number of people or harm threshold. A ransomware lock-out of a customer database can qualify.
- Provisional notification is possible. Rule 7(2)(a) calls for a description “without delay” and Rule 7(2)(b) allows updated and detailed information within 72 hours. That structure suggests an early, qualified notice can be supplemented. Individual notices are different: they must be accurate, and a false alarm sent to thousands of people has its own cost.
- Encryption is a fact question, not a safe harbour. If data was encrypted and the keys were not exposed, confidentiality may not have been compromised. But the Act does not expressly exempt encrypted data, so document the reasoning.
A sensible protocol is to treat the dispute as an evidence request, not an argument. The fiduciary asks the processor for specific facts within a set time: what systems, what data stores, what logs, what time window, what evidence of access or exfiltration. Where the question remains open at the deadline, the fiduciary decides on the information it has and records why.
How should an organisation design one incident-response process for both regimes?
Short answer: one intake, two triage questions, one fact base, two outputs. The design is in the next section, after the matrix.
The incident-to-obligation matrix
The matrix below sets out who must do what in six scenarios. Each row is my reading of how the two regimes are likely to apply. It is analysis, not an official position. Where I say “likely”, the point is open.
Key. F = Data Fiduciary (the client). P = Data Processor or vendor. Both regimes assume the organisation is covered by the relevant law. Sector regulators add duties not shown here.
Part 1: Who assesses and who notifies
| # | Scenario | CERT-In: who reports and when | DPDP: who assesses | DPDP: who notifies Board and individuals |
|---|---|---|---|---|
| 1 | F’s own systems, personal data affected (for example, ransomware on F’s server) | F, within 6 hours of noticing, if the incident is of a reportable type | F | F: individuals without delay; Board without delay, then detail within 72 hours |
| 2 | F’s own systems, no personal data (for example, DoS, defacement) | F, within 6 hours if reportable | F records its reasoning that no personal data breach occurred | Not triggered |
| 3 | P discovers a breach of F’s personal data in P’s systems; P tells F promptly | P, within 6 hours of noticing, if P is covered and the incident is reportable. F, within 6 hours of being brought to notice, if F is covered | F decides whether a personal data breach occurred, using facts from P | F only. P has no Rule 7 duty |
| 4 | P discovers it but delays telling F (for example, a 24-hour contract term) | P’s CERT-In duty runs from its noticing. F’s runs from when told | F, once told. Risk that a regulator treats F as aware earlier | F, once aware. Possible argument that F is late on the wide reading |
| 5 | F or a third party finds out first (for example, a researcher or customer alerts F about P’s system) | F, within 6 hours of being brought to notice. P, once it notices or is told | F, immediately asking P for facts | F. F cannot wait for P to finish its investigation |
| 6 | Disagreement: CERT-In-reportable incident at P, P says no personal data | P and F each report if covered, regardless of the personal data dispute | F decides, on evidence it demands from P. P cannot decide for F | F, if it concludes a personal data breach occurred or may have. Provisional notice, then update |
Part 2: Who supplies evidence and who keeps records
| # | Scenario | Evidence to CERT-In | Evidence to DPDP Board | Records to retain |
|---|---|---|---|---|
| 1 | F’s own systems, personal data | F: incident details, logs and any follow-up CERT-In requests | F: breach description, causes, remedial steps, report on notices to individuals | F: system logs (CERT-In: rolling 180 days; Rule 6: one year), the breach record, copies of notices sent, decision log |
| 2 | F’s own systems, no personal data | F: incident details | None, but F should keep its analysis showing no personal data was affected | F: logs, the no-personal-data reasoning, the CERT-In report |
| 3 | P discovers and tells F promptly | P: its own incident details. F: its details, using P’s input | F, relying on P for facts. P should supply data categories, volumes, timeline and root cause on request | P: logs and forensic material. F: copies of P’s notices, its own decision log |
| 4 | P delays | P: its report may show late noticing. F: facts available at the time | F: should record when it was told and explain any gap | Both: timestamps showing when each became aware. Preserve P’s internal communications on timing |
| 5 | F finds out first | F: initial report with what it has; supplement later | F: initial description now; P’s input flows in under contract audit and cooperation rights | F: its source of the alert, timeline, requests to P and responses |
| 6 | Disagreement over personal data | Both entities report on technical facts without waiting to settle the data question | F: records why it did or did not treat the incident as a personal data breach, and what evidence supported that | F: the evidence request, P’s replies, the decision and approver. P: its own analysis, kept for dispute |
Reading the matrix
- CERT-In duties can sit with both parties at once. DPDP duties sit with the fiduciary only.
- The processor’s value to the fiduciary is evidence. Its job in practice is to provide facts fast. That should be a contract obligation with timed deliverables.
- Records are split. CERT-In expects logs for a rolling 180 days. Rule 6 requires logs and personal data kept for one year to support detection and remediation. A sensible policy is to keep the longer period for security logs.
- Everything turns on timestamps. Whoever can show when each person learned what will have the stronger position.
Designing one incident-response procedure for both regimes
The aim is not to duplicate investigations. The aim is to produce one verified fact base and then adapt it twice.
1. One intake, one clock board
All alerts go to a single incident channel with a named incident commander. Open a clock board the moment someone says “possible incident”. It shows:
- time of first detection,
- time the organisation was “brought to notice” (if a vendor, researcher or customer told it),
- the CERT-In six-hour deadline,
- the DPDP “without delay” target for the Board and individuals,
- the 72-hour detailed-report deadline,
- any sector regulator deadline.
Record the start time for each clock separately and in writing. The two regimes may start from different moments.
2. Two triage questions, asked in parallel
| Question | Decides | Owner |
|---|---|---|
| Is this a listed cyber incident under the CERT-In Directions? | CERT-In report | Security lead with legal |
| Has personal data been, or may it have been, compromised in confidentiality, integrity or availability? | DPDP Board and individual notices | Data protection lead with legal |
Run both at once. Do not wait to answer the second before filing on the first.
3. A single fact base
Build one incident record that every filing draws from. It should capture, with timestamps:
- systems and data stores affected,
- data categories and the estimated number and location of people,
- how the incident was detected and by whom,
- containment steps,
- vendor involvement and when each vendor knew,
- evidence collected and where it is stored.
A CERT-In submission takes the technical content. The Board submission takes the same facts framed around the data and the individuals. The notice to individuals takes the plain-language version.
4. A document set prepared in advance
| Document | Purpose |
|---|---|
| CERT-In initial report template | File within six hours with what is known |
| Board initial intimation template (Rule 7(2)(a)) | Nature, extent, timing, location, likely impact |
| Board detailed report template (Rule 7(2)(b)) | Updated facts, causes, mitigation, findings on the responsible person, remedial measures, report on notices |
| Individual notice template (Rule 7(1)) | Plain language: what happened, likely consequences, steps taken, steps the person can take, a contact |
| Vendor evidence request | Standard list of facts the vendor must supply and by when |
| Decision log | Who decided what, when and why, including decisions not to notify |
5. Roles
| Role | Does |
|---|---|
| Incident commander | Owns the process and the clock board |
| Security lead | Containment, forensics, CERT-In technical content |
| Data protection lead | Personal data assessment, DPDP filings, individual notices |
| Legal counsel | Triage decisions, privilege, consistency across filings |
| Communications | Individual notices and public statements |
| Vendor manager | Runs the vendor evidence request and escalation |
| Approver | Signs off every external filing |
6. One voice
The most common avoidable risk is saying different things to different authorities. A CERT-In report that calls an incident minor and a Board report that calls it serious will be compared. Have legal review all outgoing filings against the same fact base.
7. Rehearse
Run a table-top exercise with a vendor-origin scenario. Include a disagreement about whether personal data was involved. Time every step. Our data mapping guide helps you know where personal data sits before an incident, and the DPIA guide covers risk assessment.
What your vendor contracts need to say
Because Rule 7 is silent on processors, the contract does the work. Section 8(2) requires a valid contract, and Rule 6(1)(f) requires security safeguard provisions. Notice timing, evidence and cooperation are for you to add. Our guide to DPDP contract compliance covers the wider set of clauses. These are the incident-specific ones.
| Clause | What it should do |
|---|---|
| Definition of incident | Cover suspected as well as confirmed incidents, and the DPDP breach definition (confidentiality, integrity and availability) |
| Two-stage notice | Immediate alert on suspicion within a short, fixed number of hours, then a structured update |
| Timestamp duty | Processor records and shares when it first became aware |
| Evidence package | List of facts due within fixed hours: systems, data categories, volumes, time window, indicators, root cause |
| Who decides | The fiduciary decides whether personal data was affected. The processor supplies facts |
| Own CERT-In duty | Processor remains responsible for its own CERT-In reporting and tells the fiduciary what it filed |
| Cooperation | Access to logs, staff and forensic reports. Right to audit after an incident |
| Sub-processors | Flow-down of the same timings |
| Log retention | Retention that meets both the 180-day and one-year periods |
| Costs and liability | Allocation of notification, investigation and penalty exposure, with a separate cap or super-cap for data breaches. See our guide to enhanced liability caps |
| Regulator statements | No public or regulator statement naming the other party without agreed coordination, except where the law requires it |
Sample wording (illustrative):
The Processor will notify the Fiduciary without undue delay, and in any event within [X] hours, after becoming aware of any actual or suspected incident affecting Fiduciary Personal Data. The notice will state when the Processor first became aware. Within [Y] hours of the notice, and updated every [Z] hours until closure, the Processor will provide: the systems and data stores affected; categories and approximate volume of Personal Data and Data Principals; the time window of the incident; the indicators of access or exfiltration; containment steps; and the likely cause. The Fiduciary alone decides whether a personal data breach has occurred. The Processor remains responsible for any report it is itself required to make to CERT-In and will give the Fiduciary a copy of that report promptly.
If you are drawing up a data processing agreement, see our data processing agreement template and vendor agreement drafting. For AI tools in the supply chain, see AI vendor contracts.
The implementation gaps
Taking the analysis together, these are the gaps I see between the two regimes, what each causes, and a possible fix. They are suggestions for policymakers and for readers who respond to consultations, not a prediction.
| # | Gap | Practical consequence | Possible fix |
|---|---|---|---|
| 1 | Rule 7 does not address processors | Uncertainty about when the fiduciary’s clock starts and what the processor owes | Official guidance or an FAQ on awareness, and a processor-to-fiduciary notice duty |
| 2 | Different clock-start wording (“brought to notice” vs “becoming aware”) | Parties start clocks at different moments for the same facts | A common reference for “awareness” across both regimes |
| 3 | No shared filing channel or information-sharing arrangement that I could find | Duplicate effort and a risk of inconsistent statements to two authorities | A shared intake or an agreed protocol between CERT-In and the Board, with consistent forms |
| 4 | Overlapping but different triggers | Over- and under-reporting in the first hours | A published mapping of Annexure I categories to personal data breach scenarios |
| 5 | Two log-retention periods | Organisations keep the shorter period and fall short of the longer | Aligned guidance on retention for security logs |
| 6 | The Board is not yet staffed | No one to receive intimations, answer questions or issue guidance before the main duties start | Prompt appointments and pre-commencement guidance |
| 7 | Sector regulators add their own clocks | A third and fourth stream of reporting for banks, insurers, telecom and securities firms | Cross-sector reporting guidance that identifies a primary report and recognises copies |
| 8 | “Without delay” is undefined | Disagreement about acceptable time before the 72-hour detail | Guidance with examples, or a short outer limit for the first notice |
| 9 | Cross-border processors | Unclear reach of CERT-In and DPDP over a foreign vendor’s own filing duties | Clarification of how foreign service providers fit |
| 10 | Provisional notice is implied, not stated | Organisations hesitate to notify early for fear of being wrong | Explicit recognition that early, qualified notice can be supplemented |
None of these requires abolishing or merging the regimes. They are coordination and clarity problems, and they can be addressed through guidance, forms and protocols without changing either law.
What this means by type of organisation
- Startups and SaaS companies. You are often both a fiduciary (for your own customers’ staff data) and a processor (for your customers’ data). Your contracts will point in both directions. Clients will ask you to promise short notice, and your own vendors may not.
- E-commerce and consumer platforms. Large numbers of individuals mean individual notices are a major workstream. See our e-commerce lawyer in India page and e-commerce compliance checklist.
- Regulated sectors. Banks, insurers, capital markets entities and telecom companies have sector reporting on top. Map these before you design the process.
- Foreign companies with Indian users. Check how both regimes reach you. Our guide to data protection laws around the world and our note on standard contractual clauses for exporting data help with the cross-border picture.
- Edtech and AI companies. Sensitive and children’s data raise the stakes. See edtech lawyer in India and AI startup lawyer in India.
A practical checklist before May 2027
- Map where personal data sits and which vendors hold it (data mapping guide).
- List which entities in your group and supply chain are covered by the CERT-In Directions.
- Rewrite vendor incident clauses using the table above.
- Write one incident procedure with a clock board and two triage questions.
- Prepare the six templates.
- Align log retention to the longer period.
- Run a vendor-origin table-top exercise with a personal-data disagreement.
- Check sector regulator reporting and add it to the clock board.
- Re-check the DPDP commencement date, Board appointments and any new guidance every quarter.
- Use the free DPDP compliance checker and website scanner to find the obvious gaps first.
How we can help
We advise Indian and international businesses on DPDP readiness and the contracts that support it.
- Data protection and privacy compliance for DPDP readiness, including incident response planning.
- Contract review of your vendor and processor agreements against the points above.
- Contract drafting of processor, SaaS and service agreements with incident clauses.
- Privacy policy drafting that matches your breach and notice commitments.
- Contract lawyers in India for ongoing support, and our legal retainership for startups.
Want your vendor contracts and incident process checked before the DPDP breach rules start? Tell us who your key vendors are and what data they hold. We’ll come back with a clear scope and fixed fee. Get a quote or message us on WhatsApp.
This article is legal analysis for general information, not advice on a specific incident. Neither CERT-In nor the Data Protection Board has issued guidance on the interaction discussed here, so the readings above are my own and may differ from how the authorities decide. If you are dealing with a live incident, take advice immediately.
Frequently asked questions
Will organisations have to report one data breach to both CERT-In and the Data Protection Board?
Often, yes. A reportable cyber incident that also compromises personal data can trigger a CERT-In report (within six hours) and DPDP intimations to the Board and affected individuals. The two regimes are cumulative under Section 38(1) of the DPDP Act. A cyber incident with no personal data goes to CERT-In only, and a personal data breach that is not a listed cyber incident goes to the Board and individuals only.
Does the DPDP Act replace the CERT-In Directions?
No. The DPDP Act says it is in addition to other laws, and the Act prevails only where there is a conflict. I found no provision that replaces or merges the CERT-In reporting duty. The DPDP Act does omit Section 43A of the IT Act when it commences, which concerns compensation for failure to protect sensitive data, not CERT-In reporting.
What is the deadline for reporting a data breach under DPDP?
Affected individuals must be told without delay. The Board must receive a description of the breach without delay and detailed information within 72 hours of the fiduciary becoming aware, or a longer period the Board allows on a written request (Rule 7). These duties are scheduled to start about 13 May 2027.
Who must report a breach: the Data Fiduciary or the Data Processor?
Under DPDP, the Data Fiduciary alone must notify the Board and individuals. The processor has no direct duty under Rule 7, but the contract should require it to alert the fiduciary quickly and supply evidence. Under the CERT-In Directions, any covered entity that notices a reportable incident may have its own duty, and law-firm summaries of the FAQs say this cannot be shifted by contract.
When does the 72-hour DPDP clock start if my vendor finds the breach first?
The text of Rule 7 says the fiduciary’s duty arises when it becomes aware, which suggests the clock starts when the vendor tells it. A regulator could take a wider view because the fiduciary is responsible for processing done on its behalf. No guidance settles this, so contracts should require fast vendor alerts and fiduciaries should act as if the clock may start earlier.
Is a 24-hour breach notice in a vendor contract enough?
For most vendors that hold significant personal data, probably not. It can leave little time for the “without delay” notices and does not satisfy the vendor’s own CERT-In duty if it is a covered entity. A two-stage clause that requires an immediate alert on suspicion and a fuller update shortly after is safer.
What if we disagree with the vendor on whether personal data was involved?
CERT-In reporting does not wait for that question. For DPDP, the fiduciary decides, using facts the vendor must supply. Treat the dispute as an evidence request with a deadline, make a documented decision, and notify provisionally if the risk of a personal data breach is real.
Does a ransomware attack count as a personal data breach even if no data was stolen?
It can. The DPDP definition covers loss of access and compromise of availability, not only theft. If personal data became unavailable because of the attack, the definition may be met. Record your assessment either way.
Do I need to notify individuals under the CERT-In Directions?
The Directions do not contain a general requirement to notify affected individuals. The DPDP framework does, once it is in force.
How long should we keep logs?
The CERT-In Directions require system logs for a rolling 180 days. DPDP Rule 6 requires logs and personal data to be kept for one year to detect, investigate and remediate unauthorised access, unless another law requires a different period. Keeping security logs for the longer period satisfies both.
Related reading
- DPDP Act and its implications: the complete guide
- Data breach response: the legal playbook for the first 72 hours
- DPDP contract compliance in India
- Data mapping under DPDP
- What is a DPIA under DPDP?
- Consent management rules under the DPDP Act
- Cookie compliance
Legal references
Information Technology Act, 2000, sections 70B(6) and 70B(7); Information Technology (The Indian Computer Emergency Response Team and Manner of Performing Functions and Duties) Rules, 2013; CERT-In Directions No. 20(3)/2022-CERT-In dated 28 April 2022 and related FAQs; Digital Personal Data Protection Act, 2023, sections 2(u), 8(1), 8(2), 8(5), 8(6), 33, 38 and 44(2) and the Schedule; Digital Personal Data Protection Rules, 2025, Rules 6 and 7; MeitY circular F. No. 2(1)/2026-Pers.I dated 6 May 2026 (Board appointments); Regulation (EU) 2016/679 (GDPR), Articles 33 and 4(12), and EDPB Guidelines 9/2022 on personal data breach notification (comparative point only).
