The worst hour of a breach is rarely the hour you find it. It is the hour, days later, when somebody asks precisely when you first knew, and the answer turns out to carry more consequence than anything your engineers did in between. A security incident in India starts more than one clock. They run at different speeds, they are triggered by different facts, and the ones carrying the largest financial exposure are not the ones a security operations team is trained to watch.
Most Indian incident response plans are good documents written by the wrong committee. They are precise about isolation, forensic triage, credential rotation, malware containment and service restoration, because those sections were written by people who do that work. Then, somewhere near the end, under a heading like external communication, there is a single line: notify legal and the relevant regulators as required. That line is doing an enormous amount of unexamined work. It is where the reporting duty measured in hours lives, where the duty to tell every affected individual lives, and where the evidence obligations that decide a later dispute live. None of it survives being compressed into one bullet in an appendix.
This article is written for the people who end up in the room: the general counsel, the compliance head, the data protection officer, the incident commander and the CISO who has to explain a timeline to a board. It sets out the obligations that run in parallel after a breach in India, the tension between containing an incident and preserving the evidence of it, the honest limits of asserting privilege over a forensic report, and a runbook for the first 72 hours built around legal actions rather than technical ones. It is general commentary for practitioners, not legal advice, and the position on any specific obligation must be confirmed against what is actually notified and in force when you are acting.
The argument in one line
Breach response plans written by security teams alone routinely satisfy every technical objective and miss the legal deadlines that carry the largest penalties. The clock that costs you the most is not the clock your SOC is watching, and it usually starts before anybody has decided the incident is serious.
Two Clocks, Running at Different Speeds
The first thing to internalise is that there is no single notification event in India. There are at least two distinct regimes, with different triggers, different recipients, different content and different timing, and they were not designed as a set. One comes from the cybersecurity side of the state and cares about incidents against systems. The other comes from the data protection side and cares about personal data and the people it belongs to. An event can trigger one, the other, or both, and working out which is a legal judgement that has to be made fast and on incomplete facts.
The CERT-In clock: fast, technical, and triggered by noticing
In April 2022 the Indian Computer Emergency Response Team issued directions under the Information Technology Act, 2000 covering cybersecurity incidents. Two features of those directions matter more than any other to an in-house team. First, specified categories of cyber incident must be reported to CERT-In within a short window measured in hours from the time the incident is noticed. Second, service providers, intermediaries, data centres, body corporates and similar entities are required to enable and securely maintain logs of their systems for a defined rolling period, held within India and made available when called for. The exact list of reportable incident types, the precise reporting window, the retention period and the categories of entity covered must be checked against the directions as they stand rather than taken from any article, including this one.
The word that repays attention is noticing. The trigger is not confirming, not concluding an investigation, not receiving a forensic report and not the moment your executive committee accepts that you have a problem. A duty framed around noticing an incident starts running while the technical picture is still ambiguous, which is exactly when an organisation is least inclined to make an external filing. Every hour spent waiting for certainty is an hour spent inside a window that was never sized for certainty.
The DPDP clock: broader in reach, harder in operation
The Digital Personal Data Protection Act, 2023 approaches the same event from the other end. Its architecture places obligations on the data fiduciary, the entity that determines the purpose and means of processing personal data, in respect of the data principal, the individual the data is about, and it extends duties down the chain to the data processor acting on the fiduciary's behalf. Section 8(6) requires a data fiduciary, in the event of a personal data breach, to give intimation to the Data Protection Board and to each affected data principal in the form and manner prescribed. For two years the words in the form and manner prescribed carried the whole obligation and there was nothing to read behind them. That stopped being true in November 2025.
Rule 7 of the Digital Personal Data Protection Rules, 2025 prescribes the form and manner, and it sets more than one clock.
- To each affected data principal, without delay. The intimation goes to her through her user account or another mode of communication she has elected, in a concise, clear and plain manner, and it must set out a description of the breach including its nature, extent and timing, the consequences relevant to her that are likely to arise, the measures implemented or being implemented to mitigate risk, the safety measures she may take herself, and the business contact details of a person able to respond to her queries.
- To the Board, without delay. A description of the breach including its nature, extent, timing and location of occurrence, and its likely impact.
- To the Board again, within seventy-two hours of becoming aware of the breach, or such longer period as the Board may allow on a written request. This is the detailed filing: updated and detailed information on the first intimation, the broad facts, circumstances and reasons leading to the breach, the measures implemented or being implemented to mitigate risk, the findings regarding the person who caused the breach, the remedial measures taken to prevent recurrence, and a report on the intimations given to affected data principals.
Where the seventy-two hours in the title actually comes from
The number circulates loosely enough that it is worth pinning down. Seventy-two hours is not the deadline for telling anybody that a breach has happened. Both of those duties, to the affected individual and to the Board, run without delay, which is faster and harder. The seventy-two hours is the window for the second, detailed report to the Board, and it runs from becoming aware of the breach rather than from establishing its scope. An organisation that reads the number as three days in which to work out what to say has inverted the rule. The telling is immediate. Seventy-two hours is when the explanation is due.
The operational lift is severe and cannot be improvised, which is why the runway matters more than the commencement date. Intimating the Board is a single filing to a single recipient. Intimating each affected data principal is a different order of problem. It requires you to know which individuals are in the affected dataset, to resolve those records to identities, to hold current contact details, to send a communication that is comprehensible rather than legalistic, to survive the volume, and to keep proof that you did it. Organisations discover during an incident that their customer identity graph is not clean enough to answer the question, which individuals were in this table. That discovery is not a legal problem you can argue your way out of at hour thirty.
When Rule 7 actually bites, and what is already live
The rules are published, so vagueness about their content is no longer defensible. Their commencement is staged. The rules constituting and governing the Data Protection Board took effect on notification in November 2025. The consent manager registration rule follows twelve months later. The substantive tranche, which includes Rule 7, commences eighteen months after notification, which falls in May 2027. Two things follow, and they point the same way. An organisation planning today is building to a fixed published standard rather than to a guess. And the operational lift, above all the duty to intimate every affected data principal without delay, takes longer to build than the runway that is left, so the commencement date is not the date to start. Confirm the position as notified on the day you act. Note also that the CERT-In directions are in force now and are not waiting for any of this.
Why We Were Still Investigating Is Not an Answer
The single most common failure in Indian breach response is not concealment. It is a sincere and reasonable instinct to know what happened before saying anything. Engineers do not want to report a number that turns out to be wrong. Executives do not want to alarm the market over an event that resolves into a misconfiguration. Counsel does not want a filing on record that a later forensic report contradicts. Every one of those instincts is professionally respectable and every one of them, applied to a clock measured in hours, produces a late filing.
The way out is to stop treating the first report as a conclusion. A short-window reporting regime is short precisely because it expects an early and incomplete account, followed by updates. Build the template accordingly, and pre-agree with your security leadership that it will be filed on the facts available rather than held for the facts you would prefer. A first report can be honest and still be thin.
- What was noticed, and exactly when. The detection timestamp, the source of the detection, and who first saw it. This single field is the one most likely to be examined later.
- What kind of incident it appears to be, stated as a preliminary characterisation with the uncertainty made explicit rather than hidden.
- Which systems or services are implicated so far, and which are still being assessed.
- Whether personal data is known, suspected or not yet assessed to be involved, kept deliberately separate from the technical account.
- What containment steps have been taken, and what evidence has been preserved.
- A named point of contact who will actually answer the phone at two in the morning, with a deputy.
A short clock does not ask you to be right. It asks you to be prompt, honest about your uncertainty, and willing to update.
The Obligation Map: Who You Owe What, and Why
The practical instrument every in-house team should own before an incident is not a policy. It is a one-page map of every obligation a breach can trigger, who each one runs to, what fact sets it running, and what has to be preserved in order to discharge it and to defend it later. The table below is a starting shape. Populate it with your own regulators, your own contracts and your own systems, and keep it current, because the value of the map collapses the moment it describes a version of the business that no longer exists.
| Obligation | Who it runs to | What triggers it | What must be preserved |
|---|---|---|---|
| Cyber incident report under the CERT-In directions | CERT-In | Noticing a cyber incident of a specified type. Scope and window must be checked against the directions as they stand. | Detection alerts, the first-notice timestamp and its source, the internal escalation trail, and the report as filed. |
| Log enablement and retention | CERT-In, on being called for | A continuing obligation, not incident specific. It is already running before anything happens. | System and security logs for the required rolling period, maintained within India, with integrity controls that survive scrutiny. |
| Intimation of a personal data breach to the Board | The Data Protection Board under Section 8(6) and Rule 7(2) | Becoming aware of a personal data breach. A description without delay, then a detailed report within seventy-two hours of becoming aware. Rule 7 commences with the substantive tranche of the 2025 Rules in May 2027. | The scoping analysis, dataset extracts, the basis on which affected records were identified, both intimations as sent, and above all the recorded moment of becoming aware, which is what the seventy-two hours runs from. |
| Intimation to affected individuals | Each affected data principal, under Section 8(6) and Rule 7(1) | Becoming aware of a personal data breach affecting that individual. The duty is to intimate without delay, not within seventy-two hours, and it is the harder of the two to operate. | The mapping from affected records to identities, contact data used, the notice text against the five content heads Rule 7(1) prescribes, and delivery evidence at volume. |
| Sectoral incident reporting | Your sector regulator, where you are a regulated entity | Sector-specific triggers that are usually broader and faster than the general ones. Highly sector-dependent. | The materiality assessment, who made it, when, and the record of the decision to report or not report. |
| Disclosure by a listed company | The stock exchanges and, through them, the market | An assessment that the event is material under the listing framework applicable to you. | The materiality note, board or committee minutes, and the timing record showing when the assessment was made. |
| Contractual notification | Enterprise customers, and upstream fiduciaries if you are a processor | A security incident as defined in the contract, which is often wider than any statutory definition. | The contract inventory, the clause extract relied on, the notice served, and proof of service within the contractual window. |
| Notice under a cyber insurance policy | Your insurer and broker | Policy conditions, which frequently require notice before you incur significant response costs. | The policy wording, the notice, and a contemporaneous record of costs incurred and consents obtained. |
| Preservation for prospective proceedings | A future court, tribunal or regulator | A dispute or proceeding becoming reasonably foreseeable, which for a serious breach is close to immediate. | Forensic images with hash values, chain of custody records, the incident timeline, and messages on relevant channels. |
Two observations about that table are worth stating plainly. The first is that only two of the nine rows are things a security team would naturally own. The second is that the preservation column, which almost never appears in a technical runbook, is what determines whether you can prove compliance a year later. An organisation that reported on time and cannot demonstrate it is, from a regulator's chair, hard to distinguish from one that did not.
Sectoral Overlays: The Rules That Sit on Top
For regulated entities the general regime is a floor rather than the whole picture. Banks, non-banking financial companies, payment system participants, insurers, market intermediaries and telecom licensees each operate under supervisory frameworks that impose their own incident reporting expectations, often with shorter timelines, wider triggers, prescribed formats and named supervisory contacts. Listed companies carry a separate question entirely, which is whether the incident is material enough to require disclosure to the exchanges, and that assessment has to be made and documented while the facts are still moving.
These overlays are genuinely sector-specific and this article deliberately does not attempt to state their content. What it does assert is a governance point: the mapping of which frameworks apply to your entity, in which capacity, has to be done in advance by someone who understands both the regulation and your legal entity structure. Groups with a regulated subsidiary, a technology entity and an offshore parent routinely discover mid-incident that the entity holding the compromised system is not the entity holding the regulatory licence, and that the reporting duty, the contractual duty and the operational capability sit in three different companies.
Containment Versus Preservation: The Tension Nobody Briefs
Every instinct of a competent engineer under attack is to make the problem stop. Isolate the host, kill the process, rotate the credentials, rebuild the machine from a clean image, restore the service and move on. That instinct is correct on the operational axis and it is capable of destroying, in twenty minutes, the only evidence that would later tell you what was taken, when the attacker got in, and whether the story you told your regulator was accurate.
Volatile memory disappears on reboot. Reimaging a compromised host overwrites the artefacts that establish dwell time. Log rotation quietly discards the window you most need. A well-meaning administrator who deletes the attacker's tooling has removed the exhibit. None of these are acts of bad faith and all of them are the sort of thing that, reconstructed later by an adversary in a proceeding, look far worse than they were. The rule to embed in the plan is simple to say and requires authority to enforce: image before you wipe, and preserve before you restore.
The resolution is not to slow containment down. It is to make preservation a parallel workstream with its own owner, started at the same minute as containment, with pre-agreed authority to say what may not be touched yet. In practice that means one named person on the bridge whose only job is evidence, a standing instruction to suspend log rotation and auto-deletion across the relevant systems, and a forensic provider already retained so that the negotiation of a statement of work is not sitting between you and the first image.
Privilege, and Its Honest Limits in India
There is a well-worn instinct, imported largely from American practice, to route the forensic investigation through counsel so that the resulting report is privileged. The instinct is sound as far as it goes. Professional communications between an advocate and a client are protected under Indian law, and that protection has been carried into the Bharatiya Sakshya Adhiniyam, 2023, which replaced the Indian Evidence Act, 1872. Structuring matters: a forensic firm retained by external counsel, for the purpose of advising on legal exposure, with the report addressed to counsel, is in a materially better position than one retained by the IT department on a purchase order.
The limits, however, deserve more candour than they usually get. India has no doctrine of work product in the American sense, and the position of communications with in-house counsel who are also employees is contested rather than settled. A regulator exercising a statutory power to call for information is not necessarily met by a privilege label. Most importantly, privilege protects communications, not facts. The date you detected the intrusion, the number of records affected and the systems involved are facts. They do not become unavailable because they were also recited in a memorandum to a lawyer. A team that believes the whole investigation is shielded will speak carelessly on that assumption, which is how the label makes things worse rather than better.
Do not let a privilege label change how people write
The realistic goal is to reduce the risk that a legal assessment of exposure becomes a public exhibit. It is not a guarantee, and it is certainly not a licence to speculate in writing. Assume that any document you create during an incident may one day be read by a regulator, a counterparty and a judge. Write the technical record as a factual timeline with no adjectives, keep legal assessment of exposure in a separate, properly structured channel with counsel, and never mix the two in the same file. Marking a document privileged does not make it privileged, and a wrongly labelled document that turns out to be disclosable is worse than one that was written carefully in the first place.
The Clocks You Signed: Contractual Notification
Statutory duties get the attention. Contractual duties get the litigation. Enterprise customers, particularly regulated ones and particularly those procuring from a vendor after their own bad experience, negotiate security incident clauses with notification windows measured in hours, defined by reference to a security incident that is broader than any statutory definition and often not limited to personal data at all. Those clauses carry service credits, audit rights, step-in rights, termination rights and indemnities, and unlike a regulator, a counterparty has every commercial incentive to enforce them.
The enterprise customer clock
A large customer's master services agreement may require notice within a fixed number of hours of becoming aware, to a named contact, in a specified form, with cooperation obligations attached. You cannot comply with a clause you cannot find, which is why the contract inventory is an incident response asset, not a procurement artefact.
The upward duty in the processor chain
If you process personal data on behalf of another organisation, your obligation is to tell them promptly enough that they can meet their own duties. Their clock is your deadline. The same logic runs down to your sub-processors, whose notice terms you should have set deliberately rather than accepted as offered.
The insurer's notice condition
Cyber policies commonly require prompt notice and prior consent before significant response costs are incurred, including the appointment of forensic and legal advisers. Retaining your preferred firm at midnight without checking the panel provisions is a familiar and expensive way to complicate a claim.
Lender, investor and board undertakings
Facility agreements, shareholder documents and material contracts can carry their own notification or no-material-adverse-change reporting. These are rarely in the incident plan and are usually discovered by the finance team a week later, which is a week too late.
The operational conclusion is unglamorous. Before anything happens, extract from your contract portfolio every clause that creates a notification duty on a security incident, record the trigger, the window, the recipient and the required form as structured data, and keep it somewhere the incident commander can open at two in the morning. A portfolio you have to read during an incident is a portfolio you will not read during an incident.
Communications Discipline While the Facts Are Moving
During an incident an organisation generates an extraordinary volume of internal writing, most of it in fast, informal channels, much of it speculative, and nearly all of it discoverable in some form later. Engineers under pressure write things like this looks like it has been open since March or we always knew that box was exposed. Those sentences, written in good faith at hour six by someone with incomplete information, read very differently when quoted back in a proceeding eighteen months later, and they are exceptionally difficult to correct once they exist.
- Run the incident on a small number of designated channels, and tell everyone which ones they are, so that the record has a shape rather than being scattered across personal chats.
- Keep one authoritative factual timeline, owned by a named person, updated with timestamps and sources. Everything external is drawn from it.
- Separate the factual timeline from the assessment of cause, blame and exposure. Conflating them is how a working hypothesis becomes an admission.
- Instruct the team, in writing and early, to avoid speculation about cause, scope, blame and legal consequence in informal channels.
- Pre-draft holding statements for customers, employees and the press, so that the first external words are not improvised by whoever is nearest the phone.
- Route all counterparty and regulator communications through one desk, so that two teams do not describe the same incident in two incompatible ways.
The Tail: What Happens After the Incident Closes
The technical incident ends when service is restored and the intruder is out. The legal incident is only beginning. The Schedule to the DPDP Act, 2023 puts figures on this, and they are the reason the regime is taken seriously: a penalty that may extend to two hundred and fifty crore rupees for breach of the obligation under Section 8(5) to take reasonable security safeguards, and a further penalty that may extend to two hundred crore rupees for breach of the Section 8(6) obligation to give the Board or the affected data principal notice of a personal data breach. They are separate entries, so a badly handled breach can attract both: one for the failure that let it happen and one for how it was reported afterwards. The CERT-In directions are issued under the Information Technology Act, 2000, and non-compliance carries consequences under that Act. Regulated entities face supervisory action layered on top. Beyond the regulators sit the private claims: contractual claims and indemnity calls from enterprise customers, consumer complaints, employment disputes where staff data was involved, and, for listed companies, uncomfortable questions about disclosure timing.
What all of that has in common is that it is decided on the record of your first 72 hours. Not on the sophistication of your security architecture, not on how hard your team worked, but on when you knew, what you did, whom you told, when you told them and whether you can prove it. That is a documentation outcome, and documentation is a legal function.
It also has a governance dimension that in-house teams should get ahead of. A material breach will be reported to the board or the audit committee, and the questions are predictable: was this within our risk appetite, did we meet our reporting obligations, what is our residual exposure, and what has changed since. Prepare a standing reporting format so that the answer to the first board question is not assembled in a panic. Directors respond far better to a dull, complete chronology than to reassurance, and a written record of what was reported to the board and when is itself part of your defence.
A First 72 Hours Runbook, Written From the Legal Side
The sequence below is deliberately expressed in legal actions. It assumes your technical playbook already exists and runs in parallel. Times are indicative, because the only clock that genuinely matters starts when the incident is noticed, and that moment is often earlier than anyone acknowledges at the time.
Hour zero: fix the time of noticing, in writing
Record the exact moment of first detection, who saw it, and how. Every clock in this article runs from a version of that moment, and it is the single fact most likely to be tested later. Establishing it contemporaneously is far better than reconstructing it from memory during an inquiry.
Hour one: stand up incident command with legal in it
Name the incident commander, the evidence owner, the communications owner and the legal lead. Confirm the decision rights: who can approve a regulatory filing, who can approve customer notice, who can authorise remediation that will destroy evidence. Undefined authority is what turns an eight-hour window into a fourteen-hour one.
Hour one: issue the preservation instruction
Suspend log rotation and auto-deletion on relevant systems and channels, freeze the affected estate, and instruct that no host is rebuilt and no cloud resource is terminated without the evidence owner's sign-off. Preservation started late cannot be started retrospectively.
Hours one to four: make the two threshold calls
Is this within the categories of cyber incident that must be reported to CERT-In, and does it involve personal data such that the Section 8(6) and Rule 7 intimation duties are engaged, on the position notified at the time you act. Record the reasoning and the time the call was made, including if the answer is no. A documented negative decision is defensible. An undocumented one is not.
Hours two to six: engage counsel and forensics properly
Retain external counsel and, through them, the forensic provider, on a retainer arranged in advance rather than negotiated now. Check the insurance policy for consent and panel conditions before appointments are made, and give notice to the insurer if the policy requires it.
Within the reporting window: file, even if the picture is thin
Submit the CERT-In report on the facts you have, with uncertainty made explicit and a commitment to update. Do not hold it for the forensic conclusion. Keep the filed copy, the submission acknowledgement and the timestamp together in the evidence set.
Day one: run the contract sweep
Pull every agreement with a security incident notification clause and identify the ones whose windows are shortest. Serve the notices in the specified form and to the specified address, and keep proof of service. This is where a maintained contract register earns its cost several times over.
Days one to two: scope the personal data, deliberately
Determine which categories of personal data and which individuals are affected, and record how you determined it. This drives the DPDP intimations, the content of individual notices and much of the later exposure analysis. Resist the pressure to state a headline number before the scoping method is sound.
Without delay once personal data involvement is established: both DPDP intimations
Note that this step is not scheduled for a particular day, because Rule 7 does not schedule it either. The intimation to the Board and the intimation to each affected data principal both run without delay. Then the detailed report to the Board is due within seventy-two hours of when you became aware, which is usually earlier than the moment you finished scoping. Write the individual notice for a person, not a lawyer, and check it against the five heads Rule 7(1) prescribes: what happened including nature, extent and timing, what it is likely to mean for her, what you have done to mitigate, what she should do herself, and the business contact details of someone who will actually answer her.
Days two to three: brief the board and align the external story
Give the board or audit committee a factual chronology, the regulatory position, the known exposure and the open questions. Ensure that what your regulator has been told, what your customers have been told and what your press statement says are the same account at different levels of detail.
After the window: close the loop and keep the file
File updates as the picture firms up, complete the notifications, and assemble one indexed evidence file covering the timeline, the decisions, the filings and the proofs of service. Then run a post-incident review that treats the missed legal steps as seriously as the missed technical ones.
You will not be judged on how quickly you understood the breach. You will be judged on how quickly you told the people you owed a duty to, and whether you can show it.
Where CourtMesh Fits, and Where It Does Not
It is worth being exact about what a platform can contribute here, because incident response is a domain where overclaiming does real damage. CourtMesh does not detect breaches, does not do forensics, does not tell you whether an obligation has been triggered and does not give legal advice. What it addresses is the part of this article that is about records, contracts and the disputes that follow.
Notification clauses held as tracked obligations
My Agreements, the CourtMesh contract lifecycle app, keeps contracts in one place with obligations captured as structured data rather than left in prose. Security incident notification windows belong there, so the contract sweep on day one is a query rather than an archaeology project.
Counterparty exposure, read from the record
Counterparty litigation and insolvency screening lets you see what a vendor or customer is already involved in. Where a breach originates in a vendor chain, the litigation record is often the fastest honest read on how that counterparty behaves when a relationship goes wrong.
Precedent research across the whole court system
Unified search covers the Supreme Court, 25 High Courts, District Courts and Tribunals over a corpus of roughly 310 million cases drawn from official government portals, with AI case analysis to work through what a judgment actually held. Useful when the tail arrives and you need to see how comparable disputes have been treated.
A private watch on the parties that concern you
An organisation-scoped watchlist surfaces new matters involving a party you are monitoring. After an incident, that is a practical way to learn about a claim when it is filed rather than when it is served on you.
None of that makes an organisation compliant, and nothing honest would claim otherwise. It reduces the number of things that have to be reconstructed under pressure, which in the first 72 hours is a meaningful contribution and not the same as a solution.
Rehearse the legal clock, not just the technical one
Most Indian organisations have a competent technical incident plan and a single unexamined line covering everything a lawyer would recognise as an obligation. That asymmetry is where the largest penalties, the contractual claims and the board-level questions come from. Map the obligations before you need them, decide who is allowed to file on incomplete facts, make preservation a parallel workstream with real authority, and keep your notification clauses somewhere you can query at midnight. CourtMesh keeps contract obligations, counterparty exposure and case law research behind one login, with My Agreements for the contracts and unified search across roughly 310 million cases for the disputes that follow. It will not respond to your breach for you, and it does not give legal advice. It will stop the answers being scattered across four systems on the worst day of your year.
Explore CourtMesh
