The 72-hour data breach response playbook for Indian businesses

TL;DR: Under the DPDP Rules, a personal data breach requires notification to affected Data Principals without delay, intimation to the Data Protection Board without delay, and a detailed report to the Board within 72 hours. Failure to implement reasonable security safeguards carries a penalty up to ₹50 crore.

The deadline is not the hard part. The hard part is that the clock starts when you become aware, and the typical Indian SMB website has no mechanism for becoming aware. Compromises are usually discovered by a customer, a bank, or Google, weeks after the fact, at which point you have 72 hours to write a detailed account of an incident your logs rotated away three weeks ago.

What counts as a reportable breach

A personal data breach is any unauthorised processing of personal data, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access, that compromises the confidentiality, integrity or availability of that data.

Read that list again, because it is broader than "hacker steals database."

Confidentiality breaches are the obvious ones: a database dumped, a customer list emailed to the wrong recipient, an S3-equivalent bucket left public, an employee copying records to a personal drive on the way out.

Integrity breaches involve unauthorised alteration. An attacker who modifies order records or injects a payment skimmer into checkout has compromised integrity even if nothing was exfiltrated in bulk.

Availability breaches are the ones people forget entirely. Ransomware that encrypts your customer database is a personal data breach. So is a backup failure that permanently destroys records you were obliged to hold. Loss of access counts, whether or not anyone else gained access.

Some concrete cases that qualify and are routinely not treated as breaches: a WordPress site compromised through a vulnerable plugin, where the attacker had database access, even if you cannot prove data was taken. A misconfigured staging environment indexed by Google with real customer data in it. A departing employee's still-active admin account used after their last day. An email sent to 400 customers with all addresses in the To field instead of BCC. A lost, unencrypted laptop with a customer export on it.

The bar is compromise, not proven exfiltration. "We could not confirm data was taken" does not make an incident non-reportable, and treating it that way is the most common judgement error in the first hours.

When the clock actually starts

The obligation triggers on becoming aware of the breach.

That word carries the whole weight of the regime. It does not say when the breach occurred. It does not give you a grace period to investigate before the clock starts. Awareness starts it.

Awareness is not the same as certainty. If your host tells you they detected suspicious outbound traffic from your server, you are aware of something. If a customer reports fraud traceable to your checkout, you are aware. If your file integrity monitor flags a modified core file, you are aware. In none of those cases do you yet know the scope, and in all of them the clock is running.

The instinct is to investigate quietly first and start the clock when you have a clear picture. That instinct is wrong and it is how organisations end up filing late with a worse story than they needed to tell.

The structure the Rules contemplate accommodates uncertainty. You give the Board an intimation without delay, describing what you know now. You notify affected Data Principals without delay. Then you file the detailed report within 72 hours, containing the fuller picture your investigation produced.

The intimation is not the report. Treating them as one document, and delaying both until you have answers, is the failure mode.

One more thing about awareness: it is organisational, not personal. If your developer noticed something odd on Monday and mentioned it in a group chat, the organisation arguably became aware on Monday, regardless of when it reached anyone senior. This is why an internal escalation path matters as much as any technical control.

The first four hours

The sequence below assumes you have just become aware and know almost nothing. That is the normal starting condition.

Do not wipe anything. The reflex is to delete the malicious file, restore from backup and move on. That destroys the evidence you need for the report and usually leaves the entry point intact, which is why reinfection within days is so common. Preserve first.

Take a forensic snapshot. Before changing anything, snapshot the server or take a full image. Most VPS platforms make this a one-click operation. This single step preserves your ability to answer questions later, and it costs minutes.

Preserve logs immediately. Copy access logs, error logs, authentication logs and database logs to somewhere outside the affected system. Logs rotate. If your rotation window is seven days and you are three days from losing the relevant period, this is urgent in the literal sense.

Contain without destroying. Containment options in rough order of preference: block the attacker's IP ranges at the firewall, disable compromised accounts, revoke API keys and tokens, take the affected component offline. Full server shutdown is a last resort because it can destroy volatile evidence and it guarantees an availability incident on top of the confidentiality one.

