The clock starts when the incident does, not when someone remembers.
DORA, NIS2 and RGPD all give you a deadline measured in hours. mlab IR calculates them at classification time and shows you what is overdue, so the notification is a task rather than a discovery.
Assign a framework, get the calendar
Mark an incident as falling under a framework and every notification it requires is created with its deadline already computed. Overdue ones surface on the dashboard.
| Framework | Reference | Notifications created | Sent to |
|---|---|---|---|
| DORA | Art. 19 | Initial 4hIntermediate 72hFinal 30d | Competent authority |
| NIS2 | Art. 23 | Early warning 24hIntermediate 72hFinal 30d | Authority and CSIRT |
| RGPD | Art. 33 | Notification 72h | Supervisory authority |
| RGPD | Art. 34 | Data subjects | Affected people, when the risk is high |
Your authorities, configured once
Regulatory authorities are set per organisation, so a French entity notifies CNIL and CERT-FR while a subsidiary elsewhere notifies its own. The framework decides the deadline, you decide the recipient.
Content and send status
Each notification holds its own draft and records whether it was sent and when. The evidence that you notified in time is the record itself, not a mailbox search.
Major incident designation
DORA Art. 13 designation is explicit on the incident, alongside category, attack vector and root cause, so the classification that triggers the obligation is auditable.
The export the auditor asks for
ICT incident register
DORA Art. 17(3). Every incident with its classification, costs, RGPD fields and notification history, exported as JSON or CSV. Not a screenshot of a dashboard.
RGPD violations register
Art. 33(5). Filtered to incidents that involved personal data, with data subject counts, categories, DPO notification and the risk assessment.
Immutable activity log
Append-only in ClickHouse, two-year default retention, configurable from 30 to 3 650 days. Every action, every actor, every timestamp, exportable.
Case reports
A printable dossier at /c/report/<uuid>, or a PDF through the API. It carries the timeline, the observables, the evidence list and the service level actually achieved.
Controls, and where they live in the product
A control is only met when someone can point at the artefact. Here is the artefact.
| Control | Where it lives |
|---|---|
| A.5.7 | Risk register: likelihood and impact on a 1-5 scale, auto-calculated level, owner, treatment plan, and a link from a risk to the incident that proved it real. |
| A.5.10 | TLP classification on incidents, cases and observables, with optional enforcement. TLP RED restricts a record to its commander, its responders and admins. |
| A.5.24 | Response plans: versioned documents with a review interval, a next-review date and an overdue indicator. Marking one reviewed increments the version and archives the previous one. |
| A.5.28 | Chain of custody: SHA-256 and MD5 computed at upload, UUID-based storage, and an audit trail on every evidence item. |
| A.8.32 | Change management references on post-incident action items: the change request id and its URL, so a lesson learned ends in a tracked change. |
| ISO 27035 | Incident lifecycle across the five NIST phases, post-incident reviews scored per phase, and an emergency contact list for internal and external parties. |
Lessons learned, with a due date
Hot and cold
A hot review runs on a five-day clock while memory is fresh. A cold review runs at 180 days, when you can see whether anything actually changed.
Scored per phase
Identification, containment, eradication, recovery and lessons learned each get a 1 to 10 score, plus what worked, what failed and a recurrence risk analysis.
Action items that close
Category, priority, assignee, due date and a change request reference. Anonymous feedback is collected per review, because the honest answer is rarely the attributed one.
Show your auditor the register, not the spreadsheet.
Free tier is fully featured. The monthly caps are the only difference.