This project is not covered by Drupal’s security advisory policy.
One incident rarely creates one duty.
A breach at an Indian operator serving European customers engages three regimes at once, from a single moment of awareness. They do not agree on the deadline, on what starts the clock, or on whether a threshold applies at all:
| Duty | Due |
|---|---|
| CERT-In report | 6 hours |
| DPDP intimation to affected Data Principals | without delay |
| DPDP initial description to the Board | without delay |
| DPDP detailed intimation to the Board | 72 hours |
| GDPR notification to the supervisory authority | 72 hours, where feasible |
| GDPR communication to data subjects | without undue delay, where article 34 applies |
Missing one because you were occupied with another is the failure this module exists to prevent.
How it works
An incident records what happened. Each duty arising from it is a separate obligation, carrying its own trigger event, clock start and deadlines.
The trigger matters as much as the duration, because regimes disagree about what starts the clock. CERT-In starts on noticing or on being brought to notice. The DPDP Rules start on becoming aware. The GDPR starts on the controller becoming aware, which a processor's notification may be what causes. A single timestamp on an incident would force them all to pretend they agreed.
Deadlines are computed from the regime on every read rather than stored, so correcting a regime corrects the historical records instead of leaving a trail of wrong figures behind.
Regimes are plugins
No maintainer can track every statute. A jurisdiction can be added by another module without touching this one.
Every regime must cite the instrument its deadlines come from, and a test enforces that for all of them, present and future. A deadline sourced from a vendor blog is worse than no deadline, because an operator would rely on it.
Three ship today:
| Plugin | Jurisdiction | Instrument |
|---|---|---|
cert_in |
India | No. 20(3)/2022-CERT-In, MeitY, 28 April 2022, under s. 70B(6) of the IT Act, 2000 |
dpdp_breach |
India | S. 8(6), DPDP Act 2023; rule 7, DPDP Rules 2025 (G.S.R. 846(E), 13 November 2025) |
gdpr_breach |
EU and EEA | Articles 33 and 34, Regulation (EU) 2016/679, EUR-Lex CELEX 32016R0679 |
Implement RegimeInterface or extend RegimeBase, declare the plugin with the #[Regime] attribute, and supply a source. Contributions adding further jurisdictions are welcome.
What this module does not do
It does not make a site compliant. It records and times what you already know. An organisation that never notices an incident is not helped by it, and no amount of record-keeping substitutes for detection.
It does not decide which regimes apply to you. Whether you are an essential entity, a Significant Data Fiduciary, or a controller subject to the GDPR are legal questions with consequences. You declare the obligations; the module tracks the clocks that follow.
It does not detect incidents, and it does not submit reports. It records that a report was sent, by which route, and when.
It cannot confirm log retention. Core's Database Logging trims by row count rather than by age, so a busy site can discard a fortnight of entries while a quiet one keeps years, and where log data physically sits is a hosting question. The module reports both facts rather than displaying a tick it cannot justify.
Honest failure modes
An obligation whose regime plugin is missing, because the module providing that jurisdiction was uninstalled, reports no deadline rather than inventing one.
An incident with no obligation recorded against it says so plainly and warns on save, because an empty column would read as nothing to do when what it means is that nobody has yet decided which duties apply.
Permissions
Logging an incident and declaring it reported are separate permissions. Whoever notices something can record it immediately without also holding the authority to say a report was filed.
Requirements
Drupal 11. No third-party libraries.
Related
DPDP Compliance Toolkit covers the consent and Data Principal rights side of India's Act. A breach engages both: that module holds the consent and rights position, this one carries the clocks.
A note on the instruments
Every deadline here was checked against the instrument itself rather than against commentary, and that repeatedly mattered:
- The seventy-two hours usually attributed to the DPDP Act appear nowhere in it. They are in rule 7(2)(b) of the Rules, and the duty is staged rather than single.
- The penalty figures widely quoted for the CERT-In directions appear nowhere in them. The directions say only that non-compliance "may invite punitive action under sub-section (7) of the section 70B of the IT Act, 2000 and other laws as applicable". No figures are reproduced in this module.
- The GDPR seventy-two hours are qualified. The duty is to notify "without undue delay and, where feasible, not later than 72 hours", and a later notification is permitted if accompanied by reasons for the delay. Article 33 also excuses notification where the breach is unlikely to result in a risk, which the Indian regimes do not.
Verify anything load-bearing against the instruments rather than against summaries, including this one.
Project information
- Project categories: Security
- Created by vinodkannan18 on , updated
This project is not covered by the security advisory policy.
Use at your own risk! It may have publicly disclosed vulnerabilities.
Releases
GitLab CI, a clearer module description and internal cleanups. No database update from alpha3.