Rotate credentials, in order. Database passwords, admin accounts, API keys for connected services, SSH keys, payment gateway credentials, email sending credentials. Assume everything the compromised system could read is compromised. This includes credentials stored in a .env file, in wp-config.php, or in any automation tool the server could reach.

Open an incident log. A plain document, timestamped, recording what you observed, when, and every action taken. This becomes the backbone of your detailed report and it is far easier to keep contemporaneously than to reconstruct at hour 60.

Notify your host. They may have infrastructure-side visibility you lack: traffic patterns, prior alerts, evidence of lateral movement. They are also a Data Processor with contractual obligations to you, and this is the moment those obligations become concrete.

Escalate internally. Whoever signs off on external communication needs to know inside the first hour, not at hour 40.

Hours four to twenty-four: scope and notify

Scoping answers four questions, and the report cannot be written without them.

What data was accessible? Not what was proven taken, what was reachable. If the attacker had database credentials, everything in that database was accessible.

How many Data Principals are affected? An approximate number is acceptable and expected. A precise number that arrives at hour 71 is worth less than an honest approximation at hour 20.

What categories of data? Names and emails are one risk profile. Passwords, financial details, government ID numbers or health information are a materially different one.

What is the likely consequence? Credential stuffing against other services if passwords leaked. Payment fraud if card data was in scope. Targeted phishing if the data supports it.

Notification to Data Principals goes out without delay. Not after the 72-hour report, not once you have complete answers. The purpose of notifying individuals is to let them protect themselves, and that value decays by the hour.

What the notification should say, in plain language: what happened, what data of theirs was involved, what the likely consequences are, what you have done, what they should do specifically, and who to contact. Send it directly to affected individuals rather than posting a notice and hoping. If passwords were in scope, force a reset rather than suggesting one.

What it should not do: minimise, use the phrase "we take your privacy seriously," lead with reassurance before facts, or bury the material detail in paragraph six. A notification that reads like it was written by someone protecting the company rather than the reader does measurable additional damage.

Intimation to the Board goes out in parallel. What you know, when you became aware, preliminary scope, immediate actions taken. This is short and it is not the detailed report.

Breach type	Typical detection route	Immediate priority	Notification urgency
Database exfiltration	Customer report, dark web listing	Preserve logs, rotate DB credentials	Highest, credentials at risk
Payment skimmer in checkout	Bank or customer fraud reports	Remove script, snapshot first	Highest, financial exposure
Ransomware encryption	Immediate and obvious	Isolate, assess backup integrity	High, availability breach
Misdirected email	Internal or recipient report	Recall attempt, contain distribution	High, scope usually known
Public staging environment	Search engine indexing	Remove access, check access logs	Depends on exposure duration
Compromised admin account	Login anomaly, unexpected changes	Disable account, audit actions taken	Depends on data reached
Departed employee access	Access review, audit log	Revoke, audit retrospectively	Depends on data reached
Lost unencrypted device	Employee report	Remote wipe if possible, scope export	High if unencrypted

What the detailed report has to contain

The 72-hour report to the Board is a substantive document. Broadly, it needs to cover:

The nature and circumstances of the breach, including how it occurred and the vulnerability or failure that permitted it. The categories of personal data involved. The approximate number of Data Principals affected. The likely consequences for those individuals. The remedial measures taken and planned, including what prevents recurrence. Details of the notifications made to Data Principals, including when and by what means. And your contact point for follow-up.

Notice what that list assumes. It assumes you can reconstruct how the attacker got in, when, and what they reached. That reconstruction is a log exercise.

If your access logs cover seven days and the compromise began in March, you cannot describe the nature and circumstances. You cannot bound the affected population. You are filing a report that says, in effect, that something happened at an unknown time by an unknown route affecting an unknown number of people.

That report is worse than a bad incident. It is evidence that your safeguards were not reasonable, which is the specific failing that carries the ₹50 crore ceiling.

Write it plainly and do not speculate beyond your evidence. "Log retention did not permit determination of the initial access date" is a defensible sentence. An invented timeline is not, and it will not survive contact with a forensic examination.

The detection gap that makes this impossible

Here is the uncomfortable arithmetic.

Attackers on small business websites are frequently present for weeks before anything visible happens. The compromise is quiet by design: a skimmer that captures card details silently, a backdoor left for later use, a slow extraction that stays under any threshold that would trigger an alert. Nothing breaks. The site keeps serving pages. Revenue continues.

Discovery comes from outside. A customer's bank flags fraud clustering around your checkout. Google marks the site as deceptive. A researcher finds your data in a dump. Your host notices outbound traffic to somewhere odd.

By that point your dwell time is measured in weeks, and everything the 72-hour report requires is in logs that no longer exist.

The typical shared hosting configuration retains access logs for somewhere between three and fourteen days. That window is fine for debugging a 500 error. It is useless for investigating an incident that began before it.

This is the gap. Not the 72 hours, which is a reasonable deadline for an organisation that detects its own incidents, but the weeks of undetected dwell time that precede hour zero and put every required fact out of reach.

Closing it is not expensive. It is just not exciting, which is why it does not get done.

Building the capability before you need it

Seven things, in rough order of value per rupee.

Extend log retention to ninety days minimum. Access logs, error logs, authentication logs. Ship them off the server so a compromise cannot erase them, which is the first thing a competent attacker does. This is the single highest-value change on the list.

Run file integrity monitoring. Alert on unexpected changes to core files, themes, plugins and anything in the web root. Most WordPress compromises modify files, and an alert on the day it happens converts a six-week incident into a same-day one.

Enable server-level malware scanning. Not a plugin, which an attacker with file access can disable. Server-side scanning sits outside the application's blast radius.

Confirm your host's breach notification commitment in writing. How fast will they tell you? Hours or days? This should be in the processing agreement. Our guide on DPDP hosting obligations covers the full set of clauses to check.

Test a restore quarterly. Not verify that backups exist, actually restore one and confirm the site comes up. Untested backups fail at exactly the moment you need them, and during a ransomware incident the backup is the entire response plan. The 3-2-1 backup approach is the baseline here.

Write a one-page incident plan. Who declares an incident. Who contacts the Board. Who talks to customers. Who talks to the host. Where the incident log lives. One page, printed, because your first real incident is not when you want to be deciding this.

Do an access review twice a year. Every admin account, every API key, every integration. Departed employees, forgotten contractors, agencies you stopped working with, plugins that hold credentials you have not audited.

Total cost for a small business: some configuration, better log retention on the hosting plan, and about half a day of setup. Against a ceiling of ₹50 crore for inadequate safeguards, the arithmetic is not close.

Mistakes that make a bad incident worse

Cleaning up before snapshotting. Destroys evidence, usually leaves the entry point open, and produces reinfection within days.

Waiting for certainty before notifying. The Rules contemplate an intimation followed by a fuller report precisely because certainty takes time. Silence while you investigate is not a neutral choice.

Restoring from a backup taken after the compromise. If the attacker was present for six weeks, backups from the last six weeks contain the backdoor. Restoring one reinstates it, and this is why sites get reinfected within hours of a clean-looking recovery.

Notifying by public notice only. Posting on your website is not the same as telling the people affected. Direct notification is the expectation.

Downplaying scope in the customer notification. "A limited number of accounts may have been affected" when you do not know the number is a claim you may have to retract, and retracting it is worse than never making it.

Forgetting the connected systems. The compromised web server had credentials for your email platform, your CRM, your payment gateway, your automation tool. Rotating only the database password leaves the rest open.

Never establishing root cause. If you do not know how they got in, you cannot say the remediation prevents recurrence, and that statement is part of the report.

FAQs

What is the breach reporting deadline under India's DPDP Act?

Affected Data Principals must be notified without delay, the Data Protection Board must receive an intimation without delay, and a detailed report must reach the Board within 72 hours. The 72-hour clock starts when you become aware of the breach, not when the breach occurred, and the intimation and the detailed report are separate filings rather than one document.

Does the 72 hours start from the breach or from discovery?

From awareness. If an attacker was present for six weeks before you discovered the compromise, the clock starts on discovery, not six weeks earlier. Awareness does not require certainty about scope, so credible indications such as a host alert or a customer fraud report start the obligation running while you are still investigating.

What counts as a personal data breach in India?

Any unauthorised processing, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access, that compromises the confidentiality, integrity or availability of personal data. This includes ransomware encrypting your database, an email sent with addresses in the To field, a public staging environment containing real data, and a compromised site where an attacker had database access even without proven exfiltration.

Do I have to report if I cannot prove data was actually stolen?

Generally yes. The standard is compromise, not proven exfiltration. If an attacker had access to a system holding personal data, that data was compromised regardless of whether you can demonstrate it left the server. Treating unproven exfiltration as non-reportable is one of the most common judgement errors in the first hours of an incident.

What are the penalties for a data breach under DPDP?

Failure to implement reasonable security safeguards carries a penalty up to ₹50 crore, and the most serious violations under the Act reach ₹250 crore. Penalties apply per contravention rather than per company. The Board can also publish details of a violation, adding reputational exposure on top of the financial penalty.

What should I do in the first hour of discovering a breach?

Snapshot the server before changing anything, copy logs to a location outside the affected system, contain the attacker without destroying evidence, and start rotating credentials beginning with the database and any API keys the server could reach. Open a timestamped incident log, notify your hosting provider, and escalate internally to whoever will sign off on external communication.

Should I take my website offline after a breach?

Usually not as the first move. Full shutdown can destroy volatile evidence and creates an availability incident alongside the confidentiality one. Prefer targeted containment: blocking attacker IP ranges, disabling compromised accounts, revoking tokens, or taking a single affected component offline. Reserve full shutdown for active ongoing data extraction you cannot otherwise stop.

How long should I keep server logs for breach investigation?

Ninety days minimum, and ship them off the server so a compromise cannot erase them. Typical shared hosting retains logs for three to fourteen days, which is adequate for debugging and useless for investigating an incident that began earlier. Without sufficient log history you cannot reconstruct the nature, timing or scope the detailed report requires.

What must the 72-hour detailed report include?

The nature and circumstances of the breach including how it occurred, the categories of personal data involved, the approximate number of Data Principals affected, the likely consequences for them, remedial measures taken and planned, details of the notifications made to affected individuals, and a contact point for follow-up. Approximate figures are acceptable; invented specifics are not.

Is my hosting provider responsible for reporting the breach?

No. Your host is a Data Processor, and the reporting obligation sits with you as the Data Fiduciary even where the processing was carried out by a processor. Your host's responsibility is to secure the infrastructure and to notify you under the terms of your processing agreement, which is why the notification window in that agreement directly determines whether you can meet your own deadline.

Can I restore from backup and treat the incident as closed?

Not without establishing root cause and checking backup integrity. If the attacker was present for weeks, recent backups contain the backdoor, and restoring one reinstates the compromise. Restoration is a recovery step, not an investigation, and the report still requires you to describe how the breach occurred and what prevents recurrence.

What should the customer notification actually say?

What happened, what data of theirs was involved, the likely consequences, what you have done, what they should do specifically, and who to contact. Send it directly to affected individuals rather than relying on a public notice. If passwords were in scope, force a reset rather than suggesting one, and avoid leading with reassurance before the material facts.

Conclusion

Seventy-two hours is a workable deadline for an organisation that detects its own incidents. It is an impossible one for an organisation that finds out from a customer six weeks later.

That is the real gap, and it sits entirely before hour zero.

Everything the detailed report demands, how they got in, when it started, what they reached, how many people are affected, is a question answered from logs. If the logs are gone, the report becomes an admission that you had no visibility, which is the same finding as inadequate safeguards.

The response side is learnable in an afternoon. Snapshot before you clean. Preserve logs first. Contain without destroying. Notify without waiting for certainty. Rotate every credential the compromised system could reach, not just the obvious one. Keep a timestamped log from the first minute.

The detection side has to be built in advance, and it is neither difficult nor expensive: ninety days of off-server log retention, file integrity monitoring, server-level scanning, a host that commits in writing to telling you within hours, and a restore you have actually tested.

HostCloud runs extended log retention, server-level malware scanning and automated daily backups you can restore and verify from the panel, on Indian infrastructure with a written processing agreement covering breach notification timelines. Plans start at ₹99 a month at https://hostcloud.in. If you are mid-incident right now, contact support first and preserve everything before you change a single file.